North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

  • From: Daniel Senie
  • Date: Fri Sep 28 20:36:01 2007

At 04:39 PM 9/28/2007, Iljitsch van Beijnum wrote:



On 28-sep-2007, at 6:25, Jari Arkko wrote:

And make it works both way, v4 to v6 and v6 to v4.
And also don't call it NAT-PT. That name is dead.


For what it is worth, this is one of the things that I want
to do. I don't want to give you an impression that NAT-PT++
will solve all the IPv6 transition issues; I suspect dual stack
is a better answer. But nevertheless, the IETF needs to
produce a revised spec for the translation case. Fred and
I are organizing an effort to do this.


The problem with NAT-PT (translating between IPv6 and IPv4 similar to
IPv4 NAT) was that it basically introduces all the NAT ugliness that
we know in IPv4 into the IPv6 world.

NAT grew out of need. It didn't grow up in the IETF. We did have a NAT WG, to document, define common terminology and guidelines. We took a lot of heat for just documenting what was out there. The marketplace resulted in the success of NAT. Even if there had been limitless address space, it's unlikely NAT would have been avoided.

 Rather than "solving" this issue
by trying harder, I would like to take the IETF to adopt the
following approach:

1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay
TCP connections

So your fobia over all things NAT is so deep that you would insist on the use of a SOCKS-like mechanism, breaking end-to-end connectivity, to avoid implementing NAT of any sort. Pardon me for thinking this is a stretch.


2. for hosts that are connected to IPv6-only networks but with needs
that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6

Add more devices in the path, resulting in a tortured "end-2-end" that has lots of points of failure, and lots of state in the network for those tunnel endpoints, timeouts on same, etc.

I fail to see how your proposals preserve the end-to-end nature of the Internet in any meaningful way. You've gone a long way to find something, anything, that can take the place of NAT, but in so doing, you've proposed solutions which do not appreciably differ in effect on the function of the Internet.