Network Engineer Silver - Transition Mechanisms

For some time, we are going to have IPv4 and IPv6 both running on the Internet. Unlike when color television was introduced, there is no "backward compatibility" between IPv6 and IPv4. With color television, a single signal could be interpreted by a color receiver in full color, but a legacy B&W receiver could at least produce a normal B&W image from the same signal. This simplified the introduction of color TV. IPv6 is more like the introduction of HD television. An SD receiver cannot create an SD image from an HD signal. That's why we have separate History and History-HD channels. Sometimes they even show the same content, one in SD and one in HD.
 
This means we are going to need various mechanisms to get from "here" (all IPv4) to "there" (all IPv6). The transition may take 10 years (or more). During that time we need to learn to "just all get along".
 
Having IPv4 and IPv6 co-exist on the same nodes and networks is one approach, known as "Dual Stack". This is kind of like everyone being "bilingual". This is the approach favored by the IETF, but it does double the cost of network management, and you still need IPv4 addresses. The solution is to NAT the heck out of the IPv4 addresses (even Carrier Grade NAT), and move everything that has problems with NAT to the IPv6 side (where there is no NAT). Many things (like outgoing web) work fine even through multiple layers of NAT. They can be left on "the dark side". There is little advantage to doing web over IPv6 other than that now there is no shortage of global addresses, so anyone can become a content provider. Those protocols can be the last to move to IPv6. Other protocols, such as IPsec, VoIP and P2P, really don't work well through even one layer of NAT, let alone two. Those should be moved to the IPv6 side first.
 
Another solution uses the existing worldwide IPv4 infrastructure to "tunnel" IPv6 through regions where there is no IPv6 yet. Currently, IPv6 exists in rapidly growing "islands" separated from each other by an "IPv4 ocean". Tunnels are like undersea cables that can connect the IPv6 islands together, right through the IPv4 ocean. This means you don't have to wait for your ISP to finally offer IPv6 service to you. You can get IPv6 right through their legacy infrastructure. Which ISPs today allow you to use IPv6? All of them do. It's just with some you need tunnels.
 
Someday the IPv6 islands will grow until they overlap and start to merge together. Then it will be an "IPv6 ocean" with shrinking "islands" of IPv4. We can use the same idea (stood on its head) to tunnel IPv4 between those islands. Tunnels don't translate between IPv4 and IPv6, they link regions of one IP family together through intervening infrastructure of the other IP family. There are several "tunneling" solutions. Some are "manually created", while others can be created automatically. Some require global IPv4 address at each endpoint, while others will work with one endpoint behind NAT44. The latter variety tend to be unstable and insecure. We will discuss the various options available. Generally, tunnels should be used only between a customer's border router and the source of tunneled IPv6. Inside the customer network, everything should be native dual stack. Currently there are a number of sources of free tunneled IPv6 service. You can easily create your own, if you have one site with native IPv6. We will soon see the evolution of "virtual ISPs" that provide commercial tunneled IPv6 service with Service Level Agreements.
 
One promising transition technology provides native IPv6 with IPv4 tunneled over it. The IPv4 addresses come from Carrier Grade NAT, so there is no shortage of them. This scheme tags each IPv4 address with the customer's IPv6 address, which solves some of the nasty problems of CGN without IPv6. This is called Dual Stack Lite or DS-Lite. Just deploying CGN without IPv6 is a recipe for disaster, and is strongly discouraged in the RFCs. Since DS-Lite is still Dual Stack, you can use protocols that are affected by NAT on the IPv4 side, and protocols that don't work well with NAT on the IPv6 side (which is native and works really well). Dual Stack Lite is the most likely way that ISPs will provide service for the next 10 years.
 
With DS-Lite, someday they can just quietly shut off the IPv4 and nobody will notice. What's left will be native IPv6. There may be an obituary in the Times: "Today, IPv4 passed away quietly among a few friends. He did great things when he was young, but most people don't even know his name today, like his ancestor, NCP."
 
The third solution is like an HD converter that can fabricate an SD signal from an HD one, for legacy receivers. In the case of HD->SD, it would be a poor solution because not only the signal is different, the format is also different (16:9 instead of 4:3), so you would get black bands at top and bottom of the screen. IPv6 and IPv4 are so different, there are many problems with trying to translate either way. It is particularly difficult to translate IPv6 into IPv4 (NAT64). Several attempts (like NAT-PT) have failed badly. They are trying again with NAT64/DNS64 which seems to also be running into serious problems. An approach I've used successfully is translation at Layer 7 (translating web proxy). See SolidProxy. It has none of the problems of the Layer 3 translators, but requires a different proxy for each translated protocol (e.g. http, smtp, etc).