Deploy360 Growing the Internet IPv6

Deploy360 @ ENOG 14

Our colleague Jan Žorž from the Deploy360 team will be presenting at the 14th Eurasia Network Operators Groups (ENOG 14) on 9-10 October 2017 in Minsk, Belarus. This is being preceded by workshops on Best Practices in IPv6 BGP and DNSSEC Operations.

Jan will be talking about his real life experiences with NAT64/DNS64 and will be demonstrating the NAT64check tool on Monday evening (17.00-18.15). Following after his talk is a BoF on the Internet-of-Things (18.30-19.30), which is also sure to include discussions about the importance of IPv6 to scale the expected many billions of devices in future.

We’d also like to highlight the Cloudflare update on IPv6, DNS, DNSSEC, CA certs from Martin Levy (Cloudflare) on the Tuesday (10.00-11.30), who seems to be managing to cover just about all the Deploy360 topics in one talk. And for routing security, Kirill Malevanov, (Selectel) will be discussing his experiences of IPv4 prefix hijacking.

More Information

Deploy360 Events Internet of Things (IoT) IPv6

Deploy360 @ SdNOG 4

Our colleague Jan Žorž will be presenting at the 4th Sudan Network Operators Group meeting (SdNOG 4) on 16-17 August 2017 in Khartoum, Sudan. This is being preceded by an IPv6 Workshop.

Jan will be talking about his real life experiences with NAT64/DNS64 on the Thursday, which will be followed by an IPv6 Security 101 by Stephan Musa (AfriNIC), and then a talk on Testing IPv6 Firewalls using THC-IPv6 by Mohamed Alhafez (Canar).

Our ISOC Board colleague Walid al-Saqaf will also be presenting the keynote presentation on Blockchain Technology, whilst other Deploy360-relevant topics include presentations on Securing Web Traffic using TLS from Khalid Elmansor (University of Khartoum), and on Web Security from Hiba Alamin (NCTR).

Additionally worth checking out are the IoT presentations on Zigbee and the Unique Identifier System, the SDN session covering OpenFlow and NFV technologies, and overviews of Internet rollout in Sudan.

More Information

Deploy360 Events IPv6

Talking NAT64Check at DKNOG in Copenhagen

Tomorrow (16 March) from 13:45 – 14:30 CET (UTC+1), at the Danish Network Operators’ Group (DKNOG) in Copenhagen, I’ll talk about our experiments on NAT64 and DNS64 in the Go6lab and also about NAT64Check. Watch live via DKNOG’s live stream page at

As many mobile operators are moving to IPv6-only, which is incompatible with IPv4 on the wire, it’s necessary to employ transition mechanisms such as 464XLAT or NAT64. The Go6lab NAT64/DNS64 test bed was established so that operators, service providers, and hardware and software vendors can see how their solutions work in these environments. This has already generated significant interest; instructions on how to participate are available on the Go6lab website.

NAT64check allows websites to be checked for consistency over IPv4, IPv6-only, and NAT64, and to compare responsiveness using the different protocols. This allows network and system administrators to easily identify if anything is ‘broken’ and to pinpoint where the problems are occurring, thus allowing any non-IPv6-compatible elements to be fixed. For example, even if a web server is not running IPv6 (why not?), hard coded IPv4 addresses can cause NAT64 to fail.

During the talk I’ll share some insight and discuss issues that I found while testing NAT64/DNS64 technology in real life scenarios and use cases.

If you are at DKNOG, I’m more than happy to chat and discuss all this new technology that makes the Internet such a great place!

Deploy360 IPv6

New NAT64/DNS64 implementations available for public testing in Go6lab

go6labThis 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.

Jan Žorž

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 ‘’. The more NAT64 implementations there are for testing, the better it is.