As we approach the 10 year anniversary of World IPv6 Launch, a parallel effort attempting to extend IPv4 addressing is taking place – introducing a series of complex technical, political, and logistical issues. With all the success occurring with the ongoing migration to IPv6 (49% IPv6 adoption in North America according to Google), we recommend you avoid IPv4 extension solutions for a multitude of reasons.
The Misguided Solution
There are several subnets in the IPv4 range which are classified per RFC as reserved ranges, in many cases having been marked as reserved since the 1980s. The IPv4 extension solution is based around the concept of reclassifying multiple IPv4 reserved ranges and making them available for general use on the public IPv4 internet. Based on estimates of the ranges that would be subject to reclassification, this effort would only release an additional 419 million IPv4 addresses – insufficient to satisfy the worlds ever-increasing IP addressing demands brought on by the booming consumer technology sprawl created by the Internet of Things (IoT) revolution. These subnets consist of the following:
- 240.0.0.0/4 – future reserved use in RFC 1700 (later deprecated but still in the IANA reserved database)
- 0.0.0.0/8 – reserved for “this host on this network,” partially used for DHCP/BOOTP, not routable on the network and requires broad network device updates
- 127.0.0.0/8 – loopback subnet for local machines, not routable on the network and requires broad network device updates
- 224.0.0.0/4 – used for IP multicast routing, currently in use in many enterprise scenarios, would require considerable software updates and enterprise network re-addressing
For further reading, including technical details of this endeavor to circumvent modernization by clinging to last ditch efforts for extending the legacy of the IPv4 protocol, go here and here.
Technical Issues
Countless technology practitioners are fatigued by the lengthy 20-year and still ongoing migration to IPv6, and as a result may be eager to find solutions allowing them to avoid participating in the IPv6 migration and simply keep using IPv4. This exact behavior of perpetual avoidance and procrastination are the key factors that are driving the IPv6 migration into its third decade. Each attempt to extend the life of the legacy IPv4 protocol, through transition to CIDRs instead of class networks, and then widescale implementation of Network Address Translation (NAT), and now multiple levels of NAT, have not only delayed transition to IPv6, but have also introduced a quagmire of security concerns and end-to-end reachability issues while only delaying the inevitable exhaustion of IPv4.
Like each of the prior changes to the IPv4 protocol, the effort to reclassify currently reserved IPv4 ranges is fraught with technical challenges that will introduce a similar amount of churn to many organizations as simply migrating to IPv6 – all without providing any real improvement in capability. In order for this reclassification approach to be successful, the worlds network routing infrastructure would need to be pervasively updated to allow for these previously reserved ranges to be accepted. Further, a vast majority of all network connected hosts and application stacks would also require updates to be able to treat these previously off-limits ranges as usable and routable. The significant undertaking that would be required to address this change, which is so broadly ingrained into technology utilizing the IPv4 protocol makes this approach a significant investment in the wrong direction of progress – something most CIOs should not be keen on entertaining.
Logistical Issues
While introduced as a simple “patch” to the IPv4 protocol to change the address reservation behavior, the reality is that the process of implementing this fix across the existing technology base has an equivalent magnitude of transitioning to IPv6. In both successful migration to IPv6 and simply re-factoring the way the IPv4 protocol functions, the same often multi-year process must be completed:
- Perform a thorough inventory of all IP-enabled systems within the organizations network
- Assess each of the identified systems for their compatibility with the updated technology requirements, considering any internal and external system integration concerns
- Develop a plan for design, testing, acceptance, implementation, and support, considering business availability and continuity throughout the transition, and management plan for any internal or external factors and co-dependencies that exist
- Assess the cost and benefit of retrofit or replacement of legacy systems to ensure organizational alignment with the updated technology requirements
- Ensure staff receive the necessary training to implement, support, and operate the updated technology requirements
- Execute development, testing, acceptance, production piloting and final implementation through a gradual rollout of capability across the global production network.
- Continue to support the updated technology requirements through planned obsolescence.
Why should my organization care?
The world’s IT organizations are on the verge of repeating the same mistakes of yester-year, simply kicking the proverbial IPv6 can down the road again. Are today’s technology leaders satisfied accepting the risk, burden and lack of value added by yet another substantial technology migration that merely band-aids the problem of IPv4 address exhaustion by adding only 419 million addresses – an amount that will only extend the available pool of addresses by a few years? Instead of contributing to the problem by participating in this boondoggle – the worlds technologists must actively and aggressively embrace and adopt IPv6 now more than ever, to avoid yet another significant waste of human capital spent on additional IPv4 stall tactics.
If your organization is struggling to understand the path to IPv6 success, let our experienced IPv6 engineering team help you figure out where to get started! Contact the Tachyon Dynamics team today!