Updated: August 07, 2017
From the time that this post was first published, global IPv6 adoption has increased from less than 7% to more than 20%.
In April of 2014 the American Registry for Internet Numbers (ARIN) announced that it was entering its final phase of its IPv4 countdown plan after reporting less than 17 million IP addresses remain.
Recently, ARIN created a waitlist for those ISPs who want IPv4 addresses because IPv4 is fully depleted and requests for new IPv4 addresses can only be fulfilled by matching up existing resource holders or returns. With the Internet of Things (#IoT) starting to take off, the transition to IPv6 is especially critical. ARIN and others are working to ensure the good folks of the Internet will have enough IP addresses to support our estimated 50 billion connected toasters, phones, endless devices by 2020.
The 32-bit nature of IPv4 means that it can support a maximum of roughly 4.3 billion IP addresses. Because IPv6 is a 128-bit communications protocol, it supports an astronomical number which has been expressed as “340 trillion trillion trillion.” It’s becoming clear to most that migrating to IPv6 is the logical and inevitable solution to the problem of limited IPv4 addresses, but some folks are still hesitant to take the leap into IPv6. But whyyyyy?!
So, what are some of the misconceptions out there about developing an IPv4 to IPv6 migration strategy?
1) My gear doesn’t support it!
We get it, you have gear setup and everything seems to be working fine. It’s expensive to buy new stuff and daunting to migrate your network to a whole new set of unknowns. We won’t go all “Moore’s Law” on you right now. Change is inevitable and we know IPv6 is not some fad, it’s the future and it’s already underway.
But get this – chances are your gear already supports it and you may even be using IPv6 without even knowing it. Keep in mind that “migration” at this stage isn’t clobbering your IPv4 network, but enabling the IPv6 network alongside your IPv4 network. The easy step here is just looking up the gear you have and seeing if it supports IPv6 – most vendors have released patches or have supported IPv6 for some time (IPv6 is not exactly new).
Update: As of 2017 this issue is certainly not the problem it once was. Operating Systems have added first-class support for IPv6, infrastructure components are being upgraded by Service Providers for both wired and wireless communications, and App Stores are even requiring support of IPv6-only networks.
2) My software/application is not affected.
Hardware and software upgrades are critical to IPv6 transition, as is re-thinking about how to layout a network. This is due to the fact that the IPv4 mind-set was one of “scarce resources” (we will run out of addresses). In an IPv6 world, you have nearly unlimited resources and can plan your network IP Address plan very differently. Of course, that also means that your “software stack” will require testing – enabling and confirming the correct behavior from the network -> OS -> application can be interesting, but given the increase in IPv6 users worldwide, you should know the bottlenecks and issues before they result in application downtime.
Update: Virtualization has been helping – but is still behind the curve a bit on IPv6 specific support. The challenge has been that all the new virtual network technologies/acronyms have muddied the waters. As orchestration/DevOps tools mature, we should expect to see support for IPv6 getting rolled in. For example – you can spin up VMs with various interfaces and IP addresses – but orchestration tools are still catching up to move away from the “copy and paste the IPv6 address” and go to more API-driven workflows.
3) My current IPv4 approach meshes perfectly with dual stack environments.
IPv4 and IPv6 are meant to coexist within a network, meaning that organizations will have to support both for some time in order to continue complete Internet operations. This technique of supporting both IP versions at the same time is known as dual-stacking. It was developed due to the limitations of the IP versions, particularly with each other. IPv4 and IPv6 are not compatible and don’t “speak the same language”. Thus support for both must be maintained in order to utilize them at the same time during the migration process. Moving too quickly or only supporting one or the other is almost guaranteed to lose some connectivity or communication until a total world-wide changeover is completed.
Update: This is still ongoing – I think user education has finally sunk in given IPv6 adoption and penetration by service providers. The next question is going to be “why am I managing two networks” – it’s only natural that as you deploy IPv6, you start to evaluate the role that IPv4 plays in your environment. Is managing two networks (dual-stack) on the same infrastructure a good use of technical resources? How does this affect your use of RFC 1918 space? Is it worth monitoring the same services across two networks? As IPv6 gets further deployed in the stack, these are going to be the next questions that come up. We still have some time since the orchestration tools that would simplify IPv6 are still maturing – they key is that shift in the conversation from “keep IPv4 as is” to “leverage IPv6 wherever possible”
4) IPv6 works the same as IPv4.
The migration to IPv6 is not a rocket ship ride to Mars. The concepts are the same and migration tools do exist. We also just happen to have some network migration tools that will save you from drowning in spreadsheets…
It’s no secret that the migration process will take significant time and effort. To begin the planning process for migrating from IPv4 to IPv6, organizations should conduct an inventory of IPv4 addresses on their network and how they are used, assess devices for IPv6 compatibility, and begin developing a plan dealing with IPv6 endpoints and individual device addresses. This is also only prudent planning for the future in general, since IPv6 is being adapted on a global scale, IPv4’s role will eventually shift, leaving “v4 only” organizations scrambling.
Update: Fortunately, this misconception has been going by the wayside due to extensive education efforts.
TL;DR It sits it fits
There’s plenty of elbow room for the Internet of Things once IPv6 takes root. Migration from IPv4 is not as hard as you think.
Questions? Concerns? You can contact us at 6connect to speak directly with an engineer. If you are looking for a turnkey solution for robust DNS management and automated network resource allocation, we’ve got your back.
Email: info@6connect.com or call +1 (650) 646-2206.