Re: Flow label versus Extension header - protocol itself

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

Francis Dupont wrote:

>    The trouble with a destination option is that you need to spend 8  
>    bytes so you get a 4 byte payload, and the possibility of having  
>    multiple destination options that need to be in different places in  
>    the protocol chain is just asking for nasty bugs.
>
> => so Mobile IPv6 should not work?

Part of the complexity with destinations options is that they can appear 
in multiple places. RFC 2460 says that this is the order an 
implementation must support:

           IPv6 header
           Hop-by-Hop Options header
           Destination Options header (note 1)
           Routing header
           Fragment header
           Authentication header (note 2)
           Encapsulating Security Payload header (note 2)
           Destination Options header (note 3)
           upper-layer header

Mobile IPv6 then added a need for a destination options header in a 3rd 
place; between the routing header and the fragment header in the above list.

Dealing with the same header for different purposes in different places 
in the header sequence doesn't make an implementation easier. So while 
this might be viewed as conceptually simple, and implementation needs to 
verify that a particular option (such as the MIPv6 one) is not present 
in the wrong "type" (aka "placement") of destination option.

To me this, and the additional 2 byte overhead for destination options 
compared to a new extension header, means that I rank a new extension 
header better than defining a new destination option.
But I still want to explore the hybrid receiver-based allocation of flow 
labels, that Greg suggested, more.

   Erik