There are three general classes of transition mechanisms to get from all-IPv4 through a mixture of IPv4 and IPv6, to eventually all-IPv6.

Co-existence

Under this mechanism, all client and server nodes support both IPv4 and IPv6 in their network stacks. The only mechanism in this group is the Dual Stack. This is the most general solution but also involves running essentially two complete networks that share the same infrastructure. It does not double network traffic, as some administrators fear. Any new connection over IPv6 is typically one less connection over IPv4. Over time, an increasing percentage of the traffic on any network will be IPv6, but the only increase in overall traffic will be from the usual suspects (increasing number of applications, users and/or customers), not from supporting Dual Stack. In fact, at some point you will see the total amount of IPv4 traffic begin to decrease. You may see an increase in incoming customer connections due to the ability to now also accept connections from IPv6 users. When YouTube started accepting connections over IPv6, there was an enormous and almost instant jump in IPv6 traffic on the backbone. Many nodes are ready to begin using IPv6 as soon as content is available, because of automated tunneling. In many cases, the end users might not even have been aware that they were now connecting over IPv6.

Tunneling

This mechanism works by creating IP-in-IP tunnels with a variety of mechanisms to allow sending IPv6 traffic over existing IPv4 infrastructures by adding an IPv4 packet header to the front of an entire IPv6 packet. This treats the entire IPv6 packet, including IPv6 packet header(s), TCP/UDP header and payload fields as a “black box” payload of an IPv4 packet. In the later phases of the transition, it reverses this: it treats an entire IPv4 packet, including IPv4 packet header and options, TCP/UDP header, and payload fields as a “black box” payload of an IPv6 packet. Some of these tunnel mechanisms are “automatic” (no setup required). Others require manual setup. Some require authentication while others do not. The benefit is to leverage the existing IPv4 infrastructure as a transport for IPv6 traffic, without having to wait for ISPs and equipment vendors to support IPv6 everywhere before anyone can start using it. This allows early adopters to deploy nodes and entire networks today, regardless of whether or not their ISP supports IPv6 today. In some cases (e.g. tunnels to a gateway router or firewall), when the ISP does provide dual-stack service, it is a simple process to change from tunneled service to direct service, and the process is largely transparent to inside users. There are several organizations providing free tunneled IPv6 service (using various tunnel mechanisms) during the transition, to help with the adoption of IPv6. Tunneling mechanisms include 6in4, 4in6, 6to4, 6over4, TSP (from gogonet) and Teredo. There are many Operating Systems features and installable client software available to make use of these tunneling mechanisms.

Translation

This basically means Network Address Translation (with all of its attendant problems), this time between IPv4 and IPv6 (as opposed to the more traditional NAT which is IPv4 to IPv4). An IPv6 to IPv4 translation gateway allows an IPv6-only internal node to access external IPv4-only nodes and allow replies from those legacy IPv4 nodes to be returned to the originating internal IPv6 node. Connections from an internal IPv6-only node to external IPv6-only or dual-stack nodes would be done as usual over IPv6 (without going through the translation gateway). This would be useful for deploying IPv6-only nodes in a predominantly IPv4 world. An IPv4 to IPv6 gateway would allow an IPv4-only internal node to access external IPv6-only nodes, and allow replies from those external IPv6 nodes to be returned to the internal IPv4-ony node). Connections from an internal IPv4-only node to external IPv4-only nodes, or to dual-stack nodes, would be done as usual over IPv4 (without going through the translation gateway). This would be useful for deploying IPv4-only nodes in a predominantly IPv6 world. Some of these mechanisms require considerable modification to (and interaction with) DNS, such as NAT-PT and NAT64 + DNS64.

There are two broad classes of Network Address Translation between IPv4 and IPv6 – those that work at the IP layer, and are transparent to upper layers and protocols; and those that work at the application layer (i.e. Application Layer Gateways, also called Proxies). The IP layer mechanisms need only be implemented once, for all possible application layer protocols. Unfortunately they also have the most technical issues. Application Layer Gateways (e.g. for SIP, for HTTP, for SMTP, etc) work quite well, but require an ALG to be created and run for every application layer protocol you want to translate between IPv4 and IPv6. They are also more resource intensive (require the most processor and memory in translation gateways). Basically they accept a connection over one IP version (e.g. IPv6) and make a second connection (on behalf of the original node) over the other version of IP (e.g. IPv4). In some ALGs an entire message might be spooled onto temporary storage, (e.g. email messages) and then retransmitted later. In other cases, the ongoing connection would be simultaneous with the incoming connection, and bidirectional (e.g. with web). One version of this is a dual-stack façade (e.g. for HTTP/HTTPS) that would accept an incoming connection over either IPv4 or IPv6, and make an ongoing connection over IPv4 to an internal IPv4-only web server. It would translate the web server’s responses to whatever version of IP was used in the original incoming connection. One issue here is that SSL/TLS is link-oriented (it only secures one connection link). This means that authentication all the way from the real server to the client is not possible. Encryption all the way between real server and client depends on whether the ongoing connection is also over SSL/TLS. This is a typical outgoing web proxy, with the addition of IP version translation. This kind of translation can help you provide dual stack versions of your web and email services quickly and easily, without having to dual-stack the actual servers themselves.

There are quite a few Network Address Translation mechanisms between IPv4 and IPv6 currently proposed in IETF drafts, and all have advantages and disadvantages of various kinds. None is a “clean” design without any problems. One such mechanism called NAT-PT was defined in RFC 2766, “Network Address Translation – Protocol Translation (NAT-PT)”, February 2000. It had so many issues that it has already been deprecated to historic status by RFC 4966, “Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status”, July 2007. Reading RFC 4966 gives a lot of insight into the issues with trying to do translation between IPv4 and IPv6 at the Internet Layer.

SOURCE: The Second Internet, book authored by InfoWeapons Chairman and CTO Lawrence E. Hughes.