# Demystifying DNS64 and NAT64: How an IPv6 Network Talks to an IPv4 World

As the global pool of public IPv4 addresses continues to run completely dry, Internet Service Providers (ISPs) face a massive architectural challenge. They must transition their core infrastructure and subscriber devices to modern, highly scalable **IPv6-only networks**.

But there’s a catch: a massive portion of the internet remains stuck on legacy, IPv4-only hosting environments. Because the two protocols speak entirely different languages, an IPv6-only device cannot natively route packets to an IPv4 server.

To bridge this massive gap seamlessly without breaking the consumer internet experience, ISPs rely on a coordinated tag-team protocol duo: **DNS64** and **NAT64**.

In this post, we will tear down exactly how this mechanism works by examining real-world outputs from a terminal ping session and global DNS propagation checks.

## The Core Problem: A Tale of Two Records

To understand the translation layer, let's look at how the domain [`cloud.datahub.com.np`](http://cloud.datahub.com.np) is configured out on the public internet using a global DNS propagation checker.

### 1\. The Global Ground Truth (A Record)

When we query the global authoritative name servers for the standard IPv4 **A Record** of [`cloud.datahub.com.np`](http://cloud.datahub.com.np), public resolvers like Google DNS (`8.8.8.8`), Quad9, and OpenDNS all return a clean, legacy IPv4 address: `202.51.75.23`.

### 2\. The Native Black Hole (AAAA Record)

However, when we switch the query to pull the native IPv6 **AAAA Record**, the result across the globe is completely blank (`-` with red failure indicators).

Globally, this domain has absolutely no native IPv6 infrastructure. It resides entirely inside a legacy IPv4 perimeter.

## Enter DNS64: The Art of Synthesizing IPs

If a subscriber on an IPv6-only ISP network types [`cloud.datahub.com.np`](http://cloud.datahub.com.np) into their browser, their operating system automatically fires off a request for an IPv6 destination (`AAAA`). Normally, seeing the blank record above, the DNS resolver would return an error, and the connection would fail.

Instead, the ISP’s specialized **DNS64 server** intercepts the empty response and dynamically synthesizes a proxy destination. Let’s look at what happens when we execute a standard terminal ping from a local machine behind such an ISP:

Bash

```plaintext
suraj@vostro ~ > ping cloud.datahub.com.np
PING cloud.datahub.com.np (64:ff9b::ca33:4b17) 56 data bytes
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=1 ttl=51 time=23.8 ms
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=2 ttl=51 time=37.1 ms
...
```

Notice the IP address returned by the local resolver: `64:ff9b::ca33:4b17`.

Where did that come from? The DNS64 server engineered it using a standard mathematical mapping:

*   **The Well-Known Prefix (**`64:ff9b::/96`**):** This specific 96-bit prefix is reserved globally by RFC 6052 for local NAT64 translation services.
    
*   **The Embedded Hexadecimal Payload (**`ca33:4b17`**):** The last 32 bits of the address are simply the legacy IPv4 address converted cleanly into hexadecimal notation.
    

Let's break down the math:

*   `ca` (Hexadecimal) $\\rightarrow$ `202` (Decimal)
    
*   `33` (Hexadecimal) $\\rightarrow$ `51` (Decimal)
    
*   `4b` (Hexadecimal) $\\rightarrow$ `75` (Decimal)
    
*   `17` (Hexadecimal) $\\rightarrow$ `23` (Decimal)
    

By embedding `202.51.75.23` inside the IPv6 string, the DNS64 server hands the client machine a fully valid destination string that it can route natively over the local network.

## Enter NAT64: Breaking the Protocol Barrier

Now that the local computer has an IPv6 address (`64:ff9b::ca33:4b17`), it can package its data and fire it down the wire. The packet flow travels through the network in four clean stages:

```plaintext
[ IPv6 Client ] 
       │  (Src: Native IPv6 | Dst: 64:ff9b::ca33:4b17)
       ▼
[ ISP Core Network ]
       │
       ▼
[ NAT64 CGNAT Gateway ] ───► (Strips IPv6 Header, Maps to Public IPv4 pool)
       │
       ▼
[ IPv4 Internet ] 
       │  (Src: ISP Public IPv4 | Dst: 202.51.75.23)
       ▼
[ Target Server (cloud.datahub.com.np) ]
```

1.  **Packet Assembly:** The client computer creates an IPv6 packet where the destination is the synthetic address.
    
2.  **ISP Core Routing:** The ISP’s core routers see the `64:ff9b::` prefix and instantly know this traffic is bound for external legacy infrastructure. They route it directly to a high-capacity Carrier-Grade NAT engine sitting on the network edge: the **NAT64 Gateway**.
    
3.  **The Great Rewrite:** The NAT64 Gateway intercepts the packet, strips away the outer IPv6 layer entirely, extracts the hidden `202.51.75.23` hex value, and shifts the payload into a standard IPv4 packet. It assigns a temporary mapping from its public IPv4 address pool using specific transport layer ports.
    
4.  **Delivery:** The packet crosses the standard IPv4 internet. The target server receives a completely normal IPv4 request, completely oblivious to the fact that the request originated from an IPv6 client.
    

When the server responds, the NAT64 gateway reverses the translation mapping using its internal state tables, wraps the data back into an IPv6 packet, and delivers it safely back to your machine.

## Observing Real-World Gateway Performance

Looking back at our practical ping experiment, we can even observe the real-world operational health of the ISP's NAT64 gateway simply by analyzing the ICMP response times:

Bash

```plaintext
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=7 ttl=51 time=25.4 ms
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=8 ttl=51 time=94.9 ms
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=9 ttl=51 time=125 ms
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=10 ttl=51 time=152 ms
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=11 ttl=51 time=162 ms
64 bytes from 64:ff9b::ca33:4b17: icmp_seq=12 ttl=51 time=27.6 ms
```

While the baseline latency sits at a tight **~25ms**, packets `8` through `11` show a massive, temporary spike climbing up to **162ms** before dropping right back down to normal.

Because NAT64 gateways are stateful devices managing massive translation pools (recomputing checksums, altering header fields, tracking port allocations for thousands of concurrent users), transient latency spikes like this are classic symptoms of momentary processing queues or link-layer buffer congestion right at the carrier's translation boundary.

## Conclusion

Without DNS64 and NAT64, the transition to IPv6 would have stalled years ago, fragmenting the internet into isolated networks. Together, they act as the invisible, highly efficient digital translators keeping the legacy web fully operational for modern, next-generation infrastructure deployments.