We’ve known for a long time that the days of IPv4 – the machine-friendly 32-bit expression of IP addresses (126.96.36.199) which undergird every web address (https://www.google.com/) – are limited. Yet the challenge of converting to the replacement IPv6 protocol – a 128-bit version with 340 undecillion possible addresses – is proving to be far more difficult than anyone predicted.
How difficult are IPv6 migrations? A recent report from the Government Accountability Office – a US agency which audits government departments – shows just how hard.
The US Department of Defense (DOD) reportedly uses more IP addresses than any other organization in the world – 300,149,760 at last count. Recognizing the natural limits of IPv4 early on, DOD resolved to switch over to IPv6 as early as 2003. Seventeen years later, only one DOD network has fully transitioned to IPv6. Reports were written, Inspectors General weighed in multiple times, GAO audits were performed, and even legislative mandates were passed.
Yet IPv6 remains a pipe dream at DOD. It’s almost a punchline among the many IT admins we speak with – the big initiative that’s always 2-3 years from completion.
While GAO found fault with DOD’s planning and procedures, they also recognized the intrinsic technical challenge of migrating to IPv6. This isn’t an easy lift. It’s not just a blanket change you can roll out over a weekend with a few network admins. IPv6 migrations involve re-architecting entire systems. The sheer volume of effort involved is enormous.
Why are IPv6 migrations so hard?
The inventory challenge
Transitioning a network to IPv6 means changing every single IP address in use on that network.
In 2003, those IP addresses were mostly devices and servers. Creating a complete inventory of DOD devices and servers was a challenge, but not an impossible one. Yet as the IPv6 project was delayed, the number of IP-enabled items ballooned. IoT and mobile devices joined the network. Then virtualization hit, adding IP addresses for every VM. Now, each of those VMs has devolved into thousands of containers, each with their own IP address, many of them existing only for a few hours at a time.
If the number of IP addresses was a bucket of sand in 2003, it’s an entire beach today. Simply getting a handle on what needs to be transitioned seems like an impossible task.
Let’s say DOD was able to magically inventory all of its IP space. Then it would have to assess the risks of shifting to IPv6 for each of those devices, servers, VMs, containers, and more.
It’s not a security issue – IPv6 is far more secure than IPv4. The issue is that so many devices and applications aren’t IPv6 compliant. Even worse, many devices and applications claim to be IPv6 compliant but aren’t actually compliant when deployed in the wild. Sometimes hardware can handle IPv6, but the accompanying software can’t. In many cases, IPv6 patches and bugs are known issues that companies aren’t in a major hurry to resolve.
In the absence of a clear government mandate or enforcement mechanism, the state of IPv6 compliance will probably remain murky for some time to come. All of this is a massive headache for any network administrator trying to roll out IPv6 – there’s simply no way to tell in advance what’s going to cause trouble. The only way to find out is to exhaustively test things out in a lab. Which brings us to the final reason why IPv6 is so difficult.
Finally, there’s the cost of actually making the transition. Given the complexity involved, this is not something you’re going to want a robot to do – at least not all the time. It takes network administrators a great deal of detail-oriented effort to test any IPv6 transition and then bring it into production. They have to test connections, ensure devices are actually IPv6 compliant in practice, and in some cases re-architect entire networks.
Weighed against the day-to-day demands on any network team plus the need to move forward on strategic initiatives like cloud, virtualization, SD-WAN and others, IPv6 seems like a high-effort, low-value project. That’s why it’s been continually deprioritized at DOD and just about everywhere else.
Leaning in on IPv6
While transitioning to IPv6 is a daunting task, everyone is going to have to do it eventually. With IPv4 space now officially exhausted, the cost of treading water is only going to increase. Sure, hacks like NAT-ing and dual stack deployments will buy some time. The secondary market for IPv4 space may provide a viable (if costly) way of kicking the can down the road. Yet the reckoning will come for everyone.
Here at BlueCat, we know that any IPv6 transition is going to be a huge effort. Nobody wants to do it. They’re forced to do it.
We’ve led our customers through many IPv6 transitions, and along the way we’ve learned a few things about what works and what doesn’t. For example, we’ve learned that IPv6 transitions require close attention to all three parts of DDI – DNS, DHCP, and IPAM, all working together. We’ve used these and other lessons learned to build out a repeatable strategy to guide customers through the change, from planning to execution.
If you’re making the move to IPv6 (however grudgingly), we’re here to help. Get in touch and let’s chat about it.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
9 tech leaders’ advice on running a technology organization (part 2)
A compilation of 8 tech leaders’ (+ BlueCat CSO Andrew Wertkin) advice on driving innovation and achieving overall success as a tech organization.
9 tech leaders’ advice on sustaining business alignment (part 1)
Now that Season 1 of the popular podcast Network Disrupted has wrapped, it’s time to parse insights from the show and share them with you.
IT pros debate: Should you DIY your DDI?
Five IT pros get real about DIY vs. enterprise DNS solutions during the second Critical Conversation on Critical Infrastructure hosted in Network VIP.
How to Configure DHCP Failover
The DHCP failover protocol provides a method for two DHCP servers to communicate with each other.