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

[Fernando Gont <[e-mail]>]

Hi, Thomas,

On 02/06/2014 09:21 AM, Thomas Narten wrote:
>> 1) If this problem remains un-addressed, then it's impossible to
>> differentiate between new upper-layer headers (e.g. a new transport
>> protocol) and new extension headers. Since such new extension headers
>> might be leveraged for malicious purposes, the end-result is that
>> middle-boxes are going to block *everything* (see RFC7045), which means:
>>
>>   + no new extension headers
>>   + no new transport protocols
>>
>> ... so I think we really don't want to go there.
> 
> But we are already there. Folk won't deploy anything other than
> TCP/UDP because NAT won't deal with it. That has already been reality
> and is the reason that other or new transport protocols appear to be
> virtually undeployable today.

Well, IPv6 *might* give a fresh start in this respect -- there *might*
be IPv6 NAT.. but not necessarily. So.. while the end result might be
the same, it need not.

I don't think we have widespread deployment of IPv6 NAT ("as we know it"
for IPv4), nor that we have such a large/massive deployment of IPv6 that
we can argue "the cat is out of the box".

In any case, I believe this is a discussion to be had. There has been a
lot of work around fragmentation and extension headers, with the more
conservative folks still hoping that EHs are usable on the public
Internet, and the other folks wishing EHs and fragmentation go away
(and, well, actually making that happen by blocking them).

So there seems to be a disconnect between what we expect the IPv6
Internet to be, and how it is being shaped (and is) in practice.

IMHO, we should either accept what's becoming more and more of a fact
(EHs and fragmentation being massively dropped on the public Internet;
e.g.
<http://iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>), or
try to do something to make them usable (after all, we're not planning
for IPv7 anytime soon).

All the above aside, the uniform format in RFC6465 cannot really work as
specified. So it looks like, at the very least, a "please ignore section
X of this document" is warranted... and/or a clear statement that we
have abandoned the possibility of standardizing any new transport
protocols (well, unless we encapsulate them over an existing one).

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492