Re: Extension header vs destiantion option

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 26-apr-2005, at 13:10, Pekka Savola wrote:

> Destination options can be placed before routing, fragment or AH/ 
> ESP headers (see RFC2460 section 4.1), so this is not an issue.

But with the following caveat:

           note 1: for options to be processed by the first destination
                   that appears in the IPv6 Destination Address field
                   plus subsequent destinations listed in the Routing
                   header.

> The issue about different destination options inside the  
> destionation options header may be worth considering, though.  I  
> think there may be other issues stemming over from MIPv6 security  
> design as well. (Like, does the shim6 stuff need to be used as  
> IPsec selectors, which might be challenging for dest options.)

I think the main reason to make it a destination option rather than a  
header of its own is that a single destination option header can hold  
more than one destination option so you save some space if the  
options are small. However, there is also a penalty because of the  
additional layering, so the savings will only be in the order of a  
couple of bytes IF there is another destination option.

I'm starting to think along what you said in a previous message,  
where an option could be used when it's necessary, but it's left out  
when it can be optimized away. Since potentially, this is in almost  
all cases (i.e., the only time this can't be done is when using  
different ULIDs with overlapping locator sets towards the same host  
with an overlapping flow label and a higher-layer protocol that  
doesn't support port numbers or an SA.), there shouldn't be any long- 
term adverse effects of having an option but ONLY if the receiver can  
force the sender to omit the option when the receiver doesn't need  
it. This would allow for simple implementations at first and more  
advanced ones (after some real-world experience) later.

The identifier in such an option would ideally be a set of indexes  
pointing to:

- the shim6 state (= the association between the two hosts)
- the source ULID
- the destination ULID

Something like this could easily be encoded in 16+4+4 to 32+8+8 bits.

The destination host would tell the source host which shim6 state  
index to use (this value would remain constant as long as the  
association persists) and an ordered list of locators would be  
exchanged so they can be referenced by an index from there on.

Then there would have to be an "applicability statement" from the  
destination to the source, which can include a set of options like:

- never use the option (= locators for different ULIDs don't overlap)
- don't use the option for TCP and UDP (= I'll demux on port numbers)
- don't use the option for IPsec (= I'll demux on SA)
- don't use the option when flow label is known to be unique enough  
(= I'll demux on flow label)

If none of these is selected all packets where the shim has replaced  
addresses will have the option. Support for the first three would be  
mandatory, so including the option anyway would lead to an error. The  
last depends on how smart the source is about assigning flow labels  
so setting the option when the flow labels are in fact unique  
wouldn't lead to an error.

I think it makes sense to have the shim negotiation, demux and  
reachability test all rolled up into a shim extension header. Having  
all these as destination options would use up a lot of destination  
option number space and make identifying the shim harder, along with  
potential issues with ordering and coexistance with other destination  
options.

The advantage of having a header rather than use UDP (TCP isn't  
suitable) is that the header can either exist as its own packet or  
live between the IP header and payload. In IPv4, UDP would have a big  
advantage that it can traverse NAT and firewalls, but to the chagrin  
of some we're assuming no NAT in IPv6 and bang-for-your-buck ratio of  
working around firewalls would quickly deteriorate to below zero in  
the long term, and is arguably the wrong thing to do anyway.

Ok, going off the deep end now:

With a demux option present and having site-wide agreement on at  
least part of the list of source address prefixes, it would be easy  
to add a field that indicates that routers can safely rewrite source  
addresses.

Even deeper: if we apply some header compression on the subsequent  
headers we may even be able to compress the TCP/UDP/RTP header away  
for most packets    , so rather than making the packet 8 bytes  
longer, we're making it 12 bytes shorter (for TCP)! Now we're getting  
somewhere.  :-)