RE: About carring information in the next header value

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

I apologize for the format of this email (i was using a different email
client and things went wrong, sorry)
I send it again with a better format (i hope)
Regards, marcelo


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