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

Fernando Gont <> Mon, 10 February 2014 20:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C0FA71A046A for <>; Mon, 10 Feb 2014 12:34:44 -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 rF8zL24hGGfN for <>; Mon, 10 Feb 2014 12:34:43 -0800 (PST)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 32BC01A0410 for <>; Mon, 10 Feb 2014 12:34:40 -0800 (PST)
Received: from [2001:5c0:1000:a::81f] by with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WCxYt-0004E8-DK; Mon, 10 Feb 2014 21:34:39 +0100
Message-ID: <>
Date: Mon, 10 Feb 2014 17:27:39 -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 20:34:44 -0000

On 02/10/2014 05:07 PM, RJ Atkinson wrote:
> I don't think that draft-gont-6man-ipv6-universal-extension-header
> is worth any time investment, because it can't change the deployed 
> operational behaviour.

FWIW, if anything, I care about middle-boxes being able to process the
entire IPv6 header chain, and differentiate between transport protocols
and ext headers. Among the possible ways to do this are:

1) Ban new ext headers once and for all, xor,

2) Do something like the UEH we specified, xor,

3) Reserve a range for the universal format in RFC 6465.

And if we do anything other than 3), possibly also clarify that the
section on the universal format in RFC 6465 is to be forgotten --
because quite a few of us got confused with it.

While I have my preference, any of the above 3 would work for me.

Now, if you ask what are my personal beliefs regarding deployability of
Ext Headers in the public Internet, my take would be "Forget it -- It
won't work".

> If we bother to do anything, we ought to just acknowledge reality
> and say that no more IPv6 extension *headers* are allowed.  Instead,
> options must be used.  We also should note that options with hop-by-hop
> behaviour likely cannot be deployed reliably across the global public
> Internet.  That would mean that any "new" NextHeader value would
> denote a transport-layer protocol (which I think also would be 
> very difficult to deploy - I have never seen SCTP on-the-wire).

For SCTP/IPv4, the reason for not seeing SCTP is probably NATs. -- Also,
neither Windows nor Linux support it AFAICT. While in IPv6 this could be
different, I expect firewalls that "only allow outgoing connections" to
be pretty common... so one way or another, they situation would not be
that different.

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