Maxed out
The inevitable IP address shortage.
Maury Wright, Executive Editor

Think about that hypothetical scenario. The PC has served us incredibly well, but surely it's not the best or most elegant architecture we're capable of devising. What's your vote—retrofit or replace?

Now, what if we ask the same question about the Internet? The Internet is actually older than the PC. People have subjected the Internet to far more retrofits and facelifts than the PC has endured. Many argue that the Net needs a major overhaul in order to support the future demands we're going to place on it.

Like the PC, the Internet isn't facing an immediate crisis. Despite some naysayers' claims, the Net won't just break down and stop working. At least not any day soon. Undoubtedly, the average user doesn't even realize that the Internet faces significant obstacles. But obstacles there are.

I need my space

Topping the list, a sort of housing shortage. Limited to a 32-bit address space, the Internet has a finite number of possible IP addresses. As the online population worldwide catches up with Europe and North America, we will run short. And that's despite stopgap measures such as NAT (Network Address Translation). Worse, new applications, such as mobile Net access and home networking, could vastly increase the world's appetite for addresses. The Internet also faces problems in security, routing, and installation complexity. Together, these problems limit the Internet's potential.

As the new millennium dawns, the Internet's brain trust must decide how to upgrade the Net's foundation: the venerable TCP/IP infrastructure. The powers-that-be can continue a 20-year process of retrofits, some of which have been extremely effective, and some of which have merely mitigated problems in the short term. Or, they can make a more revolutionary change and replace the current IPv4 (Internet Protocol Version 4) with IPv6, which has been in development for much of the past decade.

IPv6 offers a few significant advantages that simply cannot be spliced onto IPv4. Most significantly, IPv6 uses a 128-bit address space. Other examples include an end-to-end security feature called IPSec (IP Security) and automatic or plug-and-play installation, using node discovery and dynamic address assignment.

Other IPv6 features have already been tacked onto IPv4, with varying degrees of success. For example, take IP Multicast, which allows a single server to broadcast an audio or video stream to many different nodes. Multicast is an absolute requirement if the Internet is to support a growing base of streaming content. Though IP Multicast originated as part of the IPv6 project, close to half of the existing IPv4-based Internet can support it today.

Then there's QoS (Quality of Service), the ability to give time-sensitive data, like voice or video, an express ride to its destination. IPv6's creators included QoS from the start. A packet flow label in the address header ensures reliable delivery of streaming data, enabling applications such as VoIP (voice over IP). IPv4 retrofits provide QoS, but force routers and other equipment to open and examine the actual data payload of packets. Moreover, companies making routers and switches support different QoS techniques (see sidebar, "IPv6 resources").

What's the problem?

Sounds like a no-brainer; let's upgrade to IPv6. Unfortunately, logistic and technical roadblocks obstruct the path. For starters, the Internet is a huge entity. No one owns it or even has the power to control its direction. The IETF (Internet Engineering Task Force) shepherds the development of new technologies, but can't dictate how they're deployed by the thousands of organizations that control little pieces of the Internet.

A complete upgrade to IPv6 would be what engineers wryly refer to as "non-trivial." Every router, every PC, and every server owned by ISPs, corporations, universities, governments, and individuals would have to be replaced or upgraded. Typically, upgrades happen gradually, the way QoS and Multicast are seeping in. Individuals and businesses upgrade or replace network equipment and hosts (terms used for clients and servers in Internet parlance) one at a time. But IPv6 isn't backward compatible with IPv4, and no smooth transition path exists.

The barriers to an easy transition have some industry insiders wondering if IPv6 will ever be adopted, while others insist that the question is when and not if. The two sides disagree on whether IPv6 brings enough value to warrant the expense and time the transition would entail. Many believe IPv6 simply isn't revolutionary enough to justify the massive upheaval.

Address depletion

While IPv6 offers more than a larger address space, that feature appears to be the one most likely to force a change. IPv4 can theoretically address more than 4 billion nodes. IPv6 supports a number of addresses greater than 3 followed by 38 zeroes. Experts say every person on earth could have a personal IPv6 network, which could in turn have a number of unique addresses represented by 20 digits.

So are we really in danger? Ask Noel Chiappa, who invented the multiprotocol router while at MIT and has worked on numerous IETF initiatives. "We've already run out of addresses," he answers. "Just look at how many people are deploying NAT." Chiappa, currently an independent network-architecture researcher, happens to believe IPv6 doesn't offer sufficient benefits to merit a change. He prefers a more radical approach to a next-generation network.

But the point in Chiappa's comment is that the industry has already taken measures to prevent, or at least delay considerably, the day that the address well runs dry. In the early 1990's, the Internet transitioned to a more granular routing architecture called CIDR (Classless Inter-Domain Routing—often pronounced "cider"). Prior to CIDR, all subnets were assigned based on 1- to 3-byte boundaries, which meant that small and large organizations often received far more addresses than they required (see Connected: An Internet Encyclopedia, at www.freesoft.org/CIE/index.htm).

To further stretch the address space, the computer world has adopted NAT, in which a single host (with a single public IP address) conceals a host of other hosts. The hosts behind the gateway use private IP addresses; it doesn't matter if they duplicate addresses that exist elsewhere. NAT finds use in widely ranging scenarios, from connecting the private networks of huge corporations to allowing multiple PCs to share a home Internet connection (see "Inside the Digital Den"). In its purest form, NAT transparently alters address headers as packets pass through the gateway.

Panacea or poison?

But NAT is far from a panacea. In fact, it's almost pure evil in the eyes of some Internet purists. NAT violates one of the Net's basic tenets—that the source and destination hosts control communications between themselves. With NAT, all data passes through an intermediary, and NAT critics see that single point of failure as potential trouble. NAT can also cause huge logistical problems. For example, if you try to merge two private networks that previously existed behind NAT gateways, you may have to contend with duplicate addresses.

GLOBAL IMPACT: Fred Baker heads the Internet Engineering Task Force.

Moreover, NAT can't head off escalating address requirements arising from the move to broadband connections. With dial-up modems, ISPs only need IP addresses for a fraction of their subscriber base, because they dynamically assign an address when a subscriber dials in. With an always-on broadband connection, such as a DSL (Digital Subscriber Line) or cable modem, each subscriber needs at least one unique address, potentially more. If home networking and automation take off, each subscriber may need a block of addresses (see sidebar, "The connected home").

Finally, new applications can eat up globs of address space. For example, IP Multicast needs a unique public address for every audio/video stream. The Multicast standard reserves a total of 268,435,200 IP addresses. Who knows what application will emerge next month, or next year, to devour even more?

Where to go

Most Internet experts agree that NAT is, at best, an interim solution to a future address shortage. But even the staunch proponents of IPv6 can't reach a consensus on how to proceed

The next big retrofit to IPv4 could be RSIP (Realm Specific IP—typically pronounced "are-sip"). According to your perspective, RSIP could be the start of a transition to IPv6, or a way to delay a transition while a more radical alternative is developed.

RSIP solves many of NAT's problems (with, of course, a few adverse side effects), but does no more than NAT to handle address depletion. Whereas NAT is transparent to the host, RSIP requires that each host participate in the process by which many hosts share one public IP address. In doing so, RSIP restores the ability to make end-to-end connections, thereby enabling applications such as IPSec and real-time video delivery.

In an RSIP scenario, the host makes a request to the RSIP gateway and retrieves instructions on how to address and format its outgoing packets. Still in development, RSIP could be deployed over the course of the next year. RSIP only works when the host behind the RSIP gateway instigates a session, but some say it can be extended to allow an external host to initiate a session.

Mike Borella, senior architect at 3Com and one of the leaders in the IETF RSIP development effort, believes the technology can lead the transition to IPv6. Most transition strategies include a mixture of three concepts:

• Dual stacks, where hosts or routers have both IPv6 and IPv4 protocol stacks and can work on either type of packet.

• Translation, which works like a NAT gateway, except that the gateway translates an IPv6 address to an IPv4 address.

• Tunneling, in which IPv6 packets are encapsulated within IPv4 packets, so that IPv4 networks can connect IPv6 clouds.

Unfortunately, upgrading routers to support IPv6 isn't so straightforward. Many existing routers use hardware-based schemes to speed packet processing. These will have to be replaced—a process many in the IETF expect could take more than a decade.

Of the ways to connect IPv6 clouds to the IPv4 infrastructure, Borella thinks the RSIP concept offers the best scenario. A dual-stack RSIP gateway could support end-to-end connections for hosts in the IPv6 cloud, whether the remote host speaks IPv4 or IPv6. The scenario would still require the RSIP gateway to perform tunneling in order to link two IPv6 hosts across what for some time will remain an IPv4 Internet. And the RSIP gateway could integrate NAT functions as well, so that RSIP can be deployed across connected hosts one at a time.

A tough sell

Others, such as Chiappa, see NAT, RSIP, and other retrofits as ways to delay the transition to IPv6. Chiappa points out that ISPs and corporate MIS managers—whose support would speed a brick-by-brick transition to IPv6—have no incentive to make the change. "If 5 or 10% of the managers upgrade to IPv6," he asks, "would they be better off?" And he's probably right in assuming the answer would be "No." You couldn't run IPv6-enabled applications in such a situation, except in cases where you knew for sure that both ends of a connection had been upgraded.

Even Chiappa concedes, however, that a 32-bit address space isn't large enough in the long term. Considering that IPv6 took more than five years to develop, most industry luminaries don't believe there's a viable alternative to IPv6.

3Com's Borella believes movement toward IPv6 will come suddenly, he just doesn't know when. Perhaps, he suggests, an application like Internet services for cell phones will explode overnight in a region like Asia, jumpstarting the process.

Advocates of IPv6 are also—finally—making an effort to promote the technology. In mid 1999, industry leaders formed the IPv6 Forum to educate everyone from MIS managers to end users. Vint Cerf, senior vice president for Internet architecture and technology at MCI WorldCom and a pioneer of the Internet, serves as honorary chairman of the group.

"IPv6 offers an opportunity to re-visit design of the basics of Internet protocol," Cerf says. "To vastly expand the address base, to allow for more flexible address assignment policies, multicasting design, and security features to become basic components of the evolving Internet. IPv6 also offers features that facilitate the deployment of new qualities of service, which are needed to serve an expanding array of applications...."

From a more pragmatic perspective, Jim Bound, senior member of the technical staff at Compaq and co-chair of the IPv6 Deployment Group claims, "IPv6 is the only solution to maintain the principles of end-to-end networking as we approach the next millennium." CV