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 (RFC6180 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 9096 describes 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:

  1. 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.
  2. 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 IETF RFC 9313.
       D. Microsoft-specific: IP-HTTPS, DirectAccess and Teredo.

  3. 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   this article

464xlat. A later IPv4aaS transition mechanism.

tutorial this article, this article, this article, this frequently asked question (faq), this IETF RFC 8683
6over4. An early IPv4aaS transition mechanism white paper  
6to4. An early IPv4aaS transition mechanism white paper  
Adaptive IPv4 Address Space (EzIP)   this article
Application Level (or Layer) Gateway (ALG) white paper this article

Anything in Anything (AYIYA). An early transition mechanism, proposed but never implemented

  this article
BUMP IN THE API (BIA) white paper  
BUMP IN THE HOST (BIH) white paper  
BUMP IN THE STACK (BIS) white paper  
Carrier-Grade NAT (CGN, sometimes called CG-NAT or CGNAT). Also called Large Scale NAT (LSN or LSNAT). An early IPv4aaS transition mechanism paper, tutorial this article, this presentation
Domain Name Service ALG (DNS_ALG) white paper  
Dual-Stack Lite (DS-lite). One way to implement Carrier-Grade NAT (See above) paper, tutorial

this IETF RFC 7021, this presentation

Dual-Stack Transition Mechanism (DSTM). An early IPv4aaS transition mechanism white paper  
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 this analysis
IPv4 Residual Deployment IETF RFC 7600 (4rd) this article  
IPv6 Rapid Deployment IETF RFC 5969 (6rd) and the earlier IETF RFC 4213 (6in4 also called 6-in-4). Two early IPv4aaS transition mechanisms tutorial this presentation, this article
Intra-Site Automatic Tunneling Addressing Protocol (ISATAP). An early IPv4aaS transition mechanism white paper  
Lightweight IPv4-over-IPv6 (lw4o6) (also called 4over6). An example of an IPv4aaS transition mechanism   this article, this presentation
Locator/ID Separation Protocol (LISP) paper this article
Mapping of Address and Port with Encapsulation (MAP-E) and the related Address + Port (A+P) paper, tutorial this presentation, this article
Mapping of Address and Port using Translation (dIVI-pd or MAP-T)   this article, this draft IETF RFC
NETWORK ADDRESS TRANSLATION (NAT). Informally called NAT44 paper this article
NAT444. One way to implement Carrier-Grade NAT (See above) paper this IETF RFC 7021
NAT64/DNS64 paper, tutorial this article, this faq, this presentation
Public IPv4-over-IPv6 Access Network (Public 4over6). An early IPv4aaS transition mechanism   this article
Prefix-specific and Stateless Address Mapping (IVVI or IVI) paper, tutorial this article
Stateless Automation IPv4 over IPv6 Technology (SA46T/SA46T-AS) Datacenter Solution paper  
Socket Secure (SOCKS) white paper  
STATELESS IP/ICMP TRANSLATION (SIIT) white paper, tutorial  
Teredo. An early IPv4aaS transition mechanism white paper  
Transport Relay Translator (TRT) white paper  
Tunnel Broker white paper  
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.)

transition mechanism 17


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.