This summer we’ve been busy in the Go6lab updating old NAT64/DNS64 implementations and adding new ones for public testing – A10 Networks and Jool NAT64 builds – as well as enhanced the pool of testing options we initially set up in 2013.
First of all – what does public NAT64/DNS64 testing mean? While some people assign a ‘private’ IPv6 segment (64:ff9b::/96) as their NAT64 prefix while setting up their NAT64 deployment, we decided that our NAT64 prefix should be from our global IPv6 pool of addresses and therefore accessible from the whole of IPv6 Internet.
Anyone with IPv6 connectivity can now test different NAT64 implementations by simply setting their computer’s recursive DNS servers to one of those specified on the Go6lab NAT64 test instructions page. Then just turn off IPv4 and start using your computer as usual.
This would direct traffic to the corresponding NAT64 implementation in the Go6lab, and by changing the DNS IPv6 address on your computer, you change where the traffic goes. The Go6lab is using public IPv6 addresses as NAT64 prefixes so everyone can see how an IPv6-only environment looks, what works, and what breaks.
Some basic information on how NAT64/DNS64 works can be found here.
So why are we setting up different NAT64/DNS64 implementations in the Go6lab, and why have a public testing option?
Mobile operators are increasingly looking into using IPv6-only mobile data connectivity for their customers and NAT64/DNS64 is an essential part of the 464XLAT mechanism that is now widely deployed in Android phones from version 4.4 upwards. The first to widely deploy this in production on their mobile network was T-Mobile USA that now has around 48 million phones connected to the Internet using the IPv6-only Packet Data Protocol (PDP) type.
Mobile operators can therefore perform initial tests of IPv6-only operation on their network and devices quite easily. If you have the latest updates for your Serving GPRS Support Node (SGSN), then you most probably already have IPv6 support enabled by default. Same goes for your Gateway GPRS Support Node (GGSN) device, where you just need to configure APN and the PDP type and a few other options (and of course have GGSN on a dual-stack network in your environment). This should be documented in your GGSN’s vendor documentation.
Next is testing mobile phone and application behaviour in an IPv6-only environment. Here you can point the DNS resolver IPv6 address in the phone to different DNS64 servers in our testing environment, and test applications and their behaviour. These DNS64 resolvers in our lab will divert traffic to different NAT64 implementations, so you can test different applications in a repeatable way in order to figure out which ones work best.
Our testing environment can also be useful for application developers on vendors. By setting-up IPv6 on your device, disabling IPv4 and setting the DNS resolver to one of our DNS64 servers, and you’ll quickly determine whether your application works with IPv6+NAT64 (or 464XLAT) or not.
Until recently, we observed that Android enabled CLAT (the client part of 464XLAT) for IPv6-only connections over 2G/3G/4G, but not for Wi-Fi connection. This has changed, and from Android version 5.1 onwards, the CLAT interface is also enabled for Wi-Fi networks as well, meaning that the majority of applications should just works. The only application we’ve seen issues with was Global Protect from Palo Alto Networks (a VPN client) who’ve been informed of the problem.
We’s also like to hear back anyone who’s tested our NAT64 implementations, Which one you like the most, which one causes the least issues, and which applications break (if any). This will help us advance the IPv6 technology that’s now increasingly being used on the Internet.
So go read the instructions, test and report.
P.S – If you are a NAT64/DNS64 vendor and do not have an example of your implementation in the go6lab yet, but would like to have it, please send an e-mail to ‘firstname.lastname@example.org’. The more NAT64 implementations there are for testing, the better it is.