12 Steps to Enable IPv6 in an ISP Network [Archived]

By Jordi Palet Martínez

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

There are 12 fundamental steps ISPs can take to enable IPv6 on their networks. I have pulled together a brief executive summary on how ISPs can achieve native IPv6 support and the maintenance of IPv4 as a transparent service (not including services like DNS, web, email, etc.).

12 Steps to IPv6 for ISPs

Determine how many customers (home+corporate) your network has and the expected growth in the short/medium term. If the total is smaller than 50,000 customers, we recommend you to 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 got a /32 and have more than 50,000 customers, you can request an upgrade of your actual prefix. (Note: This example does not apply to the ARIN region. Please see either our Quick Guide or our Requesting Resources page to learn more.
Audit your network, as you need to know what equipment has the right IPv6 support or what needs to be updated or replaced. It is important to have a detailed inventory from your upstream connections to the customer’s CPEs. If your vendors don’t provide the right support, you should push them to do so. Generally, the market is big and free…
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. Possibly it could 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 becomes more urgent, that time will cost much more in terms of business losses and problems with IPv4, than the cost of that training and consultancy.
Confirm with your upstream providers that they have IPv6 support and enable it in your BGP with them. 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.
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.
Configure IPv6 support in all your monitoring systems. IPv6 has the same importance as IPv4, so any system that allows you to view the traffic quality, quantity, stability, visibility of your prefixes, etc. (either from inside or outside your network), must support both IPv4 and IPv6 with the same conditions.
Design your detailed addressing plan. This is your masterpiece for a correct IPv6 deployment, very different from IPv4. For sure 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 may have done before with IPv4.
Deploy IPv6 in your core and distribution networks. Dual-stack may be sufficient in a first phase. In a follow-up stage, maybe you will be able to supress IPv4 in parts of those networks, so you can reuse those addresses in more relevant places of your network.
Start a small trial in your own corporate network. Remember that /64 is the minimum for each LAN or VLAN. The golden rule is to keep dual-stack in the LANs/VLANs (even if using private IPv4 addresses) and that it’s easier to use SLAAC and RDNNS. DHCPv6 is an option, most of the time unnecessary (moreover, Android doesn’t support it). Also in this phase, it may be interesting to involve in the pilot some of your corporate customers, even some residential ones. It is not so relevant if at this stage, manual provisioning is required.
Prepare your access network as well as the provisioning system. Your billing systems may be affected too. Now is the time to define what transition mechanism is the right one. My recommendation is 464XLAT, at least for the residential customers and cellular networks. 464XLAT is one of the most recent transition mechanisms (and the most used one, with millions of users in 3G/4G networks), which has the advantage of using IPv6-only in the access network, so the ISP doesn’t require IPv4 addresses there; despite that, it provides IPv4 private addresses to the users (by means of the CLAT), so that devices and applications still work in a transparent way. It is a must to have good support from the CPE vendors. For provisioning, the best will be to use DHCPv6-PD. Use the RIPE BCOP in order to understand how to number your customers.
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 PLAT deployment, and set up an IPv6-only APN, you will be all done for the smartphones and other 3G/LTE devices. Android and Windows come with the CLAT, while iOS/Apple only use the PLAT, because all their apps mandatorily support IPv6.
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 a commercial announcement.

Bravo, your network is ready for the future! Now, you need to start considering how to take advantage of IPv6 with new services and applications. IoT is one area, but surely you will find others as well.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.