Re: A problem with RFC 6465's Uniform Format for Extension Headers
"C. M. Heard" <heard@pobox.com> Wed, 12 February 2014 06:42 UTC
Return-Path: <heard@pobox.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49C21A0815 for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2014 22:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmrV-l9z-H1J for <ipv6@ietfa.amsl.com>; Tue, 11 Feb 2014 22:42:08 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5311A07FF for <6man@ietf.org>; Tue, 11 Feb 2014 22:42:07 -0800 (PST)
Received: (qmail 1615 invoked from network); 11 Feb 2014 22:42:05 -0800
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net 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" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: 6MAN <6man@ietf.org>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
In-Reply-To: <52F804B3.5040803@gmail.com>
Message-ID: <Pine.LNX.4.64.1402110903580.20313@shell4.bayarea.net>
References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <CAFU7BATrYRsNJ7D4AJSy62XobNaGDgW-zTvX=yrqZea-Q67YPA@mail.gmail.com> <52F13D1D.9050800@gont.com.ar> <Pine.LNX.4.64.1402090915000.27591@shell4.bayarea.net> <52F804B3.5040803@gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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 > 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
- A problem with RFC 6465's Uniform Format for Exte… Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Hagen Paul Pfeifer
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Hagen Paul Pfeifer
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Jen Linkova
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Suresh Krishnan
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Thomas Narten
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … brianjusa
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Randy Bush
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Randy Bush
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Karsten Thomann
- Re: A problem with RFC 6465's Uniform Format for … Hagen Paul Pfeifer
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Mark ZZZ Smith
- Re: A problem with RFC 6465's Uniform Format for … C. M. Heard
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … RJ Atkinson
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … RJ Atkinson
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: Re: A problem with RFC 6465's Uniform Format … Ray Hunter
- Re: A problem with RFC 6465's Uniform Format for … C. M. Heard
- Re: A problem with RFC 6465's Uniform Format for … Mark ZZZ Smith
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont
- Re: A problem with RFC 6465's Uniform Format for … Dan Lüdtke
- Re: A problem with RFC 6465's Uniform Format for … Mark ZZZ Smith
- Re: A problem with RFC 6465's Uniform Format for … Brian E Carpenter
- Re: A problem with RFC 6465's Uniform Format for … Fernando Gont