The Transition to IPv6
MEMBER BRIEFING 6 < Main Index
|January 2002||By Eric Carmès|
IP version 6 (IPv6) is a new version of the Internet Protocol, designed as a successor to the current IP version 4 (IPv4). The transition between today's IPv4 Internet and a future IPv6-based one will be a long process during which both protocol versions will coexist. The IETF has created the NGTrans Working Group to assist IPv6 transition and propose technical solutions to achieve it.
The IPv6 specification introduces major modifications. Not only has the IP address length been extended to 128 bits but also the IP header format and the way header information is processed have been modified. Moving from IPv4 to IPv6 is not straightforward and mechanisms to enable coexistence of and transition between the two versions have to be standardised.
Today hundreds of millions of people are connected to the Internet and an equivalent number of hosts and devices implement the IP protocol. Switching on a D-day from IPv4 to IPv6 following a "Y2K model" would prove impractical. Migration to IPv6 within such a very short period would require the re-definition of a world-wide IPv6 addressing plan, the installation of the IPv6 protocol on every router and host and modification of all existing applications to run over IPv6.It would incur heavy expense and would cause unacceptable service interruptions as well as major damage to critical distributed applications. Such an approach would also be pointless, as many working applications do not immediately require the IPv6 improvements or were not designed to benefit from the new functionalities enabled by IPv6.
No general rule can be applied to the IPv4 to IPv6 transition process. In some cases, moving directly to IPv6 will be the answer. For instance IPv6 could be pushed by a political decision to extend the number of IP addresses to sustain the economic growth of a country. Another example is the large- scale deployment of a new IP architecture (such as mobile or home networking) to provide disruptive applications and innovative services.
Other transition plans will enable a gradual interoperability between IPv4 and IPv6 as transition evolves. Here, ISPs and enterprises will prefer to preserve the heavy investments made to deploy IPv4 networks.
Some studies foresee that the transition period will last between today and 2030-2040. At that time, IPv4 networks should have totally disappeared.
Three main transition techniques have been defined by the NGTrans working group.
The first technique is the dual-stack network. This approach requires hosts and routers to implement both IPv4 and IPv6 protocols. This enables networks to support both IPv4 and IPv6 services and applications during the transition period in which IPv6 services emerge and IPv6 applications become available. At the present time, the dual-stack approach is a fundamental mechanism for introducing IPv6 in existing IPv4 architectures and will remain heavily used in the near future. The drawback is that an IPv4 address must be available for every dual-stack machine. This is annoying, since IPv6 was developed precisely due to the scarcity of IPv4 addresses.
The second technique relies on tunnelling. Tunnelling enables the interconnection of IP clouds. For instance, separate IPv6 networks can be interconnected through a native IPv4 ser vice by means of a tunnel. IPv6 packets are encapsulated by a border router before transportation across an IPv4 network and decapsulated at the border of the receiving IPv6 network. Tunnels can be statically or dynamically configured, or implicit (6to4,6over4).The TB (Tunnel Broker) approach has been proposed to automatically manage tunnel requests coming from the users and ease the configuration process. ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is a recent technique to avoid tunnel manual configuration. Finally, in later stages of transition, tunnels will also be used to interconnect remaining IPv4 clouds through the IPv6 infrastructure.
The last technique uses a translation mechanism. Translation is necessary when an IPv6 only host has to communicate with an IPv4 host. At least, the IP header has to be translated but the translation will be more complex if the application processes IP addresses; in fact such translation inherits most of the problems of IPv4 Network Address Translators. ALGs (Application-Level Gateways) are required to translate embedded IP addresses, recompute checksums, etc. SIIT (Stateless IP/ICMP Translation) and NAT-PT (Network Address Translation - Protocol Translation) are the associated translation techniques. A blend of translation and the dual stack model, known as DSTM (Dual Stack Transition Mechanism), has been defined to allow for the case where insufficient IPv4 addresses are available. Like tunnelling techniques, translation can be implemented in border routers and hosts.
This complex set of coexistence and transition techniques can be "mixed and matched" in many ways.
Transition is not always the solution - It is important to keep in mind that transition is not the solution to all the problems. Some disruptive applications need IPv6 for mass deployment. Deploying transition mechanisms at a large scale can also lead to scalability issues that could heavily limit the IPv6 performance compared to a native solution.
IPv4 and IPv6 coexistence - When IPv4 and IPv6 have to coexist, keeping IPv4 to IPv6 transition under control is essential to avoid the deployment of two parallel Internet infrastructures. IPv6 applications will benefit from heavy investments already made to deploy existing IPv4 networks.
Service continuity - IPv4 to IPv6 transition is not only an address or a routing issue. Available and emerging enhanced IPv4 services such as IP QoS, IP security, telephony over IP have to be continuously provided whatever the IP infrastructure might be.
Transition solutions - Transition mechanisms proposed by the NGTrans Working Group bring some necessary engineering tools to build transition strategies. Choosing the convenient mechanisms, defining where to locate and how to deploy them is not an obvious task. Based on guidelines, user-oriented transition plans will be required to ease the transition process.
Edge server based transition - NGTrans has concentrated on network-level transition techniques, including translation. Another approach, which is quite complementary, is to use dual-stack edge servers at the IPv4/IPv6 border as application level proxies, removing the need for network-level translation.
Successful introduction of IPv6, first in specific geographies and fields of application, and later in the core of the net- work, is one of the most strategic requirements for the continued growth of the Internet. ISOC will continue to support relevant standards work, will support related education and training activities, and will be watchful for any public policy issues affecting the deployment of IPv6.
For More Information
Relevant IETF RFCs
The IPng Transition (ngtrans) working group of the IETF is under the Operations and Management Area, and has as its overall goal assisting the transition to IPv6. Many RFCs have already been published by the IETF NGTrans Working Group, please visit the RFC Editor pages to retrieve a full listing. A large number of recent contributions to NGTrans show that the group is very active. Many IETF RFCs are relevant to the discussion of OPES. Visit the for more information
Examples in the News
Edge Routers for IPv6 migration.
About the Author
Eric Carmès is 6WIND's co-founder and Chief Operating Officer. 6WIND, a French spin-off company from the Dassault / Thales (former Thomson-CSF) group, is the first one to market the 6WINDGate, a smart IPv4 and IPv6 router. As this equipment implements QoS, security, mobility management for the both versions of IP as well as all the different transition mechanisms, it brings an efficient solution for providing IPv4 to IPv6 service continuity. In Thomson-CSF, Eric Carmès was responsible for the development of the IPv6 technology now embedded in 6WIND's products. He is now in charge of the design of a new generation of IPv6 service and transition platforms.
This paper produced with editorial support from the IPv6 Forum.
The ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and the RIPE NCC, Sida. More information on the Platinum Sponsorship Program...
About the Background Paper Series
4, rue des Falaises
Series Editor: Martin Kupres
Copyright C Internet Society 2005.