Measuring NAT64 Usage in the Wild

NAT64 is a kind of Network Address Translation (NAT) that translates IPv6 packets to IPv4. In doing so, it allows IPv6-only hosts (e.g., clients) to communicate with IPv4-only hosts (e.g., servers). It is usually used together with an extension to DNS called DNS64 that synthesises AAAA records for IPv4-only names.

One NAT64-based technology, 464XLAT, is widely used in mobile networks. Fixed-line networks have been slower to adopt IPv6 transition mechanisms, though NAT64, 464XLAT, and other mechanisms such as MAP-E have been widely discussed. It is not well known to what extent NAT64 is used in fixed-line networks, and how it impacts path length and latency in these networks, and so it is important to periodically measure deployment.

We used the RIPE Atlas measurement platform to explore NAT64 usage and its impact. We find that full NAT64 and DNS64 deployments are rare in fixed-line networks, though a larger number of hosts can access a NAT64 that they likely weren't intended to use. NAT64 only moderately increases path length and latency when compared to native IPv4 paths.

What is NAT64?

NAT64 and DNS64 work together to allow IPv6 hosts to seamlessly communicate with IPv4-only hosts. In the diagram above, the desktop computer is configured with IPv6, and the domain, www.example.net, does not have any AAAA (IPv6) records, just an A (IPv4) record. To communicate with the server, the host first sends a AAAA query to the DNS64. The DNS64 synthesises a AAAA record by encoding the IPv4 address in the last 32 bits of an IPv6 address. The IPv6 address has a special prefix, the NAT64 prefix. This can either be the standard prefix 64:ff9b::/96, or a custom prefix.

Having received this synthesised address in the response from the DNS, the client may send packets using it as the destination address, and those packets will be forwarded towards the NAT64. The NAT64 extracts the IPv4 address from the IPv6 address, translates the packet to IPv4, and sends it on to www.example.net. Replies get translated back to IPv6 in the same way.

It is possible to discover the NAT64 prefix that is used by the NAT64 and DNS64 by sending a AAAA query for a name that only has an A record, such as the special-use domain name ipv4only.arpa. If a AAAA record is received, then this record was synthesised by a DNS64.

Measuring NAT64 usage with RIPE Atlas

We used RIPE Atlas to run a large-scale study on the existence and performance of NAT64 in networks today. RIPE Atlas, when we conducted our measurements, had approximately 6,000 IPv6-enabled probes. We checked whether these probes use NAT64 and/or DNS64, using ping measurements and DNS queries. We also perform traceroutes towards native IPv4 addresses and the corresponding encoded IPv6 address, to see how NAT64 impacts path length and latency.

Finding NAT64s on RIPE Atlas

We determine whether a RIPE Atlas probe has DNS64 by sending AAAA queries for two names that only have A records - ipv4only.arpa and time-c-b.nist.gov. We also check whether a probe can send ping requests to addresses with the standard NAT64 prefix. If a probe received an address with a non-standard prefix from a DNS64, we also check if all probes in the same AS can ping an address with that prefix.

Our measurements reveal some interesting characteristics:

• NAT64 is very rare on RIPE Atlas: only 18 out of 6,154 probes (0.3%) have a fully functional NAT64 and DNS64 setup. A further 206 probes (3.3%) can ping addresses with a (non-public) NAT64 prefix, but they have at best semi-functional DNS64. These could be probes that are behind a NAT64, but that use an alternative DNS resolver (e.g. a public resolver). They could also just happen to be able to access someone else's NAT64 deployment.

• Misconfigurations are common: 162 probes received a AAAA record from their resolver when querying for ipv4only.arpa but were not able to receive AAAA records for any other IPv4-only names, or ping addresses with the NAT64 prefix they received. Most of these probes were in the same AS (Free SAS). A further 131 probes were able to send ping requests through a NAT64 but were not able to traceroute through it. Most of these probes accessed a NAT64 that appears to be a hobbyist deployment which inadvertently translated ping packets from other networks.

• There are many kinds of setups: There are 224 probes that can ping addresses with a NAT64 prefix. We categorised these probes based on the NAT64's probable location and type of deployment. Even though the total number of probes is low, we find a large diversity of setup types. For example, only three probes likely use an DNS64 set up by the ISP (ISP DNS64 in the diagram), though 27 probes are in an AS with such a DNS64 (AS with DNS64). Three of these exclusively use public DNS resolvers (only public resolver), which might prevent them from using the DNS64. Six probes can ping through a private NAT64s deployment in a different AS (remote NAT64, but not public NAT64). Some of these NAT64s might be misconfigured to accept ping requests from other networks.

Tracerouting through NAT64s

Out of the 224 probes that were able to ping addresses with a NAT64 prefix, 37 probes could also connect to IPv4, were able to traceroute through their NAT64, and were available for traceroute measurements. We used these probes to compare characteristics of native IPv4 paths and paths going through the NAT64 to the same destination. In doing so, we found that:

• NAT64 paths are longer: We find that the paths going through the NAT64 contain more IP hops than the native IPv4 paths, and have higher latency, possibly due to the location of the deployments in the network. NAT64 paths were, on average, 23.13% longer (3.27 hops) with a 17.47% higher latency (23.74ms).

• NAT64 leads to missing hops? The paths going through the NAT64 had significantly more missing hops (devices on the path that don't respond to traceroute packets). This is not because the NAT64s are filtering out traceroute packets, as all these paths contain at least one hop with the NAT64 prefix. Rather, it seems to be due to the behaviour of specific routers on the path, both before and after the NAT64s. More investigation is needed to determine why this occurs.

Conclusion

While NAT64 deployments are uncommon on RIPE Atlas, there are many types of setups with diverse behaviours. This is possibly due to the relatively high number of hobbyist NAT64 deployments on the network. Paths going through the NAT64s that we discovered are somewhat longer and have more hops. Some behaviours, such as the higher number of unresponsive hops, and various misconfigurations, remain unexplained.

Learn more

A full write-up of our experiments is available on arXiv. We welcome comments on this work, especially from readers who host a RIPE Atlas probe with NAT64, and anyone else with NAT64 deployment experience.