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.

Dual Stack (PDF)

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

Dual Stack Lite (PDF)

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

Lw4o6 (PDF)

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

MAP-E (PDF)

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

MAP-T (PDF)

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

NAT64 DNS64 (PDF)

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

464xlat (PDF)

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

SIIT-D (PDF)

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