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

[Fernando Gont <[e-mail]>]

Hi, Ran,

On 02/10/2014 10:54 AM, RJ Atkinson wrote:
>
> I agree with Thomas Narten's analysis.  
> 
> The deployed situation perhaps isn't ideal, but the IETF ought to  
> hew to the deployed reality.

FIWIW, that's the bottom-line of my reasoning.


> Today's reality is that the Internet 
> is very unlikely to deploy any new transport protocol(s) or any new 
> IPv6 extension headers.  My own preference (has been and) would be 
> to outright ban all new IPv6 Extension Headers -- insisting that 
> future IPv6 extensions be specified as options within the existing 
> Destination Options header or Hop-by-Hop Options header.

That's certainly among the options -- and is an acceptable outcome: if
you receive a packet that has an unrecognized next header, treat it as a
new transport protocol (and probably drop it).

But we currently assume that there might be new extensions, and that we
can parse unrecognized headers -- which we cannot.



> ENTERPRISE/OPERATOR FIREWALLS:
[...]

I fully agree with all your observations.


> NEWER TRANSPORT PROTOCOLS:
> 
> Few, if any, IP firewalls support SCTP at present.  Ditto for NORM,
> although NORM can traverse some firewalls because NORM usually runs
> over UDP.  I'm not certain why SCTP has little or no deployment,

Apparently, there's a fair share of SCTP deployment, albeit not for
public Internet services. And, in many cases, SCTP is being encapsulated
on top of UDP.


> BOTTOM LINE:
> 
> My perception is that this ship sailed several years ago, and that it
> is either impossible or nearly impossible to deploy any new IPv6
> Extension Header (although IPv6 options carried in existing headers
> still seem possible) or any new transport-layer protocol using different
> framing from TCP/UDP.

FWIW, Extension Headers seem to be widely dropped. See e.g.:
<http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>
(Tim Chown has obtained similar results). However, we still need to
determine when in the network such packet drops happen.


What I would expect is that:

1) We clarify that despite RFC 6465, no middle-box can parse
unrecognized Next Headers. i.e., no middle-box could parse a new
Extension Header, unless the middle-box explicitly supports it.
Then, we either provide a way for them to parse unknown headers (as in
our UEH I-D), or ban new extension headers once and for all -- and we
forget about this.

2) Even with the current data, it seems that employing extension headers
for protocol extensions is not really a viable option in the real world.
That is, if we were to specify a new option (even if it is to be
included in a Dst Options header), that would lead to packet drops
(rather than "ignore the extensions/options"). The conclusion would be
that, for the general case, "think twice before relying on Ext Headers,
then don't". And this should be documented, so that any protocol design
that means to use EHs is aware of the fact that it probably won't work
as expected in the deployed world.

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