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

Fernando Gont <> Mon, 10 February 2014 14:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D11141A0846 for <>; Mon, 10 Feb 2014 06:46:01 -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 xZSXmlpqmsPU for <>; Mon, 10 Feb 2014 06:45:55 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 7828C1A02E1 for <>; Mon, 10 Feb 2014 06:45:55 -0800 (PST)
Received: from [2001:5c0:1000:a::81f] by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WCs7N-0004Ij-04; Mon, 10 Feb 2014 15:45:53 +0100
Message-ID: <>
Date: Mon, 10 Feb 2014 11:45:36 -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: RJ Atkinson <>,
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
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: Mon, 10 Feb 2014 14:46:02 -0000

Hi, Ran,

On 02/10/2014 10:54 AM, RJ Atkinson wrote:
> I agree with Thomas Narten's analysis.  
> The deployed situation perhaps isn't ideal, but the IETF ought to  
> hew to the deployed reality.

FIWIW, that's the bottom-line of my reasoning.

> Today's reality is that the Internet 
> is very unlikely to deploy any new transport protocol(s) or any new 
> IPv6 extension headers.  My own preference (has been and) would be 
> to outright ban all new IPv6 Extension Headers -- insisting that 
> future IPv6 extensions be specified as options within the existing 
> Destination Options header or Hop-by-Hop Options header.

That's certainly among the options -- and is an acceptable outcome: if
you receive a packet that has an unrecognized next header, treat it as a
new transport protocol (and probably drop it).

But we currently assume that there might be new extensions, and that we
can parse unrecognized headers -- which we cannot.


I fully agree with all your observations.

> Few, if any, IP firewalls support SCTP at present.  Ditto for NORM,
> although NORM can traverse some firewalls because NORM usually runs
> over UDP.  I'm not certain why SCTP has little or no deployment,

Apparently, there's a fair share of SCTP deployment, albeit not for
public Internet services. And, in many cases, SCTP is being encapsulated
on top of UDP.

> My perception is that this ship sailed several years ago, and that it
> is either impossible or nearly impossible to deploy any new IPv6
> Extension Header (although IPv6 options carried in existing headers
> still seem possible) or any new transport-layer protocol using different
> framing from TCP/UDP.

FWIW, Extension Headers seem to be widely dropped. See e.g.:
(Tim Chown has obtained similar results). However, we still need to
determine when in the network such packet drops happen.

What I would expect is that:

1) We clarify that despite RFC 6465, no middle-box can parse
unrecognized Next Headers. i.e., no middle-box could parse a new
Extension Header, unless the middle-box explicitly supports it.
Then, we either provide a way for them to parse unknown headers (as in
our UEH I-D), or ban new extension headers once and for all -- and we
forget about this.

2) Even with the current data, it seems that employing extension headers
for protocol extensions is not really a viable option in the real world.
That is, if we were to specify a new option (even if it is to be
included in a Dst Options header), that would lead to packet drops
(rather than "ignore the extensions/options"). The conclusion would be
that, for the general case, "think twice before relying on Ext Headers,
then don't". And this should be documented, so that any protocol design
that means to use EHs is aware of the fact that it probably won't work
as expected in the deployed world.

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1