12 Steps to enable IPv6 in an ISP Network

IPv6 BadgeHere’s an quick guide on how to enable IPv6 in an ISP from Jordi Palet (Consulintel), that’s just been published by LACNIC. It’s not intended to be a comprehensive technical digest of how to deploy IPv6 in a network that currently has IPv4, but rather an summary of the 12 fundamental steps, not including services (DNS, web, email, etc..) for enabling native IPv6 support as well as maintaining IPv4 as a transparent service.

  1. Work out how many customers (home+corporate) your network has, and your expected growth in the short-to-medium term. If the total is fewer than 50,000 customers, we recommend you request a /32 from your RIR, a /31 if you have up to 100, 000 customers, a /30 for up to 200, 000 customers, and so on. If you already have a /32 and have more than 50, 000 customers, you can request an upgrade of your actual prefix. To request your IPv6 prefix, you need to contact the RIR for your region: AfriNIC (Africa), APNIC (Asia-Pacific), ARIN (North America), LACNIC (Latin American) and RIPE NCC (Europe).
  2. Audit your network, as you need to know which equipment has the right IPv6 support, and which needs to be updated or replaced. It’s important to have a detailed inventory, from your upstream connections to the customer CPEs. If your vendors don’t provide the right support, you need to be pushing them for it as the market is big and free…
  3. Get professional training from companies that have demonstrable experience with IPv6 deployment in ISPs. IPv6 is not more difficult, but IPv4 and IPv6 are different and the difficulty can be changing your mindset and it’s necessary to ‘unlearn IPv4 in order to correctly understand IPv6. Possibly will be convenient that you agree on a consultancy service together with the training. It may seem excessive, however, you will save a lot of time, as the transition to IPv6 will become more important and urgent and that time will cost much more in terms of business losses and problems with IPv4 than the cost of that training and consultancy.
  4. Confirm with your upstream providers that they have IPv6 support, enable BGP4+ with them, and do the same for CDNs, caches and IXPs. If the upstream providers don’t have IPv6 support, then you need to be looking for other partners. This part of your network must be dual-stack, but if there is no way to get dual-stack from one or more of your upstream providers, you may need to use a tunnel. This is typically provided using 6in4 (protocol 41, manually configured) or GRE, but you should consider this only as a temporary solution.
  5. Review your security policies. These should be equivalent to what you apply with IPv4, but remember that you should not filter ICMP with IPv6 amongst other things, as this will prevent the correct flow of traffic across your network. Review also the IPv6 prefix filtering with your BGP peers – these policies are again conceptually equivalent to those for IPv4, but using different protocol.
  6. Configure IPv6 support in all your monitoring systems. IPv6 has the same importance as IPv4, so any system that allows you to view traffic quality, quantity, stability, visibility of prefixes, etc.., needs to support the same with IPv6.
  7. Now that you know the differences between IPv4 and IPv6, you’re ready to design your detailed addressing plan. This is the key to correct IPv6 deployment, and is very different from IPv4. For sure, you’ll need an IPAM (IP Address Management) device or tool, as it’s impossible to manage millions of IP addresses using the traditional text file or spreadsheet methods you used with IPv4.
  8. Deploy IPv6 in your core and distribution networks. Dual-stack is possibly sufficient in the first phase, but in the next phase it may be possible to remove IPv4 from certain parts of those networks so you can reuse the IPv4 addresses elsewhere.
  9. Start a small trial in your corporate network. Remember that /64 is the minimum for each LAN or VLAN, that the golden rule is to have dual-stack in the LAN/VLANs (even when using private IPv4 addresses), and that is easier to use SLAAC and RDNNS. DHCPv6 is another option, but is usually unnecessary and Android also doesn’t support it. In this pilot phase it may be interesting to involve some of your corporate customers, even some residential ones, and you can use manual provisioning for just a few users.
  10. Prepare your access network as well as the provisioning system, and your billing systems may be affected too. It’s time to define which transition mechanism is the right one, and my recommendation is 464XLAT[1], at least for the residential customers and mobile networks. It’s also essential to have good support from the CPE vendors, and for provisioning it’s best to use DHCPv6-PD. Use the RIPE BCOP in order to understand how to number your customers.
  11. Configure PLAT (NAT64+DNS64) in your network. Don’t use CGN as it’ll bring more problems and higher costs (not only for the CGN itself, but also the logging systems). If you’ve got a mobile network with PLAT deployment and you’re setting up an IPv6-only APN, most smartphones and other 3G/LTE devices will already support this. Android and Windows devices come with the CLAT, whilst Apple/iOS/ only use the PLAT because all their apps are required to support IPv6.
  12. Update the CPEs, and try again with some customers once they’re been updated them as this is the most critical and complex part of the process.  Once done, you’re ready for your mass IPv6 activation (maybe in phases or regions, etc.) and you can make your commercial announcement!

Your network is now ready for the future, and you can start considering how to profit from IPv6 through new services and applications. IoT is the key hint, but you’ll be sure to find other advantages.

[1] 464XLAT is one of the most recent transition mechanisms (and the most widely used one with millions of users in 3G/4G networks). It has the advantage of using IPv6-only in the access network so the ISP doesn’t require IPv4 addresses there, but provides private IPv4  addresses to the users (by means of the CLAT) so that devices and applications still work in a transparent manner.

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

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 🙂

Deploy360 Events IPv6 To archive

Video: 464XLAT Live Demo at World IPv6 Congress in Paris

Mobile operators have said they can’t start selling IPv6 phones and data packages because some applications – including Skype – don’t work on IPv6-only networks. How do we fix this problem?

At the third World IPv6 Congress in Paris, we gave a live demo showing exactly how this can work using an IETF Internet Draft called 464XLAT to make IPv4-only applications like Skype work on an IPv6-only mobile phone.

The World IPv6 Congress was one of the best IPv6 events so far this year with great speakers and a great audience. I gave two talks: the first about the GEN6 project and how to enable emergency response teams with mobile IPv6 and a second talk about World IPv6 Launch and also our efforts to build a global Best Current Operational Practice (BCOP) repository where the best operational documents on how to run networks and implement new technologies like IPv6, DNSSEC, RPKI, and others should reside.

Lorenzo Colitti from Google contacted me before the event because he wanted to test an IETF Internet Draft implementation called 464XLAT: Combination of Stateful and Stateless Translation and demonstrate a prototype or “proof of concept” on his development Nexus 4 phone. (Editor’s note: This I-D was published as RFC6877 a few hours ago.)

I decided to make my GEN6 presentation a little shorter and invite Lorenzo on stage for the last 10 minutes to do a live demo of 464XLAT. The decision paid off, as the live demo was a blast! Below you can watch the video, recorded by Mark Townsley (big thanks!).

Lorenzo asked me to bring my test SIM cards from Simobil, one of the Slovenian operators that implemented IPv6 in its mobile network. My test SIM cards are provisioned and well tested with an IPv6 PDP context and are also currently testing the PDPv4v6 setup that enables both protocols in one connection.

As my SIM cards were provisioned to a non-production HLR (because of PDPv46 testing) we could not use it on the first day, until they were re-provisioned to the production HLR that was permitted to do roaming in France. For a start we used Norwegian SIM cards borrowed from Tore Anderson and they also worked well. After hacking the code late into the night on Tuesday, the 464XLAT was ready for a live demo in time for my GEN6 talk on Wednesday.

Hacking, coding and testing of 464XLAT went late in Tuesday night. Thanks also to Andrew Yourtchenko for help. Left: Andrew Yourtchenko, right: Lorenzo Colitti

For an introduction, listen to Lorenzo’s explanation in the video of how 464XLAT actually works (or read about that on the tmoipv6 pages).

In short: Some applications do not work in an IPv6-only environment because there is no IPv4 that they can send data to. One of those applications is Skype, and this stands between mobile operators and the start of handing out IPv6-only mobile devices, which is currently the only viable way to extend mobile networks. There is standardised NAT64 for accessing the IPv4-only content in the operators’ core, but this does not help IPv4-only applications on mobile phones.

The trick in 464XLAT is the CLAT daemon that resides on the phone. It creates a virtual interface with one IPv4 address (it can be the same for all the handsets, it does not matter). The application then connects to this interface and happily starts to send packets, because from the application’s point of view this is just an IPv4 interface. The trick is behind the curtains, where the IPv4-to-IPv6 translation engine resides, translating IPv4 packets and sending them over an IPv6-only mobile network to a NAT64 device in the core that translates the IPv6 packets back to IPv4 and sends them to the destination. The return packet goes back to the handset through the same procedure.

The name says it all – 464XLAT means IPv4 to IPv6 and back to IPv4 cross translation. This is very useful for mobile handsets, where demand is not as high as in fixed networks.

During the demo, Lorenzo explained how 464XLAT works and then put on the screen two packet traces – one for the IPv6 mobile interface and one for the IPv4 CLAT interface. His phone was connected over an IPv6-only PDP context to the Simobil core over a roaming connection and had a Slovenian IPv6 address. When he started Skype, both traces started to show packets and this continued even when I called him and set up a video call, as you can see on the video below. My phone was connected to the IPv4/IPv6 wifi network in the conference room, so the packets’ paths were quite wild, but nevertheless – it worked!

Lorenzo Colitti and Jan Žorž calling over Skype in IPv6-only environment.

What is the take-away from this live demo? Mobile operators were complaining that they can’t start shipping IPv6 phones and data packages to their users because “not everything is working, especially Skype.” Not anymore, as we showed to the world that there is a solution that fits and solves exactly this problem. We just need to wait until this appears in production Androids, and users get it with an OTA upgrade – but the first steps are done. It works, it is simple, and there are no visible issues with the code.

Message to mobile operators: “time to wake up, technology is ready and coming, it’s your turn now!”

Watch the video of the live demo: