IPv6

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.)

Table 23.1. Number of Networks and Addresses for IP Address Classes

Class	First Octet	Number of Network	Possible Addresses per Networks
A	0–126	127	16,777,214
B	128–191	16,383	65,534
C	192–223	2,097,151	254

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.

Some of the goals for IPv6 are as follows:

• Expanded addressing capabilities— Not only does IPv6 provide more addresses, it also provides other improvements to IP addressing. For instance, IPv6 supports more hierarchical addressing levels. IPv6 also improves address auto-configuration capabilities and provides a new kind of address called an anycast address, which enables you to send a datagram to any one of a group of computers.

• Simpler header format— Some of the IPv4 header fields have been eliminated. Other fields have become optional.

• Improved support for extensions and options— IPv6 allows some header information to be included in optional extension headers. This increases the amount of information the header can include without wasting space in the main header. In most cases, these extension headers are not processed by routers; this further streamlines the transmission process.

• Flow labeling— IPv6 datagrams can be marked for a specific flow level. A flow level is a class of datagrams that requires specialized handling methods. For instance, a real-time service might require a different flow level than an email message.

• Improved authentication and privacy— IPv6 extensions support authentication, confidentiality, and data integrity techniques.

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.

The fields of the IPv6 header are as follows:

• Version (4-bit)— Identifies the IP version number (in this case, version 6).

• Traffic Class (8-bit)— Identifies the type of data enclosed in the datagram.

• Flow Label (20-bit)— Designates the flow level (described in the preceding section).

• Payload Length (16-bit)— Determines the length of the data (the portion of the datagram after the header).

• Next Header (8-bit)— Defines the type of header immediately following the current header. See the discussion of extension headers later in this section.

• Hop Limit (8-bit)— Indicates how many remaining hops are allowed for this datagram. This value is decremented by one at each hop. If the hop limit reaches zero, the datagram is discarded.

• Source Address (128-bit)— Identifies the IP address of the computer that sent the datagram.

• Destination Address (128-bit)— Identifies the IP address of the computer that receives the datagram.

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.

The IPv6 specification defines the following extension headers:

• Hop-by-Hop Options

• Destination Options

• Routing

• Fragment

• Authentication

• Encrypted Security Payload

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.

The following sections discuss each of these extension header types in greater detail.

Hop-by-Hop Options Header

The purpose of the hop-by-hop options header is to relate optional information for routers along the transmission path.

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.

Routing Header

The Routing header is used to specify one or more routers that the datagram will route through on the way to its destination.

The Routing header format is shown in Figure 23.3.

The data fields for the Routing header are as follows:

• Next Header— Identifies the header type of the next header following this header.

• Header Length (8-bit)— Specifies the length of the header in bytes (excluding the Next Header field.

• Routing Type (8-bit)— Identifies the routing header type. Different routing header types are designed for specific situations.

• Segments Left— Indicates the number of explicitly defined router segments before the destination.

• Type-Specific Data— Identifies data fields for the specific routing type given in the Routing Type field.

Fragment Header

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.

Authentication Header

The Authentication header provides security and authentication information. The Authentication field provides a means of determining whether a datagram was altered in transit.

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.

IPv6 Addressing

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, 111.121.131.142). 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:

111.121.35.99.114.121.97.0.0.88.250.201.211.109.130.117

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.

However the various vendors decide to relate the IPv4 and IPv6 address systems, you can expect to see more on IPv6 in the coming years.

IPv6 and Quality of Service (QoS)

IPv6 addresses another challenge that has recently faced the aging IPv4 infrastructure: the need for uniform Quality of Service (QoS) levels.

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.