By Pete Loshin
IPv6 – The Next Version of the Internet Protocol
A lot of hot air has been blowing over the past year or so about the next version of the Internet Protocol, IPv6. Unlike the Y2K problem or even the move to support the latest version of Microsoft Windows, there are no “flag day” transitions by which time systems must be upgraded or else. Members of the IETF (Internet Engineering Task Force) recognized that the current version of IP, IPv4, would need an upgrade by the late 1980s, and RFCs specifying the new protocol began appearing by 1995. But some big questions remain unanswered: why support IPv6 at all, and how will it work?
Savvy network professionals already know quite a bit about IPv6. For one thing, they know that IPv4 has limited address space and that IPv6 increases the network address size from 32 bits to 128 bits. They know that IPv6 smoothes the rough edges around IPv4 and adds some very nice features such as stateless autoconfiguration (“plug-and-play” networking). But they may not know all that much more about IPv6, especially not about the upgrade paths from IPv4 to IPv6, how to migrate individual hosts and networks, what to do about applications, and where to find more real-world resources for deploying IPv6.
IPv4 is sufficiently robust and scalable to go from serving as the network layer protocol for a research network linking a few dozen government and academic research sites to today’s Internet, a global network now linking something on the order of 100 million nodes. But IPv4 was published in RFC 791 back in 1981, and it has needed a face-lift for some time. Number one problem is the IPv4 address space. As anyone who has requested a globally unique IP network address in the past five years knows, they are in very short supply.
Despite the fact that the 32-bit IPv4 address could (in theory at least) uniquely identify over four billion different nodes, much of that space is inaccessible (either reserved or unused). The problem is that addresses were originally apportioned inefficiently. But perhaps an even more pressing problem is how to cope with the explosive growth in Internet routing tables.
Part 2: The Trouble with IPv4
The Trouble with IPv4
Figure 1 shows how the IPv4 address space is allocated: as you can see, the original architecture allocated fully half of all IPv4 addresses to 126 Class A networks. Originally intended for very, very large networks maintained at the national level (or multinational, for corporations), quite a few Class A addresses were snatchedup by net-savvy organizations such as MIT and Carnegie Mellon University early on. Each Class A network is capable of handling as many as 16 million nodes, so since few organizations with Class A network addresses have that many nodes much of that address space is wasted.
Another 25% of all addresses are allocated for Class B networks: roughly 16,000 Class B networks are possible, each capable of addressing as many as 65,000 nodes. Again, net-savvy organizations scooped these up early even though they might never come close to having that many nodes. The problem was that Class C networks, which compose only one eighth of the entire IPv4 address space and of which there are over 2 million, can handle no more than 254 nodes. Clearly, these addresses are inappropriate for companies with 1,000 nodes even if a Class B is overkill.
Figure 1: (from RFC 791)
IPv4 started slowly strangling on this structure by the mid 1990s even as corporations began embracing TCP/IP and the Internet in earnest. Each new IP network address assigned meant some more addresses taken out of circulation. Even though there are still plenty of addresses left, that is only due to the implementation of a series of stopgap measures, strict rationing, and better utilization of existing addresses.
The IETF and the IANA (the Internet Assigned Number Authority, in the process of being superceded by the Internet Corporation for Assigned Names and Numbers, ICANN) used several approaches to extending IPv4’s lifetime while IPv6 was being readied. These steps can be characterized as rationing, repackaging, recycling, and replacing.
First, rationing. This one is easy: the process of getting a Class B or Class A network address was tightened up. And Class C addresses were distributed by ISPs, who get a limited number of addresses and need to take care that they are not wasted unnecessarily. Class B addresses were very hard to come by as early as 1990 or so, and Class A addresses virtually impossible. By holding onto the Class A and B network addresses, it is now possible to break them up and redistribute them in smaller chunks.
Next, repackaging. Classless InterDomain Routing (CIDR) does away with the class system, allowing ISPs to allocate groups of contiguous Class C addresses as a single route. The alternative would be to have routers treat each individual Class C address as a separate route, resulting in a nightmarishly large routing table. Instead of Class A, B, or C, routed addresses are expressed along with a number indicating how many bits of the network address is to be treated as the route. For example, 256 Class C addresses could be aggregated into a single route by indicating that 16 bits of the address is to be treated as the route (the same as for a Class B address). In this way, an ISP or other entity that administers CIDR networks can handle the routing from the Internet.
Address space can be recycled, sort of, in two ways: first, Class A and B addresses that have not yet been assigned can be divided up and allocated to smaller organizations. Where the CIDR approach is sometimes referred to as “supernetting”, this approach simply breaks the larger networks into subnets which can be routed by some entity handling routing for the entire (undivided) network address.
Another approach is to use the reserved network addresses, sometimes called Network 10, to do network address translation, or NAT. RFC 1918 sets aside the network address ranges:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
to be used for private intranets. These addresses provide one Class A, 16 Class B, and 255 Class C network addresses to be used by anyone who wants to, as long as they don’t attempt to forward packets to or from those networks on the global Internet.
The last option is to replace IPv4 addresses entirely. This is the IPv6 option. Each of these other approaches pushes back the day when IPv4 will no longer work, but does not relieve the stress.
Part 3: The IPv6 Solution
The IPv6 Solution
IPv6 adds 128-bit addresses and an aggregatable address space to solve the address shortage while at the same time making possible much smaller backbone routing tables. Its streamlined header and design refinements fix nagging issues such as network autoconfiguration, mobile IP, IP security, fragmentation, source routing and the very large packets known as jumbograms.
The IPv6 global aggregation addressing architecture splits addresses into two parts. The high-order 64 bits identify the network, and the low-order 64 bits identify the node. A format prefix gives the type of IPv6 address. Next comes a top-level aggregation entity, likely to be a country or a large carrier, followed by 8 bits reserved for future growth. Then comes another aggregation entity, likely to be a large company or Internet provider, and finally a site-level aggregation entity, probably assigned by the entity above it. Such addresses are far more efficient to route across backbones.
Aggregation means any address contains its own route. The first few bits of the address might indicate, say, Europe. The packet would go to a router serving Europe, which might see Portugal in the next few bits and forward the packet to Portugal’s router. From there, the packet might go on to a router in Lisbon and then on to its final destination.
Figure 2 shows that the Top-Level Aggregation ID (TLA) uses 13 bits. This gives an upper limit of no more than 8,192 (2 to the 13th power) top-level entities, which pares down the size of the routing table a backbone router would have to deal with to forward packets anywhere in an IPv6 Internet. The next 8 bits are reserved, presumably held back, just in case the TLA allocation should be bigger (or the Next-Level Aggregation ID allocation should be bigger).
Figure 2: (from RFC 2373)
NLA entities are expected to include large ISPs, among others. These entities get their address allocations from the TLAs, who also handle routing for the NLAs. Each TLA can allocate as many as 16 million or so NLA networks (2 to the 24th) The NLAs, in turn, can allocate as many as 65,536 networks each (2 to the 16th) to Site-Level Aggregation (SLA) entities. In other words, network sites. And each SLA entity still has 64 bits of address space to play around with, for as many as 18 million trillion (18,446,744,073,709,551,616) nodes per network.
While the IPv6 address is longer than we’re used to, the IPv6 header is simpler than we are used to (see Figure 3). IPv6 eliminates length, identification, flag, fragment offset, header checksum, options, and padding fields that were found in IPv4 headers. Because IPv6 headers are all the same length, no length field is necessary. IPv6 prohibits fragmentation except between end nodes, so the identification, flag and fragment offset fields go away, too.
Figure 3 (from RFC 2460)
IPv6 options are handled in separate extension headers so options no longer clutter the main header. The IPv4 type-of-service field has evolved into the traffic class field, and the time-to-live field is replaced by the hop limit field. A flow label field supports IPv6 packet sequences that require the same routing treatment, such as video streams.
The simplified, standard-sized IPv6 header also makes routing easier for packets with special options. IPv4 forces routers to sense and handle all special packets, such as those using IP Security encryption and authentication. But IPv6 routers can ignore the end-to-end options and process only those relevant to the routing process.
Part 4: Migrating to IPv6
Migrating to IPv6
Software upgrades, particularly operating system upgrades, can have a huge impact on organizations. Remember the transition from Windows 3.x to Windows 95? In addition to the raw cost of the OS upgrade, system hardware had to be upgraded or systems discarded because they lacked the RAM, CPU, or hard drive resources to run the new OS. Migration to IPv6 is likely to produce less intense pain and has the potential for being less expensive. For one thing, the transition will be gradual. Brian Carpenter, Internet Architecture Board (IAB) chair and Program Director of Internet Standards and Technology for IBM, explains: “We never expected the transition process to take less than 15 years, counting from around 1994.”
Another active member of the IPng working group and senior member of technical staff at Compaq’s UNIX Internet Engineering Group, Jim Bound, urges not to “view IPv6 as a migration or transition for the majority of organizations, but rather the ‘interoperation’ of IPv6 with IPv4 for some time.” Bound continues, “It’s important to realize that IPv6 is an evolution from IPv4, not a revolution to a [totally] new Internet Protocol.”
By design, moving to support IPv6 will mean moving to a multiprotocol Internet rather than a full-blown protocol cutover or flag-day conversion. No one expects IPv4 to go away, ever. Which means that the big question will not be whether or not to upgrade to IPv6, but rather when, how, where, and how much to transition to support for IPv6. Supporting IPv6 is going to be both simpler and more complex than any other networking decision you’ll make.
IPv6 interoperability with IPv4 is supported in three ways: tunnels, translators, and dual-stacks. As Bound explained, these are all works in progress: “Right now, to build any products on these technologies is premature.” He continued, “multiple tools will be defined…a user will have a range of tools to use just like a carpenter, mason, or landscaper does in their tasks.” According to Bound, no single mechanism is “better” than the others; he can “see a case where all three are used in one organization eventually.”
There is no single road to IPv6 support. Some individual networks will be upgraded en masse, creating reservoirs of IPv6 support surrounded by oceans of IPv4. Individuals within the IPv6 networks can be IPv6-only, but IPv4/IPv6 gateways are necessary at their borders for these networks to interoperate with IPv4 networks. And different IPv6 networks can communicate with each other through the IPv4 Internet by setting up IPv6/IPv4 tunnels.
Other organizations will migrate host by host, with dual-protocol IPv4/IPv6 nodes scattered throughout the existing IPv4 network like raisins in a loaf of raisin bread. These nodes will be able to interoperate with each in native IPv6, or with IPv6 nodes outside the network by tunneling IPv6 inside IPv4 packets.
Part 5: Rolling IPv6 Out
Rolling IPv6 Out
Even though IPv6 lacks broadbased demand, router vendors Bay Networks, 3COM, Digital, Hitachi, Nokia, Sumitomo and Telebit all currently support IPv6; the Linux kernel also includes IPv6 support. Other vendors are working on IPv6 routers as well as IPv6 stacks for nodes. Microsoft Research, for example, currently offers an alpha version of an experimental IPv6 stack that works with Windows NT and Windows 2000; the Microsoft Windows networking group is reportedly working on a commercial version.
The next issue is finding an IPv6 network to connect to. Though you can deploy IPv6 on a testbed network within your organization, that level of implementation will not adequately demonstrate IPv6’s strengths or identify potential problems. Right now your only options are the 6BONE and the 6REN; 6BONE is an experimental IPv6 backbone and 6REN offers production quality IPv6 networking.
In either case, you can’t connect to an IPv6 network without connecting to an IPv6 access point: either a pTLA (pseudo top level aggregator) for 6BONE backbone transit or a pNLA (pseudo next level aggregator) for non-backbone transit. Access providers are designated pseudoTLAs and pseudoNLAs because no official registry is yet assigning “real” TLA or NLA address spaces. The access provider allocates IPv6 network address space to its customers. At that point, you can build a configured IPv4 tunnel from your site’s IPv6 router to your 6BONE point of entry.
Internet Architecture Board (IAB) chair Carpenter suggest that “right now, the thing to do is to learn about IPv6.” Once implementers are freed from the constraints of a overly-full IP address space, almost anything is possible. Carpenter suggests that IPv6 will soon make possible very interesting applications like “small appliances such as smart cell phones, that roll out in millions.”
Allison Mankin, computer scientist at University of Southern California/Information Sciences Institute (USC/ISI) adds that one “potential killer app in IPv6 is efficient, transparent mobility. The pull for continuously connected moving devices is not here yet, but someone could create it with IPv6.” Compaq’s Bound sees great potential for IPv6, especially where the plentiful IPv6 addresses can reflect a business model, as in “retail department stores where each aisle is an IP subnet.”
What should you do about IPv6? Organizations can support IPv6 from the inside out or from the outside in. Early implementers have the option of building islands of IPv6 connectivity within the organization to meet a specific need; research groups may begin IPv6 support this way. Other groups may support IPv6 as requested by end users, for example to enable mobile IPv6 networking, IP security architecture (IPsec) networking, and IPv6-enabled applications.
Expect network vendors to fold IPv6 support into all their products just as they now support IPv4. IAB chair Carpenter says “If it is shipped as a standard operating system or router upgrade, the costs will be operational in nature. That makes it very dangerous to generalize about the cost–a fair analogy would be with the costs of implementing an operating system release.”
Mankin suggest that supporting IPv6 will reduce costs in the long run. She suggests that moving to IPv6 for ISPs is “not as costly as making a transition to nested NATs (between providers)” while for for end-users, “the cost of transition is as low as just the cost of upgrading the operating system or router version.” Overall, Mankin claims, “the cost of running an IPv6 network is less than the cost of running an equivalent IPv4 network.”
Part 6: IPv6 – The Bottom Line
IPv6 – The Bottom Line?
Is IPv6 all that and a bag of chips? Not everyone agrees, but it’s hard to find anyone close to the issues who believes that IPv4 is fine the way it is and needs no updating. Even so, foes of IPv6 proclaim deep flaws and plan to wait for “something better than IPv6” before they give up on IPv4. They believe that address assignment and routing problems are under control. According to John Levine, author of IDG’s “Internet for Dummies”, the original motivation for IPv6 was a shortage of IPv4 addresses and that is no longer enough reason to change. Levine claims that conservation measures have worked so well that “the original impetus for IPv6 has disappeared, and now it’s a solution casting about for a problem.”
While ISPs seem to dislike IPv6 more than most, they should also be the ones who gain the most from a new IP with no restrictions on addressing. Mankin says “providers are opposed to adding another protocol to their operations, because just operating IPv4 is a strain,” but “the same providers do respond to customer requests, so I believe that when customers request IPv6, the providers will be less opposed.”
The IETF has already invested almost a decade in the development of the next generation of IP; it’s hard to imagine someone else coming up with an alternate solution any time soon. Continued growth puts the Internet at risk unless relief can be found for the address space crunch as well as the routing table explosion. Despite these pressures, it may ultimately be the pent up demand for ever more ubiquitous networks that drives acceptance of IPv6.
With the future of the Internet hanging in the balance, the next ten years should prove interesting, to say the least.
Pete Loshin ([email protected]) began using the Internet as a TCP/IP networking engineer in 1988, and began writing about it in 1994. He runs the website Internet-Standard.com where you can find out more about Internet standards.