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

[Fernando Gont <[e-mail]>]

Hi, Jen,

On 02/04/2014 11:20 AM, Jen Linkova wrote:
>> We've written a short I-D that discussed the problem, and that proposes
>> an alternative, such that we achieve the same goal without possibly
>> messing with our Transport friends. :-)
>>
>> The I-D is available at:
>> <http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-universal-extension-header-00.txt>
> 
> 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.

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.


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.

Please do let me know if the above clarifies our rationale...

P.S.: FWIW, we're working together with Hagen to offer 6man a more
unified document that discusses possible approaches, pro's nd con's, etc.

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