IPv6 Transition Mechanisms Reference

Disponibile anche in:

IPv6 Transition Mechanisms Reference

Comparison and decision guide for 6rd, DS-Lite, NAT64/DNS64, 464XLAT, MAP-E, MAP-T, and deprecated mechanisms — with RFC references and deployment context.

1. Why Transition Mechanisms Exist

IPv4 address exhaustion reached IANA level in February 2011; RIR free-pool exhaustion followed (APNIC 2011, RIPE NCC 2012, ARIN 2015, LACNIC 2014, AFRINIC 2021). ISPs now rely on carrier-grade NAT (CGN) to share a single IPv4 address across many customers — at the cost of operational complexity, port-allocation overhead, and loss of end-to-end reachability.

The long-term solution is native dual-stack or IPv6-only networking. Transition mechanisms are bridges that let IPv6 networks reach IPv4 content, or let IPv6 services be deployed over IPv4 infrastructure, while migration proceeds.

Best option when available: Native dual-stack — the host has both a globally routable IPv4 and a globally routable IPv6 address, and the application uses whichever is available (RFC 6555 Happy Eyeballs). No encapsulation, no NAT, no special hardware. If your ISP offers this, prefer it over all transition mechanisms.

2. IPv6-over-IPv4 Tunnel Mechanisms

6rd — IPv6 Rapid Deployment (RFC 5969)

Stateless Deployed

The ISP allocates a /32 or shorter IPv6 prefix and embeds each customer's IPv4 address in the lower bits to derive a /56 or /60 customer prefix. The CPE (6rd CE) encapsulates IPv6 packets in IPv4 (proto 41) addressed to the ISP's 6rd BR (Border Relay). Return traffic is decapsulated at the BR.

Use case: ISP with IPv4 access network deploying IPv6 connectivity quickly. Free (France) deployed this at scale in 2007 before the RFC was published.
Key limitation: Still uses IPv4 in the access layer; introduces ~20 byte overhead per packet.

6in4 Manual Tunnel (RFC 4213)

Stateless

A manually configured point-to-point IPv6-in-IPv4 tunnel (protocol number 41) between two fixed endpoints. Still used for enterprise lab connectivity and Hurricane Electric's TunnelBroker service.

3. NAT64 + DNS64

Stateful Widely deployed

NAT64 (RFC 6146) is a gateway that translates between IPv6 and IPv4. IPv6-only clients send packets to a synthesized IPv6 address (in the NAT64 prefix, typically 64:ff9b::/96) that embeds the destination IPv4 address. The NAT64 gateway translates headers and maintains a stateful session table.

DNS64 (RFC 6147) works alongside NAT64: when an IPv6-only client queries DNS for a name that has only an A record (IPv4), DNS64 synthesizes an AAAA record by embedding the IPv4 address in the NAT64 prefix. The client connects to the synthesized address, which is then translated by NAT64.

DNS64 does not work with DNSSEC validation at the client. Synthesized AAAA records cannot have valid DNSSEC signatures. Applications doing their own DNS resolution (e.g., Android with private DNS, most VPN clients) bypass DNS64 and will fail to reach IPv4-only servers from an IPv6-only network without 464XLAT.

4. 464XLAT

Stateful (PLAT) Stateless (CLAT) Standard for mobile/cellular

464XLAT (RFC 6877) solves the DNS64/DNSSEC problem and also handles apps that embed IPv4 literals. It has two components:

CLAT (Customer-side Translator): Runs on the device (phone, router). Synthesizes a private IPv4 address space, intercepts IPv4 traffic from the OS, and translates it to IPv6 using the NAT64 prefix as the destination. The translation is stateless (RFC 6145/RFC 7915 IVI mapping).
PLAT (Provider-side Translator): The ISP's NAT64 gateway. Receives the translated IPv6 packets from the CLAT and translates back to IPv4 to reach the real IPv4 Internet.

The net result: apps running on the device see a real IPv4 interface. IPv4-literal connections work. DNSSEC works. This is the standard model for IPv6-only LTE/5G mobile networks (T-Mobile US, many EU operators).

The CLAT discovers the NAT64 prefix via DNS (RFC 7050: querying ipv4only.arpa) or via RA options (RFC 8781 PREF64 option).

5. DS-Lite — Dual-Stack Lite

Stateful (AFTR) Common in broadband

DS-Lite (RFC 6333) is designed for ISPs with an IPv6 access network who still need to serve IPv4 to customers. The CPE gets a native IPv6 address but no public IPv4. IPv4 traffic from the customer's LAN is encapsulated in IPv6 (B4 element in the CPE) and sent to the ISP's Address Family Transition Router (AFTR).

The AFTR decapsulates and performs CGN (carrier-grade NAT) from a shared IPv4 pool. IPv4 sessions are tracked at the AFTR. Because there is no IPv4 on the access loop, ISPs save IPv4 addresses; because the access network is native IPv6, IPv6 traffic takes the fast path without translation.

Use case: European cable/DSL operators (KPN, Swisscom, others).
Key limitation: IPv4 performance depends on AFTR capacity; per-subscriber port allocation limits max concurrent connections.

6. MAP-E and MAP-T

Stateless Growing deployment

Mapping of Address and Port (MAP) is a stateless translation/encapsulation framework that eliminates the CGN session table by mathematically deriving each customer's IPv4 address and port range from their IPv6 prefix. No per-session state at the Border Relay — it can be a simple router or even a line card function.

MAP-E (RFC 7597): Encapsulates IPv4 in IPv6. The CPE (MAP-E CE) encapsulates IPv4 packets in IPv6; the BR decapsulates. Stateless.
MAP-T (RFC 7599): Translates IPv4 to IPv6 (and back) using address+port-mapping rules. No encapsulation overhead — headers are translated in place.

MAP is increasingly popular in DOCSIS 3.1 and PON deployments where zero-state BRs are attractive for scaling. Requires careful port-range planning: each CE gets a restricted port range (e.g., 1024–2047 of 65536 total ports) derived from its IPv6 /56 prefix.

7. Deprecated Mechanisms — Do Not Use

6to4 and Teredo are formally deprecated. Do not deploy or enable them.

6to4 (RFC 3056, deprecated by RFC 7526): Used the anycast relay prefix 192.88.99.0/24. Unreliable due to inconsistent anycast relay operation, broken behind NAT, and abandoned by major OS vendors.
Teredo (RFC 4380): UDP-based IPv6 tunneling for NAT traversal. Disabled by default in Windows since Vista SP1 and Server 2008; no longer recommended. Security concerns (tunneled traffic bypasses IPv6 firewalls that don't inspect Teredo).

8. Comparison Table

Mechanism	Access Network	IPv4 for customer?	Stateful?	Overhead	Best for
Dual-Stack	IPv4 + IPv6	Yes (native)	No	None	Preferred everywhere
6rd	IPv4	No (IPv6 via tunnel)	No	20B/pkt	ISP deploying IPv6 over IPv4 access
DS-Lite	IPv6	Yes (AFTR CGN)	Yes (AFTR)	40B/pkt	Broadband; ISP wants IPv6 access + IPv4 service
NAT64 + DNS64	IPv6 only	Via translation	Yes (NAT64)	None	IPv6-only network reaching IPv4 Internet
464XLAT	IPv6 only	Yes (CLAT on device)	Yes (PLAT/NAT64)	None	Mobile/cellular IPv6-only; apps needing IPv4 socket
MAP-E	IPv6	Yes (stateless)	No	40B/pkt	Scale CPE deployments; zero-state BR
MAP-T	IPv6	Yes (stateless)	No	None (translate)	Same as MAP-E but without encap overhead
6to4	IPv4	No	No	20B/pkt	Deprecated — do not use
Teredo	IPv4 (behind NAT)	No	No	8B/pkt UDP	Deprecated — do not use

References

RFC 6555 — Happy Eyeballs: Success with Dual-Stack Hosts
RFC 4213 — Basic Transition Mechanisms for IPv6 Hosts and Routers (6in4)
RFC 5969 — IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
RFC 6146 — Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
RFC 6147 — DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
RFC 6333 — Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
RFC 6877 — 464XLAT: Combination of Stateful and Stateless Translation
RFC 7050 — Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis (NAT64 prefix discovery via ipv4only.arpa)
RFC 7526 — Deprecating the Anycast Prefix for 6to4 Relay Routers
RFC 7597 — Mapping of Address and Port with Encapsulation (MAP-E)
RFC 7599 — Mapping of Address and Port Using Translation (MAP-T)
RFC 8781 — Discovering PREF64 in Router Advertisements
RFC 8585 — Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service