IPng doesn't just solve the Internet's addressing crunch; it also offers a suite of features designed to make net managers lives' easier. But at what cost?
In a moment of high drama this past summer, the Internet Engineering Task Force announced that it narrowly averted a looming network disaster. The crisis: a rapidly expanding Internet that would soon run out of addresses to allocate to new users. The solution: a revamped version of the 15-year-old Internet Protocol that included both a roomy addressing space
and assorted enhancements designed to make TCP/IP networks safer, more flexible, and easier to manage. The product of an initiative called IPng--for IP "next generation"--IP version 6, as the new protocol's called, is said by those overseeing its development to be a scheme that will fix known problems and provide a flexible and extensible platform for the future.
But now that everyone can breathe more easily, knowing that the Internet's no longer in imminent danger of grinding to a halt, some harder questions are beginning to surface. Specifically, in the effort to devise a new protocol before time ran out, did those involved in the IPng endeavor cut so many corners that the resulting protocol will be too difficult to implement or unfeasible over the long run?
Nobody doubts that the basic architecture underlying IPv6 both solves the imminent addressing crisis and provides most--if not all--of the promised benefits. The real question is--at what cost? Exactly what will it take to upgrade to the new protocol, and how will that be accomplished? Are there other, less-painful, ways to solve the problem? And does IPv6 do enough to avert problems a little further off on the horizon, such as the fact that the growth in routing tables is outpacing that in the memory technologies from which they're constructed?
Proponents of IPv6 say that the combination of an increased addressing size and the addition of features like built-in user authentication and encryption, autoconfiguration (the ability for IP hosts to configure themselves automatically) and future support for real-time traffic will be enough to spur deployment of the spec. Moreover, they say, the transition to IPv6 will be relatively painless. And as for the routing-table problem, IPv6 provides at least a step in the right direction, but the real problem is up to router vendors and routing-algorithm researchers to solve.
"IPv6 does a pretty amazing job of meeting the requirements. It's going to make a dramatic difference to people who run networks on a day-to-day basis, and I look forward to it a lot, " says Mike O'Dell, member of the Internet Engineering Steering Group and vice president for research and development at UUnet Technologies, a major Internet service provider. O'Dell is particularly enthusiastic about the autoconfiguration and security components of the new spec, and says he plans to implement the spec in his company's network as soon as is feasible.
"The fundamental architecture is flawed in ways that are not fixable, long term," counters Noel Chiappa, a respected member of the IETF and independent network architect who helped design some of the earliest routing protocols. Chiappa is particularly concerned about the new spec's inability to handle what he sees as an unavoidable routing crisis. He also has doubts about the feasibility of upgrading the Internet--or any TCP/IP nets--to support the protocol.
To understand how the IPv6 spec can continue to generate such controversy, it helps to take a close look at what it does--and doesn't--do, and how it was arrived at.
The most pressing spur for the development of a new protocol was the need for more TCP/IP addresses. Host addresses in a TCP/IP network are expected to be globally unique, meaning that no two hosts can have the same address, even if one is on a private network that isn't connected to the Internet. In theory, this shouldn't be difficult, given that the current IP address is 32 bits long, which means that about 4.29 billion hosts can be addressed. For reasons having to do with the particular type of hierarchical architecture chosen when TCP/IP was first deployed, it's becoming increasingly difficult to find unused addresses. The current version of IP, version 4, only allows for about 2 million addressable networks (IP version 5 is a little-used experimental protocol, which is why the new spec is referred to as IPv6.). The IETF has predicted that these addressses will be exhausted sometime between 2005 and 2011, plus or minus 50%.
To solve these problems, in late 1993 the IETF created an initiative called the IPng Area, which was charged with overseeing the development of the next-generation protocol. This past July, the group recommended that a variant of one of three proposed protcols should become IP version 6.
The spec is not yet finished, although the IPng group hopes to have completed standards-track specifications by this December. Assuming all goes as scheduled, the group predicts that products incorporating the spec will appear about a year later, by the end of 1996.
The major improvement IPv6 provides over IP is a larger address size. As noted, IPv4 defines a four-byte (32-bit) addressing space. The basic architecture agreed upon in July is based on a proposal called SIPP, for Simple Internet Protocol Plus, which calls for a fixed-length address of 16 bytes (see figure 1).
Originally, SIPP called for a shorter fixed-length address 8 bytes long, while other schemes under consideration called for variable-length addresses that could expand beyond 16 bytes. The IPng Area picked the 16-byte addresses because it represented the best compromise between those that wanted variable-length addresses and those demanding a shorter, fixed-length address, according to Scott Bradner, co-director of the IPng area.
While a compromise by definition leaves all sides unhappy, there's a bigger issue at stake here, namely, whether in its rush to come up with a proposal--any proposal--that would alleviate the addressing crunch, the IPng group didn't spend enough time doing its homework.
In particular, there was a heated debate over whether a fixed-length address could provide the kind of flexibility necessary for future routing algorithms, and if so, at what cost in terms of processing overhead.
Common Architecture for the Internet (Catnip) and the TCP/IP Over CLNP-addressed Networks (TUBA), were two schemes that were also considered--and ultimately rejected--by the IPng group. Both called for variable-length addresses. Both approaches were ostensibly rejected for reasons that had nothing to do with variable-length addressing--Catnip was deemed insufficiently developed, and Tuba unnecessarily complex. But proponents of the variable-length addressing proposal argue that their concerns were dismissed too readily.
The argument here is that in order to short-circuit the explosive--and unsustainable--growth in routing tables, new routing algorithms would be needed in the future, algorithms that would include what routing gurus refer to as "layers of abstraction", or "levels of aggregation", meaning the ability to treat an arbitrarily large group of subnetworks as a single network. Today's routing schemes use one layer of abstraction, in the sense that backbone routers need only keep track of every subnet address in the network, rather than storing every host address (see sidebar, "Rough Route Ahead"). A long, fixed-length addressing scheme like that of IPv6 can support additional layers (the precise number of such layers is still under definition), but the concern with any fixed-length scheme, no matter how long, is that ultimately, routing algorithms for a very large network might require more layers of abstraction than the addressing scheme can support. Therefore, for a next-generation protocol to be truly extensible, it would have to support variable-length addressing. "People should have been thinking a little farther ahead," says Tony Li, member of the IETF and technical lead at Cisco Systems, Inc. "Aggergation causes you to have a very low utilization of the address space, and (what) IPv6 defines is possibly not big enough." Li suggests that if the Internet continues to grow at its current rate, future routing algorithms will require so many layers of abstraction that IPv6 could become outdated as soon as 20 years from now--less than ten years after IPv4's projected expiration date.
Bradner's response to such arguments is that it's impossible to design protocols today for future routing algorithms that may or may not even be developed. "We're attempting to address the problems that we know about. We can't predict the future."
Furthermore, he says, proponents of the variable-length addressing scheme have failed to address what some say is a serious flaw with variable-length addressing, namely, processing complexity. "Fixed-length addresses are much faster to process," says Jim Bound, IPng technical leader and member of techincal staff at Digital Equipment Corp.
Not true, says Li. According to him, variable-length addresses add very little to processing overhead. One of the schemes presented to the IPng group was based upon Connectionless Network Protocol, the OSI equivalent to IP, which has variable-length addresses. Cisco's routers already handle CLNP with no trouble, according to Li.
The question of whether or not processing variable-length addresses contributes an unacceptable overhead remains unsolved, in no small part because of the lack of sufficient empirical data.
"The decision to choose SIPP over CLNP was made before there was any conclusive evidence," says David Piscitello, former Internet Engineering Steering Group member and one of the developers of TUBA. He says it's because of the intense time pressure to come up with a spec before the Internet ran out of addresses. "There was a fuse, and the fuse was burning. No one knew how long we had."
The sixty-four-thousand dollar question is whether the burning fuse that Piscitello refers to leads to a live bomb, or to a dud. That is, is IPv6 the only solution to the addressing crisis, or are there alternatives that network managers could explore? If IPv6 is the only way to solve the problem, it doesn't matter how difficult the protocol is to implement. Net managers will do it because they have no choice.
If not, however, the question becomes a more subtle cost-benefit analysis: how do these solutions compare to IPv in terms of the benefits they offer and the cost of implementation?
Herein lies the biggest area of uncertainty. Everyone agrees that within ten to fifteen years, the addressing crisis could be acute, and that could be a disaster.
But it's equally possible that other projects could solve the problem. Oneated approach would be to something called a "network address translation" box, or NAT box, that would solve the immediate addressing problem without requring network managers to implement new protocols.
NAT'S A FACT?
The idea behind the NAT box is to violate what has until now been one of the cardinal rules of TCP/IP: the tenet that each 32-bit address must be unique not just locally--within that host's particular TCP/IP subnet--but globally, within the entire Internet, even if that subnet isn't even connected to the Internet.
Hosts on one side of a NAT box would have local addresses that are never sent out over the Internet (see figure 2). On the other side of the Internet, the box would offer a set of globally unique addresses. The catch is that providing the mapping between the globally-unique and locally-unique addresses could be technically challenging, and there's some question as to whether a NAT box is technically feasible.
A similar type of product is definitely feasible, however--a device known as a circuit-level TCP gateway, which essentially relays TCP connections from the "outside" (global network) to the "inside" (the private network). Such a device also has the advantage that it can be used to provide enhanced security for private networks.
The IPng's group's response to such efforts is that while they might work, IPv6 will work. And at the same time, it will offer features like security, autoconfiguration, and support for real-time traffic that would be much harder to implement otherwise.
But is that really true? Many people have expressed concerns that the costs of implementing a brand-new protocol could outweigh the benefits like security, autoconfigration, and support for real-time traffic (see table). The question again is whether most, if not all, of IPv6's benefits could be implemented over IPv4. That's not going to happen, says Bound, because it's too much of a challenge technically. "IPv6 brings functionality to the market that can be engineered more easily. Can we retrofit IPv4? Yes. Can we do it as efficiently? No."
To see if this might be so, it helps to examine both the promised benefits and the costs.
SECURE FROM THE START
The security component, in particular, is of critical importance to networkmanagers, because it ensures that both user authentication and encryption are built in from the start."This will let companies use the Internet commercially," says Randall Atkinson, an IETF member who is working on security features for IPv6 and a research scientist at the Naval Research Laboratory (Washington, DC.) (Atkinson is not operating on behalf of his employer.) ((DESK: DO NOT CUT. HE WILL GO JAIL IF THIS IS NOT MADE EXPLICIT.))
User authentication ensures that a packet comes from where it claims to; this protects against a wide class of security breaches in which one host impersonates another. IPv6 ensures user authentication by means of an authentication header, which includes a 32-bit field containing a Security Association Identifier and a variable-length field containing authentication data. The purpose of the SAID is to enable two hosts to negotiate a variety of security parameters--including the type of encryption algorithm and the key size used by the algorithm--for each session.
Encryption essentially allows for the entire packet to travel in encrypted form, something that's necessary for the Internet--or IP networks in general--to be used for financial transactions and other highly sensitive applications. The IPv6 spec spells out both a default authentication algorithm and a default encryption algorithm, although users are free to add additional algorithms if they so desire.
A key point with IPv6 is that the encryption and authentication are decoupled. In other words, it's possible to provide authentication without encryption. This is important for foreign countries in which the use of encryption is not allowed, says Atkinson.
Although the security features are by and large worked out, one piece that's missing is a key-management scheme. The goal here is to decide how two hosts will agree on a set of encryption keys, says Steven Bellovin, head of the recently-formed IETF key management working group and a senior researcher at AT&T Bell Laboratories. Although the problem sounds simple, there are some subtleties that need to be worked out. For example, the encryption keys themselves must be encrypted, but there are several possible choices for encryption algorithms. Another issue is whether or not host machines should be allowed to pick their own keys with which to encrypt the encryption keys. While allowing hosts to choose their own keys could make implementation of a key-management scheme simpler, it could also weaken the overall security of the system, because it's extremely difficult for a computer to come up with the truly random numbers that are necessary to create uncrackable keys. A hacker who understood the pseudo-random number generation algorithm of a particular host machine might be able to guess the key, and hence break the security.
Bellovin hopes to have developed a secure key-management system as soon as possible, and certainly in time for the spec to be deployed in the first round of IPv6 products.
Built-in security is not available as part of IPv4, but some say it could be added. Bellovin's not sure whether or not that would be possible. "(security) may not be retrofittable," he says. Another possibility is to provide security at the application layer, rather than at the network layer--i.e., to encrypt files rather than packets. While this is certainly possible, it leaves the network open to subtler forms of cracking, such as traffic analysis and password theft.
O'Dell thinks that IPv6 is worth installing for its security benefits alone: "I'm going to implement IPv6. I don't have a choice. I have to protect my network."
AUTOCONFIGURATION'S A PLUS
Another key component of IPv6 is support for autoconfiguration. The design goal for autoconfiguration is for TCP/IP hosts to work "right out of the box". In other words, users should be able to unpack them, plug them into the network, and have the hosts configure themselves.
"Autoconfiguration is going to make a dramatic difference for people who run a network on a day-to-day basis," says Mike O'Dell.
It already has. Although most proponents of IPng don't mention this, an Internet spec for autoconfiguration has already been defined, and is in use in at least one non-negligible network--Microsoft's.
"The biggest barrier to deploying TCP/IP on our internal network was the lack of autoconfiguration," says J. Allard, member of the IPng directorate and program manager for internet technologies at Microsoft. To solve this problem, Allard helped develop a protocol called Dynamic Host Control Protocol, which allows the server to automatically (and invisibly) configure all attached hosts. It's already been used to configure over 10,000 hosts at Microsoft's internal network, and is shipping as part of Windows NT. "What's the incentive for us to move to IPv6? There isn't any," says Allard.
A final feature that's new with IPv6 is support for real-time traffic via a field in the address called the flow ID. The idea here is to provide a quickly-recognizable identifier that tells a router that a particular packet is part of a real-time data stream, says Robert Hinden, editor of the IPng working group and manager of Internet Engineering at Sunsoft.
One catch with the Flow ID is that no one knows exactly how it will work. Once the router determines that a particular packet should be handled in realtime, what should the router do? In other words, what are the procedures--or "semantics"--for handling real-time traffic?
"Until you have defined the semantics, a field is just baggage. Right now, the Flow ID is just baggage," says Li. Sure, no one knows how the Flow ID will ultimately be used, retorts Hinden. That's one of the risks it's necessary to take when devising new protocols, he says.
Given the mixed bag of benefits resulting from IPng, network managers may be wondering exactly how difficult it is to implement. Unfortunately, the jury's still out in that quarter as well.
GETTING THERE FROM HERE
All parties agree that the details of transitioning from IP to IPv6 are crucially iportant if the protocol is to be implemented before the Internet runs out of addresses. Where they don't agree is on how easy spelling out those details will be. "In my mind, transition is one of the biggest areas that needs to be worked out,"says Ross Callon, co-chair of the IPng working group.
The problem is that IPv6 isn't backwards compatible with IP, so in the long run, every network component must be upgraded to IPv6. "To really work, (IPv6) requires that you replace all your end hosts. I'm sorry, that's just not going to happen," says Chiappa.
There are three network components that need upgrading: hosts, routers, and domain name servers (which resolve IP addresses into user-friendly format).
Callon believes that a dual-stach scheme that relies upon strictly managing the order of the transition might be simplest. The idea is for each network manager to first upgrade the routers, then the DNS's, and lastly the hosts, with dual IP stacks that include both IP and IPv6. Such an approach would ensure that as each component is upgraded, it can still communicate with all other components in the network. (Upgrading in reverse order, even with dual stacks, wouldn't have this result, because an IPv6 host would end up generating packets that would be unreadable by non-upgraded routers and DNS's.)
There are two major problems with this approach. First and foremost, it requires all vendors to implement dual stacks on their products, a requirement the IETF is reluctant to make and a step that vendors may not take. "I don't think you can tell vendors what to do with their products," says Jim Bound, IPng technical leader and member of techincal staff at Digital Equipment Corp.
This is especially true when it comes to hosts. Adding an additional protocol stack to a multiprotocol router is no big deal; it's something router vendors do routinely. And modifying domain name servers to recognize the new addresses is unlikely to present much of a problem, either.
The problem arises when vendors of IP hosts either can't or won't provide dual-stack upgrades to their machines, which might occur if, for example, the vendor is no longer supporting a particular machine, or if a low-end host such as a PC or printer doesn't have the processing power and memory necessary to run dual stacks.
The second major concern is that the dual-stack scheme will only last as long as there are IPv4 addresses available for dual-stack machines to use. After all, if it were possible to support IPv4 addressing indefinitely, there would be no need for IPv6 even to exist. Once the IPv4 addresses run out, all hosts would have to become IPv6-only machines.
In other words, the dual-stack approach only delays the moment of impact for the final transition. And nobody's really sure what will happen then.
Some say that it won't be an issue, because by that time most of the Internet will have migrated over to IPv. Based on current statistics, the Internet will double in size within two and a half years, says O'Dell. Assuming every new host implements IPv6, after two years the IPv4 machines would be in the minority. Managers of those networks would either have to upgrade all their existing machines or find some way to co-exist.
Some coexistance mechanisms are already under development within the IPng working group. The catch is that they're either non-trivial to implement, inefficient, or both.
For example, one solution would be to define an encapsulation protocol that would enable IPv4 machines to "tunnel" through the network. This would allow such hosts to communicate with each other, but not with hosts that support just IPv6.
Another solution would be to provide gateways for address translation between IPv4 and IPv6 networks, a solution that Piscitello calls "truly ugly".
For these reasons, Piscitello says, "Deploying IPv6 is going to be an incredibly painful process, and it may not even succeed."