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

Hi Fernando,

Sorry for the long mail, but there is a lot of history here.

The short version is

"Yes we wanted to do this as well, but the WG didn't want to waste a 
protocol number for something that may never be used"

Now for the long version:

When we set out to work on what became RFC6564, this was the *exact* 
problem we set out to solve. e.g. If you look at 
draft-ietf-6man-exthdr-00 differentiating between unknown extension 
headers and unknown upper layer protocols was an explicit goal

"One key advantage of using such a generic IPv6 extension
  header is that it allows nodes to distinguish between unknown
  extension headers and unknown upper layer protocols, which was not
  possible earlier.  Another one is that this generic extension header
  conserves values in the IPv4 protocol numbers registry."

But unfortunately, it turns out that this was not really a problem the 
WG wanted to solve with RFC6564 :-). The documents that lead up to 
RFC6564 (draft-krishnan-ipv6-exthdr-*) and the first two versions of 
draft-ietf-6man-exthdr actually had this idea of an assigned code point 
all along. After WG adoption and subsequent discussion there was severe 
opposition to allocating a protocol number without knowing whether there 
will be any ipv6 extension headers ever defined in the future. The draft 
was changed in version -02 to not request an IANA codepoint anymore. 
Diffs are here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-exthdr-02.txt

I think Thomas Narten's comment summarized the wg feeling at the time 
the best.

"My general sense is that this work is mostly just good common sense
advice to someone who has a need to define a new extension type. But
until we see such a concrete proposal, I am not convinced (yet) that
we should define anything new that suggests people go change
implementations or allocate code points. Both are premature."

Thanks
Suresh

On 01/30/2014 08:02 PM, Fernando Gont wrote:
> Folks,
>
> Mike Heard noted that the Uniform Format specified in RFC 6465 can't
> possibly work.. and after giving some thought about it, it turns out
> that implementing it would hamper the deployment of new transport protocols.
>
> We've written a short I-D that discussed the problem, and that proposes
> an alternative, such that we achieve the same goal without possibly
> messing with our Transport friends. :-)
>
> The I-D is available at:
> <http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt>
>
> Thanks!
>
> Best regards,
> Fernando
>
>
>
>
> -------- Original Message --------
> Subject: New Version Notification for
> draft-gont-6man-ipv6-universal-extension-header-00.txt
> Date: Thu, 30 Jan 2014 15:07:40 -0800
> From: internet-drafts@ietf.org
> To: Fernando Gont <fgont@si6networks.com>, "Fernando Gont"
> <fgont@si6networks.com>, "Shucheng LIU (Will)" <liushucheng@huawei.com>,
> Will (Shucheng) Liu <liushucheng@huawei.com>
>
>
> A new version of I-D, draft-gont-6man-ipv6-universal-extension-header-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:		draft-gont-6man-ipv6-universal-extension-header
> Revision:	00
> Title:		IPv6 Universal Extension Header
> Document date:	2014-01-31
> Group:		Individual Submission
> Pages:		6
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-universal-extension-header/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-ipv6-universal-extension-header-00
>
>
> Abstract:
>     This document analyzes a problem in the Uniform Format for IPv6
>     Extension Headers specified in RFC 6564, which results in forwarding
>     nodes and middle-boxes not being able to process an IPv6 Header Chain
>     if it contains an unrecognized IPv6 Extension Header that follows the
>     aforementioned Uniform Format.  Additionally, it specifies a new IPv6
>     Extension Header - the Universal Extension Header - that overcomes
>     the aforementioned problem, and enables the extensibility of IPv6
>     without impairing middleboxes that need to process the entire IPv6
>     Header Chain.  Finally, this document formally updates RFC 6564
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>