The true transition of the global Internet from IPv4 to IPv6 is expected to span many years. And, during this period of transition, many organizations introducing IPv6 into their infrastructure will support both IPv4 and IPv6 concurrently. There is not a one-size-fits-all transition strategy for IPv6. The incremental, phased approach allows for a significant period where IPv4 and IPv6 can co-exist using one or more transition mechanisms to ensure interoperability between the two protocol suites. The most often-used methods of performing this transition is by operating in a dual-stack environment, or by using tunneling and translation between the two versions of Internet Protocol (IP).
IPv4/IPv6 Dual Stacks
Because IPv6 represents a conservative extension of IPv4, it is relatively easy to write a network stack that supports both IPv4 and IPv6 while sharing most of the code. Such an implementation is called a dual stack, and a host implementing a dual stack is called a dual-stack host.
The term “dual stack” means that the host or router uses both IPv4 and IPv6 at the same time. For hosts, this means that the host has both an IPv4 and IPv6 address associated with each Network Interface Card (NIC), and that the host can send IPv4 packets to other IPv4 hosts, and that the host can send IPv6 packets to other IPv6 hosts. For routers, it means that in addition to the usual IPv4 IP addresses and routing protocols, the routers would also have IPv6 addresses and routing protocols configured. To support both IPv4 and IPv6 hosts, the router could then receive and forward both IPv4 packets and IPv6 packets.
The dual stack approach can be a reasonable plan of attack to migrate an enterprise to IPv6 for communications inside the enterprise. The routers could be easily migrated to use dual stacks and today most desktop operating systems (OS) support IPv6. In some cases, the upgrade may require new software or hardware, and these conditions could cause a slower migration schedule. This situation is not necessarily a bad thing because a support staff could require additional time to learn how IPv6 works.
There are a number of factors that will affect the success and duration of the transition process. At the top of that list is training. IPv6, while built on many of the fundamental principles of IPv4, is different enough that most IT personnel will require formalized training. The level of training required will vary and depend upon the role a member of the organization’s IT staff plays in developing, deploying, and supporting IPv6 integration. (Check out this post discussing training issues for more on this).
The term tunneling refers to a means to encapsulate one version of IP in another so the packets can be sent over a backbone that does not support the encapsulated IP version. For example, when two isolated IPv6 networks need to communicate over an IPv4 network, dual-stack routers at the network edges can be used to set up a tunnel that encapsulates the IPv6 packets within IPv4, enabling the IPv6 systems to communicate without having to upgrade the IPv4 network infrastructure that exists between the networks.
Several types of IPv6-to-IPv4 tunnels exist. Three of the following types of tunnels are used by routers, where the fourth type (Teredo) is used by hosts.
- Manually Configured Tunnels (MCT): This is a simple configuration in which tunnel interfaces, which are a type of virtual router interface, are created with the configuration referencing the IPv4 addresses used in the IPv4 header that encapsulates the IPv6 packet. Manually configured tunneling is used when network administrators manually configure the tunnel within the endpoint routers at each end of the tunnel, and is usually more deterministic and easier to debug than automatic tunneling, and is therefore recommended for large, well-administered networks. Any changes to the network, like renumbering, must be manually reflected on the tunnel endpoint. Tunnels result in additional IP header overhead because they encapsulate IPv6 packets within IPv4 (or vice versa).
- Dynamic 6to4 Tunnels: This term refers to a specific type of dynamically created tunnel, typically done on the IPv4 Internet in which the IPv4 addresses of the tunnel endpoints can be dynamically found, based on the destination IPv6 address.
- Intra-site Automatic Tunnel Addressing Protocol (ISATAP): ISATAP is another dynamic tunneling method, typically used inside an enterprise. ISATAP treats the IPv4 network as a virtual IPv6 local link, with mappings from each IPv4 address to a link-local IPv6 address. Unlike 6to4 and Teredo, which are inter-site tunneling mechanisms, ISATAP is an intra-site mechanism, meaning that it is designed to provide IPv6 connectivity between nodes within a single organization.
- Teredo Tunneling: Teredo is a tunneling protocol designed to grant IPv6 connectivity to nodes that are located behind IPv6-unaware NAT devices. It defines a way of encapsulating IPv6 packets within IPv4 UDP datagrams that can be routed through NAT devices and on the IPv4 Internet. Many hosts are currently attached to the IPv4 Internet through one or several NAT devices, usually because of an IPv4 address shortage. In such a situation, the only available public IPv4 address is assigned to the NAT device, and the 6to4 tunnel endpoint needs to be implemented on the NAT device itself. Many NAT devices currently deployed, however, cannot be upgraded to implement 6to4 for technical or economic reasons.Teredo alleviates this problem by encapsulating IPv6 packets within UDP/IPv4 datagrams, which most NATs can forward properly. Thus, IPv6-aware hosts behind NATs can be used as Teredo-tunnel endpoints even when they don’t have a dedicated public IPv4 address. In effect, a host that implements Teredo can gain IPv6 connectivity with no cooperation from the local network environment.
Translating Between IPv4 and IPv6 with NAT-PT
Both classes of IPv6 transition features so far discussed-dual stack and tunnels-rely on the end hosts to at least support IPv6, if not both IPv4 and IPv6. However, in some cases, an IPv4-only host needs to communicate with an IPv6-only host. A third class of transition features need to be used in this case: a tool that translates the headers of an IPv6 packet to look like an IPv4 packet, and vice versa.
In Cisco routers, Network Address Translation-Protocol Translation (NAT-PT), which is defined in RFC 2766, can be used to perform the translation. To do its work, a router configured with NAT-PT must know what IPv6 address to translate to which IPv4 address and vice versa. This is the same kind of information held in the traditional NAT translation table. And, like traditional NAT, NAT-PT allows static definition, dynamic NAT, and dynamic PAT, which can be used to conserve IPv4 addresses.
As indicated previously, NAT-PT is defined in RFC 2766, but due to numerous problems it has been made obselete by RFC 4966 and deprecated to historic status. It is typically used in conjunction with a DNS Application-Level Gateway (DNS-ALG) implementation.
While almost identical to NAT-PT, Network Address Port Translation + Protocol Translation, which is also described in RFC 2766, adds translation of the ports as well as the address. This is done primarily to avoid two hosts on one side of the mechanism from using the same exposed port on the other side of the mechanism, which could cause application instability or security flaws.
As a final note, to support IPv6, all of the routing protocols had to go through varying degrees of changes, with the most obvious being that each had to be changed to support longer addresses and prefixes.
Author: David Stahl