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