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

Sat Sep 29 00:11:29 UTC 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. 