IPv6: More
Filling, Less Taste
Fred Goldstein, December 2005
...The adoption of Classless Interdomain Routing (CIDR) greatly expanded the number of addressses usable with 32-bit IPv4; Network Address Translation (NAT), in which a single IP address is shared among multiple computers, also reduced the need for addresses...
...doing so exposes these values to the outside world, giving crackers a clue about what type of equipment they're going after, for one thing. It's also a huge waste of space...
...they lacked the taint of the disdained OSI. Paul's and Steve's proposals were combined into one new one, and that is what became IPv6...
... IPv6 is an expensive fix. It's a lot of work and a lot of cost, for not a whole lot of gain...
December, 2005 marked the tenth anniversary of the publication of RFC1883, Internet Protocol, Version 6 Specification, by the Internet Engineering Task Force (IETF). The "Next Generation" of IP was the product of several years' study and debate, and when it was finally published, proponents expected it to become widespread within a few years. A decade later, they still do, and its advocates are promoting it harder than ever. But a funny thing happened on the way to the new network. The market spoke. IPv6 flopped. So while it still has its backers, they seem increasingly desperate, rather than confident.
This is what happens when politics trumps reality in the creation of proactive standards. Widespread adoption of IPv6 would be costly, yet offer tantalizingly few benefits. It's the extra heavy version of IP, not what the doctor ordered to help the Internet move forward.
What is IPv6 all about anyway?
The original Internet Protocol that was developed in the early 1970s and which caught on in the 1980s is formally referred to as IP Version 4. It uses a 32-bit address space, which seemed absolutely huge at a time when the ARPAnet, the Pentagon's research network for which it was developed, had a few dozen computers on it. A 32-bit number can have over four billion possible values, though IPv4's original method of address assignment, based on "classes" of address, was very inefficient. With the rise of personal computers and then the public Internet, suddenly four billion isn't such a big number. So IPv6 uses a 128-bit address space, which is large enough to have no foreseeable risk of running out. IPv6 also makes a few other changes to the IP header. It adds a flow identifier, and includes certain security and authentication features.
Compared to IPv4, the newer protocol has some advantages, but it adds a lot of overhead. With 32 bytes of address (source and destination) per packet, vs. 8 in IPv4, applications that require short packets, such as voice, are especially disadvantaged. Is that much overhead really necessary?
The primary impetus of the IPNG project, which produced IPv6, was the shortage of address space, which was especially serious in the early 1990s, when classful addressing was still the norm. The adoption of Classless Interdomain Routing (CIDR) greatly expanded the number of addressses usable with 32-bit IPv4; Network Address Translation (NAT), in which a single IP address is shared among multiple computers, also reduced the need for addresses. (To be sure, some mavens consider NAT to be an ugly hack, but for most desktop computers, it's actually a good security tool.)
What about its other claimed advantages?
IPv6 is said to have other benefits. For instance, it is supposed to support Quality of Service (QoS) better than IPv4. That doesn't sound hard: QoS is not something that IP was designed for in the first place; it is usually achieved below IP, for instance using MPLS or ATM. IPv6, like IPv4, is connectionless: Each packet is typically handled atomically, with the router having no memory of previous packets between the same source and destination. A connection would, however, have a connection identifier to which the network could allocate resources. IPv6 has a flow identifier, which is a sort of like a connection identifier, but for people who are congenitally afraid of connection-oriented networks. But there is no definition of how to use it. And no practical way, in general, to do so, either, since a sequence of IP packets don't have to follow the same path, so there's nothing to keep track of the assignment of the flows.
MPLS uses flow IDs too, but it's really a connection-oriented protocol. If you want QoS, there are ways to go about it, but IPv6 doesn't do it any better, in practice, than IPv4. RFC1883 and its successor RFC2460 admit, "This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer." So the flow ID in IPv6 is basically a waste of 24 more bits.
What about security? A conformant IPv6 implementation includes features that are now available for use with IPv4, via the IPSec protocol. IPsec wasn't complete when IPv6 was first published, but if you need it, you can have it now, and you don't need IPv6 to use it.
And what about all of those address bits? As it turns out, they're not very smartly used at all. Half of the 128-bit address space is "interface ID", typically built upon the 48-bit MAC address of the Ethernet or other LAN interface. This is an awful lot of address space for something that is assigned within a LAN. It seemed like a good idea at the time -- since MAC addresses are assigned to equipment manufacturers and are unique, IPv6 addresses can be assigned automatically just by sticking the MAC address after the site prefix. Look, ma, no DHCP! But doing so exposes these values to the outside world, giving crackers a clue about what type of equipment they're going after, for one thing. It's also a huge waste of space, meaning a huge waste of network resources -- each address bit is, of course, transmitted in every packet. MAC addresses belong in a lower layer, not carried gratuitously across the Internet.
IPv4, to be sure, has a problem with its addressing space: Each "network" on the worldwide Internet has its own range of addresses, and backbone routers have to keep track of all of them. That's over a hundred thousand networks, nowadays. But there's only so much capacity for new networks in the 32-bit address space, so customers are encouraged to use their ISPs' address space instead of getting their own. With IPv6, it is theoretically possible to aggregate groups of addresses, to have smaller blocks inside larger ones, but that's doable in IPv4 too, if you really want to. It just doesn't happen very often. IPv6, with a bigger address space to begin with, allows the backbone to have more disjointed address blocks to keep track of. That increases cost and degrades performance.
A more sensible approach would be to insist that addresses be strictly topological, with the numeric IP address actually representing where the addressed device is, in terms of its connection to the rest of the network. That would require addresses to change when phsyical connections changed. But then isn't that what the Domain Name System is for? Too many companies still use IP address as names. IPv6 doesn't force users to stop doing that.
How did this become the standard?
IPv6 has a rather checkered past. Recall that the TCP/IP protocol suite itself was not designed for a public Internet. It was basically created in 1972 for a quick demonstration of a possible new ARPAnet protocol. During the 1970s, the early ARPAnet used a different protocol, NCP, but TCP/IP was chosen as its replacement, and on "flag day" in 1983, NCP support was (with some exceptions made for laggarts) shut off.
Around that time, UC Berkeley was creating its own version of Unix, and its inexpensive graduate student labor force included an implementation of the TCP/IP protocol suite. The price was right (open source is not a new idea) and it caught on. Companies started using TCP/IP internally, and those who could get attached to the ARPAnet, or its publicly-funded early Internet successors, often did so, helping propagate TCP/IP. It worked, and the price was right.
Ironically, during the 1980s, the computer and network industry was largely committed to a different vision of networking. Each major computer company had its own protocol suite. IBM had SNA. Digital Equipment Corp. had DECnet. Burroughs had BN. Wang had Wangnet. Most enterprises, though, had more than one vendor's computers. So they wanted some way for them to talk to each other. And their vision was to develop Open Systems Interconnection, OSI, a huge programme of the International Organization for Standardization (ISO) and the International Electrotechical Commission (IEC). The ISO OSI standards began with the very famous, if mistaken, seven-layer model. And that provided an organizational structure for a number of committees to actually produce detailed protocol specifications.
But OSI was a flop. A huge, multi-billion-dollar flop. Why? Perhaps one reason is that its many participants couldn't agree upon the goals. IBM and the European PTTs were primarily interested in terminal-to-host access, which X.25 and SNA were good at. Many other computer companies, such as DEC and Sun, were more interested in computer-to-computer communications. The committe did not produce a very good dessert topping / floor wax. And by the time its protocols were nearing modest usability, TCP/IP, with no PTT burden, had stolen its thunder.
This fiasco led many people to think that the OSI people had done a bad job across the board. This was not true: There were many awful details among the OSI specs, but some very good work too. In particular, its Connectionless Network Protocol (CLNP) was a very well designed rethinking of IP, with flexible addressing not fixed at a specific length. (To be sure, ISO addresses could be as long as IPv6's, or longer.) By the early 1990s, CLNP had been widely implemented; most of the major router vendors supported it, based on earlier hopes of OSIs' success. (Federal procurements also, for a time, required OSI compatibility, though OSI was rarely utilized.) It was OSI's upper layers that really needed to be returned for regrooving, while its Connection-Oriented Network Protocol (CONP), a recycled X.25, was best ignored.
The IPNG working group had a few proposals on its table. One was called TUBA (TCP and UDP with Bigger Addresses), and used OSI CLNP with constrained addressing choices. It would have recycled a working part of OSI. An IETF insider, Steve Deering, had his own proposal (sometimes called SIP, for "Steve's IP") for a new IP, as did Paul Tsuchiya (a/k/a Paul Francis) who wrote PIP. They were, in this observer's opinion, rather amateurish. But they lacked the taint of the disdained OSI. Paul's and Steve's proposals were basically combined into one new one, and that is what developed into IPv6. At one point, the Internet Architecture Board, which recommends Internet "standards", decided to adopt TUBA as the IPNG, but some members balked. So at a subsequent meeting, IAB member Vint Cerf changed his vote, and IPv6 became the recommended new "standard". TUBA was effectively dead, along with other IPNG ideas. About a decade has passed since then. IPv6 largely sits on the shelf, with pilot projects and numerous implementations getting very little actual use.
Who would benefit?
IPv6 has its backers. For one thing, its widespread adoption would spur the purchase of new routers. That makes Cisco happy; they are a leading supporter. Its longer headers would use up bandwidth, making the telecom carriers happy. Some Asians support it because the current allocation of IPv4 addresses is perceived as favoring Americans, though quite a bit of address space has been allocated to Asia.
There's no real reason to jump onto the IPv6 bandwagon. It's costly, in terms of both bandwidth and equipment requirements. While IPv4's addressing limits do impose certain inconveniences, IPv6 is an expensive fix. It's a lot of work and a lot of cost, for not a whole lot of gain.
It's not that IPv4 is adequate. It's not -- it's old and tired. But the Internet needs new protocols developed that are more prepared to meet its growing set of needs. It needs new protocols that offer more real capabilities than IPv4, not just more fat. Sadly, real network research seems to have slowed down dramatically since the Internet became public, especially since it has become a mass-market phenomenon. A bigger Internet, it seems, has more inertia. So the cost of supplanting it continues to rise. And at the same time, there are pernicious efforts to destroy the spirit of the Internet by replacing it with Fat Wasteband and walled gardens. So a wholesale migration to IPv6 could be a distraction, taking away attention from more serious problems that still haven't been addressed.
