Here’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.
- 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).
- 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…
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.