IP address depletion hastens IPv6 adoption

The brain has a funny way of increasing the relative importance of any particular issue with temporal proximity. In other words, it is well known that we tend to do things at the last minute (no, there's nothing wrong with you -- we're all like that!). It's not so much a brain disorder as a tendency to see more value in things that are closer to us.

Assuming that this has some evolutionary benefit that somehow aided our distant ancestors, we can understand why the likes of Bill Gates can observe:

We consistently overestimate the amount of change in the next two years, and underestimate the amount of change in the next 10 years.

This much also appears to be true in the case of version 6 of the Internet Protocol (IPv6).

Recent years have seen plenty of sturm und drang surrounding the impending collapse of the IPv4-based Internet. Or, at least, the vague possibility was good copy and made for catchy headlines. No one really seemed to think that there was a wall to hit, and Network Address Translation (NAT) and Classless Inter-Domain Routing (CIDR) offered a certain amount of relief from the stress of dealing with the impending depletion of IPv4 addresses.

The hysteria has some germ of relevance in it, however. It really is true that the IPv4 address space is running out -- quickly, slowly or somewhere in between. But "how soon?" seems to be what is keeping everyone up nights.

ARIN changes tune

In its annual update at the summer 2007 Internet2 Joint Techs meeting in Minnesota, the American Registry for Internet Numbers (ARIN) offered a pretty clear view to the end. As of July 2007, there were 49 IPv4 Class A (otherwise known by CIDR reference as a "slash eight," or /8, corresponding to the first set of numbers in a "dotted quad" numerical IP address) domains left available for allocation (IANA reserved). Further, they changed their official position on IPv6, now recommending that organisations actively move toward IPv6, instead of being neutral on the topic as they have been to this point.

Is that bad?

Well, ARIN should certainly be taken seriously. But let's look at the same facts that they do. Originally, of course, there were 256 Class A domains, and they have been slowly allocated over time to various service providers and network operators. They, in turn, usually partition the Class As into smaller Class B and Class C domains (or something comparable in CIDR terms) before distributing them for use. That said, ARIN reported that in 2006 there were more than 10 Class A domains allocated by RIRs (regional Internet registries) to LIRs (local Internet registries) and ISPs (Internet service providers) worldwide. Ten per year is a slightly higher rate than in 2005.

With a little bit of math, and assuming no growth in Class A allocations, it is pretty clear that IPv4 will run out of space within five years. That assumes no significant increase in the allocation rate (which seems unlikely). Allocations to RIRs are usually based on 12-18 month projections of need. So there may be another year of buffer time before anyone feels the effects of address space depletion. And depletion may speed up as organisations try to grab extra resources in view of that depletion.

Either way, the happy days of ignoring IPv6 are coming to a close sometime soon.

Should you panic?

It depends on who you are and how far along your organisation is in transitioning to IPv6, but the answer is probably "no." The U.S. government mandated that all of its organisations be prepared to transition in June 2008. DREN, the research network for the Department of Defense (DoD), was tasked to pilot IPv6 in 2003 and signed off a transition plan for the DoD in March 2005. Of course, this is a research network, not an operational military network, but it underscores the concrete progress. The vendors and the service providers have also been busily preparing the infrastructure for the move. Applications and interfaces have been transitioning and maturing. The transition has been happening whether you've noticed or not.

For a sense of how far along we are, consider the state of the familiar aspects of everyday IT. Current versions of core router operating systems like Juniper's JunOS and Cisco's IOS are fully IPv6 ready and serve at line rate. Windows XP has IPv6 available, and it can be turned on easily; Vista has IPv6 turned on by default (and has been approved by the DoD); Mac OSX has IPv6 enabled by default, and the various Linux implementations have it available and usually enabled (for example, Redhat/Fedora enables by default but does not install ip6tables).

Many of the basic networking applications on common operating systems are also IPv6 ready -- FTP, Telnet, traceroute, ping, netstat and the like. Applications like Apache v2.0 have built-in IPv6 support. Microsoft is strongly committed to IPv6 -- so MS Outlook, MS-SQL and IE v7 are already IPv6 capable, with Exchange 2007 and most other MS applications to follow soon. Also, host firewall support is variable. For more detailed information on hardware and software that supports IPv6, see the IPv6.org site.

Switching from IPv4 to IPv6

If you haven't yet started to delve into the subtleties of the IPv4-to-IPv6 transition, there is plenty of information available (maybe too much! -- see the reference list at the end). Arguably, the biggest challenge is for network planners, operators and IT administrators. For end users, it should all be transparent, particularly since the support of mixed IPv4/IPv6 networks has been assumed and accommodated.

For the network operator, there is a veritable maze of concerns, all of which are generic to any aspect of networking IT. At the top of the list, of course, is security -- transitioning to a replacement infrastructure is bound to introduce various new idiosyncrasies that create opportunities for hackers -- yet another vector for the delivery of security attacks. On the whole, though, DREN has concluded that IPv6 is functionally no less secure than IPv4. It will simply take time to develop new practices that are at least as secure as the current IPv4-centric practices.

Tunnels and dual stacks

That said, there will certainly be a rise in complexity as IPv4 and IPv6 networks merge, collide and coalesce. The foreseeable future offers a combination of approaches to deal with the inevitable presence of both new and old IP versions. Initially, tunnels were expected to be the predominant transitional mechanism, connecting pools of IPv4 through oceans of IPv6, and vice versa. Certainly, there are many instances of IPv4-over-IPv6 and IPv6-over-IPv4 tunnelling to be found. However, network vendors have responded very quickly to the demand for dual stack interfaces. Now dual IPv4/IPv6 interfaces are broadly implemented with relatively little complication.

Relatively, of course, since the fact remains that managing dual stacks and tunnels makes more work for administrators and operators. And tunnels are one of the commonly referenced security risks that need to be carefully managed. They can create unintended backdoors through firewalls that allow all manner of threat to enter the enterprise network. Teredo, the IPv6 tunnelling capability provided with Vista, has been specifically identified as one such issue. However, as has been painstakingly pointed out by Sean Siler, Microsoft's IPv6 Program Manager, Teredo should not be used in the enterprise environment and is intended only for residential use.

Aside from the security issues, there are the usual management problems, multiplied by two (or more). With two possible ways to interface the network, and thus two (possibly unique) routes between any pair of dual stacked hosts, the problems of configuring, tracking and managing overlaid IPv4 and IPv6 networks will emerge. At a minimum, it incrementally increases the load on network managers, but it also means that management software and tools must adapt both to handling IPv6 alongside IPv4 and to presenting a coherent view of the combined network to the manager. This was hard to do in one flavour of IP and will get harder with two, possibly conflicting, views to handle.

And what about the effect on support staff? Not only will it be a question of whether the network is responsible for an application problem but also which IP is responsible.

Hard work ahead

As to where the work lies ahead, consider DREN's experience, reflected in how they grade the challenges of IPv6 deployment:

• Relatively easy
  • Implementing dual stacks in LAN and WAN
  • Enablling IPv6 in operating systems
  • Setting up essential IPv6 services, e.g. DNS, SMTP, NTP
  • Setting up IPv6 in certain key services such as HTTP
• Moderately hard
  • Composing an effective address/domain deployment
  • Operating a dual stack network
  • Multicasting
• Very difficult
  • Security infrastructure such as firewalls, proxies, VPNs, etc.
  • DHCP
  • Dealling with incomplete and broken implementations
  • Promoting adaptation at the social layer
  • Soliciting vendor support

Have you started to think about IPv6 in your network? Do you have a plan? Perhaps the approach has been over-hyped, long and drawn out; but now would seem to be a good time to look seriously at the road ahead. IPv6 may be closer than you think.

About the author: Chief Scientist for Apparent Networks, Loki Jorgenson, Ph.D., has been active for more than 18 years in computation, physics and mathematics, scientific visualisation and simulation. Jorgenson has headed research in numerous academic projects, from high-performance computing to digital publishing, working closely with private-sector partners and government.