The IP addressing system described in Hour 4, "The Internet Layer," has served the Internet community for nearly a generation, and those who developed it are justifiably proud of how far TCP/IP has come. But for the past few years they've been worrying about one thing: The world is running out of addresses. This looming address crisis might seem surprising, because the 32-bit address field of the current IP format can provide over three billion possible host IDs. But it is important to remember how many of these three billion addresses are actually unusable. A network ID is typically assigned to an organization, and that organization controls the host IDs associated with its own network.
Recall from Hour 4 that IP addresses fall within address classes determined by the value of the first octet in the address field. The address classes and their associated address ranges are shown in Table 23.1. Table 23.1 also shows the number of possible networks within an address class and the number of possible hosts on each network. A Class B address can support 65,534 hosts. Many Class B organizations, however, do not have 65,534 nodes and therefore assign only a fraction of the available addresses—the rest go unused. The 127 Class A networks can support 16,777,214 addresses, many of which also go unused. It is worth noting as well that the 16,510 Class A and B networks are reportedly all taken. The Class C networks that remain face a limitation of only 254 possible addresses. (Refer to Hour 4 and Hour 5, "Subnetting," for more on the anatomy of IP addresses.)
By the Way
The emergence of Classless Internet Domain Routing (CIDR) has helped this problem of using Class C addresses for larger networks. You learned about CIDR in Hour 5.
Internet philosophers have known for some time that a new addressing system would be necessary, and that new system eventually found its way into the standard for IP version 6 (IPv6), which is sometimes called IPng for IP next generation. The current IPv6 specification is RFC 2460, which appeared in December 1998. (Several other preliminary RFCs set the stage for RFC 2460, and newer RFCs continue to discuss issues relating to IPv6.)
The IP address format in IPv6 calls for 128-bit addresses. Part of the reason for this larger address space is supposedly to support one billion networks. As you'll learn later in this hour, this large address size is also spacious enough to accommodate some compatibility between IPv4 addresses and IPv6 addresses.
By the Way
The recent emergence of Network Address Translation (NAT) devices has reduced the threat of this looming IP address shortage. As you learned in Hour 9, "Network Hardware," a NAT device enables a network to use a private address space and still access the Internet through a relatively smaller number of registered addresses.
IPv6 has already begun to emerge into the networking world. Sun Solaris 8 includes built-in support for IPv6, and IPv6 implementations are available for Linux, BSD, and other operating systems. The following sections discuss IPv6 and some of its next-generation features.
IPv6 Header Format
The IPv6 header format is shown in Figure 23.1. Note that the basic IPv6 header is actually simpler than the corresponding IPv4 header. As was just mentioned, part of the reason for the header's simplicity is that detailed information is relegated to special extension headers that follow the main header.
As was already mentioned in this hour, IPv6 provides for bundles of optional information in separate extension headers between the main header and the data. These extension headers provide information for specific situations and at the same time allow the main header to remain small and easily manageable.
Each header type is associated with an 8-bit identifier. The Next Header field in the main header or in an extension header defines the identifier of the next header in the chain (see Figure 23.2).
Of the extension headers described in the preceding list, only the Hop-by-Hop Options header and the Routing header are processed along the transmission path by intermediate nodes. Routers do not have to process the other extension headers; they just pass them on.
Hop-by-Hop Options Header
The Hop-by-Hop Options header, like the Destination Options header discussed in the next section, was included in the specification largely to provide the industry with a format and a mechanism for developing future options.
The specification includes an option type designation and some padding options for aligning the data. One option that is defined explicitly in the specification is the jumbo payload option, which is used to transmit a data payload longer than 65,535 bytes.
Destination Options Header
The purpose of the Destination Options header is to relate optional information to the destination node. Like the Hop-by-Hop Options header, the Destination Options header is included primarily as a framework for developing future options.
The Routing header format is shown in Figure 23.3.
Each router along a message path has a setting for the maximum transmission unit (MTU). The MTU setting indicates the largest unit of data the router can transmit. In IPv6, the source node can discover what is called the path MTU—the smallest MTU setting for any device along the transmission path. The path MTU represents the largest unit of data that can be sent over the path. If the size of the datagram is larger than the path MTU, the datagram must be broken into smaller pieces so that it can be delivered across the network. The Fragment header contains information necessary for reassembling fragmented datagrams.
Encrypted Security Payload Header
The Encrypted Security Payload header (ESP) provides encryption and confidentiality. Using IPv6's ESP capabilities, some or all of the data being transmitted can be encrypted. Using tunnel-mode ESP, an entire IP datagram is encrypted and placed in an outer, unencrypted datagram. In Transport node ESP, authentication data and ESP header information are encrypted.
As you'll recall from Hour 4, 32-bit IPv4 addresses are commonly expressed in dotted-decimal notation, in which each byte of the address is expressed as a decimal number of up to three digits (for example, 188.8.131.52). This string of 12 decimal digits is easier to remember than the 32 binary digits of the actual binary address, and it is possible, if you try, to even remember a dotted-decimal address. This method for humanizing a 32-bit address, however, is utterly useless for remembering a 128-bit address. A dotted-decimal equivalent of an IPv6 address looks something like this:
It's too early to predict how network administrators will accommodate these long addresses. You can certainly bet that DNS will play an important role on IPv6 networks (see Hour 11, "Name Resolution").
Engineers typically use a hexadecimal (base 16) format to express 128-bit IPv6 addresses as eight 4-digit hexadecimal values (each signifying 16 digits). Colons separate 4-digit values. This string of eight 4-digit hexadecimal numbers is easier to remember than the dotted-decimal equivalent, but it still isn't easy to remember.
As a consequence of the address assignment scheme for IPv6, it appears that all-zero bytes will be common. Eliminating leading zeros and leaving out zero strings (with a double colon to signify missing digits) should further improve memorization. But if you traffic in 128-bit addresses every day, think about using DNS.
IPv6 with IPv4
The only way IPv6 will ever take hold, of course, is if it phases in gradually. A full-scale retooling of the Internet isn't going to happen, so engineers designed IPv6 so that it could coexist with IPv4 over a long-term transition.
The intention is that an IPv6 protocol stack will operate beside the IPv4 protocol stack in a multiprotocol configuration, just as IPv4 now coexists with IPX/SPX, NetBEUI, or other protocol stacks. The software components necessary for multiplexing IPv4 and IPv6 will then have to operate at the Network Access layer (see Figure 23.4).
The addressing systems also provide a measure of compatibility or at least convertibility. One scheme suggests that the 32 bits of an IPv4 address could fill the lowest 32 bits of an IPv6 address. The top 96 bits could then contain a standard bit pattern.
IPv6 and Quality of Service (QoS)
In the old days, when the Internet primarily was used for email and FTP-style downloads, no one thought much about prioritizing data transmission. If an email message didn't arrive in two seconds, it would arrive in 2 minutes—or possibly in an hour. No one really cared about specifying or limiting the time interval in which the message could arrive. In contrast, today's Internet supports many different types of transmissions, some with very rigid delivery requirements. Internet video and television and other real-time applications cannot operate properly with long delays as packets wind their way through router buffers. Even a small delay in an Internet phone connection can have the effect of distorting the speech of the participants.
In the Internet of the future, it will be possible to prioritize IP datagrams as they wait for delivery. A datagram from an interactive video application could move to the top of the queue as it waits in a router buffer, whereas an email datagram might pause for a momentary delay.
IPv6 is designed to support prioritizing through differentiated service levels. The Traffic Class and Flow Label fields of the IPv6 header provide a means for specifying the type and priority of data enclosed in the datagram (refer to Figure 23.1). Of course, new data fields in the header will not provide new functionality on the Internet until hardware vendors develop routers and other devices that recognize these new routing parameters.
By the Way
In the IPv4 world, some vendors and engineers have experimented with using the Type of Service field (refer to Figure 4.3) for differentiated service information. The IPv6 Traffic Class field is intended to support continued experimentation with differentiated service.