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

Fernando Gont <> Thu, 06 February 2014 12:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6CBCA1A03AF for <>; Thu, 6 Feb 2014 04:47:16 -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 741BWpl-8JjE for <>; Thu, 6 Feb 2014 04:47:13 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id A59EE1A00F5 for <>; Thu, 6 Feb 2014 04:47:13 -0800 (PST)
Received: from [2001:5c0:1400:a::be3] by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WBOM8-0006yR-9v; Thu, 06 Feb 2014 13:47:00 +0100
Message-ID: <>
Date: Thu, 06 Feb 2014 09:44:16 -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: Thomas Narten <>
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: "C. M. Heard" <>, Tim Chown <>, "" <>, Suresh Krishnan <>
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: Thu, 06 Feb 2014 12:47:16 -0000

Hi, Thomas,

On 02/06/2014 09:21 AM, Thomas Narten wrote:
>> 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.
> But we are already there. Folk won't deploy anything other than
> TCP/UDP because NAT won't deal with it. That has already been reality
> and is the reason that other or new transport protocols appear to be
> virtually undeployable today.

Well, IPv6 *might* give a fresh start in this respect -- there *might*
be IPv6 NAT.. but not necessarily. So.. while the end result might be
the same, it need not.

I don't think we have widespread deployment of IPv6 NAT ("as we know it"
for IPv4), nor that we have such a large/massive deployment of IPv6 that
we can argue "the cat is out of the box".

In any case, I believe this is a discussion to be had. There has been a
lot of work around fragmentation and extension headers, with the more
conservative folks still hoping that EHs are usable on the public
Internet, and the other folks wishing EHs and fragmentation go away
(and, well, actually making that happen by blocking them).

So there seems to be a disconnect between what we expect the IPv6
Internet to be, and how it is being shaped (and is) in practice.

IMHO, we should either accept what's becoming more and more of a fact
(EHs and fragmentation being massively dropped on the public Internet;
<>), or
try to do something to make them usable (after all, we're not planning
for IPv7 anytime soon).

All the above aside, the uniform format in RFC6465 cannot really work as
specified. So it looks like, at the very least, a "please ignore section
X of this document" is warranted... and/or a clear statement that we
have abandoned the possibility of standardizing any new transport
protocols (well, unless we encapsulate them over an existing one).



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