You are here: Home > Publications > RIPE Labs > Jan Zorz > Introducing NAT64 Checker

Introducing NAT64 Checker

Jan Zorz — 22 Aug 2017
Contributors: Kevin Meynell
There has been much discussion about the need for IPv6 over the past decade and more, but with IPv4 addresses approaching exhaustion, this has seen an upsurge in IPv6 deployments over the past year. In particular, mobile operators are increasingly deploying IPv6-only in their consumer networks, whilst many of the major content and cloud service providers now also support IPv6, which increasingly means IPv6 connections can be established between users and services.


However, much of the Internet remains IPv4-only and as the IPv4 and IPv6 protocols are incompatible on the wire, it is necessary to use translation mechanisms such as NAT64 and 464XLAT to enable connectivity between IPv6- and IPv4-only hosts. NAT64 (RFC 6146) facilitates communication between IPv4 and IPv6 using a form of Network Address Translation (NAT) whereby multiple IPv6 addresses can be mapped onto one IPv4 address, thus allowing traffic using the different protocols to be exchanged whilst conserving IPv4 address space. NAT64 utilises a gateway that routes traffic from an IPv6 network to an IPv4 one, and performs the necessary translations for transferring packets between the two networks.

Of course, IPv6 clients also need to be able to perform DNS lookups in order to obtain a target IPv6 address from a domain name query. This poses a problem if a host does not have an IPv6 address registered in a AAAA record, so DNS64 is used to synthesise a AAAA record if a DNS lookup only finds an A record. The first part of the synthesised IPv6 address points to the NAT64 gateway, whilst the second part embeds the IPv4 address from the A record. When a synthesised address is received, any packets destined for that address are routed via the NAT64 gateway that performs the necessary IPv6 to IPv4 translation (and vice-versa).

Apple now requires all apps submitted to its App Store to support NAT64/DNS64, but one issue with NAT64 is that it does not support protocols that embed IPv4 literal addresses such as SIP, FTP and Skype. A number of existing applications also reference IPv4 specific APIs or fail to use Fully Qualified Domain Names (FQDNs) to specify remote hosts, so 464XLAT (as defined in RFC 6877) was devised to convert IPv4 packets into IPv6 packets that can be sent to a NAT64 gateway. This effectively allows IPv4-only applications to be used on an IPv6-only network, therefore dual-stack support is unnecessary and additional IPv4 addresses are not required. 464XLAT is supported by Android (from version 4.3), Windows Phone (from version 8.1) and Windows 10 (from version 1703).

Figure 1: The input field of the NAT64 checker tool

A benefit of NAT64 is that should it be possible to reach a target destination over IPv6, then IPv6 packets can be transmitted directly without needing to use the NAT64 gateway, thus obtaining performance benefits. As more hosts, servers and intermediate networks support IPv6 natively, then IPv6 traffic will automatically be routed end-to-end and the use of NAT64 gateways will gradually decline.

Nevertheless, there are still some pitfalls to be aware of when deploying IPv6 and NAT64/DNS64 in real life. Some common problems include misconfigured AAAA records in the DNS, servers not supporting IPv6, firewall that are not IPv6 aware, server modules inadequately or not supporting IPv6, hard coded IPv4 addresses in web pages or scripts, URLs referencing IPv4 addresses, and so on… This means that even if a user is able to physically access a website via IPv4, IPv6 and/or NAT64, the content can be displayed differently in each case.

The Internet Society has therefore sponsored Go6, SJM Steffann and Simply Understand to develop the NAT64check tool. This allows you to enter the URL of a particular website, and run tests over IPv4, IPv6 and NAT64 in order to check whether the website is actually reachable in each case, whether identical web pages are returned, and whether all the resources such as images, stylesheets and scripts load correctly. This is reflected by a percentage score based on a number of parameters that reflects the IPv6-compliance of the website, along with a comparison of response times and whether there are any Path MTU Discovery issues.

The image below shows an example of a website that doesn't have IPv6 enabled yet.

Figure 2: Example of a website that doesn't have IPv6 enabled

This tool enables website providers to easily check whether their sites are reachable and work correctly over IPv6 and NAT64. It will identify the absence of AAAA records along with any other DNS misconfigurations, and will also identify which website elements fail. These elements can then be fixed and the tests repeated until 100% compliance is obtained, as the aim of NAT64check is to help website providers see what (if anything) is broken and provide guidance on how fix things.

NAT64check utilises two separate installations that run four VM instances each, one hosted at the Go6lab and another at - the Go6lab installation runs on a Proxmox 4.2 cluster, whilst the installation runs on a VMWare Cluster. In both installations, one VM is used for the management and web server, one is used for the IPv4 server, another for the IPv6 server, and the remaining one for the NAT64 server. PhantomJS is used as a command line browser to retrieve versions of specified web pages using the different protocols, and then to compare the images and loaded resources.

Figure 3: Example of a website that has IPv6 enabled including the results of the tests and suggestions for improvements

So if you’re interested in taking a look at this tool, go to either  or,

type the URL you wish to check into the box at the top of the page, and the result should be returned within a few seconds. It’s simple and easy, and will help you identify what needs to be done to make your website accessible with IPv6. Try it today!


This tool was presented during the IPv6 working group at the RIPE 74 Meeting in May 2017.



Tassos says:
22 Aug, 2017 06:43 PM
When testing on, I'm getting a lot of "The test failed because the website could not be loaded over IPv4." errors, while testing on the test finishes ok.
Sander says:
22 Aug, 2017 11:30 PM
I noticed, currently debugging! Sorry for the inconvenience :(
Sander says:
23 Aug, 2017 12:04 AM
Ah, found it. It seems that quite some sites have problems with smaller MTUs on IPv4. My test boxes are (intentionally) behind a link with an MTU of 1280 to check that pMTU is handled correctly. Apparently they don't :( I now added MSS clamping, and that seems to help. But it is disappointing that so many websites are sending packets with DF set and then don't handle fragmentation properly.
Tassos says:
23 Aug, 2017 06:48 PM
Still getting the same error " The test failed because the website could not be loaded over IPv4. ":( (check 20363)
Ross Chandler says:
23 Aug, 2017 08:20 AM
Unfortunately the Windows 10 support for 464XLAT is only where the device has a Wireless WAN (3GPP) interface.

As far as I can see there's no good reason to restrict this functionality that way. If Windows 10 running desktops and laptops with wired or WiFi interfaces had it they could control the CLATs activation by checking for the presence of a working NAT64. The Network operator could control its activation by advertising DNS64 recursive DNS servers.
Jan Zorz says:
24 Aug, 2017 10:13 AM
Indeed... Android fires up CLAT interface independent on what interface is IPv6-only - it can be 3gpp or wifi... :)
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.