IPv4-to-IPv6 Transition Strategies
(Part 1 of 3)
By Tim Rooney
Director, Product Management, INS

Organizations with existing IPv4 networks seeking to implement IPv6 face challenges in identifying impacts, planning the transition, and executing the migration to IPv6. Given organizations’ reliance on external communications for partner links, home-based employees, and Internet access for email, web browsing, etc., an overall plan should be compiled addressing the current environment, end users, and the controlled steps to IPv6 deployment.

This article, excerpted from a white paper of the same name, will be presented over the next three issues of 6Sense, and will review the three primary migration technologies that can be used to transition from an IPv4 network to an IPv6 network: (1) dual stack, (2) tunneling, and (3) translation. This article deals with dual stack.

Click here to download our IPv6 Toolkit, which includes the full IPv4-to-IPv6 Transition Strategies white paper in addition to webinars on IPv6 management.

Migration Technologies Overview

When we discuss migration, we’re referring to an initial state of an IPv4-only network to which IPv6 nodes and networks are added or overlaid over time, resulting in an IPv6-only network, or, more likely, a predominantly IPv6 network with continued IPv4 support.

A variety of technologies are available to facilitate the migration to IPv6. These technologies are discussed according to the following basic categories:

1. Dual stack – support of both IPv4 and IPv6 on network devices
2. Tunneling – encapsulation of an IPv6 packet within an IPv4 packet for transmission over an IPv4 network
3. Translation – address or port translation of addresses such as via a gateway device or translation code in the TCP/IP code of the host or router

Dual-Stack Approach

The dual-stack approach consists of implementing both IPv4 and IPv6 protocol stacks on devices requiring access to both network layer technologies, including routers, other infrastructure devices and end-user devices. Such devices would be configured with both IPv4 and IPv6 addresses, and they may obtain these addresses via methods defined for the respective protocols as enabled by administrators. For example, an IPv4 address may be obtained via DHCPv4, while the IPv6 address may be autoconfigured.

Implementations may vary with dual-stack approaches with respect to the scope of the stack that is shared versus what is unique to each IP version. Ideally, only the network layer would be dualized, using a common application, transport, and data link layer. This is the approach being implemented in Microsoft Vista, the newest Microsoft desktop operating system. This contrasts with the Microsoft XP implementation, which utilized dual transport and network layers, requiring, in some cases, redundant configuration by administrators of each stack. Other approaches may span the entire stack, down to the physical layer, requiring a separate network interface for IPv6 vs. IPv4. This approach, while contrary to the benefits of a layered protocol model, may be intentional and even desirable, especially in the case of network servers with multiple applications or services, some of which support only one version or the other.

Dual-Stack Deployment
Deployment of dual-stacked devices sharing a common network interface implies the operation of both IPv4 and IPv6 over the same physical link. After all, Ethernet and other layer 2 technologies support either IPv4 or IPv6 payloads. Dual-stacked devices require routers supporting such links to be dual stacked as well. This overlay approach is expected to be very common during the transition and is depicted in Figure 1. This diagram can be extended beyond a physical LAN to a multi-hop network where routers support IPv4 and IPv6 and route IPv4 packets among native IPv4 hosts and IPv6 packets among IPv6-capable hosts.

Figure 1

While routers would generally be among the first IP elements to be upgraded to support both protocols, RFC 4554 is an informational RFC describing an innovative approach using VLANs to support an overlay configuration without requiring immediate router upgrades. This approach relies on VLAN tagging to enable layer 2 switches to broadcast or trunk the Ethernet frames containing IPv6 payload to one or more IPv6 capable routers. By upgrading one router to support IPv6, the switch ports to which its interfaces are connected can be configured as the “IPv6 VLAN.” Other IPv6 or dual-stacked devices could then be configured as members of the VLAN, and multiple VLANs could be configured likewise. An example of this deployment is displayed in Figure 2.

Figure 2

DNS Considerations
DNS plays a crucial role in proper operation of each transition technology; after all, it provides the vital linkage between end-user naming and the destination IP address. End users attempting to access a dual-stack device will query DNS, which can be configured by administrators with an A resource record corresponding to the node’s IPv4 address and an AAAA resource record corresponding to its IPv6 address. The owner field of the resource record may have a common host name corresponding to the device per the following example:

dual-stack-host.example.com. 86400 IN A 10.200.0.16
dual-stack-host.example.com. 86400 IN AAAA 4FFE:320:200::A

Resolution of the IP-address-to-host name may also be configured in DNS within the appropriate .arpa domain:

16.0.200.10.in-addr.arpa. 86400 IN PTR dual-stack-host.example.com.
A.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.2.3.0.E.F.F.4.ip6.arpa. 86400
IN PTR dual-stack-host.example.com.

The dual-stack node itself must be able to support receipt of A and AAAA records during its own DNS resolution processing and communicate with the intended destination using the address and protocol corresponding to the returned record. Resolver configuration may enable definition of the preferred network protocol when both A and AAAA records are returned from the query, not to mention the protocol to use when issuing DNS queries themselves. In addition, as we shall see in the next major section, some automatic tunneling technologies utilize specific IPv6 address formats, so addresses corresponding to one or more tunneled address formats may also be returned and may be used to the extent that the resolving host supports the corresponding tunneling technology.

DHCP Considerations
The mechanism for using DHCP under a dual stack implementation is simply that each stack uses its version of DHCP. That is, in order to obtain an IPv4 address, use DHCP, and to obtain an IPv6 address or prefix, use DHCPv6. However, additional configuration information is provided by both forms of DHCP, such as which DNS or NTP server to use. The information obtained may lead to incorrect behavior on the client, depending on how the information from both servers is merged together. This remains an ongoing area of concern, as documented in RFC 4477, but the current standard is to use a DHCP server for IPv4 and a DHCPv6 server for IPv6, possibly implemented on a common physical server.

Next issue of 6Sense: Tunneling Approaches. Click here to download our IPv6 Toolkit, which includes the full IPv4-to-IPv6 Transition Strategies white paper in addition to webinars on IPv6 management.