[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label versus Extension header - protocol itself

Francis Dupont wrote: 
 In your previous mail you wrote:

Dealing with the same header for different purposes in different places in the header sequence doesn't make an implementation easier.

=> the price has been already paid for Mobile IPv6... 

Yes, but that doesn't mean we want to pay again for shim6.

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.
=> note this check will be needed by an extension header too.

I don't think so. The receiver can be liberal in what it accepts when it comes to the order of extension headers. The only exception is ESP and AH which might want to, for security as opposed to functionality reasons, check what extension headers are before and/or after.

and the additional 2 byte overhead for destination options 

=> there will be no real overhead if the proposed extension header
will be 8 byte aligned and the tag length a power of two.

In any case the minimum thing we can add to e.g. a IPv6+TCP packet, is an 8 byte extension header; doesn't matter whether this is a destinations options header or a "shim6" header.
But the overhead is due to the destination options header implying an extra 16 bits for the option type and length. Thus a minimum size destination options header would be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option Type | Opt Data Len |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

    |       32 bit option value = shim6 payload                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Whereas with a separate extension header the minimum is
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 

    |       48 bit option value = shim6 payload                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hence the destination option approach has 16 bit more overhead.
The criticality of this depends on how big we need the shim6 payload to be. The "firewall uniformity" argument implies that we want to use the same approach for the shim6 control messages and the data messages.
Thus we need a "message type" field.
And we need a context tag. Some people has expressed that they think that 20 bits is too little; not clear to me how many context we want one host to be able to support.
I hope we can design the state management so that the shim6 payload doesn't need to carry its own checksum.

But in any case, this is just one of the items to consider when comparing the destinations options approach with an extension header approach.

=> how do you address my concern about new extension header handling
(BTW more not handling :-) by classifiers/filters/etc?

There are actually two potential issues in here: implementation and policy.
1. Current classifiers/filters etc would not have code that can deal with either a new shim6 destination option, or a new shim6 extension header. Thus for classifiers/filters in firewalls and elsewhere to be able to make decisions about the content, there would need to be new code written in either case. With an extension header approach there would also need to be code to find the next extension header, but given that we can design the extension header to have the type/len in the same place as other headers this change is trivial compared to the other necessary changes.

2. Existing (and future) IPv6 firewalls might have various policies that allow or block packets with destination options header independent of content, or allow or block such packets based on the actual options.

I suspect that the firewall mindset is that "anything unknown should be dropped", but I don't know what policies folks currently operate with.
It does seem odd to have a firewall policy which allows destination options independent of the options contained therein, so I would not assume that a shim6 destination option can silently sneak by a firewall.

   Erik