At 11:13 PM +0200 10/21/07, Iljitsch van Beijnum wrote:
... If an IPv6-only box is going to talk to the IPv4 world, at some point, the traffic needs to hit a dual stack system that can do the IPv6/IPv4 translation.
I think an approach where you have a regular IPv4 NAT and then tunnel the RFC 1918 addresses over an IPv6-only network would work better than NAT-PT.
There are companies which would like to be connecting new customers with IPv6 as we approach IPv4 depletion and then handle translation for IPv4 site connectivity in their network i.e. customers connecting to "The Internet" via only IPv6 with the expectation of reaching all Internet destinations (IPv4 and IPv6) without any hassles. While making the backbone networks dual-stack is going to be serious work, it's at least an understandable goal that operators can makes plans to hit. That's not the case with the requirement to provide transparent connectivity to IPv4 destinations via IPv6 transport. NAT-PT wasn't exactly an elegant solution, but it's now precisely what some providers are looking for (so connecting customers via just IPv6 is at least viable). Without it, every provider is going to come up with ad-hoc customer connection models with various IPv4 tunnelling and translation games once IPv4 address blocks become generally unavailable. The irony is that the I* rationale for moving NAT-PT to historic was "to restore the end-to-end transparency of the Internet" and yet the only real chance we have to restore end-to-end transparency is to first have a transition to the IPv6 (using dual-stack, NAT-PT, and every other tool at our disposal) and then over time let present IPv4 destination sites add IPv6 for end-to-end transparency based on their actual need for it. Instead, central planning may have effectively killed the very tool that's needed to allow providers to provision new Internet customers over a pure IPv6-only model, and create the right motivation for existing Internet sites to go dual-stack and actually gain "end to end transparency" via IPv6. /John