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

"C. M. Heard" <> Wed, 12 February 2014 06:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B49C21A0815 for <>; Tue, 11 Feb 2014 22:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OmrV-l9z-H1J for <>; Tue, 11 Feb 2014 22:42:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0E5311A07FF for <>; Tue, 11 Feb 2014 22:42:07 -0800 (PST)
Received: (qmail 1615 invoked from network); 11 Feb 2014 22:42:05 -0800
Received: from ( by with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Feb 2014 22:42:05 -0800
Date: Tue, 11 Feb 2014 22:42:05 -0800
From: "C. M. Heard" <>
To: 6MAN <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Feb 2014 06:42:10 -0000

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
> 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.


Mike Heard