NAT64 and DNS64: Letting IPv6-Only Clients Reach IPv4 Services

An IPv6-only client cannot talk to an IPv4-only server. The protocols are not interoperable, and a client with no IPv4 address has no way to form the packet. NAT64 and DNS64 solve this together, and they are the mechanism behind IPv6-only mobile networks that still reach the entire IPv4 internet.

The two halves

DNS64 handles the lookup. When an IPv6-only client asks for a name, the DNS64 resolver queries normally. If a AAAA record exists, it returns it and nothing special happens. If only an A record exists, the resolver synthesises an AAAA record by embedding the 32-bit IPv4 address inside a designated IPv6 prefix — commonly the well-known prefix reserved for this purpose — and returns that.

The client now has an IPv6 address to connect to, and it has no idea the destination is actually IPv4.

NAT64 handles the traffic. The synthesised address routes to the NAT64 gateway, which recognizes the prefix, extracts the embedded IPv4 address, and performs stateful translation between the families — rewriting headers, maintaining a translation table, and multiplexing many IPv6 clients behind its IPv4 addresses using ports.

That last part is the same many-to-one mechanism as PAT, applied across protocol families rather than within one.

Why anyone does this

Running dual stack means operating two protocols everywhere — two address plans, two sets of firewall rules, two sets of monitoring — and for a very large network that is a permanent operational cost. Large mobile carriers moved to IPv6-only client networks with NAT64 at the edge precisely to stop paying it, and to escape the scarcity of IPv4 addresses for millions of subscribers.

The trade-off is a middlebox in the path of everything IPv4-bound, which is exactly the complication IPv6 was meant to remove.

What breaks

Applications using literal IPv4 addresses. DNS64 only intervenes during a name lookup. An application that connects to a hardcoded IPv4 address, or receives one inside a protocol message, never consults DNS and therefore never gets a synthesised address. It simply fails.

DNSSEC validation. A synthesised AAAA record is fabricated by the resolver, so it cannot be signed by the zone owner. A client performing its own DNSSEC validation sees an invalid record. The workarounds are validating at the resolver rather than the client, or client-side synthesis where the client learns the prefix and does the translation itself.

Protocols embedding addresses in payloads — FTP in active mode, SIP, and various peer-to-peer protocols — break unless the gateway understands and rewrites them, which is the same class of problem NAT has always had.

Inbound connections do not work. Like any stateful translation, the mapping is created by outbound traffic, so an IPv4 host cannot initiate a connection to an IPv6-only client.

464XLAT

The workaround for the literal-address problem, and the reason IPv6-only mobile networks actually function.

A small translator on the client presents a private IPv4 address locally, so applications that insist on IPv4 get one. It translates that traffic to IPv6, which crosses the IPv6-only network, and the NAT64 gateway translates it back to IPv4 at the far end. Two translations, and applications that would otherwise break work unchanged.

This is why an IPv6-only phone network runs IPv4-only applications without anyone noticing.

Choosing between the approaches

Dual stack remains the preferred transition mechanism wherever both protocols can be carried: native performance, no translation, nothing to break. Its cost is operational duplication — and the security gap that matters, which is IPv6 enabled but unfirewalled and unmonitored because the network was designed for IPv4.

NAT64 with DNS64 suits IPv6-only client networks at large scale. Tunnelling suits isolated IPv6 islands crossing IPv4 infrastructure.

From a security standpoint, treat the NAT64 gateway as a security boundary with logging: it sees every IPv4-bound flow, and without translation logs correlating an internal client to an external connection becomes impossible after the fact — the same attribution problem any address-sharing device creates, and a reason those logs belong in your SIEM. Firewall policy must also be written for both families; a policy covering only IPv4 leaves the IPv6 side of the gateway open.

Exam angles

Know DNS64 as synthesising AAAA records by embedding an IPv4 address in an IPv6 prefix, and NAT64 as the stateful gateway translating between the families. Understand that they work together and that the client is unaware. Know that applications using IPv4 literals bypass DNS64 and fail, that DNSSEC validation conflicts with synthesised records, and that 464XLAT adds client-side translation to fix the literal-address case. Place dual stack as preferred where both protocols can run.