Strategies for Migrating to IPv6
The growing demand for Internet addresses has prompted the development of a new protocol. For years, the Internet protocol known as IPv4 was sufficient for existing demand, but over the past two decades, it became clear the number of possible IPv4 addresses would eventually fail to meet demand. Realizing this, engineers and network designers established a new version of the IP protocol called IPv6. As the previous article outlined, the new IP protocol has a vastly larger number of potential addresses and adds required security features. The value of IPv6 and its benefits relative to IPv4 are not in question here; they are obvious. This article starts with the importance of migrating to IPv6 and asks the question, How should organizations move from IPv4 to IPv6 without disrupting their operations?
Very few organizations are in a position to make a wholesale change from IPv4 to IPv6 overnight. We have substantial network infrastructures designed for routing IPv4 traffic, applications that make assumptions about the underlying Internet protocol, and policies and procedures for managing IPv4 addresses within the organization. Making a "big bang" adoption of IPv6, in which there is a wholesale move from one platform to another, is fraught with risks. How sure are you that you have assessed all applications and how they will function with IPv6? Have you planned for and updated every piece of network infrastructure? Have you tested every client device with the new protocol?
Positing questions like these can make you wonder why anyone would ever try a big bang adoption with such a fundamental change. Big bang adoptions have significant risks when attempted with higher‐level applications, such as enterprise resource planning (ERP) systems; it is hard to overestimate the risks of taking such an approach at the network level. As a result, most of us will be living in a hybrid networking world while we make the transition from IPv4 to IPv6.
Let's explore three strategies for migrating to IPv6 in a phased approach and consider the benefits and drawbacks of each:
- Dual stack
- Translation
- Protocol tunneling
There are differences between the three, but they all address a fundamental issue: how to run two logical networks on the same physical infrastructure.
Dual‐Stack Approach to Migrating from IPv4 to IPv6
Networking services are implemented by a number of software types. Some software works at low levels close to the hardware while others provide high‐level services to applications. Figure 1 shows the four‐layered model of the Internet.
Figure 1: The Internet protocols are organized into a stack of four layers each delivering services to the layer above it.
As the figure implies, each layer provides services to the layer above it. The link layer works closest to the network and provides services to the Internet layer. The Internet layer is where the IP protocols—IPv4 and IPv6—operate. (There are other protocols at this layer too, such as the Internet Control Message Protocol—ICMP, but IP is the most important protocol in this discussion.) These layers interact making calls for services to the layer below and providing services for the layer above; thus, it is essential that they are coordinated. You cannot, for example, change the IP protocol in the Internet layer without affecting the transport layer which would, in turn, affect the application layer. One way to deal with this reality when migrating to IPv6 is to implement two stacks: one for IPv4 and one for IPv6.
Figure 2: Devices, such as workstations, running both IPv6 and IPv4 stacks can communicate with devices running either or both protocols.
The advantage of a dual‐stack approach is that it provides for flexible operations. Devices supporting both stacks can function with other devices supporting either (or both) of the IP protocols under discussion. A drawback of the dual‐stack approach is that running two stacks consumes more memory than running a single stack and there may be additional computational overhead as well. Also, from a systems manager's perspective, there is the matter of configuring and maintaining two protocol stacks.
In spite of the disadvantages of a dual‐stack approach, it is often the best option. Let's consider the option of translating between protocols.
Translation Between IPv6 and IPv4
If we think of the IP protocols as languages, it seems that translation is one obvious method for dealing with the differences in protocols. This is certainly an option, but as with translation of natural languages, there are sometimes problems in the process.
Designers of IPv6 planned for a transition period in which networks would have to support both IPv4 and IPv6. The IPv6 protocol includes support for translating packet headers from the IPv4 format to the IPv6 format. This support is accomplished by mapping IPv4 addresses to a special subset of IPv6 addresses known as IPv4‐translated addresses. (This process basically entails adding a prefix to the beginning of an IPv4 address to make it a full IPv6 address).
The primary advantage of translation is that it avoids the overhead of the dual‐stack approach. There are, however, disadvantages. Translation is not always a viable option when network address translation (NAT) is used with IPv4. An attempt was made to support NAT and IP translation, but that protocol is no longer supported.
In addition to dual stacks and translation, there is the tunneling approach. This method is sometimes used to support protocols that are not directly supported on a network.
Protocol Tunneling with IPv6 and IPv4
The word "tunneling" evokes images of sneaking something into a place where it would not normally be allowed. That makes it an ideal term for repackaging network traffic into a supported protocol. With protocol tunneling, an IPv6 packet is treated as data that is transmitted as payload by IPv4 packets.
Figure 3 illustrates the general principle that IPv6 packets are treated essentially as data that is transmitted as data within the IPv4 packet. This setup is an over simplification. For example, the IPv6 packet may contain a payload that is too large to fit into a single IPv4 packet. This situation is addressed in the standard.
Figure 3: Protocol tunneling uses IPv4 infrastructure to transmit IPv6 packets by embedding IPv6 data in IPv4 packets.
Information about the IPv6 packets destination address is encapsulated in an IPv4 packet, so there must be a method for determining the address the IPv4 packet should be routed to. Network administrators have a couple of options. One way to do so is with configured tunneling, in which the encapsulating packet contains information about the destination address of the IPv6 packet. An alternative method is to use automatic tunneling in which the final destination address is determined using an IPv4‐compatible address of the IPv6 packet, which is the IPv4 address prefixed with 96 bits of 0s.
IPv6 requires greater security measures than IPv4 requires, so implementing security measures, such as encryption, at IPv4 can be redundant.
Summary
Moving a network from IPv4 to IPv6 usually requires a transition from one standard to another. Trying to make a "big bang" adoption as is sometimes done with enterprise software is not recommended. Instead, running dual stacks to support both IPv4 and IPv6 can provide a fair degree of flexibility at the cost of additional device resources and some additional management overhead. Translating IPv6 to IPv4 protocols may be an option in some cases, such as when NAT is not used, and tunneling is another supported method. No one approach is best for every situation, and your requirements will dictate the appropriate solution for your environment. However, the dual‐stack approach can provide a good balance of functionality versus management overhead in many cases.