Transition Mechanisms
One of the premises of IPv6 design was that it had to allow transitioning to the new version of the IP protocol without the need to abruptly move from one version to the other. In this context, various transition mechanisms have been designed to create a space for the coexistence of IPv4 and IPv6.
During the early stages of IPv6 deployment it was believed that adoption of the new protocol would be quick enough and that IPv6 would have gained widespread adoption before IPv4 ran out. This, however, did not happen which is why transition mechanisms are an even more relevant topic today.
The following is a description of the most widely deployed and more mature mechanisms.
Based on
Doble Pila
Provider backbone
Dual Stack
Geared towards
Dual-stack networks
Popularity
High
Preserves IPv4 addresses
No
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
NAT on the provider side
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC4241 (2005)
Transport network
Dual Stack
Functional components
N/A
Purpose for which the mechanism was designed
To allow clients to access the IPv4 and IPv6 Internet using a double protocol stack
Based on
Dual stack and encapsulation
Provider backbone
IPv6 Only
Geared towards
Dual-stack networks with an IPv6-only ISP network
Popularity
Medium - High
Preserves IPv4 addresses
No
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
NAT on the provider side
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC6333, RFC7870, RFC6674
Transport network
IPv6 Only
Functional components
B4 y AFTR
Purpose for which the mechanism was designed
Dual-stack over an IPv6-only transport network at the ISP
Based on
Dual stack and encapsulation
Provider backbone
IPv6 Only
Geared towards
Dual-stack networks with an IPv6-only ISP network and NAPT44 CPEs
Popularity
Medium
Preserves IPv4 addresses
No
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
NAT on the user side
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC7596 (2015)
Transport network
IPv6 Only
Functional components
lwB4 and lwAFTR
Purpose for which the mechanism was designed
Extension of DS-Lite with NATPT44 distributed at the lwB4/CPE level
Based on
Dual stack and encapsulation
Provider backbone
IPv6 Only
Geared towards
Dual-stack networks with an IPv6-only ISP network, NAPT44 CPEs and port sharing
Popularity
Low
Preserves IPv4 addresses
No
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
Port sharing
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC7597 (2015)
Transport network
IPv6 Only
Functional components
MAP-E CE and MAP-E BR
Purpose for which the mechanism was designed
Stateless-stateless double NAT64 solution with IPv6 transport network. Based on tunneling/encapsulation
Based on
Dual-stack and translation
Provider backbone
IPv6 Only
Geared towards
Dual-stack networks with an IPv6-only ISP network, NAPT44 CPEs and port sharing with translation to avoid overhead
Popularity
Low - Medium
Preserves IPv4 addresses
No
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
Port sharing
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC7599 (2015)
Transport network
IPv6 Only
Functional components
MAP-T CE and MAP-T BR
Purpose for which the mechanism was designed
Stateless-stateless double NAT64 solution with IPv6 transport network. Based on translation
Based on
Algorithmic mapping translation
Provider backbone
IPv6 Only
Geared towards
IPv6-only networks
Popularity
Medium - High
Preserves IPv4 addresses
Yes
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
NAT on the provider side
Possibility of reaching IPv4-only sites
Yes, with some limitations
Reference RFCs
RFC6146 (2011), RFC6147 (2011)
Transport network
IPv6 Only
Functional components
NAT64 and DNS64
Purpose for which the mechanism was designed
To allow IPv6-only clients/devices to establish connections to IPv4-only servers (A records only) using DNS64
Based on
Algorithmic mapping translation
Provider backbone
IPv6 Only
Geared towards
IPv6-only networks, mobile cellular networks, datacenters and IPv6-only servers
Popularity
Very high
Preserves IPv4 addresses
Yes
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
NAT on the provider side
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC6877 (2013)
Transport network
IPv6 Only
Functional components
CLAT and PLAT
Purpose for which the mechanism was designed
Extension of NAT64 for IPv6-only clients/devices to establish connections to IPv4-only servers from an IPv4 binding
Based on
Stateless translation based on EAM tables
Provider backbone
IPv6, IPv4 or DS
Geared towards
IPv6-only datacenters, legacy IPv4-only networks, IPv6-only networks connecting to the IPv4 Internet
Popularity
High
Preserves IPv4 addresses
Yes
Native IPv6 for users
Yes
Port sharing / NAT on the provider side / NAT on the user side
N/A
Possibility of reaching IPv4-only sites
Yes
Reference RFCs
RFC7755 (2016), RFC7756 (2016)
Transport network
IPv6, IPv4 or DS
Functional components
SIIT-BR
Purpose for which the mechanism was designed
To allow interconnection between (legacy) IPv4-only networks and IPv6-only networks in datacenter scenarios