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. 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 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 The advantage of 1. is that proxies and applications that can use proxies are already in wide use. The advantage of 2. is that it provides real IPv4 connectivity without compromises. Different hosts (even on the same subnet) can have different IPv4 connectivity (NAT/ no NAT, firewalled/unfirewalled) without having to provision the complete path between the user and the edge of the network specifically for that type of connectivity. And no lost addresses for subnetting etc.