skip to content

On an IPv6-only network with NAT64 and DNS64, why do apps that use IPv4 literals still fail, and how does 464XLAT fix them?

level: seniorimportance: nice to knowfreq 12%

answer

  1. no DNS lookup, no synthesis
  2. a fake IPv4 stack on the device
  3. translate twice: stateless then stateful
  4. CLAT on the edge, PLAT in the core

basics

~20 s

An IPv4 literal or IPv4-only socket never asks DNS, so DNS64 cannot help and the device has no IPv4 route. 464XLAT adds a stateless translator (CLAT) on the device that turns IPv4 into IPv6 for the network's stateful NAT64 (PLAT).

solid answer

~40 s

NAT64 with DNS64 works only when the app resolves a name and connects to the synthetic IPv6 address. An app that connects to `192.0.2.33` directly, uses IPv4-only sockets, or receives IPv4 addresses inside a protocol never triggers synthesis, and an IPv6-only device has no IPv4 address or route. **464XLAT** (RFC 6877, Informational) fixes this with two translators. The **CLAT** on the phone or customer router presents a private IPv4 address and default route to local software, then translates its IPv4 packets **statelessly, 1:1** into IPv6 aimed at the provider's translation prefix. The **PLAT** is an ordinary **stateful NAT64** (RFC 6146) that translates them back to IPv4, N:1. No encapsulation is involved, and traffic that resolves names can still go single-translation through DNS64.

go deeper

for a junior

Recall that some software uses IPv4 addresses directly, and that 464XLAT gives an IPv6-only device a local IPv4 path that is translated twice.

for a middle

Explain why literals bypass DNS64, then name the two translators: a stateless CLAT on the device, a stateful NAT64 as PLAT in the network.

for a senior

Walk through a packet 4-6-4, then cover the dedicated /64 or NAT44 fallback, PLAT prefix discovery, the MTU cost and the client-server-only limit.

for a principal

Judge whether IPv4-only software on a fleet justifies 464XLAT or should be fixed in the software, given translation cost, logging and how long IPv4 literals will linger.

## Why NAT64 and DNS64 are not enough Stateful NAT64 (RFC 6146) and DNS64 (RFC 6147) let an IPv6-only device reach IPv4-only servers **through DNS**: the device asks for a AAAA record, DNS64 synthesises one that embeds the IPv4 address in a translation prefix, and NAT64 translates the traffic. Everything depends on step one. Three common cases skip it: - **IPv4 literals** — an app or a configuration file that names `192.0.2.33` instead of a hostname. - **IPv4-only sockets** — software written against IPv4 APIs that never opens an IPv6 socket at all. - **Addresses inside payloads** — protocols that hand peers IPv4 addresses in their messages. On an IPv6-only device none of these can work: there is no IPv4 address to send from and no IPv4 route to send on. RFC 6877 targets exactly this gap: its mobile-network case names IPv4 literals and IPv4-only sockets as what the device-side translator is for. ## The two translators 464XLAT combines **stateless translation at the edge** with **stateful translation in the core**: | Component | Where it runs | Translation | Mapping | |---|---|---|---| | **CLAT** (customer-side translator) | The phone itself, or the customer's router | Stateless, IPv4 to IPv6 | 1:1 — private IPv4 addresses to global IPv6 addresses | | **PLAT** (provider-side translator) | The provider's network | Stateful NAT64 per RFC 6146 | N:1 — many IPv6 addresses onto shared global IPv4 | On a phone, RFC 6877 has the CLAT provide an **RFC 1918 address and an IPv4 default route** to the local stack, so IPv4-only software has something to bind to. ## The packet's journey 1. An app opens an IPv4 socket to `192.0.2.33`. The device's IPv4 route points at the CLAT. 2. The CLAT translates the packet **statelessly**: the IPv4 source becomes an IPv6 address from the CLAT's own prefix, and the destination becomes the **PLAT's translation prefix** plus `192.0.2.33`. 3. The packet crosses the IPv6-only network as **native IPv6** — RFC 6877 stresses there is no encapsulation. 4. The PLAT, a normal stateful NAT64, extracts the IPv4 destination, maps the source onto one of its shared IPv4 addresses and ports, and forwards IPv4 to the server. 5. Replies reverse the path: PLAT back to IPv6, then the CLAT back to IPv4 for the app. That is the "4-6-4" of the name: IPv4 at the app, IPv6 across the network, IPv4 at the server. ## Details that matter in deployment - **The CLAT needs its own IPv6 addresses.** RFC 6877 asks for a dedicated /64 for translated traffic. Without one, the CLAT may run NAT44 so all local IPv4 traffic shares one address, then translate that to a single IPv6 address it claims with Neighbor Discovery and defends with Duplicate Address Detection — making the CLAT both stateful and stateless. - **The CLAT must learn the PLAT's prefix.** RFC 6877 points to a discovery heuristic; the usual approach queries a name known to have only an IPv4 address and reads the prefix from the synthesised answer. - **DNS64 is optional.** 464XLAT does not require it, since even DNS queries can go out over IPv4 through both translators. With DNS64 in place, name-based traffic uses native IPv6 to the PLAT — **single** translation — and the CLAT handles only the IPv4-only cases. - **The CLAT should proxy DNS** for its local clients, so an IPv4-only client's lookups do not pay for double translation each time. ## Limits and trade-offs - **Client-server only.** RFC 6877 supports IPv4 only where the server has a global IPv4 address; it is not fit for IPv4 peer-to-peer or inbound IPv4 connections. - **Translation costs.** Two header rewrites per IPv4 packet, and an IPv6 header 20 bytes larger than IPv4's minimum, which eats into the MTU. - **Status.** RFC 6877 is **Informational**: an architecture assembled from standards-track translators, not a new protocol. - **Against dual stack.** On mobile networks dual stack would need a separate IPv4 connection context per device and an IPv4 address for each; 464XLAT keeps the network IPv6-only and confines IPv4 to the translators.

  • Why is the CLAT stateless while the PLAT is stateful?
    The CLAT translates a handful of local IPv4 addresses 1:1 onto IPv6 addresses it owns, so it can compute every mapping algorithmically and keep no per-flow state. The PLAT shares a scarce pool of global IPv4 addresses among many IPv6 clients, which needs NAPT-style bindings and sessions, exactly as stateful NAT64 does.
  • If DNS64 is deployed, which traffic still goes through the CLAT?
    Only traffic that cannot use a name: IPv4 literals, IPv4-only sockets and IPv4 addresses handed over inside protocols. Name-based connections resolve to synthetic AAAA records and travel as native IPv6 to the PLAT, so they are translated once rather than twice.

saying these in an interview costs you the question

  • 464XLAT tunnels IPv4 packets inside IPv6 to the provider.
  • The CLAT is the stateful translator and the PLAT is stateless.
  • 464XLAT cannot work unless the network also runs DNS64.
  • With 464XLAT a phone can accept inbound IPv4 connections.
  • DNS64 alone fixes apps that connect to IPv4 address literals.