In February 2011, the clock finally ran out on IPv4, the trusty Internet Protocol that has been used to connect networked computers for the last 30 years. The Internet Assigned Numbers Authority (IANA), which manages the master pool of IP addresses, assigned its last five blocks of IPv4 space to the world’s five Regional Internet Registries. From that moment, another clock started ticking the countdown to the moment — in the not too distant future — when every one of IPv4’s 4.3 billion possible addresses is accounted for, and enterprises will only be able to obtain IPv6 addresses when they need to bring a new network online.
To quickly recap: IPv6 hugely increases the number of IP addresses available to Internet users, from the 4.3 billion under IPv4 to the 340 trillion trillion trillion addresses allowable under IPv6. The enlarged pool means that IP addresses should be plentiful for decades to come.
Some media reports humorously referred to the depletion of IANA’s IPv4 pool recently as the “IPocalypse,” but the reality was, of course, less dramatic. The transition from an IPv4-only Internet to a mixed v4/v6 network has been underway for over a decade, albeit slowly. It will accelerate as it continues over the next few years, but it could be decades before the Internet fully migrates to an IPv6-only environment, if it ever happens at all. But it is imperative today for every connected organization to study how the move to IPv6 will impact their services. The transition could pose operational problems and security risks for years to come.
One key thing to understand about IPv6 is that it is not backwards compatible with IPv4. In many cases you’ll most likely have to manage essentially two networks side-by-side for the foreseeable future. Even without external threats, the increased complexity that comes with an extra protocol poses a security and stability risk. To take the simplest example, IPv6’s long hexadecimal addresses make automated address management systems look more attractive, as manual data-entry errors are much more likely to occur due to human error.
In many enterprises, the transition to an architecture that supports both IPv4 and IPv6 simultaneously (often called “dual-stack” in the industry) will be preceded by an environment containing small “islands” of IPv6 that connect to the IPv4 network using methods of “tunneling” one protocol over the other. This presents its own security challenges, requiring deep packet inspection with appropriate authentication and access control mechanisms, to ensure that attack traffic does not successfully circumnavigate security filters by piggybacking on a tunnel. In any event, tunneling is a less-than-optimal solution to the transition problem, much better handled by a dual-stack environment, and is likely to only be used as a temporary stopgap at the start of a longer upgrade strategy.
Managing a dual-stack network necessitates that every piece of infrastructure in the data path, including security devices, understands how to speak IPv6. Unfortunately, there’s been something of a “chicken and egg” problem to date with some vendors waiting to see customer demand before supporting IPv6 to the same extent as IPv4, while some buyers wait for their suppliers to support the protocol before rolling out their own adoption plans. The depletion of available IPv4 will likely accelerate manufacturer support, but, for a period, enterprises should be aware that they may sometimes find IPv6 functionality and performance below their usual expectations for IPv4. Because there are no industry standards for what constitutes “IPv6 support,” security-conscious buyers need to draft their own requirements, based on what they currently expect from IPv4 equipment.
This is perhaps more of a problem in applications than in network devices, which generally have better IPv6 support. Legacy applications hard-coded to expect IP addresses in a 32-bit format may prove to be a more challenging problem to upgrade and/or replace. And while IPv6 was designed with security in mind, there are also risks from insecure implementations. Developers new to the technology stand a greater risk of incorporating problem IPv6 stacks or other vulnerable IPv6 code in their products. This is just as true for code developed in-house. As we often see when a new protocol is released and implemented, a period of testing and strengthening of the security is required.
Attackers may use this window of opportunity to increase their malicious use of IPv6 addresses. For example, it is already anticipated that spammers could take advantage of the large address blocks available to quickly jump between addresses in order to confound IP-based blocklists. IPv6-aware attack tools have been available for several years, but it should be expected that zero-day vulnerability hunters will focus more on attempting to find weaknesses in IPv6 implementations as the technology becomes more broadly deployed.
While these are just a handful of examples of challenges that the transition to IPv6 may create, many organizations will find that they encounter problems specific to their networks that need to be addressed. A solid transition strategy will plan for a gradual transition and the likelihood that IPv4 and IPv6 networks will have to be managed concurrently for the foreseeable future. Organizations need to audit their networks for possible compatibility pain points, ensure the transition plan creates the absolute minimum of disruption, and focus on increasing institutional expertise with IPv6 technology through training, experimentation and hiring.
Ensuring your organization can survive the transition through a mixed v4/v6 environment with minimal business impact should be a C-level or board-level concern, much like the Y2K problem was over a decade ago. Compliance will need to be aligned with business objectives, and these directives need to flow from the top. Just because the Internet as a whole will not experience an IPocalypse, that does not mean you can afford to be complacent about the transition to IPv6. It’s coming, and it’s coming quickly.
Related Reading: Is IPv6 Part of Your Risk Management Framework?
