IPv6 Transition Technologies: NAT64, DS-Lite, MAP-E, and Beyond

IPv6 has been "the future" for over two decades, yet the internet still runs a tangled mix of IPv4 and IPv6. The reason is straightforward: you cannot flag-day 4.3 billion devices and millions of networks to a new protocol. Instead, the industry has produced a family of transition mechanisms — each making different tradeoffs between complexity, performance, and deployment scope. Understanding these mechanisms matters because they are not academic: they sit in the forwarding path of billions of packets right now, and the one your traffic uses depends on your ISP, your device, and the destination you are trying to reach.

This article covers the full spectrum of IPv6 transition technologies in active use (and a few deprecated ones worth understanding), how they interact with BGP and DNS, and which real-world operators rely on which mechanisms.

The Core Problem: Two Incompatible Protocols

IPv4 and IPv6 are not wire-compatible. An IPv4 packet cannot traverse an IPv6-only link, and vice versa. A host with only an IPv4 stack cannot speak to a host with only an IPv6 stack without something in the middle performing translation or encapsulation. Every transition mechanism is some variation of three fundamental approaches:

• Dual-stack — Run both protocols simultaneously. Simple in theory, expensive in practice: you need IPv4 addresses for every node, which defeats the purpose when addresses are scarce.
• Tunneling — Encapsulate one protocol inside the other (typically IPv6 in IPv4, or IPv4 in IPv6). The endpoints see native packets; the tunnel hides the incompatibility. Adds MTU overhead and complicates path MTU discovery.
• Translation — Rewrite packet headers at a gateway, converting between IPv4 and IPv6 in-flight. Analogous to NAT but across protocol boundaries. Breaks end-to-end transparency and has protocol-specific limitations (e.g., IPsec, FTP).

No single approach works everywhere. The optimal choice depends on whether the operator controls both endpoints, whether IPv4 addresses are available, whether the access network is IPv4-only or IPv6-only, and how much complexity the operator is willing to manage. This is why so many mechanisms exist.

NAT64 and DNS64: The IPv6-Only Access Model

NAT64 (RFC 6146) is the dominant transition technology for IPv6-only networks that need to reach IPv4-only servers. It is a stateful translator that sits in the network path, converting IPv6 packets to IPv4 and maintaining session state — conceptually similar to CGNAT, but translating across protocol versions rather than just address spaces.

The mechanism relies on a well-known prefix — 64:ff9b::/96 — defined in RFC 6052. An IPv4 address is embedded in the last 32 bits of this prefix. For example, to reach 93.184.216.34 (an IPv4-only server), the IPv6 host sends packets to 64:ff9b::5db8:d822 (where 5db8:d822 is the hex encoding of 93.184.216.34). The NAT64 gateway strips the IPv6 header, constructs an IPv4 packet, and forwards it. Return traffic is reverse-translated.

DNS64 (RFC 6147) complements NAT64 by synthesizing AAAA records for domains that only have A records. When an IPv6-only client queries for example.com and the authoritative DNS server returns only an A record (93.184.216.34), the DNS64 resolver synthesizes an AAAA record by prepending the NAT64 prefix: 64:ff9b::5db8:d822. The client then connects to this synthesized address, which routes through the NAT64 gateway.

Operators can also use network-specific prefixes (NSP) instead of the well-known prefix. This allows more flexibility — for example, routing NAT64 traffic through specific gateways — but requires configuring the prefix in DNS64 resolvers and on CLAT devices. The well-known prefix 64:ff9b::/96 has the advantage of being universally recognized, but RFC 6052 restricts its use: it must not be used when the source or destination is a private (RFC 1918) address, because the NAT64 gateway cannot distinguish between different private address spaces.

Who uses it: T-Mobile US was the pioneer, deploying NAT64/DNS64 across its entire mobile network starting in 2014. Today, most major mobile carriers worldwide operate IPv6-only access networks with NAT64: T-Mobile, Verizon Wireless, AT&T Wireless, EE (UK), Reliance Jio (India), SK Telecom (South Korea), and Telstra (Australia). Apple requires all iOS apps submitted to the App Store to work on IPv6-only networks with NAT64/DNS64 — this single policy decision forced thousands of application developers to fix IPv4 assumptions in their code.

464XLAT: Making IPv6-Only Work for Everything

Pure NAT64/DNS64 has a critical limitation: it only works for applications that use DNS. Any application that uses literal IPv4 addresses — hardcoded IPs in configuration files, peer-to-peer protocols, VPN software, or apps that use the AF_INET socket API directly — will fail on an IPv6-only network. The DNS64 resolver never sees these requests, so no AAAA synthesis occurs.

464XLAT (RFC 6877) solves this by combining a client-side translator (CLAT) with the provider-side NAT64 (PLAT). The name reflects the double translation: IPv4 at the client is translated to IPv6 (4-to-6), transmitted across the IPv6-only network, then translated back to IPv4 (6-to-4) at the provider edge.

The CLAT runs on the end device — in the phone's operating system or on a CPE router. It presents a local IPv4 interface (typically 192.0.0.1/29 from the RFC 7335 "dummy" range) to applications. When an app sends an IPv4 packet, the CLAT translates it to IPv6 using the NAT64 prefix, and the packet traverses the IPv6-only network to the PLAT, which performs the reverse translation. From the application's perspective, it has a working IPv4 stack. From the network's perspective, only IPv6 packets traverse the infrastructure.

464XLAT is stateless at the CLAT (it performs a 1:1 mapping using SIIT — more on that below), so no per-flow state is maintained on the device. All the stateful NAT happens at the PLAT, which is the same NAT64 gateway the operator already runs. This is a critical architectural advantage: the operator consolidates all NAT state in a small number of well-provisioned gateways rather than distributing it across millions of devices.

Who uses it: 464XLAT is essentially universal on mobile networks today. Android has included a CLAT implementation since Android 4.3 (2013). iOS has supported it since iOS 12.2 (2019, though Apple's implementation is somewhat different — it uses their own CLAT for tethered devices). Windows 10/11 support CLAT for mobile broadband interfaces. Every major mobile carrier running NAT64 also runs 464XLAT. T-Mobile US, SK Telecom, KDDI (Japan), and Reliance Jio are prominent deployments.

DS-Lite: IPv4-in-IPv6 Tunneling

Dual-Stack Lite (DS-Lite, RFC 6333) takes the opposite approach from NAT64. Instead of translating, it tunnels IPv4 traffic inside IPv6. The access network is IPv6-only — no IPv4 addresses are assigned to subscribers. When a subscriber's device sends an IPv4 packet, the CPE (home router) encapsulates it in an IPv6 packet using an IPv4-in-IPv6 tunnel (specifically, a softwire) to a centralized AFTR (Address Family Transition Router) in the ISP's network. The AFTR decapsulates the IPv4 packet and performs CGNAT to forward it onto the IPv4 internet.

The key distinction from NAT64: DS-Lite preserves IPv4 semantics end-to-end (modulo the CGNAT at the AFTR). Applications see normal IPv4 — no DNS64 trickery, no synthesized addresses, no protocol translation. The tradeoff is that IPv4 packets still consume bandwidth on the access network (inside their IPv6 wrapper), and the AFTR must handle the full CGNAT load for all subscribers.

DS-Lite assigns each subscriber only an IPv6 prefix (typically a /56 or /48 via DHCPv6-PD) and the address of the AFTR. The CPE constructs a tunnel to the AFTR automatically. IPv4 traffic goes through the tunnel; IPv6 traffic goes natively. This is sometimes called "skinny dual-stack" because the subscriber appears to have dual-stack connectivity, but the IPv4 path is tunneled and NATed.

Who uses it: DS-Lite is extremely popular among European and Asian wireline ISPs. Prominent deployments include Free (France), Swisscom, Unitymedia/Vodafone Germany, Softbank (Japan), and several ISPs in mainland China. It is particularly attractive for cable and fiber operators who want to run an IPv6-only access network but need to maintain IPv4 reachability without assigning public IPv4 addresses to each subscriber.

MAP-E and MAP-T: Stateless IPv4 Sharing

DS-Lite's centralized AFTR creates a scaling bottleneck: all IPv4 traffic for thousands of subscribers funnels through a small number of CGNAT boxes. MAP-E (Mapping of Address and Port using Encapsulation, RFC 7597) and MAP-T (Mapping of Address and Port using Translation, RFC 7599) solve this by distributing the IPv4 NAT function to the CPE, eliminating the need for centralized stateful NAT entirely.

The core idea: each subscriber is algorithmically assigned a shared IPv4 address plus a port range. For example, subscriber A gets 203.0.113.1 ports 1024-5119, subscriber B gets 203.0.113.1 ports 5120-9215, and so on. The mapping between IPv6 prefix and (IPv4 address, port range) is deterministic — computable from a set of MAP rules distributed via DHCPv6. No per-subscriber state is needed in the network; any router can derive the mapping from the rules.

MAP-E uses encapsulation (IPv4-in-IPv6, like DS-Lite), while MAP-T uses stateless translation (double NAT46/64, like 464XLAT). In both cases, the CPE performs port-restricted NAT for IPv4, confining each subscriber's IPv4 connections to its assigned port range. The border relay (BR) at the ISP edge either decapsulates (MAP-E) or translates (MAP-T) and forwards the IPv4 packet.

The statelessness is the key advantage: the border relay does not maintain per-flow state. It simply applies the deterministic mapping rules. This means BRs can be horizontally scaled, load-balanced with anycast, and are far simpler than a stateful CGNAT. The tradeoff is that subscribers are limited to their assigned port range, which caps the number of simultaneous connections per shared IPv4 address (typically 2000-4000 ports per subscriber).

Who uses it: MAP-E is the dominant transition technology in Japan, deployed by NTT, KDDI, and SoftBank for their FTTH services. Japanese ISPs specifically chose MAP-E because it allows them to avoid the cost and complexity of centralized CGNAT. MAP-T has seen less deployment but is used by some operators who prefer translation over encapsulation for MTU reasons (MAP-T avoids the 40-byte IPv6 encapsulation overhead).

6rd: Rapid IPv6 Deployment Over IPv4

6rd (IPv6 Rapid Deployment, RFC 5969) works in the opposite direction from DS-Lite: it tunnels IPv6 inside IPv4 to provide IPv6 connectivity over an IPv4-only access network. Each subscriber derives their IPv6 prefix algorithmically from their IPv4 address and a delegated prefix provided by the ISP. The CPE encapsulates IPv6 packets in IPv4 for transit across the access network, and a border relay at the ISP edge decapsulates and forwards them onto the native IPv6 internet.

6rd was pioneered by Free (France) in 2007 — before it was standardized — and proved that an ISP could deploy IPv6 to millions of subscribers rapidly without upgrading the access network infrastructure. The ISP only needs to deploy border relays and push a firmware update to CPEs. The access network itself remains pure IPv4 and requires no changes.

The limitation of 6rd is that it does nothing for IPv4 address exhaustion. Subscribers still need a full IPv4 address (it is used as the tunnel outer address). 6rd is a tool for adding IPv6, not for reducing IPv4 dependence. It is typically a stepping stone: ISPs deploy 6rd to get IPv6 running quickly, then migrate to native dual-stack or DS-Lite as they upgrade their infrastructure.

Who uses it: Beyond Free, Swisscom used 6rd during their IPv6 rollout, and several US cable operators evaluated it. Adoption has declined as most access networks now support native IPv6. 6rd remains useful for operators with legacy IPv4-only access infrastructure that cannot be easily upgraded.

SIIT and NPTv6: Stateless Translation

SIIT (Stateless IP/ICMP Translation, RFC 7915) is the foundational algorithm used by several higher-level mechanisms. It defines how to translate between IPv4 and IPv6 packet headers without maintaining any per-flow state. SIIT translates IP headers, ICMP messages, and adjusts checksums. It does not translate port numbers — that is left to NAT64 (which is essentially SIIT plus stateful port mapping).

SIIT on its own is most useful for SIIT-DC (RFC 7755), a data center architecture where servers run IPv6-only and a stateless translator at the data center edge maps a pool of IPv4 addresses 1:1 to IPv6 addresses. This allows operators to run a pure IPv6 data center while maintaining IPv4 reachability. Because the mapping is stateless and 1:1, there is no port restriction, no session state, and trivial failover — any translator instance can handle any packet.

NPTv6 (Network Prefix Translation for IPv6, RFC 6296) is the IPv6 equivalent of 1:1 NAT for IPv4. It rewrites the network prefix portion of an IPv6 address while preserving the interface identifier (the last 64 bits). Unlike traditional NAT, NPTv6 is stateless, deterministic, and does not modify port numbers. It exists primarily for multihoming: an organization with provider-assigned (PA) address space from two ISPs can use NPTv6 to present a stable internal prefix while translating to each provider's prefix at the border.

NPTv6 is controversial in the IPv6 community because it reintroduces address translation, which IPv6 was supposed to eliminate. However, it fills a real operational gap: PI (provider-independent) address space is not always available or practical, and renumbering an entire network when changing ISPs is operationally painful. NPTv6 is a pragmatic compromise.

Deprecated: 6to4 and Teredo

6to4 (RFC 3056, deprecated by RFC 7526) was an automatic tunneling mechanism that derived an IPv6 prefix from a host's public IPv4 address. Any host with a public IPv4 address could generate a 2002::/16 prefix by embedding the IPv4 address in the IPv6 prefix. Packets to other 6to4 addresses could be sent directly (IPv6-in-IPv4 encapsulation); packets to the native IPv6 internet went through public relay routers.

6to4 was simple and required no ISP involvement, which made it attractive for early adopters. It was also deeply unreliable in practice. The public relay routers (192.88.99.1, an anycast address) were operated by volunteers with varying quality. Many networks filtered protocol 41 (the IPv6-in-IPv4 encapsulation), causing silent black holes. Asymmetric routing through different relays caused path MTU issues. The IETF deprecated 6to4 in 2015 and recommends that hosts not use it.

Teredo (RFC 4380) attempted to solve 6to4's biggest limitation: it did not work behind NAT. Teredo encapsulates IPv6 packets in UDP/IPv4, which traverses most NATs. It uses a Teredo server for initial connectivity and NAT traversal (similar to STUN), then establishes direct UDP communication between Teredo clients. Windows shipped with Teredo enabled by default starting with Vista.

Teredo suffered from the same unreliability as 6to4 — reliance on third-party relays, poor performance, and firewalls that block it. Microsoft disabled Teredo by default in Windows 10. The IETF has not formally deprecated Teredo, but it is effectively dead. Both 6to4 and Teredo demonstrated that automatic, unmanaged tunneling mechanisms produce unreliable connectivity. The industry moved toward ISP-managed solutions (NAT64, DS-Lite, MAP-E) where the operator controls the entire path.

Happy Eyeballs: The Client-Side Glue

Happy Eyeballs (RFC 8305) is not a transition mechanism per se — it is the algorithm that makes transition mechanisms tolerable for end users. When a client needs to connect to a dual-stack destination (one with both A and AAAA records), it must choose which protocol to try first. A naive approach — try IPv6 first, fall back to IPv4 on timeout — introduces seconds of latency when IPv6 is broken (misconfigured, black-holed, or just slower). Happy Eyeballs eliminates this by racing both protocols simultaneously.

The RFC 8305 algorithm works as follows:

1. Query for both A and AAAA records simultaneously.
2. When the first response arrives (usually AAAA, since it is preferred), start a connection attempt to the first IPv6 address.
3. If the IPv6 connection is not established within 250ms, start a parallel IPv4 connection attempt without canceling the IPv6 attempt.
4. Use whichever connection succeeds first. Cache the winning protocol family and prefer it for subsequent connections to the same destination.

The 250ms head start gives IPv6 a preference (to encourage adoption) while ensuring that broken IPv6 adds at most 250ms of latency rather than a full TCP connection timeout (typically 30-75 seconds). The algorithm also interleaves addresses from both families when multiple addresses are available, trying IPv6 #1, then IPv4 #1, then IPv6 #2, and so on.

Happy Eyeballs is implemented in every major browser (Chrome, Firefox, Safari, Edge), in operating system network stacks (macOS, iOS, Windows, Android), and in language runtimes (Go's net.Dial, Python's asyncio, curl). It is arguably the single most important piece of the transition puzzle on the client side: without it, the slightest IPv6 problem would cause users to experience broken connectivity, creating massive pressure to disable IPv6 entirely.

One subtle detail: Happy Eyeballs interacts with DNS64 in an important way. On an IPv6-only network with DNS64, the resolver synthesizes AAAA records for IPv4-only destinations. If the client also has a CLAT (464XLAT) providing a local IPv4 interface, both the synthesized AAAA and the real A record will produce working connections — but they take different paths through the network. Happy Eyeballs will race both and pick the faster one, which may or may not be the path the operator intended.

How These Mechanisms Interact with BGP

Transition technologies create interesting routing artifacts visible in the BGP looking glass. The NAT64 well-known prefix 64:ff9b::/96 is not supposed to appear in the global BGP routing table — it is meant to be routed internally within the ISP's network to the NAT64 gateway. If you see it announced globally, something is misconfigured.

The deprecated 6to4 prefix 2002::/16 still appears in some routing tables, though most operators filter it. Similarly, the 6to4 relay anycast prefix 192.88.99.0/24 may still be visible, though RFC 7526 deprecated it.

DS-Lite and MAP-E/MAP-T traffic appears as normal IPv6 in BGP — the encapsulation or translation happens at the endpoints, and the transit network sees native IPv6 packets with the subscriber's IPv6 prefix as the source. The IPv4 traffic is invisible to the IPv6 routing infrastructure until it reaches the AFTR or border relay.

6rd creates a different pattern: the tunneled IPv6 traffic appears as IPv4 in the access network (it is encapsulated in IPv4), but the 6rd border relay announces the ISP's IPv6 prefix into BGP. From the global IPv6 routing table's perspective, the ISP looks like a normal IPv6 autonomous system — the tunneling is invisible.

For operators using SIIT-DC, the IPv4 service addresses are announced in BGP normally, and the border translator handles the conversion. The data center's internal IPv6 routing is not visible externally. This is architecturally clean: the transition mechanism is entirely contained within the operator's network, with no impact on global routing.

Why There Is No One-Size-Fits-All

The proliferation of transition mechanisms is sometimes cited as evidence of IPv6's failure. The reality is more nuanced: different network architectures have fundamentally different constraints, and a single mechanism cannot satisfy all of them.

Mobile carriers gravitate toward NAT64/DNS64 + 464XLAT because mobile networks are greenfield (relatively easy to deploy IPv6-only), devices are under OS vendor control (Android/iOS ship CLAT), and address conservation is critical (carriers serve hundreds of millions of devices). A mobile network does not need to support arbitrary CPE hardware — it controls the entire stack.

Wireline ISPs face a different problem: they must support a vast installed base of CPE routers with varying capabilities. DS-Lite and MAP-E work here because they require CPE support (which the ISP can mandate in new CPE models) but do not require changes to the access network infrastructure. The choice between DS-Lite and MAP-E often comes down to whether the ISP wants centralized CGNAT (DS-Lite) or distributed, stateless port sharing (MAP-E). Japanese ISPs chose MAP-E to avoid CGNAT costs; European ISPs often chose DS-Lite because their existing CGNAT infrastructure could be reused.

Data center operators prefer SIIT-DC because it is stateless, transparent, and requires no changes to servers. Servers run IPv6-only, the translator handles the rest, and the operator gets all the benefits of a single-stack network (simplified firewall rules, no dual-stack complexity, no IPv4 address exhaustion pressure on the server side).

Enterprise networks mostly run dual-stack where they can, because they have enough IPv4 addresses (for now) and need to support legacy applications that cannot tolerate any form of translation. NPTv6 appears in enterprises that want to multihome without PI space, but this is a niche use case.

The Current State of IPv6 Deployment

As of 2026, global IPv6 adoption is approximately 45% of traffic as measured by Google, with enormous regional variation. The leaders:

• India (~70%) — driven by Reliance Jio's IPv6-only mobile network serving 400+ million subscribers
• France (~55%) — early adoption by Free (6rd, then DS-Lite) and Orange
• Germany (~55%) — Deutsche Telekom's dual-stack and DS-Lite deployments
• United States (~50%) — T-Mobile, Comcast, and AT&T leading
• Japan (~50%) — MAP-E deployments by NTT and KDDI
• Brazil (~40%) — Vivo, Claro, and other major ISPs

The laggards tend to be regions where IPv4 addresses are still available (parts of Africa, Central Asia) or where network infrastructure is old and difficult to upgrade. China is a notable case: despite government mandates for IPv6 adoption, actual traffic levels remain lower than the infrastructure capability suggests, partly because many content providers are slow to enable IPv6.

The content side matters as much as the access side. A user on an IPv6-only network gains nothing if the destination is IPv4-only — the traffic still goes through NAT64. Major content providers (Google, Facebook, Netflix, Cloudflare, Akamai) have been dual-stack for years. The long tail of smaller websites and services remains predominantly IPv4-only, which is why NAT64 and 464XLAT remain essential even as IPv6 adoption grows.

The Endgame

The long-term vision is straightforward: eventually, the internet will be IPv6-only, and all transition mechanisms will be unnecessary. The practical question is how long "eventually" takes.

The most likely path is not a clean cutoff but a gradual reduction in IPv4 traffic until maintaining IPv4 infrastructure becomes more expensive than the value it provides. Mobile networks are already there — many are IPv6-only internally, with NAT64 handling the shrinking tail of IPv4-only destinations. Wireline ISPs will follow as they refresh CPE hardware and access network equipment.

The last mile of the transition will be the hardest. Legacy industrial equipment, embedded systems, IoT devices with hardcoded IPv4 addresses, and applications that use IPv4 literals will persist for decades. Some form of translation (likely NAT64) will be needed for a very long time. The operational reality is that IPv4 is not going away — it is just becoming less and less relevant to the critical path of internet traffic.

You can observe this transition in real time by exploring the BGP looking glass: compare the AS paths and prefix counts for IPv4 versus IPv6 for any major network. The IPv6 table is growing steadily while IPv4 growth has flattened — the clearest signal that the transition, messy as it is, is actually working.