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 IPv6

More on IPv6 Performance

RIPE LabsLast week, we highlighted a presentation given by Geoff Huston at RIPE 71 where he discussed the performance and reliability of IPv6. His conclusions were that if you can establish a connection, then IPv4 and IPv6 appear to have comparable performance, although currently the odds of establishing the connection still favour IPv4 for various reasons.

RIPE Labs have followed-up on this presentation by publishing a more detailed article on IPv6 performance on their website. As well as explaining the test methodology in more detail, it makes some interesting observations about the reliability of tunnelled connections, but also the rise in the use of Unicast IPv6. More generally, it reinforces the recommendation in RFC 7526 that 6to4 should be obsoleted.

For more information on what this means for you, please do look at our Start Here page to understand how you can get started transitioning your networks, devices and applications!

Deploy360 Improving Technical Security IPv6

RIPE 71 – Highlights from Day 2

RIPE71_logoThe RIPE 71 meeting is happening this week in Bucharest and each day we’ll be highlighting the presentations and activities related to the Deploy360 technologies.

Most of Tuesday was taken up by the plenary session, but well worth highlighting is the presentation by George Michaelson on IPv6 deployment. Since 2010, APNIC has been collecting 12-15 million samples per day using placement of adverts through Google on selected websites. This has previously been undertaken with Flash, but due the increasing security issues that are leading browsers to discontinue support, they have recently moved to using an HTML5 model. In fact, with Flash predominantly running on Windows-based platforms, they are now seeing a wider range of operating systems and browsers, as well as getting a good insight into cellular networks for the first time.

One significant recent IPv6 deployment is by cable provider Sky UK which is upgrading approximately 80,000 customers to per night, with nearly 17% of their hosts currently enabled for IPv6. Whilst this dwarfs any other UK provider, it puts them on target for 20%+ IPv6 capability by 2016.

T-Mobile USA is also known to have deployed 464XLAT which allows clients on IPv6-only networks to access IPv4-only services. This is predominantly a cellular provider with some WiFi services, and is indeed showing around 60-80% IPv6 capability. Android devices in particular show high consistent usage of IPv6 capability, and with Google, Facebook, CloudFlare and Akamai routinely supporting dual-stack content, this is reducing the CGN/NAT requirement for IPv4. It should be noted though, that Apple does not implement 464XLAT in its iOS devices, which explains the very low visibility of these devices.

SK Telecom in Korea is deploying 464XLAT to its 20 million customers as well, and has converted approximately 4 million devices to IPv6 capability. As Korea has more mobile users than broadband users, this deployment along probably amounts to a 2% IPv6 penetration rate in Korea.

Over in the US, a number of the major providers including AT&T Verizon Cellular, Comcast and Sprint appear to have been deploying true dual-stack on cable and wireless networks as similar prominence of iOS devices can be seen alongside Android devices. There are exceptions seen on the AT&T and Sprint cellular networks suggesting 464XLAT deployment, but interestingly iOS devices are still seen in some numbers which may relate to APN problems or even vendor marketing preferences with respect to the handsets.

Check out George’s excellent presentation for more information on deployments in Ecuador, Brazil, Peru, Poland, Norway and Romania and the suppositions about how they’re provisioning IPv6.

Later that evening was the well attended Anti-Spoofing BoF chaired by ISOC’s Andrei Robachevsky and Benno Overeinder of NLnet Labs. This presented the problems of spoofed Internet traffic and outlined some of the solutions, but posed the question as to whether the problem was being solved in the right way, or should community efforts be better focused on the attacking vectors of a DDoS attack. The aim was to understand the challenges from the perspective of IXP customers (e.g. ISPs, CDNs) and to discuss their future needs, and led to a long and fruitful discussion running well over the time allocated for the session. Andrei will be posting more over on the Tech Matters Blog shortly.

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at

Deploy360 Improving Technical Security IPv6

New IPv6 Security Testing from go6lab

IPv6 badgeIn my go6lab, I often work with vendors to test the implementation of various IPv6 features and let them know how things are working in a real IPv6 network environment. Recently, we got a quite powerful firewall device from a vendor we’ve been working with for years to test out in the lab. In version 6 of their operating system (PanOS), they started implementing some neat IPv6 security checks that we usually don’t see with other vendors. Of course, we don’t have all firewall vendors’ devices here (we are open for everyone to send in a device and we’ll put it in our setup), but from what we see, these IPv6 security checks at firewalls are quite rare and that was the reason we took some time and looked at them a bit more closely.

We had the privilege and honor to host the IPv6 Toolkit development VPS for Fernando Gont, so we have all the latest tools and attacks at hand for testing and I would like to thank Fernando for some additional ideas about what tests to run. Of course, we used IPv6 Toolkit for all our testing and below are the commands if you have this toolkit installed.

So, what did we test? We set up a target device on the other side of the new firewall and tried to send all sorts of malformed or malicious packets through with different settings, then watched on the other side to see if some of these packets came through to the target.

This is how firewall zone protection profile setting looks like by default:

There are many very useful options, but unfortunately they are not enabled by default. From their documentation we can learn that the IPv6 sub-tab has various options that provide the ability to drop IPv6 packets based on different fields of the IPv6 header like type 0 routing header, anycast source address, hop-by-hop extension, routing extension, if the packet has needless fragmentation, etc.

So, let’s test some of the most interesting ones. We changed the configuration to enable all the options on the list to see if we can get any of the attacks through. For demonstration reasons we are using documentation prefix, 2001:db8::2 is our target where we are sending packets from 2001:db8:1::2 host.

First we tried atomic fragments: frag6 -d 2001:db8::2 –frag-type atomic

Next we tried: frag6 -d 2001:db8::2 –frag-reass-policy -v

Of course, the pMTUd less than 1280 trick: icmp6 –icmp6-packet-too-big -d 2001:db8::2 –peer-addr 2001:db8:1::2 –mtu 1000 -o 80 -v -l -z 1

The firewall did not block all the malicious or malformed packets with the default setting of Zone protection profile, but with all options turned on the device correctly identified the attacks and blocked the traffic to destination machine. Well done!

Then we went to RFC7112 compliance tests:

tcp6 -d 2001:db8::2 -X S -a 4444 -v –probe-mode script

This command sends a SYN, and the tool prints whether it received a response or it timed out – and it’s passing the firewall as this is a legitimate packet to send.

Then we tried more nasty stuff: tcp6 -d 2001:db8::2 -X S -a 4444 -v –probe-mode script -u 8

This command does the same thing, but now the IPv6 packet carrying the SYN segment will employ a Dest Options IPv6 EH of 8 bytes – and these packets are immediately filtered and blocked by the firewall.

After this we sent the same packet, but now with Destination option of 1k: tcp6 -d 2001:db8::2 -X S -a 4444 -v –probe-mode script -u 1000
…and finally we tried this: tcp6 -d 2001:db8::2 -X S -a 4444 -v –probe-mode script -u 1000 -y 600

This command produces one of the RFC7112-forbidden packets (it employs a Dest Opt EH of 1000 bytes but requests the tool to frag each packet in 600 bytes (-y 600), so the extension header chain gets fragmented. Of course, all those packets were recognized and blocked by the firewall.

We also did many other tests and this vendor did recognized every malformed IPv6 packet and blocked the attacks. We are very happy to see that IPv6 implementations are progressing and that there are vendors that are paving the way in IPv6 security.

Go6lab recently received a second PA-4050 device from this firewall vendor and we are testing PanOS 7 beta for even more advanced IPv6 features, but we can’t talk about this yet as this version was not released to the public yet and new features are still under NDA – but we’ll keep you posted.


In the meantime, if you’re looking to get started with IPv6, learn more about IPv6 Security, or even if you don’t know where to start, we’ve got you covered!

Deploy360 IPv6

Live Demo of 464XLAT at Swiss IPv6 Council Event

Last week, at the Swiss IPv6 Council’s “IPv6 Business Conference” in Zurich, I did a live demo using the 464XLAT mechanism on my Android phone, using it to allow IPv4-only applications like Skype to work in an IPv6-only mobile environment. The process got a bit bumpy, but in the end it was a successful demo!

Let me back up and say that the event, overall, was a great success. I saw some new IPv6 material and perspectives that I had not seen at other meetings, so I am thankful to Silvia Hagen for the invitation. I actually did two presentations in addition to the live demo. My first talk was about the “IPv6 troubleshooting for helpdesks” document and tool, which we’ve talked about here recently. My second talk was about the story behind RIPE-501 and RIPE-554: “IPv6 requirements for ICT equipment” publications, which we talked about here last year.

The third session was one that could have – and nearly did – go completely wrong: a live demo of 464XLAT in an Android phone. You can read more about how 464XLAT works and my first lab tests in the go6lab in this previous 464XLAT post. I would again like to thank Simobil, the Slovenian mobile operator that (long ago) provided me with an IPv6-enabled SIM card for tests and live demos.

Troubleshooting the Demo

Jan explaining 464XLAT

The issues began the day before the meeting when I realized that data roaming in Switzerland adds new unpredictability into the equation. Big thanks to Gert Doering for his assistance as we frantically fiddled with various settings and every possible combination of SIM cards and devices to find the combination that would work. In the end, we realized our major issue was a setting in Simobil’s billing system. When Simobil introduced LTE, they re-provisioned my test SIM card and the script set the roaming limit to 60EUR. When I reached this limit, strange things started to happen: the PDPv6 context was established, I got an IPv6 address, the CLAT interface did not start, and traffic did not move. Simobil quickly removed the limitation the morning of the live demo, and the whole thing started working immediately.

Just before I was set to go on stage, Skype decided not to connect anymore via my tablet. My turn was quickly approaching and I had no time for further debugging. After a brief explanation of the situation, I showed the tablet to the audience – the working connection, the IPv6 address, the 3G connection, the functioning Google and Facebook, the CLAT interface – but from some strange reason, Skype wasn’t working anymore. After some live debugging I decided that maybe the NAT64 server in Simobil’s core had some problems.

Live demo
Video stream of what’s happening on Nexus7 – interfaces and IP addresses (CLAT and others)

I tried to assure the audience that usually this works flawlessly, and went back to my seat to troubleshoot some more. Silvia continued the presentation with some IPv6 use cases and I left the stage, completely frustrated with the outcome of my live demo. I’m an engineer; I judge by results.

From my seat, I opened Skype on my laptop and began chatting with my friend Nejc from Simobil online, who had just helped me with the billing issue. He agreed with my assessment that something was wrong with their NAT64. Then I realized – there’s a working NAT64 in my go6lab (three of them, in fact)! I suggested that he reconfigure the GGSN to send one of my DNS64 addresses when establishing PDPv6 context. I re-established my PDPv6 session, received DNS information pointing to one of the implementations in my go6lab and voila – Skype connects!

Success! The 464XLAT starts, Skype connects, and video call works!

I stood up, interrupted Silvia’s presentation, and loudly proclaimed the issue solved, and called Silvia on Skype, via her mobile phone. We got the video up and showed the audience how the whole setup works. Obviously, the first question from the audience full of engineers like myself was, “How did you make it work and what was wrong?”

I explained the solution of using a different NAT64 server, and the audience was quick to realize that, in fact, everybody using IPv6 on Simobil’s network was now sending traffic to the go6lab. I assured the audience the lab has enough uplink capacity to keep it going until Simobil’s NAT64 translation service returns to operational.

Thanks, again, to Nejc Bačič from Simobil for all the help, and to Silvia Hagen for helping do the live demo with me – and for being flexible enough to let me interrupt the program to finish what we started and show a successful result!

Deploy360 IPv6

Case Study: Printing and Scanning Over IPv6 Only?

As happens to all of us from time to time, my old printer broke down and it was time to get a new one. However, for me, as co-author of RIPE-554, which defines the IPv6 requirements for ICT equipment, I couldn’t just go and buy any printer. It had to have IPv6 support. After a bit of searching, I finally found one that fit all my needs, including IPv6 support: A Brother DCP-7065DN.

After unboxing the device and connecting it to the network – the truth reveals: It has IPv6 support!

Printer Setup

Setting up the IPv6 address is not a problem; the menu is  under “Network configuration” -> “Configure TCP” (where IPv4 settings are) -> “Configure IPv6”.


So far so good! After initial setup I could ping6 the device with no problems whatsoever.

One important note: Router Advertisements (RAs) are enabled on this link, so the printer can setup its default route using SLAAC. For printing and scanning purposes I’m using a statically configured IPv6 address on the printer’s network interface.


The next step was to get my MacBook to work with the new printer. For printing there was no issues whatsoever. I chose “add a new printer,” put in the IPv6 address and the system immediately gathered the correct model and settings over IPv6 and selected the correct driver for it:


After setup, the printer was ready for the test and printing now works with no glitches over IPv6, even when I’m far away from home (and connected to an IPv6 network, of course).

A quick examination with Wireshark reveals that the packets carrying the print job are actually using IPv6 as a transport:


Too cool!

With printing working perfectly over IPv6, my next challenge was scanning over IPv6…


There is a Brother software called ControlCenter2 that is supposed to enable scanning over the network. While I did not test it with IPv4, it certainly has some issues using IPv6.

When I began the setup, my MacBook was on a different network segment than my new Brother printer. Printing over IPv6 worked like a charm – but not scanning. I tried to add the printer to my MacBook’s settings, but all I received back was an unidentified error. It seemed that the scanner software on the printer did not understand where to send packets, or where its gateway was.

Editors note: This is very likely due to either improperly scoped multicast discovery packets, or a home router blocking those multicast discovery packets. See work on service discovery in the IETF Homenet working group for more.

Of course, the next thing I did was to connect my MacBook to the network segment where the new printer is. From that point on everything went extremely well! The scanner was immediately recognized and then I could happily scan remotely, well, sort of “remotely.” I need to be on the same network segment to be able to scan over IPv6. Hopefully someone from Brother is reading this and can fix this small inconvenience for me (please, send me the patched version of drivers) 🙂


So, it looks like at least some printer vendors are implementing IPv6 today, and Brother is one of them.

A use-case for ULA?

The other issue that I encountered while using the printer over IPv6 is the dynamic nature of the local network that we are setting up. My laptop is set up to do SLAAC, so if my CPE goes down or loses its IPv6 connectivity settings then my printer is not reachable anymore, even from my local network. Since my CPE gets the prefix delegation over DHCPv6 from my ISP if that is gone (due to a link failure for example) then the IPv6 routing in my house is gone too. Well, not entirely in my house as my network gets reconfigured fairly quickly, but for a “normal” user who is not a network engineer this could be a serious problem. This is where ULA kicks in and I must admit, I put the ULA in the network segment where my printer resides – just for a test – and it worked. So there is one possible use-case for ULA addresses: For printers, home devices and all other gadgets that we want to connect to even if our ISP’s IPv6 connectivity is down or broken. In my case I removed the ULA from my network after the test, but for the less hands-on home network administrator it might be handy to have it configured just in case.

Final conclusion: We’ve come a long way, baby!

Good work, Brother. They still have some minor fixes to do, but generally IPv6 seems to just work, at least on this printer.

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 🙂