Re: Extension header vs destiantion option

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

marcelo bagnulo braun wrote:
> Hi,
>
> I guess we also need to understand the differences between using a new 
> SHIM extension header to carry the context tag or use a new Destination 
> option for carrying it.
>
> We have discussed this issue in the design team, and as far as i 
> remember. people that were involved in the design on MIPv6 argued for 
> using a new extension header rather than using a destination option. The 
> reasons for that, AFAIU, are the problems that appeared when using the 
> destination option. These were basically due to the fact that 
> Destination options are no ordered within the Destination Option 
> extension header. This result that it is not clear how to build the 
> destination option header, and that since the context tag determines if 
> the addresses are rewritten, then the resulting behavior may be affected 
> depending on the order in which destination options are placed.
> In addition there is the issue brought by Iljitsch, about the 
> destination option header being processed after the IPSec related 
> header. This seems to be in opposition with the architecture of the 
> shim, where the shim resides below the IPsec.
> However, if a new extension header is used, then the order is perfectly 
> defined and could be placed properly w.r.t. IPSec.
>
> I guess that Erik or Jari could expand on this topic, but AFAIU, we 
> should consider a new Extension header rather than a Destiantion option.

At a high enough level of abstraction an extension header and a 
destination option are isomorphic; they both provide a bit bucket into 
which we can stuff a context tag. But there are several details that 
might be important.

A destination option would be the ideal answer if we want to be able to 
send it to nodes that might not implement shim6, because the option code 
 has bits to describe what such a receiver should do (ignore option, 
drop pkt, drop pkt and send ICMP error, etc).
Also, if there is a reasonable probability that multiple small 
destination options be used at the same time, then the fact that they 
can be more densely packed into a single destination options header 
might matter.

However, if there is no need for multiple options at the same time, the 
destination options approach has higher overhead than a separate 
extension header. A destination options header has a nxthdr and length 
field, plus the option needing a type and length. Thus a minimum size 
destination options header of 8 bytes can only carry 4 bytes of data.
A new extension header only have the nxthdr and length field, thus can 
carry two more bytes of useful data.

The more complex issues have to do with all what we went through in the 
Mobile IPv6 discussion (and in the interest of full disclosure, I think 
that using the destination options header for the MIPv6 Home address 
option was a mistake, but more about that later).

The issues that appeared (as I recall) were due to (not a complete list 
I suspect):
1. extension header ordering and whether or not there can be one, two, 
or more destination options headers
2. semantics of the destination options header and IPsec (recall that 
MIPv6 rides above IPsec, and the plan for shim6 is to sit below IPsec)
3. implementation issues around sharing the same destination options 
header when there are multiple sources of the options (some being set by 
the application, others being added by the MIPv6 code in the stack)

There's already been some emails on #1 on the shim6 list.

The hard issues in #2 came from the fact that the MIPv6 Home Address 
Option is defined to perform an address transformation (semantically it 
swaps the home address with the care of address in the IPv6 destination 
field). Given that IPsec policies typically care about IP addresses and 
IPsec SADBs use IP addresses as keys for lookup, this makes things a bit 
hairy. (But the MIP6 WG managed to figure things out in the end.)

I don't know to what extent #3 has been solved. It might be a very real 
issue if shim6 will use a destination option, *and* that option needs to 
go in the same destination options header as the home address option.
(But if the result would be that shim6 would have an additional, 
separate destination options header, this issue can be avoided.)

The fact that MIPv6 has taken the destination options header to perform 
*its* address transformation, and we need shim6 to carry bits which 
affect *its* address transformation, means that we need very 
well-defined ordering between the two if we want a chance of them 
co-existing for the same packet.
It is probably harder to do that if they share the same destination 
options header.
Furthermore, since the shim sits below IPsec and MIPv6 sits above IPsec, 
then, at least when IPsec will be used, we will end up with two separate 
destination options header. Thus any byte savings packing the options 
together in the same header will not appear.

As far as I know, we do not need the destination options capability to 
control what a receiver, which doesn't implement shim6, will do with the 
packet, because before applying shim6 to the data packets there will be 
a context setup exchange between the endpoints, which will detect when 
the peer doesn't implement shim6.

In summary, to me it seems like, if we are not going to use the flow 
label as a context tag, we might as well do a separate extension header. 
The destination option approach seems to have a lot more complexity than 
the new extension header and close to zero benefits.

    Erik