How 464XLAT Works: IPv4 over IPv6-Only Networks

464XLAT is the most widely deployed IPv6 transition mechanism on mobile networks, used by billions of devices daily to access IPv4-only services over IPv6-only cellular infrastructure. Defined in RFC 6877, 464XLAT combines two translation stages -- a stateless SIIT translator on the customer device (CLAT) and a stateful NAT64 translator in the provider network (PLAT) -- to give legacy IPv4 applications a working IPv4 socket while the actual wire traffic is pure IPv6. Every major mobile carrier in the world, including T-Mobile US, AT&T, Verizon, NTT Docomo, KDDI, SK Telecom, and Reliance Jio, runs 464XLAT today. If you are reading this on a mobile device, there is a strong chance 464XLAT is translating your traffic right now.

Why Pure NAT64 Is Not Enough

Before understanding 464XLAT, you need to understand the problem it solves. NAT64 (RFC 6146) allows an IPv6-only host to reach IPv4-only servers by translating IPv6 packets to IPv4 at a network gateway. Combined with DNS64 (RFC 6147), which synthesizes AAAA records for IPv4-only domains, this works well for most traffic: the application resolves a hostname, DNS64 returns a synthetic IPv6 address (typically in the 64:ff9b::/96 prefix), the host sends an IPv6 packet, and the NAT64 gateway translates it to IPv4.

The problem is applications that use IPv4 address literals -- hardcoded addresses like 93.184.216.34 embedded directly in application code, configuration files, or protocols. These applications never issue a DNS query, so DNS64 never gets a chance to synthesize an address. The IPv6-only host has no IPv4 stack, so it cannot construct an IPv4 packet. The application simply fails. This is not an edge case. Significant categories of real-world software use IPv4 literals:

Peer-to-peer protocols -- BitTorrent trackers, WebRTC ICE candidates, SIP/VoIP signaling all exchange raw IPv4 addresses
Gaming -- Many game clients use hardcoded server IPs or receive server lists as IPv4 addresses from matchmaking services
Enterprise VPN clients -- IPsec and other VPN protocols often negotiate with IPv4 literals
Legacy corporate apps -- Internal applications that embed server addresses in configuration
Embedded protocols -- FTP (which embeds addresses in its control channel), SIP, RTSP, and H.323 all carry IPv4 addresses in application-layer payloads

A carrier deploying IPv6-only with NAT64+DNS64 would break all of these applications. 464XLAT solves this by providing the device with a real IPv4 address and a local translation layer, so applications can use IPv4 literals freely -- the CLAT translates them to IPv6 before they hit the wire.

The 464XLAT Architecture

The name "464XLAT" describes the protocol journey: IPv4 from the application, translated to IPv6 for the network, translated back to IPv4 at the provider edge. The two translators are:

CLAT (Customer-side translator) -- Runs on the end-user device (phone, tablet, PC). Performs stateless translation using SIIT (RFC 7915). Takes IPv4 packets from local applications, rewrites them as IPv6 packets using the NAT64 prefix, and sends them out the IPv6-only interface. No port mapping, no state table -- a pure 1:1 header rewrite.
PLAT (Provider-side translator) -- Runs in the carrier's network. This is a standard stateful NAT64 gateway. Takes the IPv6 packets from the CLAT, translates them back to IPv4, applying port-based NAT to multiplex many subscribers onto shared IPv4 addresses. This is the same NAT64 that serves dual-stack DNS64 traffic.

The CLAT and PLAT do not communicate directly or share any state. The CLAT simply generates IPv6 packets using the well-known NAT64 prefix (64:ff9b::/96 or a provider-specific prefix discovered via DNS64 or Router Advertisement options). The PLAT processes these packets identically to any other NAT64 traffic. This stateless coupling is what makes 464XLAT elegant: the PLAT does not even know whether its traffic came from a CLAT or from a native IPv6 application using DNS64-synthesized addresses.

CLAT: The Customer-Side Translator in Detail

The CLAT is the piece that distinguishes 464XLAT from plain NAT64+DNS64. It runs on the end-user device itself and creates a local IPv4 interface that applications can bind to. The translation is stateless SIIT (Stateless IP/ICMP Translation, RFC 7915): every IPv4 packet entering the CLAT is converted to an IPv6 packet by mechanically rewriting headers, with no connection tracking or port mapping. The inverse happens for return traffic. Key details of the CLAT:

Local IPv4 address: 192.0.0.4 -- The CLAT assigns this address (from the 192.0.0.0/29 range reserved by RFC 7335 for CLAT use) to the local tun interface. Applications bind to this address. It is never seen on the wire -- the CLAT rewrites it to the device's IPv6 CLAT address before the packet leaves.
IPv6 CLAT address -- The device uses a dedicated IPv6 address (from a /64 delegated by the carrier) as the source address in translated packets. This is distinct from the device's regular IPv6 address to avoid routing conflicts.
NAT64 prefix embedding -- The CLAT embeds the IPv4 destination address in the NAT64 prefix. If the NAT64 prefix is 64:ff9b::/96, a packet to 93.184.216.34 gets an IPv6 destination of 64:ff9b::5db8:d822 (where 5db8:d822 is the hex encoding of 93.184.216.34).
Protocol translation -- IPv4 protocol numbers map to IPv6 next-header values (TCP=6 stays 6, UDP=17 stays 17, ICMP=1 becomes ICMPv6=58 with message type remapping per RFC 7915).
No port mapping -- Because the CLAT is 1:1 (one IPv4 address mapped to one IPv6 address), it does not need to rewrite ports. The source and destination ports pass through unchanged. This is a critical distinction from NAT: CLAT does not break applications that are sensitive to port rewriting.
MTU handling -- The CLAT tun interface advertises a reduced MTU (typically 1260 bytes) to account for the IPv6 header being 20 bytes larger than IPv4. Alternatively, some implementations use the same MTU and fragment at the CLAT, but reducing the MTU is the recommended approach to avoid fragmentation.

Android CLAT Implementation

Android has included a CLAT implementation since Android 4.3 (2013), making it the earliest and most widely deployed CLAT. The implementation is a userspace daemon called clatd, located in the AOSP source tree at packages/modules/Connectivity/clatd/. Here is how it works:

Detection -- When Android connects to a network that provides only IPv6 (no IPv4 address via DHCP or PPP), the connectivity stack detects this and starts clatd.
NAT64 prefix discovery -- clatd discovers the NAT64 prefix either via DNS64 synthesis probing (it queries ipv4only.arpa, which always resolves to 192.0.0.170/171, and examines the synthesized AAAA response to extract the NAT64 prefix) or via the PREF64 Router Advertisement option (RFC 8781).
Tun interface creation -- clatd creates a v4-ifname tun interface (e.g., v4-wlan0 or v4-rmnet0). This interface gets the address 192.0.0.4 with a /29 netmask.
Routing -- A default route for IPv4 traffic is installed pointing at the tun interface. Any IPv4 packet from any application is captured by this route and delivered to clatd.
Translation -- clatd translates each IPv4 packet to IPv6 using SIIT rules. In modern Android (11+), this translation has been moved from userspace to an eBPF program running in the kernel for performance, but the logic is identical.
Egress -- The translated IPv6 packet is injected into the actual network interface (e.g., rmnet0) and sent to the carrier network as a normal IPv6 packet.

You can observe this on a rooted Android device:

# Show the CLAT tun interface
$ ip addr show v4-rmnet0
    inet 192.0.0.4/29 scope global v4-rmnet0

# Show the routing table -- IPv4 default route via CLAT
$ ip route show table main
default dev v4-rmnet0 proto static

# Show the IPv6 address used for CLAT
$ ip -6 addr show rmnet0
    inet6 2607:fb90:abcd:1234::1/128 scope global   # regular addr
    inet6 2607:fb90:abcd:1234::f/128 scope global    # CLAT addr

The eBPF-based CLAT in modern Android is notably efficient. It translates packets in the kernel's TC (traffic control) layer, avoiding the overhead of copying packets to userspace and back. Google's measurements show that this adds less than 5 microseconds of latency per packet -- negligible compared to cellular radio latency of 10-50 ms.

iOS CLAT Implementation

Apple added CLAT support in iOS 12.2 (2019), later than Android but covering iPhones, iPads, and Apple Watch (with cellular). Apple's implementation differs from Android in several ways:

Kernel-level translation -- Apple's CLAT runs entirely in the kernel (the nat464 module in the XNU kernel), not as a userspace daemon. This eliminates the userspace-kernel packet copy overhead that earlier Android versions had.
No visible tun interface -- Unlike Android's v4-rmnet0, Apple's CLAT does not create a user-visible tun interface. The translation is handled transparently within the networking stack.
Prefix discovery -- iOS uses the same ipv4only.arpa (RFC 7050) mechanism and PREF64 RA option for NAT64 prefix discovery.
On-demand activation -- iOS activates CLAT only when it detects an IPv6-only network, similar to Android. In some configurations, iOS may also use CLAT on dual-stack networks if the IPv4 connectivity is limited or degraded.

Apple also requires App Store apps to work on IPv6-only networks (a policy enforced since 2016), which pushed app developers to avoid IPv4 literals. However, 464XLAT remains essential for the long tail of apps, system services, and protocols that still rely on IPv4 sockets.

Windows CLAT Support

Windows added CLAT support in Windows 10 version 1903 (May 2019 Update) for cellular connections, and extended it to Wi-Fi and Ethernet in Windows 11. The Windows CLAT implementation:

Uses the teredo tunneling adapter infrastructure repurposed for CLAT translation
Creates a virtual adapter that provides IPv4 connectivity over IPv6-only links
Supports NAT64 prefix discovery via ipv4only.arpa and PREF64 RA option
Integrates with the Windows Connection Manager to automatically activate on IPv6-only networks

Windows CLAT adoption lagged behind mobile platforms because wired/Wi-Fi networks rarely ran IPv6-only configurations until recently. As enterprises begin deploying IPv6-only Wi-Fi with NAT64 (following the success of mobile deployments), Windows CLAT support is becoming more relevant.

PLAT: The Provider-Side Translator

The PLAT is a standard stateful NAT64 gateway (RFC 6146) deployed in the carrier's network. It maintains connection-tracking state for every active flow, mapping each (IPv6 source, source port) tuple to a (public IPv4 address, translated port) tuple -- identical to how CGNAT works but translating between protocol families rather than just rewriting addresses within IPv4.

Key characteristics of the PLAT:

Shared IPv4 pool -- The PLAT maps many subscribers to a smaller pool of public IPv4 addresses using port-based multiplexing. A typical deployment might map 1,000-4,000 subscribers per IPv4 address, using the ~64,000 available ports. This is functionally identical to CGNAT (RFC 6888) in terms of address sharing ratios.
Connection tracking -- The PLAT must maintain state for every active TCP connection, UDP flow, and ICMP mapping. This requires significant memory and CPU, which is why PLATs are typically implemented on purpose-built hardware (e.g., A10 Networks Thunder CGN, F5 BIG-IP AFM, Juniper MX with MS-MPC cards) or high-performance software platforms.
Logging for compliance -- Because the PLAT shares IPv4 addresses among many subscribers, carriers must log every port mapping to comply with lawful intercept requirements. Given that a busy PLAT processes millions of flows per second, this logging infrastructure is substantial.
Hairpinning -- When one subscriber behind a PLAT communicates with another subscriber behind the same PLAT, the traffic must be "hairpinned" -- translated to IPv4 and back to IPv6 within the PLAT. Good implementations detect this and short-circuit the double translation.
Protocol ALGs -- Some PLATs include Application-Layer Gateways (ALGs) for protocols like FTP and SIP that embed IP addresses in their payloads. However, most modern deployments disable ALGs because they cause more problems than they solve, and application-layer protocols have largely adapted.

From the PLAT's perspective, traffic from a CLAT is indistinguishable from traffic generated by a native IPv6 application that obtained its destination address via DNS64. The PLAT does not know or care whether the client used CLAT. This means a carrier can deploy PLAT (NAT64) infrastructure once and serve both DNS64-capable native IPv6 apps and CLAT-translated IPv4 apps simultaneously.

Interaction with DNS64

464XLAT and DNS64 are complementary, not competing. On a 464XLAT-enabled device, traffic takes one of two paths depending on how the destination address was obtained:

DNS64 path (no CLAT involved) -- An application resolves example.com, the DNS64 server synthesizes an AAAA record 64:ff9b::5db8:d822, and the application sends native IPv6 to this address. The traffic goes directly to the PLAT (NAT64) without touching the CLAT. This is the preferred path because it avoids the CLAT translation overhead entirely.
CLAT path -- An application uses an IPv4 literal (e.g., connect(93.184.216.34)) or an application explicitly requests an A record and gets an IPv4 address. The IPv4 packet is routed to the CLAT tun interface, translated to IPv6, and then sent to the PLAT. The PLAT translates it to IPv4 identically to the DNS64 path.

On Android and iOS, the system DNS resolver is aware of NAT64 and will preferentially use AAAA records (either real or DNS64-synthesized) when available. The CLAT path is a fallback for traffic that bypasses DNS entirely or explicitly uses IPv4 sockets. In practice, the majority of traffic on a 464XLAT network flows via the DNS64 path. Google's measurements from Android devices show that roughly 90-95% of traffic uses DNS64/native IPv6, with only 5-10% going through the CLAT. But that 5-10% includes critical applications that would completely fail without CLAT.

Carrier Deployments

464XLAT has achieved near-universal deployment on mobile networks. The progression:

T-Mobile US (2014) -- The first major carrier to deploy 464XLAT at scale, T-Mobile moved its entire LTE network to IPv6-only with 464XLAT. By 2024, over 90% of T-Mobile's mobile traffic was IPv6. T-Mobile's deployment proved that 464XLAT could work at scale with billions of daily connections, paving the way for other carriers.
SKT, KT, LG U+ (South Korea, 2014-2016) -- Korean carriers adopted 464XLAT early, driven by rapid LTE deployment and IPv4 exhaustion in the APNIC region.
NTT Docomo, KDDI, SoftBank (Japan, 2015-2017) -- Japanese carriers deployed 464XLAT across their LTE and later 5G NR networks.
Reliance Jio (India, 2016) -- Jio launched as an IPv6-only greenfield LTE network serving hundreds of millions of subscribers, using 464XLAT for IPv4 compatibility from day one. This is one of the largest single IPv6 deployments in the world.
AT&T, Verizon (US, 2017-2019) -- Both carriers migrated to IPv6-only with 464XLAT on their LTE and 5G networks.
Deutsche Telekom, Vodafone, Orange (Europe, 2018-2020) -- European carriers followed, with some markets deploying 464XLAT on fixed-line broadband in addition to mobile.

The economics are straightforward. An IPv4 address on the open market costs $30-50 (as of 2025). A carrier with 100 million subscribers would need $3-5 billion in IPv4 address costs for 1:1 allocation. With 464XLAT and NAT64, that same carrier can serve 100 million subscribers with a few hundred thousand IPv4 addresses on the PLAT, costing a fraction of a percent of the dual-stack alternative. Combined with eliminating the operational complexity of running dual-stack routing, DHCP, and per-subscriber IPv4 state across the radio and core network, the savings are substantial.

464XLAT on 5G Networks

5G NR networks have universally adopted 464XLAT. The 3GPP 5G core (5GC) specifications explicitly support IPv6-only PDU sessions with CLAT, and all 5G chipset vendors (Qualcomm, MediaTek, Samsung) implement CLAT in their modem firmware. In 5G standalone (SA) deployments, 464XLAT is the default IPv4 connectivity mechanism -- carriers no longer provision IPv4 addresses to individual PDU sessions at all.

The 5G architecture introduces some optimizations relevant to 464XLAT:

URSP rules -- User Equipment Route Selection Policy can direct specific traffic types to bypass CLAT entirely and use native IPv6.
PLAT placement -- In 5G, the PLAT (NAT64 gateway) is typically co-located with the UPF (User Plane Function) to minimize additional latency. Some UPF implementations integrate NAT64 directly rather than using a separate appliance.
IPv6 prefix delegation -- 5G networks can delegate /48 or /56 prefixes to devices, providing ample space for the CLAT IPv6 address without consuming the device's primary /128 assignment.

Performance Overhead

The natural question about double translation is: what does it cost? The answer is surprisingly little, for several reasons:

CLAT overhead is minimal. The CLAT performs a stateless header rewrite -- swapping a 20-byte IPv4 header for a 40-byte IPv6 header (or vice versa), recalculating checksums, and remapping ICMP types. There is no connection-tracking table to look up, no port allocation to perform, and no logging. On modern mobile processors, this adds single-digit microseconds per packet. Android's eBPF-based CLAT performs the translation in the kernel's TC hook, avoiding any context switch to userspace. Apple's kernel-resident CLAT is similarly efficient.

PLAT overhead is real but amortized. The PLAT (NAT64) does maintain per-flow state and performs port allocation, identical to CGNAT. However, carriers already needed CGNAT for IPv4 address conservation regardless of 464XLAT -- the PLAT replaces CGNAT rather than adding to it. The net overhead compared to dual-stack with CGNAT is actually lower because the carrier no longer needs to run IPv4 routing infrastructure in the radio and core network.

Throughput impact: Multiple carrier benchmarks show less than 1% throughput reduction from 464XLAT compared to native IPv4. The bottleneck on mobile networks is always the radio interface, not the CLAT or PLAT translation. Even on high-throughput 5G connections (1+ Gbps), the CLAT translation is not the limiting factor.

Latency impact: The CLAT adds negligible latency (microseconds) relative to cellular radio latency (milliseconds). The PLAT adds latency comparable to any NAT/CGNAT device -- typically 0.1-0.5 ms for the translation and state lookup. Total end-to-end impact is under 1 ms in most deployments.

Where overhead matters: The main concern is not per-packet cost but PLAT state table capacity. Each active flow consumes state in the PLAT. Heavy users (those with many concurrent connections, such as BitTorrent users) can create thousands of flows, consuming PLAT resources. Carriers configure per-subscriber port limits (typically 1,000-4,000 ports) and session timeouts to manage this. UDP flows without explicit teardown are particularly problematic because the PLAT must hold state until a timer expires.

Debugging 464XLAT with Packet Captures

Debugging connectivity issues on 464XLAT networks requires capturing packets at the right point in the translation chain. Here is what you see at each stage:

Capture on the CLAT tun interface (before translation):

# On Android (rooted) -- capture on the CLAT tun
$ tcpdump -i v4-rmnet0 -n
15:30:01.123 IP 192.0.0.4.49152 > 93.184.216.34.443: Flags [S], seq 12345
15:30:01.178 IP 93.184.216.34.443 > 192.0.0.4.49152: Flags [S.], seq 67890, ack 12346
15:30:01.179 IP 192.0.0.4.49152 > 93.184.216.34.443: Flags [.], ack 67891

This looks like normal IPv4 traffic. The application sees exactly this -- a standard TCP handshake to an IPv4 address.

Capture on the physical interface (after CLAT translation):

# On Android (rooted) -- capture on the real interface
$ tcpdump -i rmnet0 -n ip6
15:30:01.123 IP6 2607:fb90:abcd:1234::f.49152 > 64:ff9b::5db8:d822.443: Flags [S], seq 12345
15:30:01.178 IP6 64:ff9b::5db8:d822.443 > 2607:fb90:abcd:1234::f.49152: Flags [S.], seq 67890, ack 12346
15:30:01.179 IP6 2607:fb90:abcd:1234::f.49152 > 64:ff9b::5db8:d822.443: Flags [.], ack 67891

Same TCP handshake, same sequence numbers, same ports -- but now it is IPv6. The source is the CLAT IPv6 address, the destination embeds the original IPv4 address in the NAT64 prefix. Note that the port numbers are unchanged -- this is because the CLAT is stateless SIIT, not NAT.

Capture at the PLAT egress (after NAT64 translation):

# On the carrier's PLAT -- capture on the IPv4 egress
$ tcpdump -i eth0 -n host 93.184.216.34
15:30:01.124 IP 198.51.100.7.23456 > 93.184.216.34.443: Flags [S], seq 12345
15:30:01.177 IP 93.184.216.34.443 > 198.51.100.7.23456: Flags [S.], seq 67890, ack 12346
15:30:01.180 IP 198.51.100.7.23456 > 93.184.216.34.443: Flags [.], ack 67891

Now the traffic is IPv4 again, but the source address and port have changed -- the PLAT has NATted the connection, mapping the subscriber's CLAT IPv6 address to a shared public IPv4 address (198.51.100.7) with a translated source port (23456). The destination server sees a normal IPv4 connection from the carrier's NAT pool.

Common debugging scenarios:

App fails with "network unreachable" -- Check if the CLAT tun interface exists (ip addr show v4-rmnet0). If not, the CLAT may not have started, or the network may not be IPv6-only (CLAT only activates on IPv6-only networks).
Intermittent connection drops -- Check PLAT port exhaustion. If the subscriber has exceeded their port allocation limit, new connections will fail while existing ones continue.
Path MTU issues -- 464XLAT adds 20 bytes of header overhead (IPv6 header is 40 bytes vs IPv4's 20). If the CLAT tun interface MTU is set too high, or if PMTUD is broken, packets may be silently dropped. Check ip link show v4-rmnet0 for the MTU value.
ICMP not working -- The CLAT must translate ICMP to ICMPv6 and back. If the CLAT or PLAT drops ICMP, traceroute and ping will fail. Some older PLAT implementations had bugs in ICMP translation.

Stateless vs Stateful: Why This Split Matters

A critical design decision in 464XLAT is making the CLAT stateless and the PLAT stateful. This was not accidental -- it directly addresses the scaling constraints of each component:

The CLAT runs on the end-user device -- a phone with limited memory, battery, and CPU. Making it stateless means it does not need to maintain a connection-tracking table, does not need timers for flow expiry, does not need to allocate ports, and does not need to handle table exhaustion. A stateless CLAT can translate any packet in O(1) time with zero per-flow memory. This is essential when the device might have hundreds of concurrent connections across dozens of apps.

The PLAT runs in the carrier's data center on dedicated hardware. Making it stateful is acceptable because (a) the carrier already needs stateful CGNAT infrastructure for IPv4 address conservation, (b) the PLAT hardware is purpose-built for high-speed state tracking, and (c) the PLAT is the natural place to multiplex many subscribers onto shared IPv4 addresses, which inherently requires state.

An alternative design -- stateful CLAT (NAT44) plus stateful PLAT (NAT64) -- would create "double NAT" with all its problems: port exhaustion at two levels, compounding log requirements, and making inbound connections essentially impossible. The stateless CLAT avoids all of these issues. The total system has exactly one layer of stateful NAT (the PLAT), same as a simple CGNAT deployment.

464XLAT vs Other Transition Mechanisms

How does 464XLAT compare to the other IPv6 transition technologies?

vs Dual-Stack -- Dual-stack requires provisioning a unique IPv4 address (or at least a CGNAT address) to every device. On a network with 100 million subscribers, this requires vast IPv4 pools and dual-stack routing infrastructure. 464XLAT eliminates per-device IPv4 provisioning entirely -- the carrier only needs IPv4 addresses on the PLAT pool.
vs NAT64+DNS64 alone -- Works for most traffic but breaks IPv4 literals. 464XLAT is a superset: it includes NAT64+DNS64 and adds CLAT to handle the remaining cases.
vs DS-Lite (RFC 6333) -- DS-Lite tunnels IPv4-in-IPv6 (encapsulation rather than translation). It requires per-subscriber tunnel state at the carrier's AFTR device and transmits IPv4 packets on the wire (inside IPv6 tunnels). 464XLAT uses translation instead of tunneling, so the wire traffic is pure IPv6 -- simpler for network operators to manage and monitor.
vs MAP-E / MAP-T (RFC 7597/7599) -- MAP distributes the NAT function, avoiding the stateful PLAT bottleneck by algorithmically assigning port ranges to each subscriber. This is more scalable but more complex to configure and requires customer-premises equipment (CPE) support. MAP is used primarily for fixed-line broadband in Japan (by NTT East/West), while 464XLAT dominates mobile.
vs NAT444 (double NAT) -- Some carriers attempted IPv4 CGNAT without any IPv6 transition. This creates double-NAT issues (carrier NAT + home NAT), breaks many applications, and does not advance IPv6 adoption at all. 464XLAT is strictly superior because it moves the network to IPv6, preserves a single NAT layer, and provides a migration path to eventual IPv4 sunset.

NAT64 Prefix Discovery

The CLAT needs to know the NAT64 prefix to construct IPv6 destination addresses. Three mechanisms exist for this:

DNS64 probing (RFC 7050) -- The CLAT queries the DNS for ipv4only.arpa, which has hardcoded A records returning 192.0.0.170 and 192.0.0.171 (defined by IANA). If the network's DNS64 server synthesizes AAAA records for these addresses, the CLAT can extract the NAT64 prefix from the synthesized response. For example, if the AAAA response is 64:ff9b::c000:aa, the prefix is 64:ff9b::/96. This is the original discovery method and works with any DNS64 deployment.
PREF64 Router Advertisement option (RFC 8781) -- The router sends the NAT64 prefix directly in IPv6 Router Advertisements. This is faster than DNS probing (available immediately at network attachment, before DNS is even configured) and more reliable (does not depend on the DNS path). Most modern carrier deployments use PREF64.
Static configuration -- The prefix is provisioned by the carrier in the device's APN/profile settings. This is a fallback for networks that support neither DNS64 probing nor PREF64.

Android tries PREF64 first (if available in the RA), then falls back to DNS64 probing. iOS follows the same priority. The well-known prefix 64:ff9b::/96 (RFC 6052) is used by most deployments, but carriers can use provider-specific prefixes (e.g., 2001:db8:64::/96) if they need to route NAT64 traffic to specific PLAT instances.

The 192.0.0.0/29 Address Block

The CLAT needs an IPv4 address to present to local applications. Using any routable IPv4 address would risk conflicts with real destinations. RFC 7335 reserves the 192.0.0.0/29 block specifically for IANA IPv4 Special-Purpose Address Registry use, and 192.0.0.4 through 192.0.0.7 are designated for CLAT. The choice of 192.0.0.4 as the default CLAT address is by convention -- all major implementations (Android, iOS, Windows) use it.

This address is only meaningful within the device itself. It never appears on the wire (the CLAT rewrites it to the device's IPv6 CLAT address). Applications that call getsockname() will see 192.0.0.4 as their local address, and applications that call getpeername() will see the original IPv4 destination. To the application, the connection looks completely normal -- a standard IPv4 TCP/UDP socket with no indication that two protocol translations are happening underneath.

Limitations and Edge Cases

464XLAT handles the vast majority of real-world traffic, but some scenarios remain challenging:

IPsec with IPv4 literals -- IPsec Encapsulating Security Payload (ESP) encrypts the inner packet, making CLAT translation impossible (the CLAT cannot rewrite headers it cannot see). If the IPsec tunnel is negotiated using IPv4 literals, the connection fails. Workaround: use IKEv2 with FQDN identifiers and rely on DNS64, or use IPv6-native IPsec.
IPv4 multicast -- The CLAT translates unicast IPv4 to IPv6 but does not handle IPv4 multicast. Applications using multicast (rare on mobile) will not work through CLAT.
IPv4 options -- IPv4 header options have no equivalent in IPv6. Packets with IPv4 options are typically dropped by the CLAT (per RFC 7915 section 4.1). In practice, IPv4 options are almost never used.
Fragmented UDP -- Stateless translation of fragmented packets is problematic because only the first fragment contains port information. The CLAT must reassemble fragmented IPv4 packets before translating them, which adds complexity and memory pressure on the device.
IPv4-only tethering -- When a phone tethers via Wi-Fi hotspot, the tethered devices typically get IPv4 addresses from the phone's DHCP server. These IPv4 packets must pass through the phone's CLAT, which was designed for single-device traffic. Android handles this by running a second CLAT instance for the tethering interface, but the interaction adds complexity.
Geolocation accuracy -- Because the PLAT shares IPv4 addresses across many subscribers, IP-based geolocation may place the user at the PLAT's location rather than the subscriber's actual location. This is a general CGNAT problem, not specific to 464XLAT.

464XLAT and the Future of IPv4

464XLAT is arguably the technology that made IPv6-only networks viable at scale. Before 464XLAT, every IPv6 transition plan stumbled on the same obstacle: the long tail of IPv4-dependent applications. Carriers could not deploy IPv6-only because too many apps broke, and they could not afford to maintain dual-stack because IPv4 addresses were exhausted. 464XLAT broke this deadlock by providing a transparent compatibility layer that requires no application changes.

The trajectory is clear. As more content becomes available over native IPv6, the percentage of traffic flowing through the CLAT decreases. Eventually, the CLAT will handle near-zero traffic and can be disabled. The PLAT (NAT64) will handle the remaining IPv4-only long tail. And when the last IPv4-only servers are decommissioned -- likely decades from now -- the PLAT can be retired too.

Until then, 464XLAT remains the quiet workhorse that lets billions of mobile devices use IPv4 applications over IPv6 networks, consuming no IPv4 addresses at the subscriber level, with overhead so low that users never notice the double translation happening on every packet.

Try looking up your mobile carrier's IP address and BGP routes to see whether your connection uses IPv6 -- if it does, 464XLAT is almost certainly the reason you can still reach IPv4-only websites.