The National Institute for Standards and Technology Special Publication 800-119 Guidelines for the Secure Deployment of IPv6, Dec, 2010 distinguishes between the deployment of Internet Protocol version 6 (IPv6) and the transition to IPv6 as follows:
"Since the majority of organizations will most likely run both IPv6 and IPv4 on their networks for the foreseeable future, this document speaks about the deployment of IPv6 rather than the transition to IPv6."
IPv6 is not backwards compatible with IPv4, so some kind of IPv6 transition mechanism must be used to allow IPv4-only and IPv6-only based systems to communicate. This Internet Engineering Task Force (IETF) Request For Comments (RFC) 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment provides general guidance. In addition to the systems involved in the communication, at what point the transition occurs along the path between the communicating systems also needs to be considered, as discussed in this IETF draft document IPv6-only Terminology Definition.
This IETF RFC 7084 and an update to it describe several IPv6 transition mechanisms. The European Telecommunications Standards Institute (ETSI) Industry Specification Group for IPv6 Integration (ISG for IP6) Generic migration steps from IPv4 to IPv6 report describes several additional IPv6 transition mechanisms.
Many IPv6 transitions mechanisms have been developed over the years to allow systems that use IPv6 and/or IPv4 protocols to coexist, and for IPv4-based systems to transition to IPv6. An IPv6 transition mechanism typically falls into one of three categories:
- A dual-stack environment in which each computer or router implements both IPv6 and IPv4 protocols, so that services and applications can use either (or both) as required. This requires an IPv4 address and an IPv6 address for every dual-stack device. The dual-stack approach is a preferred IPv6 transition mechanism for introducing IPv6 support in existing IPv4 devices and will remain widely used in the near future.
- A tunneling mechanism (also known as tunnelling) in which either manually or automatically established tunnels interconnect isolated enclaves of IPv6 (or IPv4) computers so that they may communicate across an IPv4-only (or IPv6-only) wide-area infrastructure. Packets are encapsulated before being transported across a wide-area infrastructure and decapsulated at the receiving end. There are four broad categories of tunneling mechanisms:
A. One that is widely deployed and available for free to individuals who do not have native IPv6 connectivity is a tunnel broker. Hurricane Electric offers one tunnel broker here. It does not require any software to be installed locally, but does require a stable public IPv4 address. It requires user registration.
B. Another is a Virtual Private Network (VPN). VPNs are discussed separately in the IPv6 and Virtual Private Networks (VPNs) article in the Infrastructure section.
C. A third (encompassing a variety of implementations) is IPv4-as-a-Service (IPv4aaS). IETF RFC 8585 describes the general requirements for routers implementing IPv4aaS. IPv4aaS is described separately in this series of articles: part 1, part 2, and part 3. The pros and cons of several IPv4aaS transition mechanisms are compared in this IETF document.
D. Microsoft-specific: IP-HTTPS, DirectAccess and Teredo.
- Protocol translation software which allows IPv4-only or IPv6-only devices to communicate directly with IPv6-only or IPv4-only devices, via some bi-directional protocol translation process. This often involves replacing and/or modifying the addresses/port numbers in packet headers. Protocol translation can become quite complicated, and typically does not scale well. With so many different protocol translation processes available, few are likely to find wide-spread use. Notable exceptions that are finding wide-spread use include NAT64/DNS64 and the more recent 464xlat transition mechanisms.
Older IPv6 transition mechanisms are discussed in this white paper and presentation. Later IPv6 transition mechanisms are described in this paper, which offers additional reasons why most protocol translation processes will never see widespread use. Some of the later IPv6 transition mechanisms are also described in this tutorial. The following table provides information about specific IPv6 transition mechanisms:
|IETF Standards for IPv6 transition mechanism:
|Also see above references:
|For additional information see:
|4in6. An early IPv4aaS transition mechanism
464xlat. A later IPv4aaS transition mechanism.
|this article, this article, this article, this frequently asked question (faq), this IETF RFC 8683
|6over4. An early IPv4aaS transition mechanism
|6to4. An early IPv4aaS transition mechanism
|Adaptive IPv4 Address Space (EzIP)
|Application Level (or Layer) Gateway (ALG)
Anything in Anything (AYIYA). An early transition mechanism, proposed but never implemented
|BUMP IN THE API (BIA)
|BUMP IN THE HOST (BIH)
|BUMP IN THE STACK (BIS)
|Carrier-Grade NAT (CGN, sometimes called CG-NAT or CGNAT). Also called Large Scale NAT (LSN or LSNAT). An early IPv4aaS transition mechanism
|this article, this presentation
|Domain Name Service ALG (DNS_ALG)
|Dual-Stack Lite (DS-lite). One way to implement Carrier-Grade NAT (See above)
|Dual-Stack Transition Mechanism (DSTM). An early IPv4aaS transition mechanism
|Generic Routing Encapsulation (GRE). An early IPv4aaS transition mechanism
|this article, IETF RFC 7676
|Host Identity Protocol (HIP). Theoretically, an alternative to transitioning the Internet to IPv6
|this overview, references
|IPv4 Residual Deployment IETF RFC 7600 (4rd)
|IPv6 Rapid Deployment IETF RFC 5969 (6rd) and the earlier IETF RFC 4213 (6in4 also called 6-in-4). Two early IPv4aaS transition mechanisms
|this presentation, this article
|Intra-Site Automatic Tunneling Addressing Protocol (ISATAP). An early IPv4aaS transition mechanism
|Lightweight IPv4-over-IPv6 (lw4o6) (also called 4over6). An example of an IPv4aaS transition mechanism
|this article, this presentation
|Locator/ID Separation Protocol (LISP)
|Mapping of Address and Port with Encapsulation (MAP-E) and the related Address + Port (A+P)
|this presentation, this article
|Mapping of Address and Port using Translation (dIVI-pd or MAP-T)
|this article, this draft IETF RFC
|NETWORK ADDRESS PORT TRANSLATION - PROTOCOL TRANSLATION (NAPT-PT)
|Deprecated by IETF RFC 4966
|NETWORK ADDRESS TRANSLATION - PROTOCOL TRANSLATION (NAT-PT) (see NAPT-PT above)
|NETWORK ADDRESS TRANSLATION (NAT). Informally called NAT44
|NAT444. One way to implement Carrier-Grade NAT (See above)
|this IETF RFC 7021
|this article, this faq, this presentation
|Public IPv4-over-IPv6 Access Network (Public 4over6). An early IPv4aaS transition mechanism
|Prefix-specific and Stateless Address Mapping (IVVI or IVI)
|Stateless Automation IPv4 over IPv6 Technology (SA46T/SA46T-AS) Datacenter Solution
|Socket Secure (SOCKS)
|STATELESS IP/ICMP TRANSLATION (SIIT)
|white paper, tutorial
|STATELESS IP/ICMP TRANSLATION FOR IPv6 DATA CENTER ENVIRONMENTS (SIIT-DC and SIIT-DC Dual Translation)
|this article, this article
|Teredo. An early IPv4aaS transition mechanism
|Transport Relay Translator (TRT)
|Virtual Private Network (VPN)
|IPv6 and Virtual Private Networks (VPNs)
Another source of guidance about IPv6 transition mechanisms is the 3rd Generation Partnership Project (3GPP), an industry consortium of telecommunications organizations. Their Universal Mobile Telecommunications System (UMTS) specification is an ongoing series of technical reports by the 3GPP providing IPv6 deployment guidelines to 3GPP members. For the latest version of the specification, go to the TR 23.975 web page (which is mostly blank), click on the Versions tab, and then click on the version number under the Version column for the entry with the most recent Upload date. (The version number may be something other than the value appearing in the example below.)
Version 5 of the specification was released in February, 2010. It marked the first time that IPv6 became mandatory and IPv4 became optional, although a dual stack was recommended.