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

I would hope that this group would not consider hindering IPv6 capability
by designing for NAT compatibility… There is really no need for NAT in the
IPv6 world.

--
Brian

On Thu, Feb 6, 2014 at 7:44 AM, Fernando Gont <fgont@si6networks.com> wrote:

> 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: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>