About carring information in the next header value

[<mbagnulo@ing.uc3m.es>]

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?
Question, where is this next header placed in the chain of extension 
headers?
I guess that since routers must look for it when deciding whehter to 
rewrite or 
not a source address it would make it more efficient to place it in the 
first place, even before 
hop by hop options. But if this is so, wouldn't this be a problem to 
process hop by hop options?
The other options would be to place next to destination option header, 
where i guess is the 
right place for it, but in this case, the site exit routers would have 
to look over the 
extension header to find out whehter they should rewrite a source 
address or not.

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, since the 
first packet would be discarded, and the way to find this out is the 
recpetiuon of icmp packet. 
Considering the potential wide deployment of ICMP filtering, this may 
lead to importat delay 
when establishing communications between m6 hosts and legacy hosts.

Perhaps an option would be to use a Destination option instead of an 
extension header.
This would allow to define the way the detination option would be 
processed by the legacy host, 
for instance, it can be defined that the host shoudl process the packet 
and just skip the 
unknown option. This would allow to process the initial packet and also 
to obtain a more 
reliable feedback of the capabilities of the target host.
The problem with this aproach is that it is not possible to encode the 
rewrite ok 
in the main IPv6 header using destiantion options. However, this could 
be encoded inside 
the destiantion option itself.
Note that if only the destiantion option is present in the packet, the 
bit encoding rewrite 
ok is in a fixed location and while it is not in the main ipv6 header, 
it should be easy to 
find by the exit routers, i guess.
If there are more extension headers in the packet, router will have to 
parse the extension 
header chain in both cases is guess, so i don't see much benefits in 
this case.

The other option is could be the following (i am not sure this would 
work though, i still don't
understand SIM very well:-(
Use a destiantion option in initial packets. If i understand correctly, 
initial packets 
are those whose source address cannot be rewritten. Also those iniotial 
packets are the one that
are used to define if the target node supports M6 or not
Then if the target node supports M6 and once that the context has been 
created, start using 
the new extension header. This extension header means that the rewrite 
ok bit is set.

So this option has most of the benefits i guess:
It allows the detection of M6 support at the target node without 
discarding the first packet and
obtaining a reliable answer (no icmp involved)
It allows a easy access to rewrite ok bit by the site exit routers when 
it is needed (not the inital 
packets)
It don't wastes two next header values

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?
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. 
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.
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.

So my conclusion is that in order to ensure bacward compatibility and 
efficiency:
Initial packets should carry M6 information in a new destination option.
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)

Does this makes sense?
 
Thanks, marcelo