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

Suresh Krishnan <> Wed, 05 February 2014 04:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 285431A0023 for <>; Tue, 4 Feb 2014 20:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tVX8-SLPzDWo for <>; Tue, 4 Feb 2014 20:06:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 555861A0021 for <>; Tue, 4 Feb 2014 20:06:46 -0800 (PST)
X-AuditID: c618062d-b7f858e0000031c7-19-52f1b8d13ce9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 12.0B.12743.1D8B1F25; Wed, 5 Feb 2014 05:06:41 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 4 Feb 2014 23:06:43 -0500
Message-ID: <>
Date: Tue, 04 Feb 2014 23:06:38 -0500
From: Suresh Krishnan <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Fernando Gont <>, "" <>, "Will Liu (Shucheng)" <>, "C. M. Heard" <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyuXRPuO7FHR+DDE6+MrZYueIuk8WTVW/Y LG7smcNisf3ie2YHFo+WI29ZPZYs+cnkcfGSsseHQz3sASxRXDYpqTmZZalF+nYJXBlz3/az FXxUrXiy/SJ7A2OrfBcjB4eEgInE5h8WXYycQKaYxIV769m6GLk4hASOMErsO7eGFSQhJLCF UaLzFjNIPa+AtsSyaeogYRYBFYmj3xvZQGw2oDEbdn5mArFFBcIk2i/MZAaxeQUEJU7OfMIC MlNEYD6jxN5r68EahAW8JS78vcEOMT9Z4kzLUrBmTgF9iQ8fF4PtZRawlbgw5zoLhC0vsf3t HGaIek2JrWu+s0IcrSjx4vhPpgmMgrOQ7JuFpH0WkvYFjMyrGDlKi1PLctONDDYxAgP3mASb 7g7GPS8tDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExTrPy//PN7/9p P2ZRsqqva3B92L4vX3T138WzL7LP8n+VLZX3bbLAPVtNtd+Tr3Oe535vMmfxxLVLPp3s2pkd tHbOtHBDPZYAE6ntxRuT74fsYNLa3895MOFHrlGECENH4PH4rxLW05fFuG8V/8iZw7xm+/bb queXvO5WefOv3/o6R7XFb3thJZbijERDLeai4kQAAkxsrioCAAA=
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, 05 Feb 2014 04:06:49 -0000

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:

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


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:
> <>
> 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:
> To: Fernando Gont <>, "Fernando Gont"
> <>, "Shucheng LIU (Will)" <>,
> Will (Shucheng) Liu <>
> 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:
> Status:
> Htmlized:
> 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
> The IETF Secretariat
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------