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

["C. M. Heard" <[e-mail]>]

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

https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation/

> 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