Summary
This document will describe what I believe to be the realistic way the IPv6 transition will work, and hopefully quash some of the misconceptions regarding IPv6. It assumes a reasonable knowledge of both IPv6 and IPv4.
Introduction
Although as yet IPv6 is still a little discussed subject, due to IPv4 exhaustion, it will be inevitable. IANA has now allocated it's final IPv4 address blocks, to the local RIRs. RIPE, the european IAA currently has around 80 million IP addresses unallocated, equivalent to around 4.7 /8 address blocks. Based on historical data, it is expected that RIPEs allocation will run out by the end of 2011. Currently no mechanism exists for trading IPv4 blocks between LIRs, but it is likely that this will change in the future. This is an excellent resource on IPv6 exhaustion:-
http://www.ripe.net/internet-coordination/ipv4-exhaustion/faq
IPv6 Transition techniques
There are a number of transition techniques available, but few are scalable on the level required on the internet. Some are suitable for avoiding point problems, but few would allow full communication between ipv4 and ipv6 hosts.
The most important thing to remember regarding IPv6 to IPv4 communication is it is impossible for an IPv4 only host to communicate directly with an IPv6 host or vice versa. This may sound obvious, but it is something that confuses a lot of people when it comes to IPv6. Network devices can only talk protocols they are running, in the same way that if you want a Cisco router to talk to an IPX only netware server it would have to have an IPX address.
NAT-PT
NAT-PT (Network address translation - Protocol Translation) is a point to point translation mechanism that allows one address or a range of addresses to be translated from IPv4 to IPv6 and vice versa. The key issue with NAT-PT is you must translate both the source and destination address. Therefore, this protocol is suitable for fixing point to point connectivity on an enterprise network, but is not suitable for internet deployment.
For example, assume internet (ipv4 only) host 91.91.91.91 wanted to talk to ipv6.google.com (2a00:1450:8002::68). In order for this host to connect to this IPv6 address, it would need to have ipv6.google.com presented as an IPv4 address, and ipv6.google.com would need to see 91.91.91.91 as an ipv6 address. You could configure NAT-PT on a router and do this, and fix this point issue, but if that same PC then wanted to go somewhere else on the IPv6 internet, you would require a different translation. Therefore, just to allow one host to access the IPv6 internet, you would have to have a translation for every possible IPv6 address, which is inevitably unscalable. Add a second host, and you would need another set of translations.
NAPT-PT
NAPT-PT (Network address port translation - Protocol Translation) is an extension to NAT-PT that also allows port based translation as well. Similar to how PAT allowed NAT to nat many to one, so does NAPT-PT. This suffers from the same fundamental issue of NAT-PT however, in that both source and destination must be translated.
Where this could be useful however, is for networks where IPv6 only could be deployed internally, and NAPT-PT used in a similar role as IPv4 PAT. The reason it can work in this direction but not the other way round, is the entire IPv4 address range can be presented as a small part of the IPv6 address space by using a prefix, but this cannot be done the other way round. ISATAP can be used for example as an appropriate prefix (ISATAP uses prefix ::200:5EFE:w.x.y.z for public IPv4 addresses). This means the entire IPv4 internet can be presented as a subset of the IPv4 space. The other challenge with this, is the DNS server would need to convert A records into AAAA records for delivery to the client. As far as I am aware, such a product does not yet exist, but could be easily implemented with an appropriate inspection agent built into the router.
e.g.
1. Host 2001::1:1 wants to get to www.google.com (IPv4).
2. It sends a DNS request to its IPv6 DNS server
3. The server does an IPv4 DNS lookup, and translates the IPv4 address into IPv6 by adding the prefix being used by NAPT-T
4. The client connects to the translated address (e.g. FC00::200:5EFE:74.125.230.83 <- This is translated into hex)
5. The clients address is translated to a public IPv4 address, so the final communication is between e.g. 91.91.91.91 and 74.125.230.83 on the IPv4 network and 2001::1:1 and FC00::200:5EFE:74 on the IPv6 network
A good real world scenario where this could be deployed would be in a home router scenario. Hosts on the users network could use IPv6 only, and NAPT-PT could be used to allow connectivity to the (legacy) IPv4 internet.
