IPv4-to-IPv6 Transition Strategies
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:
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.
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.
dual-stack-host.example.com. 86400 IN A 10.200.0.16
Resolution of the IP-address-to-host name may also be configured in DNS within the appropriate .arpa domain:
18.104.22.168.in-addr.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.
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.