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

Fernando Gont <> Wed, 05 February 2014 04:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C93F1A0021 for <>; Tue, 4 Feb 2014 20:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2xC_AR2ng_ud for <>; Tue, 4 Feb 2014 20:26:23 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 966921A0020 for <>; Tue, 4 Feb 2014 20:26:23 -0800 (PST)
Received: from [2001:5c0:1000:a::d7f] by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WAu41-0000tY-LR; Wed, 05 Feb 2014 05:26:17 +0100
Message-ID: <>
Date: Wed, 05 Feb 2014 01:25:03 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Suresh Krishnan <>, "" <>, "Will Liu (Shucheng)" <>, "C. M. Heard" <>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Tim Chown <>
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:26:26 -0000

Hi, Suresh,

Thanks so much for your response! Please find my comments in-line...

On 02/05/2014 01:06 AM, Suresh Krishnan wrote:
> "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"

Short version of my response :-) :

This seems to have happened two/three years ago... so it might be
worthwhile to revisit that decision. In particular:

1) If this problem remains un-addressed, then it's impossible to
differentiate between new upper-layer headers (e.g. a new transport
protocol) and new extension headers. Since such new extension headers
might be leveraged for malicious purposes, the end-result is that
middle-boxes are going to block *everything* (see RFC7045), which means:

  + no new extension headers
  + no new transport protocols

... so I think we really don't want to go there.

2) Among the possible ways to solve this problem is to just use *a
single* Next Header value -- which turns out how we both tried to solve
separately (which is probably an indication that that's a sensible way
to do it ;-) ). It doesn't seem too onerous to use a single Next Header
value... particularly when the alternative is to implicitly waste all
possible Next Header values (see above).

3) We really want to make the extension headers "workable" (RFC7045).
Current stats seem to indicate that they are being massively dropped in
the public Internet (see e.g.
.. and Tim Chown's research show similar numbers). We either do
something about it.. or else we'll have to completey forget about ext

> But unfortunately, it turns out that this was not really a problem the
> WG wanted to solve with RFC6564 :-). 


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

The problem here is that unless we do something now, in the event
someone needs to define a new extension header (or transport protocol!),
it simply won't be possible.

So, by doing nothing, we kind of are implicitly saying "No new extension
headers, and no new transport protocols".  *That's* really premature.


Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492