Outgrowing your IPv4 allocation is one of many very good reasons to get on with deploying IPv6. Here's a use case on the latest steps the RIPE NCC has been taking in the piecemeal process of deploying IPv6 across its services.
Moving Toward IPv6
Our latest step towards full IPv6 deployment has been to switch the management interfaces for our DNS servers in London over to IPv6 only – both for K-root and our Authoritative DNS service. Although there's no change here for clients, we thought we'd share this as a brief use case on IPv6 deployment, explaining what prompted us to go full v6 and how we got the job done properly.
Why Now?
While parts of our DNS services have been running exclusively on IPv6 for some time, others haven't, and some components are even limited to IPv4-only. Updating services to run on IPv6 can seem daunting, but these efforts will be crucial as the global IPv4 supply continues to dwindle.
When we first set up our servers in London, our out-of-band (OOB) access was through a single device, and a small IPv4 subnet was enough for all of our services. However, our newer servers have a dedicated OOB management interface, which means they each require their own IPv4 address. As the number of devices has increased, we've outgrown the IPv4 subnet we were originally allocated. Instead of asking for more IPv4 addresses, we decided to switch to IPv6 only for our in-band management interfaces. This has now been completed in London, and we're considering doing the same everywhere. We're also evaluating moving the OOB management interfaces to IPv6-only as well.
Challenges
The process has been smooth so far, but it's always good to share solutions to the complications that can arise when you try to go full v6. First of all, our OOB interfaces don't allow setting Access Control Lists (ACLs) on IPv6 addresses. This presents a security challenge, as there’s no built-in way to filter traffic. However, we can use our firewall to filter further in the network for our own systems. So, in those locations where we control the network our OOB management interfaces are connected to, moving to IPv6-only seems like a useful goal to pursue.
Another issue we ran into was with our monitoring setup, which is based on Icinga. In its current configuration, Icinga defaults to assuming a system has at least one IPv4 address. Additional addresses, including IPv6, can then be monitored separately. To be able to monitor IPv6-only systems, we had to work around this default assumption. Where Icinga requests an IPv4 address for monitoring, we put in our IPv6 address instead and also include it as a secondary address. When Icinga does regular checks to see if the host is available at the address where we would previously configure an IPv4 address, there’s no issue because that address is now a v6 one too.
Finally, another hurdle was that some of the software repositories we depend on are available only over IPv4. We solved this by hosting a mirror on our own infrastructure and directing systems there instead. As we already have a mirror for other pieces of software and already do this for other repositories, this was easy enough to set up and was an obvious solution.
Summing Up
Once you make the switch, IPv6 just works. By taking this step, we’ve moved away from being v4-dependent, and in doing so we’ve freed up v4 space for other uses. This change also shows that v6 implementation is not only possible but practical. Although support isn't always up to par, there are solutions to the challenges of v6 implementation. Overall, IPv6 is a first-class citizen - we're now treating it that way.
Comments 0
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.