Re: A problem with RFC 6465's Uniform Format for Extension Headers

[Brian E Carpenter <[e-mail]>]

Mike,

You ended this message with

> Thoughts?

I think your analysis is pretty much spot on. Maybe the best we
can do is:

a) State that new requirements SHOULD be defined as payloads.

b) If not, they MUST be defined as options unless there is an
unavoidable technical reason that they can't be. That doesn't
seem to be significantly different from saying that they MUST
be sub-options of a new generic header. In any case, firewalls
will want to parse these options.

BTW, RFC6564 already says this at SHOULD level.

c) Re-iterate that RFC6564 requires a uniform format.

d) Re-iterate that RFC7045 requires middleboxes to handle
all defined extension headers.

Note that a) above is the only really new thing here. But if
d) is implemented, middleboxes can find the payload, and
if a) and b) are implemented, there will not be any new
extensions except in extreme circumstances.

BTW, the subject of this thread has been wrong from the start:
s/6465/6564/. I didn't correct it because of threaded mail
readers.

Regards
   Brian

On 12/02/2014 19:42, C. M. Heard wrote:
> On Mon, 10 Feb 2014, Brian E Carpenter wrote:
>> On 10/02/2014 08:35, C. M. Heard wrote:
>> ...
>>> In the absence of a strong argument to the contrary, it seems to me 
>>> that the existing Destination Options header can be used to do 
>>> exactly the same thing as the proposed UEH.  In other words, I agree 
>>> with Jen's comments.
>> I think we should carry out a thought experiment: consider each
>> of the existing extension headers, listed in RFC 7045 and at
>> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
>> and see which of them could or could not be encoded as
>> destination options.
>>
>> For some of them the answer is obvious, of course. But the others would
>> give us an idea whether the 'option' option has enough flexibility.
> 
> That is a good idea and I am going to take a stab at it.  In looking 
> over the references for the existing extension headers listed in RFC 
> 7045 and in the above-referenced IANA registry it appears to me that 
> the order in which headers other than experimental use headers 253 
> and 254 should appear is as follows (this is an update of RFC 2460 
> Section 4.1):
> 
> IPv6 header
> Hop-by-Hop Options header
> Destination Options header (note 1)
> Routing header
> Shim6 header
> Fragment header
> Authentication header (note 2)
> Encapsulating Security Payload header (note 2)
> Destination Options header (note 3)
> Mobility Header or Host Identity header (note 4)
> upper-layer header
> 
> 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.
> 
> note 2: additional recommendations regarding the relative
>         order of the Authentication and Encapsulating Security 
>         Payload headers are given in [RFC-2406].
> 
> note 3: for options to be processed only by the final
>         destination of the packet.
> 
> note 4: at present, these headers are required to contain
>         No Next Header, so an upper-layer header will not follow 
>         these headers.
> 
> To see if the 'option' option has enough flexibility, let's consider 
> each header in turn to see whether it could reasonably be replaced 
> by one of the following:
> 
> - hop-by-hop option
> - destination option
> - upper-layer header
> 
> or (for the three kinds of headers listed above) how the rules for 
> usage would be changed by a ban on new IPv6 extension headers.
> 
> This is a bit more general question than the one posed by Brian 
> Carpenter, but I think it's the right way to go when determining 
> whether a ban on new extension headers would limit flexibility.
> 
> Hop-by-Hop Options header: this header is needed to clearly 
> distinguish hop-by-hop and destination options.  It is (and always 
> has been) the only means to include optional IPv6 data with 
> hop-by-hop semantics.  A ban on new extension headers would not 
> change this.
> 
> Destination Options header: this header is needed to clearly 
> distinguish hop-by-hop and destination options.  Using a destination 
> option in place of an extension header could require that this 
> header be allowed to appear more than twice in the IPv6 header chain 
> or introduce constraints regarding the order in which destination 
> options would be allowed to appear.
> 
> Routing header: IPv4 provides an existence proof that this extension 
> header could be replaced by a destination option.  Such an option 
> would be carried in a Destination Options header immediately 
> following the Hop-by-Hop Options header if present or the IPv6 
> header otherwise.
> 
> Shim6 header: as far as I can tell, the situation is exactly the 
> same as for the Routing header.  In cases where an IPv6 packet 
> contains only Shim6 control information and no ULP data, the Next 
> Header value of the containing Destination Options header would be 
> No Next Header.
> 
> Fragment header: it is my assessment that while it might be possible 
> to make this into a destination option, that would add a good deal 
> of awkwardness to an already awkward and error-prone function.  On 
> that basis I would say that using an extension header was justified 
> in this case.
> 
> Authentication header: it certainly would be possible to encode the 
> equivalent information into a destination option, but because of the 
> fact that the authentication is done prior to fragmentation or after 
> reassembly it would be necessary to allow a separate Destination 
> Option header to appear where the Authentication header now appears.  
> However, since AH is used for both IPv4 and IPv6, that would not 
> have been a good engineering choice, and I would say that using an 
> extension header was justified in this case.
> 
> Encapsulating Security Payload header: as noted in RFC 4303, "in the 
> IPv6 context, ESP is viewed as an end-to-end payload," and we treat 
> is as such when determining where an IPv6 header chain ends.  It 
> would not make sense to replace it with a destination option, 
> but if the concept of an extension header did not exist, we would 
> just treat it as an upper-layer header that contains tunneled 
> encrypted data.
> 
> Mobility Header and Host Identity header:  unless I am missing 
> something, these are used to carry control messages and always 
> have a Next Header value of No Next Header, allowing some 
> future flexibility to include piggybacked data in a standard 
> way.  As far as I am able to tell, exactly the same goal could 
> be achieved by defining these as upper-layer protocol headers.
> 
> Experimental Use headers (protocol numbers 253 and 254): since 
> these could be either extension headers or transport protocols 
> per then whim of the experimenter, there is no defined function 
> to evaluate.  However, if we go with the 'option' option, these 
> would turn into experimental upper-layer headers, and the 
> experimental-use options would be used for experiments that 
> wanted to "sandwich" optional data into an IPv6 header.
> 
> Thoughts?
> 
> Mike Heard
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>