This post is not intended to be a comprehensive and detailed technical digest on how to deploy IPv6 in an ISP network that currently has IPv4.
Rather, I thought this would be a helpful executive summary of the 12 fundamental steps (as I see it) — not including services (DNS, web, email, etc) — to establish native IPv6 support and maintain IPv4 as a transparent service.
1. Acquire some IPv6 addresses. How many customers (home+corporate) does your network have and what is the expected growth in the short/medium term? If the total is smaller than 50,000 customers, I’d recommend that you request a /32 from APNIC, a /31 if you have up to 100,000 customers, /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, visit Get IPv6.
2. Audit your network, as you need to know what equipment has the right IPv6 support, and what needs to be updated or replaced. It’s 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 …
3. Get professional training with companies that have a demonstrated experience in IPv6 deployment in ISPs. 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 could be convenient to agree to a consultancy service together with the training. It may seem excessive, but 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 and enable it in your BGP with them. Do the same for CDNs, caches and IXs. If the actual 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 bypass.
5. Review your security policies. They should be equivalent to what you apply with IPv4, but remember that you should not filter ICMP with IPv6, 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.
6. 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, you to view the traffic quality, quantity, stability, visibility of your prefixes, etc., must support with the same conditions for IPv4 and IPv6.
7. Now that you already know the differences between IPv4 and IPv6, you’re ready for designing your detailed addressing plan. Nevertheless, the overall overview has already been done in the consultancy. This is the master plan for the correct deployment of IPv6, and is very different from IPv4. You will need an IPAM (IP Address Management) device or tool, as it is impossible to manage millions of IPs with the traditional text file or spreadsheet as you did before with IPv4.
8. Deploy IPv6 in your core and distribution networks. Dual-stack will possibly be sufficient in the first phase. In the follow-up stage, you may be able to suppress IPv4 in parts of the network, so you can reuse those addresses in the more relevant places of your network.
9. It will be very convenient to start some small trials, in your own corporate network. Remember that /64 is the minimum for each LAN or VLAN, that the golden rule is to keep dual-stack in the LANs/VLANs (even if using private IPv4 addresses) and that it is easier to use SLAAC and RDNS. DHCPv6 is an extra option, but is unnecessary most of the time; moreover, Android doesn’t support it. Also in this phase, it may be interesting to involve in the pilot some of your corporate customers, and even some residential ones. If configuring customer or residential clients involves manual provisioning, it may not be relevant at this stage.
10. Prepare your access network as well as the provisioning system. Your billing systems may be affected too. It 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 it may be best to use DHCPv6-PD. Use the RIPE BCOP to understand how to number your customers.
11. Configure PLAT (NAT64+DNS64) in your network. Don’t use CGN, as it will bring you many more problems, and higher costs (not only the CGN itself, but also the logging systems). If you have a cellular network, with the PLAT deployment, and setting up an IPv6-only APN, you will have done all that is needed for smartphones and other 3G/LTE devices. In the case of Android and Windows, they come with CLAT, while iOS/Apple use only PLAT, because all their apps are mandatorily supporting IPv6.
12. Update the CPEs. Try again with some customers, once updated; this is the most critical and complex part of all the process. There are many ways to approach it. Once done, you’re ready for a massive IPv6 activation (maybe in phases, regions, etc) and do a commercial announcement.
Your network is now ready for the future! You now need to start considering how to profit from IPv6 with new services and applications: Internet of Things is the key hint, but I am sure you will find other advantages.
Jordi Palet is CEO/CTO of The IPv6 Company.
[1] 464XLAT is one of the most recent transition mechanisms (and the most used one, with millions of users in 3G/4G networks), and has the advantage of using IPv6-only in the access network, so the ISP doesn’t require IPv4 addresses there; despite that, provide IPv4 private addresses to the users (by means of the CLAT), so that devices and applications still work in a transparent way.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
I have to question whether “Get professional training” is helpful to the objective of deploying IPv6 and enabling the creation of a better Internet. IPv6 specific training is an unwelcome expense which makes the business case more difficult as generally enabling IPv6 is done where the cost is zero.
Enabling IPv6 in the core network is easy for network engineers. IPv6 at the host is automatic. If the network, IPv6 CPE, and DNS are set-up correctly it all just works.
Well, in my experience, small and medium ISPs, even some times big ones, don’t have “free” time to tackle by themselves the learning of new technologies. This means that they can take several years to achieve a knowledge level acceptable for deploying a production network.
So yes, professional training it may be perceived as an unnecessary cost, however, in the end, it means you’re saving a lot of time, making sure that you get it right since the beginning and change your mind when learning IPv6 vs your actual IPv4 knowledge, so it is actually cheaper and more efficient than just starting from scratch by yourself.
Believe me is not so automatic as you say … unless you have done the homework correctly before.
I’ve got this comment from actual customers, some of them tried first by themselves, lost a lot of time with wrong concepts, and finally invested in a good training and in just a couple of months, been able to deploy IPv6.