Re: About carring information in the next header value

[Erik Nordmark <Erik.Nordmark@sun.com>]

> SIM uses two new next header values
> The next header format for these two values is the same, since the 
> different values are only 
> used to encode the rewrite ok bit, is this correct?

That is what the draft says. But in SIM the "no rewrite" value might only be
needed for the "no context" error message (to ensure that the locators
used in the error match the locators in the offending packet).
And it might even be possible to avoid this.

> Question, where is this next header placed in the chain of extension 
> headers?

The draft says immediately after any hbh or routing header.

For compability with existing IPv6 routers I don't see how the header
can be placed before those headers.

> The other issue with new extension headers is that host must discard 
> unknown extension headers.
> This may be a problem for the interaction between M6 hosts and legacy 
> hosts,

Not an issue as the draft is written. Only destinations which have one of
the new "ID" records in the DNS would receive M6 headers.
And for the responding end which didn't do a DNS lookup, it will
only send M6 packets if it has received an M6 packet from the peer.


> Anyway, i guess the most efficient option is the one presented in noid, 
> that uses the nextheader 
> and the flow label fields to carry the inforamtion in data packets.
> I have a doubt about how the next header values are defined.
> My first question is: do you define 2 values of next header for the  
> every ulp protocol, 
> covering the rewrite ok set and the rewrite ok not set, is this correct?

Two for each common protocol that is likely to benefit from/use multihoming
support.

> So you are not defining two values for the values of next header that 
> define an extension header,
> like routing header, hop by hop, etc. why is that, is becasue there are 
> not enough next 
> header values?
> the problem with doing so, is that when an extension header is 
> included, the site exit routers 
> will have to parse all the extension headers until they find the ulp 
> next header. Wouldn't this 
> be a problem for efficiency? Perhaps this is not a very common case, 
> though. 

Folks can argue whether such inefficiency is better or worse than the
inefficiency in SIM of including an extra 8 byte header in every packet.
That is one piece of the tradeoffs.

> Addtionally, I guess that you would like to preserve the values 
> currently defined for ulp, at 
> least fot compatibility with legacy hosts, but i am not sure if this is 
> accomplished now as 
> currently defined in section 6 of the noid doc.

NOID doesn't redefine e.g. the nexthdr value for TCP.
It does define two new values for
	TCP over M6 with rewrite ok
	TCP over M6 without rewrite ok

> I guess it would make more sense to define currently assigned ULP 
> values to the case when 
> the rewrite bit is not set, since legacy host would not recognize 
> packets with modifed locators.

That isn't sufficient since you need to carry not only the "rewrite ok"
logical bit in the packet but also the "packet is using M6".
Thus to encode this in the nexthdr field you need the existing
protocol number assignment plus two more values for each common protocol.

> So my conclusion is that in order to ensure bacward compatibility and 
> efficiency:
> Initial packets should carry M6 information in a new destination option.

Makes no sense to me since there is another mechanism to tell whether
the peer supports M6 - the DNS record.

> Initial packets carry next headers values for ULP as currenlty defined
> following packets that use the M6 protocol carry the tag information in 
> the flow label value and
> encode the rewrite bit in newly defined ULP next header values (and no 
> extension header)

That doesn't tell the receiver whether the sender supports the M6 protocol.
Thus the receiver would end up triggering M6 processing (sending
a context request in NOID etc) even if the sender doesn't support M6.

   Erik