TECHNOLOGY FOR CHANGE

Three Reasons You Don't Need to Worry About IPv4 Address Exhaustion (and Three Reasons You Do)

John Jainschigg | Date: 02-25-11 | Comments

IPv4 addresses are close to being exhausted. If your company is like most, there is big concern about how this will impact your organization. Do you need to move everything over to IPv6 instantly, or do you have other options? Here are some thoughts on what you need to worry about and, perhaps more important, what you don't.

In February of this year, the Internet Assigned Numbers Authority (IANA) handed out the last two pre-transition blocks of IPv4 internet addresses to ARINC, the addressing authority for the Asia/Pacific region. Sometime in early August, the four regional authorities (ARINC, ARIN, RIPE and LACNIC) will begin distributing their last remaining blocks of IPv4 addresses (those not reserved for transition) to customers. At that point, the Internet will enter a transition phase, the best-case endpoint of which is generally assumed to be IPv6 ubiquity, though some experts see steady-states emerging where IPv4 regimes remain stubbornly in place for many years.

How disruptive will this transition be? That's a huge topic of debate. Predictions by credible people range from "it won't be a big deal" to "this may spell the end of the open Internet as we know it"; from "many people and organizations will hardly feel more than a speed-bump" to "huge and largely unforeseen expenditures are inevitable"; and from "and, by the way, IPv6 is going to work great" to "IPv6 is going to kill network performance for many classes of application until an entire new generation of silicon comes online."

Who to believe?

As you set your own sober plans for IPv6 transition with carriers and hardware vendors, here are some things to think about.

Don't Worry: This is just like Y2K. A lot of hype, but it'll turn out to be nothing much in the end.

Worry: On the other hand, all Y2K demanded was updating some legacy code or retiring some long-outdated boxes. Here, pretty much everyone is going to need to do something�probably quite a few things�to get ready. Code munging will be required to master new APIs, do ports, and transition IP-aware applications and databases to IPv6 (or in some cases, to IPv4 utility-extension schemes). One thing we can be thankful for is that most of that code is written in something a little more nimble than COBOL. Beyond this, most enterprises are planning migration or reconfiguration of network hardware to dual-stack (IPv4/IPv6) support, combined with creative uses of NAT and firewall reconfiguration (hopefully with tools like Firewall Builder) to get over the hump. That's not necessarily expensive, but it could be complex and time-consuming. Further, the most optimistic estimates for IPv6 near-ubiquity take us out at least five years, and the potential for incompatibilities, temporary loss of access to resources, "white screens of death" and other stressors will likely be elevated until the very last IPv4 devices are retired.

Don't Worry: All our PCs are transitioned to Windows 7 and are, therefore, IPv6-ready. Our major network devices are ready, too. When the time comes, we're going to flip some switches and go all-IPv6, no problem.

Worry: Oops ... you need to stop and think about technology populism and convergence. Most WiFi-enabled mobile devices (Android, iOS, etc.) can use IPv6 over WiFi only if IPv4 is also available to encapsulate it for tunneling. Networked printers and scanners will need at least a firmware upgrade, as will most VoIP equipment. Most enterprises (and consumers) won't be able to leapfrog the dual-stack/tunneling/NAT epoch.

Don't Worry: Once we've transitioned, router performance on IPv6-only networks will improve by a factor of 18:1, and we'll have better point-to-point options to route around congestion efficiently. Internet performance can only improve.

Worry: In theory, a pure IPv6 network should perform better (or at least no worse) than IPv4. In reality, people are finding that IPv6 performance is slow by comparison with IPv4, probably for several systemic reasons. Major culprits seem to be: transition mechanics, such as IPv6-over-IPv4 tunneling, not yet robustly and centrally implemented on carrier nets; failure of content-distribution network mechanics (i.e., close-to-consumer caching) to support IPv6 as yet; and lack of a long history of network performance tuning around IPv6 requirements.