2.11. IPv6

We have already seen how CIDR and NAT are being used as short-term solutions to the depletion of IPv4 addresses. The longer-term solution is a new version of IP: IP version 6 (IPv6). IPv6 improves on IPv4 in the following areas:

• A larger address space. IPv6 increases the 32-bit addresses of IPv4 to 128 bits. The new addresses are explicitly hierarchical, which helps prevent router table growth. We'll discuss the IPv6 address structure shortly.

• A simplified, fixed-sized header. The IPv6 header is considerably simplified. The number of fields has been reduced from 13 in IPv4 to 8 in IPv6. This simplified header allows routers to process IP datagrams more efficiently and therefore to obtain higher routing speeds.

• Improved handling of IP options. Rather than include options in the IP header itself as IPv4 does, IPv6 has separate option headers. With one exception, intermediate routers need not examine these headers, again adding to routing speed.

• Flow labels. The IPv6 header includes a 20-bit flow label that allows IP packets to be identified as belonging to a particular flow. This capability enables differentiated handling of a series of IP datagrams belonging to the same flow.

The IPv6 Address Model

IPv6 has three types of addresses:

Because IPv6 addresses are so long, we use a different notation to write them. The nominal textual representation is x₁: x₂: x_3:x₄: x₅: x₆: x₇: x₈, where each x_i represents one of the eight 16-bit pieces of the address. Typical examples are

fe9c:ba78:0:0:0:400:33ac:20
2:0:0:0:204:faff:fe41:d630
0:0:0:0:0:0:0:1

As we see in the examples, we can simplify the addresses by not writing the leading 0s in each field. We can further simplify them by replacing the longest run of 0s with ::. Thus, we could write the three preceding examples as

fe9c:ba78::400:33ac:20
2::204:faff:fe41:d630
::1

The last address in the examples is the loopback address. It serves the same function as 127.0.0.1 does in IPv4.

The structure of a typical unicast address in shown in Figure 2.36.

Figure 2.36. An IPv6 Unicast Address

[View full size image]

The routing prefix corresponds to the IPv4 network ID. It is used to route datagrams to a particular network, or site in IPv6 terminology.

The subnet ID is used to identify individual segments, or links in IPv6 terminology. A site's internal routers can use this field to route datagrams to the proper link.

The interface ID is unique for each interface on the link and corresponds to the host ID in IPv4. This field is required to be 64 bits unless the address begins with the binary sequence 000.

The IPv6 addressing architecture is specified in RFC 3513 [Hinden and Deering 2003]. Specific aspects of addresses, such as the formation of the interface ID, are specified in a series of other RFCs referenced in RFC 3513.

The IPv6 Header

The IPv6 header, shown in Figure 2.37, is simpler than the IPv4 header. Because the header has a fixed size, there is no header-length field. Because IPv6 headers are not checksummed, there is no checksum field. Because fragmentation is handled with a separate extension header, there are no identification, fragment-offset, DF, or MF fields.

Figure 2.37. The IPv6 Header

[View full size image]

The version field identifies the datagram as a version 6 datagram. The version field is set to 6.

The traffic class and flow label fields are used to provide special handling for IP datagrams. The use of these fields is still experimental, and they will not play any role in this text.

The payload length field is the length of the datagram exclusive of the header. Because the header size is fixed at 40 bytes, the size of the entire datagram is implicitly known from this value. The payload length includes any extension headers present in the datagram.

The next header field is analogous to the protocol field in the IPv4 header. If the datagram has no extension headers, this field will specify an upper-layer protocol, such as TCP or UDP, or a network-layer protocol, such as ICMP. If the datagram does have extension headers, this field will specify the extension header immediately following the IP header.

The hop limit field is the same as the TTL field in IPv4. It is used to prevent IP datagrams from circulating in the network indefinitely.

The source and destination address fields contain the 128-bit addresses of the node originating the datagram and the node to which it is being sent. If a routing extension header is present, the destination address may not be that of the ultimate destination.

Because the IPv6 header is not checksummed, the use of a pseudoheader is even more important than in IPv4. The IPv6 pseudoheader is shown in Figure 2.38. As in IPv4, this pseudoheader is prepended to TCP and UDP packets for purposes of calculating the checksum only.

Figure 2.38. The IPv6 Pseudoheader

[View full size image]

IPv6 Extension Headers

In IPv6, optional network-layer information is encoded into separate data structures called extension headers. The IPv6 specification, RFC 2460 [Deering and Hinden 1998], lists six types of extension headers. Two of thesethe authentication header (AH) and the encapsulating security payload (ESP) headerare part of IPsec; we will discuss them in Part 3. The other four deal with hop-by-hop options, destination options, routing, and fragmentation.

Except for the hop-by-hop option header, no node except that specified in the destination address field need examine or deal with these headers in any way. Because the hop-by-hop extension header must immediately follow the IPv6 header, a router need merely look at the next header field in the IPv6 header to know whether or not it need concern itself with the extension headers. Currently, no hop-by-hop options are defined except for the padding options used by all the headers to align data on the appropriate boundary.

The router extension header plays a role similar to that of source routing in IPv4. This header allows the sender to specify a series of intermediate nodes through which the datagram must pass.

Fragmentation in IPv6 differs from that in IPv4. First, IPv6 datagrams are never fragmented by intermediate nodes; hence the lack of a DF bit. In IPv6, only the source host can fragment a datagram. This implies that path MTU discovery is mandatory in IPv6. Second, when a datagram is fragmented, the information about each fragment is in the fragmentation extension header. This header contains fragment-offset, MF bit, and identification fields, just as in IPv4.

The destination extension header is examined by the destination node or nodes. Like the hop-by-hop extension header, no nontrivial destination options are currently defined.

In addition to the fields necessary to perform their functions, each extension header has a next-header field. Nodes use this field to determine the meaning of the data following the extension header: another extension header, a network-layer protocol header, or a transport-layer protocol header. Figure 2.39 shows a typical IPv6 datagram with extension headers and a TCP segment.

Figure 2.39. An IPv6 Datagram

[View full size image]

The complete specification of IPv6 is spread among several RFCs. For further information, see <http://www.ietf.org/html.charters/ipv6-charter.html>, the Web site of the IETF (Internet Engineering Task Force) Working Group on IPv6.