The IPv6 Header

During 2011 the U.S. government directed all federal agencies to sup-port IPv6 on their public websites by September 30, 2012, resulting in approximately 10,000 websites falling under this mandate. In April 2011 Asia depleted all of its IPv4 address space, while the European regional registry is expected to run out of IPv4 address space in 2012, quickly followed by North America, which is expected to deplete its IPv4 address space during 2013. Although IPv4 addresses are rapidly being depleted, this is only one of the several issues that was the driv-ing force for the development of a replacement for that version of the Internet Protocol. Other issues include the need to improve support for extending the IP header to accommodate features and functions yet to be developed, simplify the header to reduce packet process-ing time, and enable the labelprocess-ing of packets belongprocess-ing to a flow as a mechanism to provide a quality of service capability. These issues resulted in a complete redesign of the IP header.

Figure 3.23 illustrates the format of an IPv6 header. Note that the resulting header is significantly simpler than the IPv4 header, consist-ing of only seven fields. Although the header is simpler than an IPv4 header, we will soon note that through the use of the Next Header field we can daisy-chain IPv6 headers, one after another, which consider-ably expands the capability of an IPv6 header, enabling such security

Table 3.9 Classless Address Blocks

options as authentication to be added. To obtain an appreciation of the IPv6 header, let’s examine each field in the header.

3.7.1 Ver Field

The Ver field is 4 bits in length and functions in the same manner as its IPv4 cousin. That is, it identifies the version of the Internet Protocol.

For IPv6 a binary value of 0110 is placed in this field. Because the Ver field in an IPv6 header like its IPv4 counterpart is located at the beginning of the header, it enables a communications device to rapidly distinguish an IPv4 packet from an IPv6 packet.

3.7.2 Priority Field

The Priority field enables a data originator to identify the desired delivery priority of a packet. Because this field is 4 bits, up to 16 priorities (0 to 15) can be specified. Table 3.10 lists presently defined Priority field values. In examining the recommended priority values

Figure 3.23 The IPv6 header.

Table 3.10 Priority Field Value Assignments

PRIORITY FIELD VALUE RECOMMENDED ASSIGNMENT 0 Uncharacterized traffic

1 Filler traffic

2 Unattended traffic

3 Reserved

4 Attended bulk transfer

5 Reserved

6 Interactive traffic 7 Internet control traffic

listed in Table 3.10, Netnews and email can be considered to repre-sent applications that could be assigned priorities of filler and unat-tended data transfer, respectively. FTP could represent an example of an attended bulk transfer priority, while Telnet and SNMP could represent interactive traffic and Internet control traffic. Priority values of 8 through 15 are reserved for non-congestion-controlled traffic or traffic consisting of real-time packets that does not back off in response to network congestion. The lowest-priority value (8) should be used for packets the originator is most willing to have discarded when congestion effects data flow, while the highest value (15) should be assigned to packets the originator is least willing to have discarded.

3.7.3 Flow Label Field

The Flow Label field is 24 bits in length. This field enables a source to identify a sequence of related packets that require special handling by intermediate routers when the packets travel from source to destination.

An example of a flow could be a real-time video conference. Through the identification of a traffic flow it becomes possible for a quality of service (QoS) protocol, such as the Resource Reservation Setup Protocol (RSVP), to use the Priority and Flow Label fields to provide special packet handling based upon the allocation of bandwidth.

3.7.4 Payload Length Field

The Payload Length field is 16 bits in length and its value indicates the payload carried by the packet after the header. Because an IPv6 header’s length is fixed at 40 octets, the total length of the packet is the value of the Payload Length field plus 40.

3.7.5 Next Header Field

The Next Header field identifies the type of header that immedi-ately follows the IPv6 header. Although the values used for this 8-bit field are the same values as used in the IPv4 Protocol field (refer to Table 3.4), the use of this field considerably differs from the IPv4 Protocol field. The latter simply indicates the protocol that follows

the IPv4 header. In comparison, the Next Header field can indicate an optional header, a higher-layer protocol, or no protocol above IP. This significantly expands the capability of IPv6 since it enables headers to be daisy-chained to support a particular function or series of functions.

Figure  3.24 illustrates an example of the extension of an IPv6 packet through the daisy chaining of headers. In this example a value of 43 in the IPv6 header indicates that the next header is a routing header. The routing header in turn would have a value of 51 in its Next Header field to indicate authentication follows, resulting in an authentication header following the routing header. The authentica-tion header would then have a value in its Next Header field to indi-cate a TCP header follows.

3.7.6 Hop Limit Field

This 8-bit field indicates the maximum number of routers a packet can traverse prior to being discarded. This field acknowledges that the use of a time entry in the IPv4 TTL field was impractical and the earlier protocol’s more practical use of a hop count is officially used by the newer protocol.

3.7.7 Source and Destination Address Fields

Both Source and Destination Address fields were extended to 128 bits from IPv4’s 32-bit addresses. Because IPv6 is based upon the same archi-tecture used in IPv4, each network interface still requires a distinct IP address. However, under IPv6 an interface can be identified by several types of addresses, each of which contains 128 bits or 96 more bits than an IPv4 address. In the remainder of this section we turn our attention to some of the address types supported under IPv6, their notation or representation, and the manner by which IPv6 address space is allocated.

Figure 3.24 An example of an IPv6 packet with daisy-chained extension headers.

3.7.7.1 Address Types IPv6 defines three types of addresses—unicast, multicast, and anycast—with the latter representing a new address category that was not included in IPv4. An anycast address identifies a group of devices similar to a multicast address. However, a packet with a multicast address is delivered to only one host, usually the clos-est one to the source with “close” defined by the routing protocol.

The use of anycast addressing can be expected to facilitate network restructuring while minimizing the amount of configuration changes required to support a new network topology. This can be accomplished since an anycast address could be used to reference a group of rout-ers, and the alteration of a network when IPv6 is used with anycast addressing would allow the stations to continue to access the nearest router without having to change the station’s address configuration in its TCP/IP protocol stack.

3.7.7.2 Address Notation IPv6 addresses are written in dotted decimal notation similar to the manner by which they are used to specify an IPv4 address. However, because an IPv6 address consists of 128 bits or 32 decimals, the format by which dotted decimal numbers are used changed. Instead of a period or dot to separate individual numbers, under IPv6 a colon (:) is used to separate 16-bit or 4-hex-character address entities. Because IPv6 addresses will often have a long string of zeros, such as a 32-bit IPv4 address represented in a 128-bit IPv6 address field, a double colon (::) is used to represent contiguous multi-ple 16-bit (4-hex-character) blocks of zeros. To illustrate IPv6 address notation, let’s examine the use of colons and double colons. For exam-ple, consider the following IPv6 address:

1ACD:4ABD:0003:0000:0000:0001:31BC:010A

To facilitate the entry of IPv6 addresses you can ignore or skip the leading zeros in each hexadecimal 4-byte component. This allows you to rewrite the previous IPv6 network address as:

1ACD:4ABD:3:0:0:1:31BC:10A

We can simplify the address further by replacing consecutive null 16-bit numbers by double colons. Doing so we obtain:

1ACD:4ABD:3::1:31BC:10A

Note that the double colon can only be used once inside an IPv6 address. This is because the reconstruction of the address requires the number of integer fields in the address to be subtracted from 8 to determine the number of consecutive fields of zero value the double colon represents. Otherwise, the use of two or more double colons would result in an ambiguity that would prevent the address from being correctly reconstructed.

3.7.7.3 Address Allocation The use of a 128-bit address space for IPv6 results in a much higher degree of address assignment flexibility than obtainable when using IPv4 addresses. For example, under IPv6 ing Internet service providers can be identified. In addition, IPv6 address-ing provides the ability to identify local and global multicast addresses, private site addresses for use within an organization, hierarchical global unicast addresses, and other types of addresses. In Table 3.11 you will note a list of the initial allocation of address space under IPv6.

Table 3.11 IPv6 Address Space Allocation

ALLOCATION PREFIX (BINARY)

FRACTION OF ADDRESS SPACE

Reserved 0000 0000 1/256

Unassigned 0000 0001 1/256

Reserved for NSAP allocation 0000 001 1/128

Reserved for IPX allocation 0000 010 1/128

Unassigned 0000 1 1/128

Link-local use addresses 1111 1110 10 1/1024

Site-local use addresses 1111 1110 11 1/1024

Multicast addresses 1111 1111 1/256

IPv6 address space allocation was assigned to the Internet Assigned Numbers Authority (IANA). IANA distributes portions of IPv6 address space to regional registries, such as the InterNIC in North America, RIPE in Europe, APNIC in Asia, and similar organizations. To obtain an appreciation for the potential use of IPv6 addresses, let’s examine several types of IPv6 addresses.

3.7.8 Provider-Based Unicast Addresses

A provider-based unicast address is assigned by an Internet service provider to a customer. Based upon the initial allocation of IPv6 addresses shown in Table 3.11, each provider-based unicast address has the 3-bit prefix 010. That prefix is followed by fields that iden-tify the Internet address registry from which the ISP obtained the address (registry identifier), the address block assigned to the ISP by the registry authority, which identifies the ISP (provider identifier), the ISP’s subscriber (subscriber identifier), and the subscriber address in the form of a 16-bit subnet identifier (subnet) and a 48-bit interface identifier (station). The latter can represent the MAC address of a station and, when used, also represents a unique address. Figure 3.25 illustrates the format of a provider-based unicast address.

3.7.9 Multicast Addresses

As indicated in Table  3.11, a multicast address begins with eight ones set (hex FF). This address is used in IPv6 to identify a group of nodes, with the term node used to indicate a device that supports the new version of the Internet Protocol and which replaces the term

Figure 3.25 IPv6 provider-based unicast address structure.

interface used under IPv4. A node can belong to any number of mul-ticast groups that allow the device to participate in multiple multi-cast sessions.

Figure 3.26 illustrates the IPv6 multicast address format. Note that after the first eight set bits the next four bits represent a set of flag bits. The first three flag bits are currently set to zero, while the fourth bit is used to indicate a permanently assigned (0) or tran-sient (1) multicast address. The next field consists of 4 bits, which indicates the scope of the address. Here the Scope field denotes the portion of the network for which the multicast is relevant, in effect providing a mechanism to focus a multicast to a specific area. Scope values include node-local (0001), link-local (0010), site-local (0101), organization-local (1000), and global (1111). The remaining 112 bits in the 128-bit address represents a Group Identifier field, which identifies the multicast group for a permanent or transient applica-tion within a given scope.

3.7.10 Transporting IPv4 Addresses

In a mixed IPv4 and IPv6 environment communications devices that do not support IPv6 will have their addresses mapped using a special form of IPv6:

0:0:0:0:0:FFF:w.x.y.z

In the above format w.x.y.z represents the original 32-bit IPv4 address.

Thus an organization with a considerable investment in time and effort in configuring hundreds or thousands of workstations and servers can migrate to IPv6 yet only need to upgrade the organization’s router to support IPv6 addressing when it deploys the new version of IP. Then, if it wishes to do so, it can gradually convert existing IPv4 addresses to IPv6 addresses.

Figure 3.26 The IPv6 multicast address format.