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, while many of the major content and cloud service providers now also support IPv6, and this 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 while 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 finds only an A record.
The first part of the synthesised IPv6 address points to the NAT64 gateway, while 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, and 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, and IPv6 packets can then be transmitted directly without needing to use the NAT64 gateway, thus obtaining performance benefits. As more hosts, servers, and intermediate networks support IPv6 natively, 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, firewalls 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 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 reflect 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 IPv6-lab.net — the Go6lab installation runs on a Proxmox 4.2 cluster, while the IPv6-lab.net 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 https://nat64check.go6lab.si/ or https://nat64check.ipv6-lab.net/, 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.
Contributor: Kevin Meynell
Slovenia-based Jan Zorz works for the Internet Society (ISOC) and is an IPv6 specialist.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.