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

[Fernando Gont <[e-mail]>]

On 02/10/2014 05:07 PM, RJ Atkinson wrote:
> BOTTOM LINE:
> 
> 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.

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