Transitioning from IPv4 to IPv6

Transitioning from IPv4 to IPv6

As we have seen the technical details of IPv6 let us look at a very practical matter: How will the public Internet, which is based on IPv4, be transitioned to IPv6? The problem is that while new IPv6-capable systems can be made backward-compatible, that is, can send, route, and receive IPv4 datagrams, already deployed IPv4-capable systems are not capable of handling IPv6 datagrams. Many options are possible.

One option would be to declare a flag day - a given time and date when all Internet machines would be turned off and upgraded from IPv4 to IPv6. The last major technology transition (from using NCP to using TCP for reliable transport service) occurred almost 25 years ago. Even when the Internet was tiny and still being administered by a small number of "wizards". it was realized that such a flag day was not possible. A flag day involving hundreds of millions of machines and millions of network administrators and users is even more unthinkable today. There are two approaches (which can be used either alone or together) for gradually integrating IPv6 hosts and routers into an IPv4 world (with the long-term goal, of course, of having all IPv4 nodes finally transition to IPv6).

Perhaps the most straightforward way to introduce IPv6-capable nodes is a dual-stack approach, where IPv6 nodes also have a complete IPv4 implementation. Such a node, referred to as an IPv6/IPv4 node, has the ability to send and receive both IPv4 and IPv6 datagrams. When interoperating with an IPv4 node, an IPv6/IPv4 node can use IPv4 datagrams; when interoperating with an IPv6 node, it can speak IPv6. IPv6/IPv4 nodes must have both IPv6 and IPv4 addresses. They must, in addition, be able to determine whether another node is IPv6-capable or IPv4-only. This problem can be solved using the DNS (see "Application Layer"), which can return an IPv6 address if the node name being resolved is IPv6-capable, or otherwise return an IPv4 address. Certainly, if the node issuing the DNS request is only IPv4-capable, the DNS returns only an IPv4 address.

In the dual-stack approach, if either the sender or the receiver is only IPv4-capable, an IPv4 datagram must be used. As a result, it is possible that two IPv6-capable nodes can end up, in essence, sending IPv4 datagrams to each other. This is shown in Figure 1. Assume Node A is IPv6-capable and wants to send an IP datagram to Node F, which is also IPv6-capable. Nodes A and B can exchange an IPv6 datagram. On the other hand, Node B must create an IPv4 datagram to send to C. Of course, the data field of the IPv6 datagram can be copied into the data field of the IPv4 datagram and proper address mapping can be done. Though, in performing the conversion from IPv6 to IPv4, there will be IPv6-specific fields in the IPv6 datagram (for example, the flow identifier field) that have no counterpart in IPv4. The information in these fields will be lost. In this way, even though E and F can exchange IPv6 datagrams, the arriving IPv4 datagrams at E from D do not contain all of the fields that were in the original IPv6 datagram sent from A.

An alternative to the dual-stack approach is known as tunneling. Tunneling can solve the problem noted above, allowing, for instance, E to receive the IPv6 datagram originated by A. The basic idea behind tunneling is the following. Assume two IPv6 nodes (for instance, B and E in Figure 1) want to interoperate using IPv6 datagrams but are connected to each other by intervening IPv4 routers. We refer to the intervening set of IPv4 routers between two IPv6 routers as a tunnel, as shown in Figure 2. With tunneling, the IPv6 node on the sending side of the tunnel (for example, B) takes the entire IPv6 datagram and puts it in the data (payload) field of an IPv4 datagram. This IPv4 datagram is then addressed to the IPv6 node on the receiving side of the tunnel (for example, E)

A dual-stack approach


and sent to the first node in the tunnel (for example, C). The intervening IPv4 routers in the tunnel route this IPv4 datagram among themselves, just as they would any other datagram, blissfully unaware that the IPv4 datagram itself contains a complete IPv6 datagram. The IPv6 node on the receiving side of the tunnel finally receives the IPv4 datagram (it is the destination of the IPv4 datagram), determines that the IPv4 datagram contains an IPv6 datagram, extracts the IPv6 datagram, and then routes the IPv6 datagram exactly as it would if it had received the IPv6 datagram from a directly connected IPv6 neighbor.

We finish this section by noting that while the adoption of IPv6 was initially slow to take off [Lawton 2001], momentum has been building recently. See [Huston 2008b] for discussion of IPv6 deployment as of 2008. The U.S. Office of Management and Budget (OMB) has mandated that backbone routers on U.S. government networks be IPv6-capable by mid 2008; a number of agencies had met this mandate at the time of this writing (November 2008). The proliferation of devices such as IP-enabled phones and other portable devices provides an additional push for more widespread deployment of IPv6. Europe's Third Generation Partnership Program [3GPP 2009] has specified IPv6 as the standard addressing scheme for mobile multimedia. Even if IPv6 hasn't been widely deployed in the first 10 years of its young life, a long-term view is clearly called for. Today's phone number system took many decades to take hold, but it has been in place now for nearly half a century with no sign of going away. Likewise, it may take some time for IPv6 to take hold, but it too may then be around for a long time thereafter. Brian Carpenter, former chair of the Internet Architecture Board [IAB 2009] and author of several IPv6-related RFCs, says, "I have always looked at this as a 15-year process starting in 1995" [Lawton 2001]. By Carpenter's dates, we're nearing the three-quarters point!

One important lesson that we can learn from the IPv6 experience is that it is extremely difficult to change network-layer protocols. Since the early 1990s, numerous new network-layer protocols have been trumpeted as the next major revolution for the Internet, but most of these protocols have had limited penetration to date. These protocols include IPv6, multicast protocols ("Broadcast and Multicast Routing"), and resource reservation protocols ("Multimedia Networking"). In fact, introducing new protocols into the network layer is like replacing the foundation of a house - it is difficult to do without tearing the whole house down or at least temporarily relocating the house's residents. On the other hand, the Internet has witnessed rapid deployment of new protocols at the application layer. The classic examples, certainly, are the Web, instant messaging, and P2P file sharing. Other examples include audio and video streaming and distributed games.  Introducing new application-layer protocols is like adding a new layer of paint to a house - it is comparatively easy to do, and if you choose an attractive color, others in the neighborhood will copy you. To sum up, in the future we can expect to see changes in the Internet's network layer, but these changes will likely take place on a time scale that is much slower than the changes that will take place at the application layer.


tunneling, dual-stack approach, ipv6 nodes, application-layer protocol

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.