This document is not intended to be a comprehensive and detailed technical digest of how to deploy IPv6 in an ISP network that currently has IPv4. Instead it is an executive summary of the 12 fundamental steps, not including services (DNS, web, email, etc.), for native IPv6 support and the maintenance of IPv4 as a transparent service.
- Determine how many customers (home + corporate) your network has and what the expected growth in the short/medium term will be. If the total is smaller than 50,000 customers, we recommend you to request a /32 from your Regional Internet Registry, a /31 if you have up to 100,000 customers, a /30 for up to 200,000 customers, and so on. If you already got a /32 and have more than 50,000 customers, you can request an upgrade of your actual prefix. To request your IPv6 prefix, visit Request IPv6.
- Audit your network, as you need to know what equipment has IPv6 support, and what needs to be updated or replaced. It is important to have a detailed inventory, from your upstream connections to the customers CPEs. If your vendors don’t provide the right support, you should push them. Generally, the market is big and free.
- Get professional training with companies that have a demonstrated experience in IPv6 deployment for ISPs (the RIPE NCC also provides IPv6 training material). IPv6 is not more difficult, but IPv4 and IPv6 are different and the difficulty may be “changing your mindset”: It is necessary to “unlearn” IPv4 to correctly understand IPv6. It might be convenient to agree on a consultancy service together with the training. It may seem excessive, however, it might save you time, as the transition to IPv6 will become more important and urgent and that time will cost more in terms of business losses and problems with IPv4 than the cost of that training and consultancy.
- Confirm with your upstream providers, including Internet Exchange Points, that they have IPv6 support and configure your BGP sessions to use it. For content, also confirm that any Content Delivery Networks (CDNs) that you use have IPv6 support. Many of them do! In some cases, they simply won't 'grandfather in' existing sites. Cloudflare is supporting this trend. If your upstream providers don’t have IPv6 support, you really need to look for better partners. This part of your network must be dual-stack. In the worst case, if there is no way to get dual-stack from one or several of your upstreams, you may need to use a tunnel, typically by means of 6in4 (protocol 41, manually configured) or GRE, but you should consider this only as a temporary solution.
- Review your security policies. They should be equivalent to what you apply with IPv4, but remember that you should not filter ICMP with IPv6 (see ICMP filtering guidelines) among other related details that will avoid the correct flow of traffic across your network. Review also the IPv6 prefix filtering in your BGP peers; again, those are policies conceptually equivalent to what you already know for IPv4, but with a different protocol. Please also see operational security considerations.
- Configure IPv6 support in all your monitoring systems. IPv6 has the same importance as IPv4, so any system that allows, either from inside or outside your network, view the traffic quality, quantity, stability, visibility of your prefixes, etc., must support IPv4 and IPv6 with the same conditions.
- Now that you already know the differences between IPv4 and IPv6, you’re ready for designing your detailed addressing plan. This is the master piece for the correct IPv6 deployment. It is quite different from IPv4 addressing plans and I recommend to use an IP Address Management tool. The RIPE Labs article on Preparing an IPv6 Addressing Plan and the online IPv6 Subnetting Card might be helpful.
- Deploy IPv6 in your core and distribution networks. Dual-stack might be sufficient during the first phase. In a follow-up stage, maybe you will be able to supress IPv4 in part of those networks, so you can reuse those addresses in other parts of your network.
- It might be useful to start with a small trial, in your own corporate network. Remember that a /64 is the minimum for each LAN or VLAN. Also remember that the golden rule is to keep dual-stack in the LANs/VLANs (even if you use private IPv4 addresses) and that it is easier to use Stateless Address Configuration (SLAAC) and RDNSS (we're also one step closer to RNDSS support for Windows). DHCPv6 is another option, most of the time unnecessary, moreover, Android doesn’t support it. Also in this phase, it may be interesting to involve some of your corporate customers in the pilot phase, even some residential ones. It is not so relevant if at this stage, manually provisioning is required.
- Prepare your access network as well as the provisioning system. Your billing systems may be affected too. Is time to define what transition mechanism is the right one. My recommendation is 464XLAT[1], at least for the residential customers and cellular networks. It is a must to have good support from the CPE vendors. For the provisioning the best will be to use DHCPv6 prefix delegation. You can use the RIPE BCOP in order to understand how to number your customers.
- Configure the provider-side translator (PLAT) (NAT64+DNS64) in your network. Don’t use carrier-grade NAT (CGN), it will bring you much more problems, higher costs (not only for the CGN itself, but also for the logging systems). If you’ve a cellular network, with a PLAT deployment, and setting up an IPv6-only APN, you will have all done for the smartphones and other 3G/LTE devices. In the case of Android and Windows, they come with a customer-side translator (CLAT), while iOS/Apple only use PLAT, because they mandate IPv6 support in third-party apps.
- Update the CPEs. Try again with some customers, once updated; this is the most critical and complex part of the entire process. There are many ways to approach it. Once done, you’re ready for a massive IPv6 activation (maybe in phases, regions, etc.) and for a commercial announcement.
Your network is ready for the future!
Now, you need to start considering how to take profit of IPv6 with new services and applications, IoT is a hint, sure you will find other advantages.
[1] 464XLAT is one of the most recent transition mechanism (and it is used in various mobile networks, 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; in addition to that, it provides IPv4 private addresses to the users (by means of CLAT), so that devices and applications still work in a transparent way. However, due to the lack of support of newer transition mechanism in installed CPEs, not many ISPs have used it yet, but some large trials are being carried out and more support in CPEs is expected due to some recent work done in the IETF.
Comments 8
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Mayssam Rahmatian •
Thank you for this useful article , Great Job !
Jacob •
I'm curious off the implementation and performance differences between 464XLAT and DS-Lite. More information would be appreciated!
Hide replies
Jordi Palet Martinez •
There are several improvement factors. In DS-LITE you tunnel every IPv4 packet, and then you are doing NAT44 for each one of them as well. In 464XLAT you only do NAT46 (at the CLAT, so no overhead for the NAT64) for those packets that use literal IPv4 addresses, no tunneling. So there is more and more native IPv6 traffic, and only when the destination is IPv4-only then the NAT64 is used. So in general you have less overhead in at NAT64 than in a CGN as well. Finally, you're not restricting specific ports per user (CGN), you share IPs per flows (NAT64).
Wisam •
Great job
Milad Afshari •
Good job!
Adil Hidayat •
Thank you
Vincent Derksen •
In general, I do think the article of Jordi Palet Martinez is a useful one. I did prior, as a program manager, most of the implementation of IPv6 within a large Dutch ISP. Most of the really important topics for a successful implementation, I think, are mentioned in this article. But in regards to this, I would like to emphasise the following: - When starting an implementation, both mindset and knowledge about IPv6 are really important. Off course, together with a lot of mission work towards all layers of management concerning the necessity to implement IPv6. - Do the IPv6 implementation with a bottom-up approach. Most complexity and functionality is in the CPE. It’s a service endpoint and is a point of vulnerability from security perspective. Test IPv6 on your CPE's first in a lab environment in conjunction with the supplier/vendor. Use it for the technicians to get acquainted with IPv6 and it’s behaviour. Like always: Start on cracking the hardest nut first! For projects with a commercial justification (Business Case) like IPv6, it’s important to keep up the pace. Always avoid losing priority over other projects! - Involve the security department from the beginning and have them co-test the IPv6 product in the lab environment on all possible security vulnerabilities. The way IPv6 is designed in regards to the CPE (e.g. No NAT anymore) creates new vulnerabilities. Use this input for a proper security plan. Important here: Implementing IPv6 is actually quite simple. Implementing IPv6 with respect to subscriber’s privacy and with sufficient level of security is a different ballgame. And the last one is what this implementation is all about (At least, I hope if I was the subscriber here). Also, don’t hesitate to do one or more security audits all over the project, it provided us surprising but very useful results! - In parallel, make sure there is a solid IPv6 plan. Allocating the right amount of address space to subscribers is very important off course but besides that, there is only one chance to design the network “first time right”. We did analyse our biggest operational challenges we had in relation to IP(v4) maintenance. We found out that we had spent over the years a huge amount of effort on shuffling, renumbering and migrating subscribers over different parts of the network, based on capacity growth, adding acquired networks and constantly balancing CMTS capacity in relation to segmentation and usage. Try to learn from the past and make smart choices towards the future. IP Address Management (IPAM) is mandatory to keep control of maintenance costs on the long term, although the importance of this is hardly never acknowledged at initial stage. - Once this is all in place or in good progress, certifying and implementing IPv6 on DNS services, within the Backbone and so on is relatively straight forward. - Implementing, like also suggested in the article needs a proper pilot. In our initial implementation, we faced several serious production issues. We couldn’t have handled those if we would have activated IPv6 over the entire footprint. I consider this a “no brainer”. Good luck with implementing, please don’t hesitate to share your findings here. Also, feel free to consult me if you feel the need to.
Hide replies
Jordi Palet Martinez •
Thanks a lot Vincent, totally agree with your inputs!