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

Ray Hunter <> Tue, 11 February 2014 08:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D3F01A090E for <>; Tue, 11 Feb 2014 00:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o3nLy2qRdyyY for <>; Tue, 11 Feb 2014 00:56:02 -0800 (PST)
Received: from ( [IPv6:2001:470:1f14:62e::2]) by (Postfix) with ESMTP id 4730D1A0906 for <>; Tue, 11 Feb 2014 00:56:01 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AC10870073; Tue, 11 Feb 2014 09:55:59 +0100 (CET)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5feQoaWBXEjC; Tue, 11 Feb 2014 09:55:59 +0100 (CET)
Received: from Rays-iMac.local (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id 40C2D870070; Tue, 11 Feb 2014 09:55:59 +0100 (CET)
Message-ID: <>
Date: Tue, 11 Feb 2014 09:55:59 +0100
From: Ray Hunter <>
User-Agent: Postbox 3.0.9 (Macintosh/20140129)
MIME-Version: 1.0
To: "C. M. Heard" <>
Subject: Re: 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
Cc: Fernando Gont <>, 6MAN <>
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: Tue, 11 Feb 2014 08:56:04 -0000

C. M. Heard wrote:
> On Tue, 4 Feb 2014, Fernando Gont wrote:
>> On 02/04/2014 11:20 AM, Jen Linkova wrote:
>>> Somehow that proposed Universal Extension Header looks exactly like an
>>> Options Extension Header to me.
>>> Am I missing something? I'm trying to use my imagination but couldn't
>>> see any possible scenario when UEH would work and Options header would
>>> not.
> In an offline discussion with Fernando before his draft was submitted
> I made the following comments:
> | This seems technically sound and is probably what RFC 6564 should
> | have said in the first place.  However, playing devil's advocate,
> | let me ask if there is a reason why the Destination Options header
> | would not serve the same purpose as the universal extension header
> | [...], so long as that header is allowed to appear multiple times at
> | any position in between the Hop-By-Hop options header (if present)
> | and the Fragment Header or the upper layer header.
> In the absence of a strong argument to the contrary, it seems to me
> that the existing Destination Options header can be used to do
> exactly the same thing as the proposed UEH.  In other words, I agree
> with Jen's comments.
> Fernando went on to write:
>> Not sure what you mean.
>> But please let me provide an example:
>> Let's say that, tomorrow, the IETF standardizes the GTP (Google
>> Transport Protocol :-)), and it is assigned the Next Header value 0xFF
>> (I'm assuming this one is not currently assigned, bbut I'm not checking
>> the IANA registry right now).
>> Say a middle-box receives a packet that simply encapsulates GTP in IPv6,
>> and that middlebox does not yet support GTP. If the middle-box tries to
>> interpret the GTP header as in RFC6465, it will certainly fail.
>> The reason? -- RFC 6465 implicitly assumes that every new Next Header
>> will employ the RFC6465 format. This may be sensible for new *extension
>> headers*, but certainly not for new transport protocols.
>> And since transport protocols and extension headers share the same
>> namespace (see RFC7045), this is a problem.
> All this is true.  The implication is that the middlebox must stop
> parsing the header chain when it encounters an unknown Next Header.
> In more detail, I see the three cases:
> 1.) The middlebox encounters an ESP Next Header, signalling that an
>      encrypted payload follows.  In that case it stops parsing the
>      header chain and applies its policy for encrypted payloads.
> 2.) The middlebox encounters a Next Header corresponding to a known
>      transport protocol.  In that case it may perform filtering
>      actions specific to that transport protocol (and of course may
>      continue parsing into the transport header in order to do so).
> 3.) The middlebox encounters an unknown Next Header value.  In that
>      case it stops parsing the header chain and applies its policy
>      for packets with unknown Next Header values.  In order to comply
>      with RFC 7045, it MUST be possible to configure the policy to
>      allow such packets, but the default MAY be to drop them.  A
>      high-quality implementation would allow the policy to be
>      configured individually for each unknown Next Header value.
> I agree that there are use cases where it is important for a middlebox
> to clearly distinguish between an unknown extension header and an
> unknown transport protocol.  One is RA Guard: see

I agree with the above analysis for the current situation.

I think this draft is worth pursuing, to see if the decision tree can be 
extended to differentiate between an unknown IPv6 header, and an unknown 
upper layer header.

Some in the IETF seem to think that end to end encrypted tunnels are 
"the solution".

I think this just moves the battlefield: end users will insist that 
encrypted tunnels are terminated on a security device, which then 
inspects the packet, potentially resulting in less security rather than 
more as certificates then have to be installed on the middleware box. 
The middleware box also then becomes a DOS target itself, as it has to 
perform significant amounts of processing.

End users and major enterprises demand that they can look inside packets 
at near wire speed and filter traffic traversing their AS boundary in a 
granular manner according to a security policy that they can tweak 

IMHO The IETF should accept that starting point as a basic requirement 
for protocol development, and facilitate simple parsing and granular 
filtering at high speed.

Anything not complying with this basic requirement is unlikely to be 

>> What we did in our I-D is specify a new Extension Header, that is
>> assigned a Next-Header value. Let us assume that our proposal moves
>> forward, and the UEH is assigned the next header value 0xfe.
>> If a middle-box supports UEH but does not support our (fictitious) GTP
>> protocol above, then, if a GTP packet encapsulated in IPv6 is received,
>> GTP will be identified as an "upper-layer protocol", rather than as UEH
>> (since the Next Header value will be 0xff, rather than UEH's 0xfe).
>> Clearly, another way to go is to reserve part of the IANA's Next Header
>> namespace for RFC6465, and leave the rest for transport protocols -- as
>> suggested by Hagen.
>> What's clear is that the only way in which RFC6465 can possibly work is
>> if the middle-box has some a-priori knowledge that what is being
>> encapsulated follows RFC6465 -- whether as a result of a reserved range
>> (as originally proposed by Hagen) or by specifying a single UEH, and
>> then encoding all possible future "extension headers" as subtypes of UEH.
> A third possibility would be to go a step further than RFC 6564 and
> ban new extension headers outright, insisting that a Destination
> Option be used instead.  RFC 6564 already says that a new extension
> header may be defined only as a last resort, requiring proof that a
> Destination Option will not work.
> Can anyone offer up a scenario where a Destination Option will not
> work?
> Mike Heard