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.

Deploy360 Domain Name System Security Extensions (DNSSEC) Improving Technical Security To archive Transport Layer Security (TLS)

FakeID, Android, Certificates, and Implementation Details

Android-FAKEID-logo-200x200Security firm Bluebox Security has uncovered a vulnerability in Google’s Android mobile operating system , which could allow attackers to trick an Android device into installing malicious applications. The package installer component of Android doesn’t check the validity of the certificate chain.

We don’t know all of the details yet. Bluebox is waiting on formally presenting the vulnerability at the Blackhat security conference, but it looks bad. Affected versions appear to be all Android releases after version 2.1 and before 4.4.

According to this article, it appears the problem has been traced to the inclusion of code from the now discontinued Apache Harmony project. The worst part of this vulnerability is due to the way Android is deployed in the marketplace. Many Android users will never see a fix, because their handset manufacturer no longer supports their handset. They will remain in the wild, and vulnerable, until they’re taken out of service.

When cryptographic gaffes happen it’s very tempting to point to a new protocol like DNSSEC, and claim it does not have this problem. Indeed, I wrote about the new trust models presented by DNSSEC, DANE, and Certificate Transparency earlier this month. I argued that we need to move away from trusting centralized entities such as Certificate Authorities, and instead distribute our trust model using both Certificate Transparency(RFC 6962), and DNSSEC / DANE.

However, the real culprit here isn’t the hard coding of CA’s in applications, or the Public Key Infrastructure(PKI) that affords the signing of certificates by multiple authorities. The real culprit here is Android’s abject lack of checking the certificate chain. From what we know of the vulnerability, Android’s package installer just implicitly trusts the presented certificate chain, without any verification.

No new technology or protocol can rectify this kind of broken behavior. If Android’s package installer implemented certificate verification via DNSSEC / DANE, it would still need to query DNS for the hash of the certificate and verify it. If Android’s package installer checked a package’s certificate against a public log, a la Certificate Transparency, it would actually have to check it. The lesson here is not that one technology is better than the other, but that actual follow through is important. If your security model is based on certificate chains, then verify the certificate chain.

There are still obvious advantages to an Internet with fully deployed DNSSEC, and an Internet where CAs append their issued certificates to a public log for Certificate Transparency. We just should not forget that implementations matter, it’s usually the implementations where the flaws are found, and not the underlying protocols themselves.

If you would like to learn more about Certificate Transparency, please visit If you would like to learn more about DANE, please visit our resource page on DANE. If you would like to get started with deploying DNSSEC please visit our DNSSEC resources, or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have a Certificate Transparency, DANE, or DNSSEC case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!

Deploy360 IPv6

Skype On Android Works Over IPv6 On Mobile Networks Using 464XLAT

Mobile operators are running out of excuses why they can’t roll out IPv6 for their users and phones! The deployment of IPv6 in mobile networks has been possible for a long time now. Slovenian operators Mobitel and Tušmobil implemented it as a test in 2010 and Simobil did it a year later, but none of the operators has  yet decided to start selling a special “package” that would offer an Android phone and IPv6-only data access (in addition to the voice service). This is due to the fact that until now “legacy” applications that works solely and exclusively on IPv4 – such as Skype – does not work if the phone is not connected with IPv4 connection …

Such a decision is understandable, since it would cause a problem with the users to whom certain applications would not work.

This is now the past, Google has added a mechanism in Android 4.3 called 464XLAT and solves the fundamental issue of such legacy applications on the phone, which has only IPv6 connection.

In Paris World IPv6 Congress meeting, Lorenzo Colitti from Google and myself showed how the system works and how 464XLAT solves the problem of Skype and other legacy v4-only applications.

The mechanism shown was a prototype, existing only on the Lorenzo’s phone, so I lent him my Simobil test SIM card, we connected over IPv6 roaming (thanks Simobil for roaming traffic for demo purposes) and Skype and other applications started working right away.

How 464XLAT works? You can find it here and on the ISOC web portal D360, where the event in Paris is briefly described.

Lorenzo mentioned to me at the IETF meeting in Berlin that this mechanism is now already included in Android 4.3 and the first device to be sold with this version pre-loaded is Nexus7 LTE.

A few weeks ago the announcement was made that this model of Nexus7 tablet was available in our country and I ordered from one of our major online stores.

After two weeks of waiting the postman brought me a package. 🙂

I wanted to see what the user experience of a regular customer is, so I did not complicate it much. I took the tablet out of the box, turned it on, went through the initial classical procedure to set basic parameters and inserted a Simobil test SIM card that has IPv6 enabled (the only one that has been “cut” to the microSIM, the same would work equally well Mobitel and Tušmobil test SIM cards with enabled IPv6) and installed Skype.

If the package would be sold by mobile operator, the settings of a mobile network connections would be pre-set to IPv6, but in this case I had to configure the network connection to use IPv6-only.

A moment later, when the connection was established I ran Skype, logged in with my username and called my other test account, which I set on another device – and the whole thing worked right away 🙂


In the picture you can see the “screenshot” from Nexus7 tablet where I called the device that also had a camera focused on me, so that I can check the quality of the videocall – and I was more than surprised of how well it worked!

Then I went to a “core” of the Android system and tried to find out what interfaces are there – and found a brand new clat4 interface that was not there before.


You can see that the mobile interface had only IPv6 address and the interface CLAT had address, which is reserved for the ” IPv4-to-IPv6 translation by IANA .”

This means that in the Android 4.3 464XLAT functionality is already included and enabled by default, you don’t have to ask for it specifically. It’s in there, waiting for legacy and archaic v4-only apps to send v4 packets.

The beauty of this new mechanism is that the operator does no longer need to assign an IPv4 address to each mobile phone. This can help significantly in the IPv4-depletion crisis that is coming. In short:

  • CLAT interface simulates the IPv4 address
  • Skype is convinced that this is the right interface and it starts sending packets
  • 464XLAT converts them into IPv6 packets that are sent over mobile network
  • the NAT64 in the core then converts them back to IPv4 and send to the Internet.

T- Mobile USA has already started to sell and ship to the users pre-set IPv6-only phones, especially because Android has the option to setup different APN protocols for home network and roaming. Moreover, T- Mobile USA has made a change in the profile APN settings in Android and set up IPv6 as a “default” 🙂

Hope that other mobile operators in my country and around the world follow this example, it is about time 🙂