NAT64: Protocol Translation for IPv6-Only Networks

All the transition mechanisms we've studied so far—dual-stack, tunneling, 6to4, Teredo—share a common assumption: hosts have IPv4 connectivity that can be leveraged to reach IPv6 destinations. But what about the inverse scenario?

As IPv4 address exhaustion intensifies, some networks are deploying IPv6-only. Mobile carriers, in particular, find that allocating IPv4 addresses to every smartphone is unsustainable. These networks use IPv6 exclusively for their internal infrastructure.

But here's the challenge: much of the Internet's content remains IPv4-only. How can an IPv6-only smartphone access an IPv4-only website?

The answer is NAT64—a protocol translation mechanism that converts IPv6 packets to IPv4 packets and vice versa. Unlike tunneling (which encapsulates one protocol inside another), NAT64 performs actual protocol conversion, enabling true interoperability between IPv6-only clients and IPv4-only servers.

NAT64 performs network address and protocol translation between IPv6 and IPv4. It translates IPv6 packets to IPv4 packets (and the reverse for responses), enabling IPv6-only clients to communicate with IPv4-only servers.

The Core Concept

IPv6-only Client          NAT64 Gateway          IPv4-only Server
2001:db8::1              Translation            192.0.2.100
        |                     |                      |
        |--IPv6 packet------->|                      |
        |                     |--IPv4 packet-------->|
        |                     |<--IPv4 response------|
        |<--IPv6 response-----|                      |

Unlike tunneling, the NAT64 gateway completely reconstructs packets:

• New IP header (v4 ↔ v6)
• Recalculated checksums
• Translated addresses
• Modified ICMP messages if needed

To the client, the server appears to be an IPv6 host. To the server, the client appears to be an IPv4 host.

NAT64 Address Embedding

For the IPv6 client to address an IPv4 server, the IPv4 address must be represented as an IPv6 address. This is done by embedding the 32-bit IPv4 address within a 128-bit IPv6 address using a NAT64 prefix.

Well-Known Prefix (WKP):

64:ff9b::/96

To represent 192.0.2.100 (0xC000:0264):

64:ff9b::192.0.2.100  (mixed notation)
64:ff9b::c000:264     (pure hex)

When the NAT64 gateway receives traffic destined for 64:ff9b::/96, it:

1. Extracts the embedded IPv4 address from the last 32 bits
2. Translates the IPv6 packet to IPv4
3. Forwards to the extracted IPv4 address

Operator-Defined Prefixes

64:ff9b::/96 is globally routable (via the NAT64 gateway), but operators can use their own prefixes:

Operator Prefix: 2001:db8:64::/96
IPv4 192.0.2.100 → 2001:db8:64::c000:264

Operator prefixes allow multiple NAT64 translations in different network segments, custom routing policies, and privacy (not revealing that NAT64 is in use).

NAT64 alone isn't enough. When an IPv6-only client wants to access 'www.ipv4only.example.com', it queries DNS for an AAAA record. If the server is IPv4-only, there's no AAAA record to return—the client can't communicate.

DNS64 solves this by synthesizing AAAA records for IPv4-only hosts.

DNS64 Operation

Without DNS64:

1. Client queries: AAAA www.example.com
2. DNS returns: (empty, no AAAA exists)
3. Client cannot connect (has no IPv6 address to use)

With DNS64:

1. Client queries: AAAA www.example.com
2. DNS64 queries upstream for AAAA
3. Upstream returns: (empty, no AAAA)
4. DNS64 queries for A record instead
5. Upstream returns: A 192.0.2.100
6. DNS64 synthesizes: AAAA 64:ff9b::192.0.2.100
7. Client connects to synthesized IPv6 address
8. Traffic routes to NAT64 gateway (which handles 64:ff9b::/96)
9. NAT64 translates and connects to real 192.0.2.100

DNS64 Synthesis Algorithm

DNS64's logic (per RFC 6147):

Receive AAAA query:
  IF authoritative AAAA record exists:
      Return real AAAA (dual-stack host, no translation needed)
  ELSE:
      Query for A record
      IF A record exists:
          Synthesize AAAA = NAT64_PREFIX + IPv4_address
          Return synthesized AAAA
      ELSE:
          Return NXDOMAIN (host doesn't exist in either protocol)

Critical behavior: DNS64 returns real AAAA records when they exist. Translation only occurs for IPv4-only destinations. This ensures optimal paths for dual-stack servers.

DNS64 TTL Handling

Synthesized AAAA records inherit the TTL of the underlying A record, but DNS64 may impose minimums/maximums:

• Too-short TTLs increase DNS64 load
• Too-long TTLs cause problems if IPv4 addresses change

Typical policy: honor A record TTL, but clamp to reasonable bounds (e.g., 60s minimum, 1 hour maximum).

There are two modes of NAT64 operation: stateful and stateless. Stateful NAT64 is far more common, especially for providing IPv4 Internet access to IPv6-only clients.

Stateful NAT64 Operation

Stateful NAT64 (RFC 6146) maintains a mapping table between IPv6 client sessions and IPv4 addresses, similar to traditional NAT44.

Outbound Flow (IPv6 → IPv4):

1. Client sends packet: src=2001:db8::1, dst=64:ff9b::c000:264
2. NAT64 extracts IPv4 destination: 192.0.2.100
3. NAT64 selects source IPv4 from its pool: 203.0.113.50
4. NAT64 creates mapping: (2001:db8::1, [port]) ↔ (203.0.113.50, [mapped-port])
5. NAT64 sends IPv4 packet: src=203.0.113.50, dst=192.0.2.100

Inbound Flow (IPv4 → IPv6):

1. Server responds: src=192.0.2.100, dst=203.0.113.50:[port]
2. NAT64 looks up mapping for 203.0.113.50:[port]
3. Finds original client: 2001:db8::1
4. Translates source: 192.0.2.100 → 64:ff9b::c000:264
5. Sends IPv6 packet: src=64:ff9b::c000:264, dst=2001:db8::1

Address Pool Management

Stateful NAT64 requires a pool of IPv4 addresses to assign to translated sessions. Just like NAT44:

• Many-to-one: Thousands of IPv6 clients can share a single IPv4 address via port mapping
• Pool size determines capacity: More IPv4 addresses = more concurrent sessions
• Port exhaustion: ~64,000 ports per IPv4 address limits concurrent connections to same destination

Example Configuration Concept:

nat64 v4 pool ipv4-pool 203.0.113.0/24
nat64 prefix 64:ff9b::/96
nat64 enable

This provides 256 IPv4 addresses, potentially supporting 256 × 64,000 ≈ 16 million+ concurrent sessions.

Stateful NAT64 Characteristics

• Asymmetric: Only works for IPv6-initiated connections (client → server)
• No IPv4 → IPv6 initiation: IPv4 hosts cannot initiate to IPv6 clients (no inbound mapping)
• Connection tracking: Maintains state per connection (memory intensive for large deployments)
• Timeouts: Mappings expire after inactivity (similar to NAT44)

Stateless NAT64, also called SIIT (Stateless IP/ICMP Translation), performs address translation without maintaining per-session state. This enables bidirectional communication initiation and scales better.

The Stateless Approach

Instead of dynamic port mapping, stateless NAT64 uses algorithmic address translation:

• Each IPv6 host has a corresponding IPv4 address
• Each IPv4 host has a corresponding IPv6 address
• Translation is deterministic based on addressing scheme
• No state table needed; any packet can be translated based on addresses alone

Example Addressing:

IPv6 network: 2001:db8::/96
IPv4 network: 192.0.2.0/24

Mapping rule: 2001:db8::x ↔ 192.0.2.x

Host A IPv6: 2001:db8::100 ↔ 192.0.2.100
Host B IPv6: 2001:db8::101 ↔ 192.0.2.101

SIIT Header Translation

Stateless translation directly converts headers:

IPv6 → IPv4:

• Version: 6 → 4
• Traffic Class → Type of Service
• Flow Label: Dropped
• Payload Length → Total Length (add header size)
• Hop Limit → TTL (decremented)
• Source/Dest: Extracted/translated per mapping

IPv4 → IPv6:

• Version: 4 → 6
• Type of Service → Traffic Class
• Flow Label: Set to 0
• Total Length → Payload Length
• TTL → Hop Limit (decremented)
• Addresses: Translated per mapping

ICMP Translation: ICMP types differ between v4 and v6. SIIT translates:

• ICMPv4 Echo Request (8) ↔ ICMPv6 Echo Request (128)
• ICMPv4 Destination Unreachable (3) ↔ ICMPv6 Destination Unreachable (1)
• And so on per RFC 7915

NAT64 + DNS64 works well for most applications, but some applications don't use DNS—they use literal IPv4 addresses embedded in application protocols, configuration files, or code. These break on IPv6-only networks.

464XLAT (RFC 6877) solves this by adding client-side translation.

The 464XLAT Architecture

'464' refers to the address translation sequence:

1. Application uses IPv4 address (literal or resolved)
2. CLAT (Customer-side Translator) on client converts IPv4 → IPv6
3. Packet traverses IPv6-only network
4. PLAT (Provider-side Translator) converts IPv6 → IPv4
5. Packet reaches IPv4 destination

CLAT (Customer-side Translator):

• Runs on the IPv6-only client device
• Provides a 'fake' IPv4 interface to applications
• Captures IPv4 traffic and translates to IPv6 with embedded destination
• Uses NAT64 prefix for translated destination addresses

PLAT (Provider-side Translator):

• Standard NAT64 gateway in the network
• Receives CLAT-translated traffic
• Performs final IPv6 → IPv4 translation to reach destination

CLAT Implementation Details

The CLAT creates a virtual IPv4 interface on the device:

Address assignment:

• Uses 192.0.0.0/29 (RFC 7335 reserved range) or private addresses
• Commonly 192.0.0.1 for the CLAT gateway
• Device believes it has IPv4 connectivity via this interface

Translation:

• IPv4 packets routed through CLAT interface
• Source rewritten to client's IPv6 address (or NAT64-style)
• Destination rewritten to NAT64 prefix + original IPv4

Example flow:

App sends: src=192.0.0.2 dst=93.184.216.34
CLAT translates: src=2001:db8::1 dst=64:ff9b::5db8:d822
PLAT translates: src=203.0.113.50 dst=93.184.216.34
Server sees standard IPv4

464XLAT in Mobile Networks

464XLAT has been adopted extensively by mobile carriers:

• T-Mobile USA: IPv6-only with 464XLAT since ~2014
• India carriers: Jio and others use 464XLAT
• Android: Built-in CLAT support since Android 4.3
• iOS: Built-in CLAT support since iOS 12.2

For users, this is transparent—they simply 'have IPv4 connectivity' even though the carrier network is IPv6-only.

Protocol translation is inherently complex. IPv4 and IPv6, while similar, have differences that create translation challenges.

Header Field Challenges

Fragment Handling:

• IPv6 doesn't have a fragment header in the base header
• Fragmented IPv4 must add IPv6 Fragment extension header
• Fragment reassembly may be required in some cases

Header Length:

• IPv4 has variable header length (IHL field)
• IPv6 has fixed 40-byte header
• Options in IPv4 may need translation to extension headers

Checksums:

• IPv4 header has checksum; IPv6 doesn't
• TCP/UDP pseudo-headers differ (include source/dest addresses)
• All transport checksums must be recalculated

Application Layer Gateways (ALGs)

Some application protocols embed IP addresses in their payload:

FTP: The PORT/PASV commands include IPv4 addresses in ASCII. NAT64 ALG must:

• Parse FTP control channel
• Rewrite embedded addresses
• Translate synthesized IPv6 back to carried IPv4

SIP: Session Initiation Protocol uses IP addresses in SDP bodies:

c=IN IP4 192.0.2.100

NAT64 ALG rewrites during translation.

Reality: ALGs are complex and often break. The trend is toward ALG-independent protocols (like ICE for media negotiation) that don't embed addresses.

Handling Fragmentation

IPv6 hosts are expected to perform Path MTU Discovery; routers don't fragment. But NAT64 must handle fragmented IPv4 responses:

1. IPv4 server sends fragmented response
2. NAT64 must reassemble complete IPv4 packet
3. Then translate reassembled packet to IPv6
4. If result exceeds IPv6 path MTU, generate ICMPv6 Packet Too Big

This reassembly requirement creates state (buffering fragments) even in 'stateless' modes.

NAT64 deployment varies significantly based on network type and requirements.

Mobile Carrier Deployment

Typical Architecture:

• User equipment (phones) get only IPv6 addresses
• CLAT on device handles IPv4 applications (464XLAT)
• DNS64 on carrier DNS servers synthesizes AAAA records
• NAT64/PLAT at network edge handles IPv4 Internet access
• Native IPv6 for IPv6-capable destinations (no translation)

Why IPv6-only for mobile?

• Simpler network (single-stack)
• No IPv4 address allocation/management
• Scales to billions of devices
• IPv4 exhaustion made dual-stack unsustainable

Major deployments:

• T-Mobile USA: >90% traffic IPv6
• Reliance Jio (India): World's largest IPv6 network
• SK Telecom (Korea): IPv6-only LTE

Enterprise Deployment Considerations

When to deploy NAT64:

• Planning IPv6-only internal network
• Need access to IPv4-only external services
• Want to reduce IPv4 address usage internally

Implementation options:

• Dedicated NAT64 appliances (loadbalancers with NAT64)
• Firewall with NAT64 module
• Open-source solutions (Jool, Tayga)
• Cloud provider NAT64 services

Integration requirements:

• DNS64 on internal DNS servers (or separate DNS64 service)
• Routing NAT64 prefix (64:ff9b::/96) to NAT64 gateway
• IPv4 address pool for outbound translation
• Logging for compliance and troubleshooting