NAT64 and 464XLAT: IPv6-Only Network Solutions

As the internet transitions toward IPv6, a stubborn reality remains: a significant portion of internet infrastructure is still IPv4-only. Web servers, APIs, game services, and legacy applications may never add native IPv6 support. For carriers and network operators deploying IPv6-only access networks, this creates a fundamental challenge — how do users reach these IPv4-only destinations?

The answer is translation: a family of technologies that allow IPv6 packets to traverse IPv4 infrastructure and vice versa. NAT64 and 464XLAT are the two most important mechanisms, and together they enable fully functional IPv6-only deployments at carrier scale.

What Problem Does NAT64 Solve?

In a pure IPv6-only network, a device has only an IPv6 address. When it attempts to connect to an IPv4-only destination — say, 192.0.2.10 — there is no direct path. The device cannot send IPv6 packets to an IPv4 address.

NAT64 (Network Address Translation 64) solves this by placing a translator on the network boundary. This translator:

1. Accepts IPv6 packets from clients destined for a special IPv6 prefix
2. Rewrites the packet headers, converting the IPv6 source to an IPv4 address
3. Forwards the resulting IPv4 packet to the destination
4. Receives the IPv4 reply and translates it back to IPv6 before returning it to the client

The client believes it connected to an IPv6 address the entire time. The IPv4 server never knows it was talking to an IPv6-only device.

The NAT64 Prefix

NAT64 uses a reserved IPv6 prefix to represent IPv4 addresses. The well-known prefix defined in RFC 6052 is:

64:ff9b::/96

To represent the IPv4 address 192.0.2.10, a NAT64-aware system constructs:

64:ff9b::192.0.2.10
or in hex:
64:ff9b::c000:020a

The last 32 bits of the IPv6 address contain the IPv4 address. Any packet destined for an address in the 64:ff9b::/96 prefix is routed to the NAT64 gateway, which strips the prefix and forwards it to the embedded IPv4 destination.

Operators can also deploy with a custom NAT64 prefix (a /96 from their own IPv6 space) if they need to avoid the well-known prefix for policy reasons.

DNS64: The Missing Piece

NAT64 handles packet translation, but it does not help with DNS. When a client resolves example.com and the server is IPv4-only, the DNS response contains only an A record (IPv4 address). An IPv6-only client that receives only an A record has no way to know it should prepend the NAT64 prefix.

DNS64 solves this. DNS64 is a DNS resolver modification that:

1. Receives a DNS query from a client
2. Queries upstream DNS as normal
3. If the response contains an A record but no AAAA record, synthesizes an AAAA record by embedding the IPv4 address in the NAT64 prefix

Query:  example.com AAAA
Upstream returns: A 93.184.216.34 (no AAAA)
DNS64 synthesizes: AAAA 64:ff9b::5db8:d822
Client connects to: 64:ff9b::5db8:d822
NAT64 gateway sees IPv6 packet, translates to 93.184.216.34

DNS64 and NAT64 always work in tandem. A NAT64 gateway without DNS64 means clients cannot discover the synthetic IPv6 addresses for IPv4-only destinations.

DNS64 Deployment

DNS64 is implemented in the recursive resolver. Common implementations include:

• BIND 9 — dns64 configuration option
• Unbound — module-config: "dns64 iterator" with dns64-prefix
• PowerDNS Recursor — dns64-prefix option

The resolver must be on the network path — typically the ISP's or enterprise's internal resolver.

NAT64 Gateway Implementations

The NAT64 translator itself is a separate component, usually running on a dedicated host or router:

At carrier scale, NAT64 gateways handle millions of concurrent flows and must maintain state tables similar to traditional NAT44 devices.

464XLAT: Solving the Hard Cases

NAT64 with DNS64 handles the majority of use cases, but fails in specific scenarios:

• Applications that embed literal IPv4 addresses (bypassing DNS)
• Applications that use raw sockets and detect the address family
• Legacy applications that explicitly refuse IPv6 connections
• Some VoIP and real-time communication protocols

464XLAT (defined in RFC 6877) adds a second translation layer on the client device itself, enabling even stubborn IPv4-only applications to work on an IPv6-only network.

464XLAT Architecture

464XLAT introduces two components:

Client Device                  Network                  Internet
+------------------+          +----------+          +-----------+
| IPv4-only app    |          |          |          |           |
|       |          |          |          |          |  IPv4     |
|   CLAT (client)  | --IPv6--> | PLAT     | --IPv4-> |  Server   |
| 192.0.0.x/29     |          | (NAT64)  |          |           |
+------------------+          +----------+          +-----------+

• CLAT (Customer-side Translator) — Runs on the client device. Creates a virtual IPv4 interface (typically from 192.0.0.0/29) and translates outgoing IPv4 packets to IPv6 using stateless translation (NAT46).
• PLAT (Provider-side Translator) — The NAT64 gateway at the network operator. Translates IPv6 back to IPv4 for the internet.

The net result: an IPv4-only application sends a packet to 192.0.0.1 (the CLAT virtual IP), the CLAT wraps it in IPv6, the PLAT unwraps it and sends it to the real IPv4 internet. The application never knows IPv6 was involved.

464XLAT on Android

Google made 464XLAT a core feature of Android in version 4.3 (2013). The CLAT implementation (clatd) is built into Android's networking stack. This was a critical enabler for carriers to deploy IPv6-only LTE networks:

• T-Mobile US deployed IPv6-only LTE in 2013, using 464XLAT for compatibility
• Most major mobile carriers worldwide have followed
• As of 2024, the majority of mobile IPv6 traffic uses IPv6-only access with 464XLAT

464XLAT on iOS

Apple added 464XLAT support (CLAT) in iOS 9.3, following Apple's App Store requirement that apps must work on IPv6-only networks. This requirement forced many developers to audit and fix IPv4-literal address embedding in their code.

464XLAT on Linux

The clatd daemon is available for Linux. It works alongside systemd-networkd or NetworkManager and activates automatically when it detects the network provides DNS64.

Carrier-Grade IPv6-Only Deployments

Major use cases for NAT64/464XLAT today:

Mobile Networks

LTE and 5G networks are naturally IPv6-native. Giving each handset a public IPv4 address wastes the scarce IPv4 pool. With IPv6-only + 464XLAT:

• Each device gets a /64 IPv6 prefix (billions of addresses)
• IPv4 connectivity provided by shared NAT64 gateways (far fewer IPv4 addresses needed)
• Native IPv6 connections to IPv6-capable services (no translation overhead)

Enterprise IPv6-Only Internal Networks

Organizations transitioning to IPv6-only can use NAT64/464XLAT for:

• Legacy Windows applications that embed IPv4 literals
• Printers and IoT devices without IPv6 support
• VPN clients with IPv4-only configurations

Cloud Provider Networks

AWS, GCP, and Azure all support IPv6-only subnets with NAT64 gateways for outbound IPv4 internet access. This simplifies address management in large-scale cloud deployments.

Limitations and Gotchas

NAT64/464XLAT is not perfect:

Applications embedding IPv4 literals — Apps that hardcode 192.168.1.1 or similar cannot use DNS64 synthesis. 464XLAT handles most of these at the device level, but server-side applications pointing to literal addresses still fail.

IPsec and encrypted protocols — Some VPN protocols encapsulate the original packet in a way that prevents translation. IKEv2 with NAT traversal generally works; older IPsec configurations may not.

Peer-to-peer applications — P2P protocols like BitTorrent use IPv4-based peer exchange. Connecting to IPv4-only peers requires traversing NAT64, which may limit performance or connectivity.

Port control — Unlike CGNAT where clients sometimes need PCP/UPnP for inbound connections, NAT64 is strictly outbound-initiated (for the IPv6 client). Inbound connections from IPv4 internet to IPv6-only clients are generally not possible without additional mechanisms.

Hairpinning — If two IPv6-only clients on the same network need to communicate via an IPv4 address (e.g., both have IPv6 but one is using a NAT64-synthesized address), hairpin NAT behavior at the gateway is required.

Testing NAT64 Reachability

# Check if your network provides NAT64 by querying ipv4only.arpa
dig AAAA ipv4only.arpa

# Should return a AAAA record with 64:ff9b:: prefix if DNS64 is active
# Example: 64:ff9b::c000:aa64

# Test actual connectivity through NAT64
ping6 64:ff9b::8.8.8.8  # Should reach Google's DNS via NAT64

# Apple's NAT64 detection endpoint
curl -6 https://nat64check.net/

The ipv4only.arpa domain is specifically reserved for NAT64 discovery — it has only A records pointing to 192.0.0.170 and 192.0.0.171. If DNS64 is active, it will synthesize AAAA records, revealing the NAT64 prefix in use.

Summary

NAT64 and 464XLAT form the cornerstone of modern IPv6-only deployments:

• NAT64 translates IPv6 packets to IPv4 at the network boundary, enabling IPv6-only clients to reach IPv4 services
• DNS64 synthesizes AAAA records for IPv4-only destinations, directing clients through the NAT64 gateway
• 464XLAT adds a client-side translation layer (CLAT) that makes even IPv4-literal applications work on IPv6-only networks
• Together, these mechanisms enable carriers and enterprises to deploy IPv6-only networks without breaking compatibility with the IPv4 internet