Chapter 10. The IPv6 Header
Return Home
Chapter 10
The IPv6 Header
Introduction
Expanded Addressing
Simplified Header
Improved Support for Extension and Option
Flow and Flow Labeling
Authentication and Privacy
IPv6 Header
IPv4 Header
Extension Headers
Hop-by-Hop Option Header
Routing Header
Fragment Header
Authentication Header
Encapsulating Security Payload
Destination Options Header
Upper-Layer Protocol Issues
Summary
FAQs
References
Solutions in this chapter:
The changes from IPv4 to IPv6 and their implications on headers
Additional functionality in IPv6: flow labeling and security features
Formats of IPv6 header and extension headers and their usage
Implications of IPv6 on upper layer protocol
Introduction
The IPv4 has served us well in the past; however, some design decisions made a couple of decades ago have many shortcomings for supporting current and future networking. The IPv6 is the new IP protocol that is designed to meet the requirements for supporting future generation networking, while interoperating with the current IPv4.
With growing popularity of internetworking, it has become apparent that the number of nodes in the Internet will outgrow the 32-bit address space used in IPv4. Further, as the number of addressable nodes increases , the size of routing table is likely to grow. The larger routing table degrades the performance of IP network; this, and the shortage of address space are the primary concerns for continued use of IPv4.
These concerns raised the need for a new IP protocol, IPv6. In addition to solving these problems, several other features have been incorporated in the design of IPv6 to enhance the IP network.
The advances in hardware technology have resulted in the development of new applications, which may need special provisioning when deployed over the network. However, the connectionless, on-demand nature of IPv4 does not lend itself well for perconnection-based support. The design of IPv6 includes flow labeling for providing perconnection-based support.
For continued success of IP internetworking, the use of IP network should be plug-and-play, similar to the use of a telephone system. To achieve the plug-and-play concept in IP network, configuration of an IP node should be simple, if not automatic. Even with the continued autoconfiguration effort such as Dynamic Host Configuration Protocol, configuration of an IPv4 node has been nontrivial so far. The IPv6 has been designed to better support autoconfiguration of IPv6 nodes.
In recent years , the use of the Internet for many businesses has been increased drastically, and e-commerce has also gained popularity. It is necessary to implement security features in internetworking. The security features are mandatory in IPv6, making an IPv6 network more suitable for meeting security requirements.
Most importantly, the design of IPv6 has provided for the transition from IPv4 to IPv6. This transition cannot occur overnight; therefore, the IPv6 has been designed with the assumption that the IPv4 network will coexist with IPv6 network for a long time, if not indefinitely. Many design decisions are in place for interoperability with IPv4 nodes. A lot of investment has been made in the current infrastructure of IPv4 networks. Without the ability to communicate with existing network, no new protocol is likely to replace the current internetworking infrastructure successfully, regardless of its benefits.
The design of IPv6 has stemmed from limitations of what IPv4 offers, and from lessons learned in IPv4. First, this chapter covers the changes from IPv4 to IPv6. Expanded addressing, simplified header, improved extension and option support, flow labeling capability, and authentication and privacy capability summarize these changes. The first three changes are due to modifications to bases of IPv4 technology such as using 128-bit address size instead of 32-bit, not allowing intermediate routers to perform fragmentation, or embedding optional information in extension headers instead of including it in the IP header. The latter two changes include additional functionality incorporated into the design of IPv6 to satisfy the network support current and near-future applications demand.
This chapter also covers the format of the IPv6 header and extension header. The fields in the IPv6 header are discussed and compared to those in the IPv4 header. The formats of extension headers are provided, along with an example usage of each extension header.
Finally, upper-layer protocol issues imposed upon the use of IPv6 are covered.
Expanded Addressing
IPv4 uses 32-bit addresses, which potentially can address up to 2 32 nodes. However, the combination of network and local address hierarchy and reserved address space for special handling such as loopback and broadcast reduces the number of addressable nodes. At the same time, the exponential growth of computer networks in recent years indicates the outgrowth of addressable node using 32-bit addresses.
Furthermore, the network and local address hierarchy in IPv4 address architecture lead to inefficient use of address spaces. For instance, an organization that needs far fewer than 2 16 hosts , but more than 2 8 hosts, may waste much usable address space when a using 2-octet network address and a 2-octet local address.
Despite the inefficiency of network address hierarchy, a flat network address (e.g., a sequential address assignment) is not realistic, since network operations such as routing would be impossible . When using a sequential address assignment, the size of routing tables would be unmanageable and routing would become a slow process because of the amount of data that needs to be scanned.
The IPv6 address size has been increased to 128 bits. The advantages of this increase are, one, more addressable nodes, and two, the ability to support more levels of addressing hierarchy. Better addressing hierarchy leads to more efficient network operations and network scaling. As more networks are added, the size of the routing table increases, and the routing process takes longer. A careful planning of addressing hierarchy can limit the growth of the size of the routing table, while routing packets efficiently . An organizational change often means configuration changes at each node that is affected. For instance, when an organization obtains a new Internet Service Provider (most often network address change), each node in this organization must be reconfigured to reflect this. However, despite continuous efforts of developing autoconfiguration mechanisms such as Dynamic Host Configuration Protocol, the reconfiguration process often needs to be done manually. The larger address space can support autoconfiguration better. The autoconfiguration process in IPv6 is described in [ 0 ].
In addition to increased address size, IPv6 eliminated broadcast address and added the notion of anycast address, which can be used to send a packet to any one of a group of nodes.
Simplified Header
IPv6 has evolved from the IPv4 technology; experiences learned from the IPv4 are reflected in the design of IPv6. The length of the IPv4 header varies between 20 and 60 bytes, and there are 11 fields within the first 20 bytes of the IPv4 header. The complexity of IPv4 can lead to inefficient router operations. By employing a simpler header, 8 fields in 40 bytes and fixed length of the header, IPv6 can enhance the performance of routers.
A couple of fields in the IPv4 header have been either removed or embedded in extension headers. Since options are embedded in extension headers, the length of the IPv6 header is no longer variable, thus eliminating the need for the Header Length field in the IPv6 header. In IPv6, only source node can perform fragmentation; therefore, the information necessary for fragmentation and reassembly is removed from IP header. Since the upper layer protocol such as TCP and UDP calculates the checksum for the entire packet, the Checksum field also can be removed from the IP header.
Improved Support for Extension and Option
Since the total length of the IPv4 header is variable, the Header Length field is used to indicate its length. The number of bits in this field, 4 bits, determines the maximum length of the IPv4 header. In particular, 60 bytes is the largest size of the IPv4 header, for this field specifies the header length in 4-octet units. Since the fixed portion of the IPv4 header is 20 bytes long, it places a stringent requirement on the length of options.
For Managers Only
Length of Addressing Options in IPv4
This limit on the length of options has eliminated some options (such as the routing option), because they are ineffective in IPv4 network.
Aside from the limit on their length, options are examined at every router on the path , when included. However, often these options are information applicable only to the destination node. Including such options in the IPv4 header forces each router on the path to examine the packet, thus leading to inefficient router operations.
By embedding options in extension headers, the option length limit has been relaxed greatly, and options can be used more effectively in IPv6. Use of a proper extension header in IPv6 allows a packet to carry optional information that is applicable only to its destination node as well as to all intermediate routers more efficiently. The proper extension also allows hardware memory lookups, since the headers are fixed.
Flow and Flow Labeling
IPv4 was designed to be connectionless (or stateless); in other words, each packet belonging to the same session is routed independently, and two packets from the same session may arrive at the destination via different paths.
This approach works well under error-prone networks, such as the time when IPv4 was being developed. There is a cost associated with this, howeverprocessing each packet at every hop adds to the delay, and it is not trivial to provide special services for a communication between selected source and destination.
With technological advances in networking, network failures, especially hardware failures, have been drastically reduced in recent years. Also, new applications are more tolerant to errors, but more sensitive to fluctuations in delay. It is inevitable that networks support such applications. In the design of IPv6, the notion of a flow has been incorporated in order to facilitate special handling of data belonging to an application with special requirements.
RFC 1883 defines a flow as a sequence of packets sent from a particular source to a particular destination for which the source desires special handling by the intervening routers. IPv6 provides a framework for an easier per-flow handling. A video application, which may have strict requirements on the maximum delay difference, may take advantage of flow and flow labeling in IPv6. The application marks each packet with a flow label, and routers on the path remember the state of packet transmissions on this flow. This state information will help a router to determine which packet to service next. A router may service a packet that has the largest elapse time since its previous packet in the flow, for instance.
Authentication and Privacy
No real security features have been incorporated into the design of IPv4. However, the wide use of IP networks by the general public has led to the use of computer networks as a means of conducting various kinds of businesses. Thus, it is natural for the design of IPv6 to provide necessary security measures. Reference [2] defines the security architecture for the IP network, and IPv6 uses the Authentication Header and Encapsulating Security Payload extension headers to implement such features.
Both Authentication Header and Encapsulating Security Payload header can be used alone, or as a combination of source and destination or two security gateways. The former mode of operation is called transport mode and the latter is referred to as tunneling mode operation.
When used in transport mode, the source and destination of a packet is the sender and receiver of the Authentication Header, respectively. When used in tunneling mode, however, the security gateway at the source of a packet would be the sender of the Authentication Header, and the security gateway at the destination of this packet would be the receiver of the Authentication Header.
The sender calculates secure and reliable checksum (message digest) calculation over packets and places it in the Authentication Header. The receiver recalculates it and compares it to the value provided in Authentication Header. When these values differ , a packet is assumed to be damaged during transmission.
Using Encapsulating Security Payload, a payload of a packet may be encrypted, or the entire IP packet may be encrypted in tunnel mode via security gateways. When encrypted in tunnel mode, real source and destination and some IP header information can be hidden, thus making it more secure.
IPv6 Header
The IPv6 header is fixed in length and aligned at 8-octet boundary, unlike the IPv4 header, which is variable length and aligned at 4-octet boundary. Most modern computer architectures are optimized to read 8 octets at a time. Thus, the length of the IPv6 header or extension headers is designed to be a multiple of 8-octets for 8-octet alignment. With a fixed IPv6 header, a router can efficiently process a packet. For instance, a router must decide if there are any options in an IPv4 packet by reading the Header Length field. Processing a variable length header leads to inefficient router implementation.
The changes from the IPv4 header and IPv6 header will be covered in the subsequent section. In this section, each field in the IPv6 header and its intended role is described. Figure 10.1 shows the format of an IPv6 header.
Figure 10. 1 IPv6 header.
The IPv6 header stores the information necessary to route and deliver packets to their destination. The headers are processed by each node along the path. The first 4-bit field, version, indicates the version of the Internet Protocol being used, and its value is 6 for IPv6. This field is necessary because it allows both protocols to coexist on the same segment without conflicts. The next two fields, traffic class and flow label, are used to provide differentiated services and support applications requiring special handling per-flow. The 8-bit traffic class field can be used to provide differentiated services based on the nature of data being transmitted. This field is similar to the intended use of the type of service field in the IPv4 header. For instance, an organization may set up its network to prioritize network traffic based on applications, source and destination information, etc., and hosts and/or routers use the traffic class field to differentiate the priority. The values and the exact use of this field are yet to be determined. The flow label in combination with source and destination addresses can uniquely identify a flow that requires special handling by intermediate routers. When a router identifies a flow the first time, it remembers the flow and any special handling this flow requires. Once per-flow handling has been set up, the processing of subsequent packets belonging to this flow can be shorter than processing individual packets. The 16-bit payload length field, similar to the total length field in the IPv4 header, indicates the length of the packet, not including the length of the IPv6 header. The 8-bit next header field is used to indicate the next header following the IPv6 header. The intended use of this field is identical to the use of the protocol field in the IPv4 header. The hop limit can be used to limit the number of intermediate hops a packet is allowed to visit, which can prevent packets from being circularly routed in a network. In IPv4, the time to live field has been used to prevent packets from being routed circularly. The name of this field has been chosen to reflect accurately the purpose of this field. As in IPv4 headers, IPv6 headers contain source and destination IP addresses. Unlike IPv4 nodes, IPv6 nodes use 128-bit addresses.
IPv4 Header
Figure 10.2 illustrates the format of an IPv4 header.
Figure 10.2 IPv4 header.
The first 4-bit version field in the IPv4 header is used to indicate the current version of the Internet Protocol (IP) being used. The same field is used in the IPv6 header and is necessary in order to make IPv6 backward compatible.
The 4-bit header length field is necessary for the IPv4 header to indicate the length of the header since the total length of the IPv4 header is a variable length between 20 and 64 bytes, depending on the presence and the length of options in the option field. However, this field is not necessary in an IPv6 header, because an IPv6 header is a fixed length of 40 bytes.
The intent of this type of service field in IPv4 is similar to the traffic class field in the IPv6 header. Nevertheless, this field has not been widely accepted and used in IPv4 implementations .
Next, two fields in the IPv4 header, flags and fragmentation offset, are all related to the handling of fragmentation and the reassembly of packets in IPv4. In IPv4, an intermediate hop may further fragment a packet when the maximum transfer unit (MTU) on the outgoing link is smaller than the size of the packet that is to be transmitted on that link. Unlike IPv4, in IPv6, fragmentation processing takes place only at the source node, using a path MTU. Further, information related to fragmentation is encoded in the Fragmentation header as an extension header in a IPv6 packet. Therefore, identification, flags, and fragmentation offset fields are not necessary in the IPv6 header.
In the original design of IPv4, the time to live field is used to indicate the number of seconds to live in a network, thus preventing packets from being circularly routed, if a circular route exists in a network. However, in implementations, this field is used to limit the number of hops the packet is allowed to visit. At each hop, a router decrements this field, and when this field reaches 0, the packet is removed from the network. In IPv6, this field is renamed to hop limit, a more accurate description of the implementation.
The protocol field, which is used to indicate the next protocol (header) following this IPv4 header, is similar to the Next Header field in the IPv6 header.
The header checksum field is used to maintain the integrity of the IPv4 header. However, the higher layer calculates the checksum again for the entire packet, thus making this field redundant. Therefore, this field is not used in IPv6 header. If applications require a higher degree of integrity, they can achieve it through appropriate use of Authentication Header and Encapsulating Security Payload extension headers.
The source and destination fields in the IPv4 header remain the same in the IPv6, except that the IPv4 node addresses are 32 bits, and the IPv6 node addresses are 128 bits.
The use of options in IPv4 implies that each intermediate node in the path needs to examine the option field in the IPv4 header, although the options may be pertinent only to the destination node. This leads to inefficient router performance when options are used. In IPv6, optional information is encoded in extension headers.
Extension Headers
Extension headers, placed between the IPv6 header and the upper layer protocol header, such as a TCP-header, are used to carry optional Internet-layer information in a packet. An IPv6 packet may carry zero, one, or more extension headers. The Next Header field in the IPv6 header and extension headers is used to indicate which extension header or upper layer protocol header follows the current header.
For IT Professionals Only
Next Header Values and Corresponding Headers
Table 10.1 provides the Next Header value and the corresponding headers. Except for the Hop-by-Hop Options header, the Next Header value appears in the immediately preceding header. When the Hop-by-Hop Options header is used, it must follow immediately after the IPv6 header. Therefore, the Next Header value of 0 can appear only in IPv6 header.
| Next Header Value | Next Header |
| 0 | Hop-by-Hop Options header |
| 4 | Internet Protocol |
| 6 | Transmission Control Protocol |
| 17 | User Datagram Protocol |
| 43 | Routing header |
| 44 | Fragment header |
| 45 | Inter Domain Routing Protocol |
| 46 | Resource Reservation Protocol |
| 50 | Encapsulating Security Payload |
| 51 | Authentication header |
| 58 | Internet Control Message Protocol |
| 59 | No next header |
| 60 | Destination Options header |
Table 10.1 Next Value Headers
When a TCP header immediately follows an IPv6 header without an extension header, the value of the Next Header field in the IPv6 header indicates that the following header is a TCP header. When a packet using TCP as its upper layer protocol carries one extension header, Routing header, this extension header is placed between the IPv6 header and the TCP header. The Next Header field in the IPv6 header indicates that the Routing header follows the IPv6 header and the Next Header field in the Routing header indicates that the TCP header immediately follows the Routing header. The Next Header value of 59 indicates that there is no extension or upper layer protocol header following the current header.
A full implementation of IPv6 includes the following extension headers: Hop-by-Hop Options, Routing (Type 0), Fragment, Destination Options, Authentication, and Encapsulating Security Payload. The recommended ordering of extension headers, when multiple extension headers are present in a packet, is as follows:
IPv6 header
Hop-by-Hop Options header
Destination Options header (to be processed by all destination nodes appearing in the routing header)
Routing header
Fragment header
Authentication header
Encapsulating Security Payload header
Destination Options header (to be processed only by the final destination of the packet)
Upper-layer header
Except for the Destination Options header, each extension header should appear at most once in a packet. The Destination Options header contains information to be processed by the final destination node. When the Routing header is present, an additional Destination Options header may be used for options to be processed by all nodes listed in the Routing header; in this case, there will be at most two occurrences of Destination Options headers in an IPv6 packet.
When an IPv4 packet carries an option that is applicable only to its destination node, all intermediate nodes must examine and process the packet before forwarding, thus impacting the performance of the forwarding nodes.
For Managers Only
Should Options Be Used in IPv4 Networks?
Most often, routers are implemented in a way that packets containing options are often handled after handling packets without options. Therefore, the use of options is discouraged in IPv4 networks.
Except for the Hop-by-Hop Options header, extension headers are examined or processed only by the destination node (or nodes, in the case of multicast) of the packet. Thus, an IPv6 packet may carry optional information applicable only to its destination node, without impacting the performance of all intermediate nodes. The Hop-by-Hop Options header can be used to carry optional information that needs to be examined or processed at all intermediate nodes.
The value of the Next Header field in the current header determines the next action to be taken, and the semantics of current extension header determines whether to continue processing the next header. Thus, extension headers must be examined in the order they appear in a packet. A node discards a packet and sends an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of one, unrecognized Next Header type encountered , when it receives unrecognized Next Header value in a packet. Because the Hop-by-Hop Options header must immediately follow the IPv6 header, the Next Header value of zero in any header other than IPv6 header is treated as a packet with unrecognized Next Header value.
Currently, the Hop-by-Hop Options header and the Destination Options header carry a variable number of options, encoded in Type-Length-Value (TLV) format, as seen in Figure 10.3.
Figure 10.3 TLV-encoded option format.
The Option Type identifiers are encoded in such a way that the highest-order two bits specify the action to be taken when the processing node does not recognize the Option Type, and the third-highest bit specifies whether or not the Option Data of that option can change en route to the packets final destination. For instance, when a node encounters an unknown option type value of 130 (1000 0010), the highest-order two bits indicate that the node must discard the packet and send an ICMP Parameter Problem, Code 2, message to the source of the packet. Table 10.2 describes the encoding of Option Type and its meaning for handling unrecognized Option Type.
| Highest-order two bits | Action to be taken |
| 00 | Skip over this option and continue processing the header. |
| 01 | Discard the packet. |
| 10 | Discard the packet and, regardless of whether or not the packets Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packets Source Address, pointing to the unrecognized Option Type. |
| 11 | Discard the packet, and only if the packets Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packets Source Address, pointing to the unrecognized Option Type. |
Table 1 0.2 Option Type Encoding
Some Option Type values may change as the packet progresses through the route to its destination. The third highest-order bit of the Option Type is used to indicate if its data value can be changed en-route or not. The third highest-order bit is 0 when Option Data does not change en-route and 1 when it may change. When the Authentication header is used, the source of the packet computes the authenticating value over the packet and places in the Authentication header. For Option Type whose Option Data may change en route, the Option Data is treated as zero-valued octets when computing the packets authenticating value.
As stated before, extension headers are designed to be a multiple of 8-octets in length. To ensure that the end of the Option Data field is aligned with the 8-octet boundary, specific Option Types may be associated with alignment requirements in the form of xn+y, indicating that the Option Type must appear at an integer multiple of x octets from the start of the header, plus y octets. For instance, a 4n+2 alignment requirement indicates that the Option Type must start at any 4-octet offset from the start of the header, plus 2 octets, such as 2, 6, 10, 14, etc.
Two padding options, Pad1 option and PadN option, may be used to make headers containing options to be multiples of 8 octets in length. The Pad1 option, one zero-valued octet, is used to insert one octet of padding, and the PadN option is used to insert more than one octet of padding. The format of the PadN option is shown in Figure 10.4. To insert 2 octets of padding, Pad2, one octet with the value of 1 and one octet (Option Data Length field) with the value of 0 can be used. The Pad2 option is a special case in that there is no Option Data, or Option Data of 0 length is used.
Figure 10.4 PadN Option format.
Hop-by-Hop Option Header
The Hop-by-Hop Options header, identified by a Next Header value of zero in the Ipv6 header, carries optional information that must be processed by every node along a packets delivery path. For instance, it may be necessary for a router to examine and process a packet containing control messages for new protocols, such as RSVP. The use of the Hop-by-Hop Options header allows routers to examine selectively packets for special handling, if necessary. The format of the Hop-by-Hop Option header is shown in Figure 10.5. Note that the Header Extension Length field is the length of the Hop-by-Hop Options header, in 8-octet units, not including the first 8 octets. In other words, when the length of TLV encoded option(s) is less than or equal to 6 octets, the Header Extension Length field is zero. Examples of Hop-by-Hop Options include Router Alert Option and Jumbo Payload Option.
Figure 10.5 Hop-by-Hop Options header.
A call set-up control message using RSVP protocol needs special provisioning at each router along the path of the connection. Using the Router Alert Hop-by-Hop option, routers can provide special handling. Processing of a Hop-by-Hop option may result in processing of an upper layer protocol such as RSVP.
The Option Type of the Router Alert option is 5 (00000101), indicating that nodes not recognizing this option should skip it and continue processing the header, and Option Data must not change its value en route. The Option Length of Router Alert option is 2; thus, the valid range of Option Data is between 0 and 65535. Currently, only 0, 1, and 2 have been defined to indicate a packet containing ICMPv6 Group Membership message, RSVP message, and Active Network message, respectively. No alignment requirement has been associated with this option.
Figure 10.6(a) illustrates a packet containing a Router Alert Hop-by-Hop Option. The value of the Next Header field in IPv6 header is 0, indicating that Hop-by-Hop Options header follows. All nodes in the path of this packet are to examine and process this packet. The Next Header field of the Hop-by-Hop Options header indicates the next header following this Hop-by-Hop headerTCP header in this example packet. The Extension Header Length field is 0 since there is only one option, Router Alter option, and the total length of TLV encoding of this option is 4 octets. Since there is no alignment requirement associated with this option, its TLV encoded option is placed first and Pad2 Option is used to make the length of this Hop-by-Hop Options header to be exactly 8 octets.
The IPv6 header uses the 16-bit Payload Length field, which limits the maximum length of a packet to 65536. However, the advances in hardware enabled the transmission of a jumbogram, a packet with payload larger than 65536 octets. This option supports jumbograms up to 4,294,967,296 octets. When path MTU can support payloads larger than 65535, this option may be used to transmit jumbograms.
The Option Type of Jumbo Payload Option is 192 (1100 0010), indicating that nodes not recognizing this option type must discard this packet and send an ICMP, Parameter Problem, Code 2, message to its sender only if the destination is not a multicast, and Option Data must not change en route. The Option Length field of this option is 4 octets, and the Option Data is the length of the IPv6 jumbogram, not including the IPv6 header. When this option is used, the Payload Length field in IPv6 is set to 0. This option has an alignment requirement of 4n+2.
Figure 10.6(b) illustrates a packet with Jumbo Payload Hop-by-Hop option. The Next Header field in the IPv6 header indicates that the Hop-by-Hop Options header follows. Note that the Payload Length field in IPv6 header is set to 0 in this sample packet. The Next Header field in this Hop-by-Hop options header indicates that the next header is TCP header. The Extension Header field is 0 because the total length of TLV encoded Jumbo Payload option is 6 octets. The value in Option Data of this packet indicates that the payload of this packet is 2,818,048 octets (0x002A FFFF). Since the end of Option Data is aligned with 8-octet boundary, no padding option is necessary in this sample packet.
Processing of a Jumbo Payload option must detect several format errors and send an appropriate ICMP Parameter Problem message. These format errors include the absence of the Jumbo Payload option when the IPv6 Payload is 0 and the IPv6 Next Header is 0, the use of the Jumbo Payload option when the IPv6 Payload is not 0, use of the Jumbo Payload option when actual payload is less than 65,535, and the use of the Jumbo Payload option when the Fragment Header is present.
For Managers Only
The Fragment header uses the 13-bit Fragment Offset field, in 8-octet units, to indicate the offset of the fragmented data, relative to the original packet. In other words, the maximum offset can be the 65536 th octet. Therefore, it makes little or no sense to use the Jumbo Payload option and Fragment header at the same time.
Figure 10.6 Packets with the Hop-by-Hop Options header.
Routing Header
The Routing Header, identified by a Next Header value of 43 in the immediately proceeding header, allows an IPv6 source to determine routes to reach its destination by listing one or more intermediate nodes to be visited (very similar to IPv4s Loose Source and Record Route option). The format of the Routing Header is shown in Figure 10.7.
Figure 10.7 Routing header.
When a node encounters an unrecognized Routing Type, and Segment Left is zero, it ignores the Routing header and continues to process the next header. However, if Segment Left is nonzero, a node discards the packet and sends an ICMP Parameter Problem, Code 0, message to the packets Source Address. Currently, only Type 0 has been defined, and Figure 10.8 shows the format of Type 0 Routing header.
Figure 10.8 Type 0 Routing header.
An example of Type 0 Routing header use is in supporting new protocols such as RSVP. In RSVP, a connection path may be established, and all packets belonging to the connection follow the same path to reach the destination. Then the source of this connection may use a Type 0 Routing header to specify the path to its destination.
Another use of a Routing header is to communicate with a mobile node away from its home network without triangle routing. Without Route Optimization [ 0 ], which may or may not be supported, packets may have to be sent to the mobile nodes home network and be forwarded by the home agent, creating triangle routing, when a mobile node is away from its home network. The source of such a connection can specify the path using a Type 0 Routing header to allow the source of a connection to specify its path and avoid triangle routing.
For the connection between source node s and destination node d via routers r1 and r2, source node s creates an IPv6 packet with the routing header, as shown in Figure 10.9(a). Notice that the destination field is r1, the first router in the path, instead of the final destination node d. Recall that except for the Hop-by-Hop Options header, all other extension headers are examined only by the packets destination node. Since router r1 is the destination of this packet, after examining the IPv6 header, it continues to process the next header as indicated by the Next Header field in the IPv6 header. In this case, the Routing header will be processed by router r1.
The Extension Header Length field is 4, indicating that the length of the Routing header is four 8-octets, not counting the first eight octets. The value 4 is also twice the number of addresses (2 as indicated in the Segments Left field) in this Routing header. The first address in the Routing header is the next router in the path, r2, followed by the final destination node d.
Router r1 decrements the Segments Left field and swaps the values in the destination field in the IPv6 header and the first address in the Routing header. Figure 10.9(b) shows the packet sent from router r1 to router r2. Similarly, after examining the IPv6 header, router r2 continues to process the Routing header, since the destination field of the IPv6 is r2. Again, router r2 decrements the Segment Left field and swaps the values in the destination field in the IPv6 header and the second address in the Routing header. When processing the Routing header, the index of the address to visit can be computed using the Header Extension Length and the Segment Left fields (the Header Extension Length/2 the Segment Left + 1). When the Segment Left is 0, the node handling this Routing header proceeds to process the next header in the packet, whose type is identified in the Next Header field in the Routing header.
When processing the Type 0 Routing header, format checking is performed. Recall that the Header Extension length is two times the number of addresses in the Routing header. Thus, the Header Extension length must not be an odd length. A node processing this packet discards the packet and sends an ICMP Parameter Problem, Code 0, message to the source node. Since the Header Extension length is two times the number of addresses in the Routing header, the largest value in the Segment Left field is at most half of the Header Extension length. If the Segment Left is larger than the half of the Header Extension length, the node handling the packet also discards this packet and sends an ICMP Parameter Problem, Code 0, message to the source.
For IT Professionals Only
The Type 0 Routing header is processed by all nodes appearing in the address field, and each node decrements Segment Left field and swaps the values in the destination field in the IPv6 node and the address. Thus, multicast addresses must not appear in the address in the Type 0 Routing header or in the IPv6 destination field of a packet containing the Routing header.
Figure 10.9 Packets with a Routing header.
Fragment Header
The 16-bit Total Length field in the IPv4 header limits the maximum size of a packet to be 64k bytes. However, depending on the link technology used, the actual size of a packet may be further limited. In IPv4 packet transmission, each IP-layer is responsible for fragmenting packets if necessary to ensure that the packet size would not exceed the Maximum Transfer Unit (MTU). Thus, the user data sent in a single packet from a source node may arrive at the destination node in multiple packets if there is a link whose MTU is smaller than the link MTU at the source node. This approach, however, may not be the most optimal solution for the path.
For IT Professionals Only
Consider an application that transfers a segment of 3000 bytes at a regular interval, where the link MTU at the source is 3000 bytes. The next link MTU is 1500 bytes; thus, a packet is fragmented into two packets of 1500 bytes each. However, the following link MTU is 1000 bytes. Then each of 1500-byte packets will be further fragmented into two packets, 1000 bytes and 500 bytes. If the path MTU had been known at the source, the source node would have fragmented 3000 bytes in three packets. The overhead involved in transmission of 3000 bytes is 20 bytes, IP header alone without options. The overhead is higher when upper-layer protocol header overhead is considered .
In IPv6, only source nodes perform fragmentation. A source node first finds the path MTU and then segments the fragmentable part of the original packet so that the length of each fragmented packet does not exceed the path MTU. The original packet before fragmentation consists of two parts : the unfragmentable part and fragmentable part. The IPv6 header and any extension headers that need to be processed at each hop on the way to the destination are unfragmentable, and extension headers processed only by the final destination node (or nodes in the case of multicast) are considered to be fragmentable.
When Hop-by-Hop Options header is present, but not the Routing header, the unfragmentable part of the original packet includes the IPv6 header and the Hop-by-Hop Options header. When the Routing header is present, the unfragmentable part includes the IPv6 header, the Hop-by-Hop Options header, the Destination Options header, and the Routing header, if the Hop-by-Hop Options header and Destination Options header are present.
The Fragmentation header is identified by the Next Header value of 44 in the immediately preceding header. Figure 10.10 shows the format of the Fragmentation header. The source node generates a unique 32-bit identifier for every fragmented packet sent to the same destination. Except for the last fragmented packet, the fragmentable part of the original packet is divided so that each fragmented part is of length integer multiples of 8 octets long. The Fragment Offset field is used to indicate the offset of the data following this Fragmentation header, relative to the start of the Fragmentable part of the original packet.
For Managers Only
Fragmentation, in general, involves high overhead, thus the use of fragmentation should be discouraged. Links with configurable MTU (e.g., PPP links) should configure their MTU to at least 1280 octets or greater, which is the required MTU in IPv6.
Figure 10.10 Fragmentation header.
Consider the packet shown in Figure 10.11(a). This packet needs to be further fragmented by the source node since its path MTU is 1514 bytes. The unfragmentable part of the original packet in the example includes the IPv6 header and the Routing header (the Next Header of the IPv6 is 43). The original packet is broken into three parts. Since the Ethernet header is 14 bytes, the IPv6 packet including the IPv6 header cannot be longer than 1500 bytes. Since the Routing header is part of the unfragmented part, each fragment includes the Routing header. Further, the Fragmentation header (8 octets) is added, leaving 1412 bytes for user data. However, the Fragmentation Offset field in the Fragmentation header is in an 8-octet unit. Therefore, the maximum size of the fragmentable part of the original packet is limited to 1408. This explains 1456 in the Payload length field in the IPv6 of the first fragmentation as shown in Figure 10.11(b).
The Next Header fields in the Routing header in all three fragments (Figure 10.11(b), (c), and (d)) are 44, indicating that the next header following this Routing header is the Fragmentation header. The Next Header field in the first fragment is 6, indicating that the upper layer protocol header follows this Fragmentation header. However, the Next Header fields in the other two fragments are 59, indicating that there are no more headers following this Fragmentation header. In this example, the hexadecimal of 0x12345678 is used to indicate that the same identifier is used for all fragments . The Fragmentation Offset field is used to indicate the offset, in 8-octet units, of the data following the Fragmentation header, relative to the start of the fragmentable part of the original packet. Thus, the Fragmentation offset in Figure 10.11(c) indicates that the data following this Fragmentation header should be positioned in the 176x8 th byte in the fragmentable part when reassembled at the destination node.
Figure 10.11 Example of fragmentation.
Authentication Header
In an IP network (both IPv4 and IPv6), the Authentication header is used to provide integrity and data origin authentication for IP packets and to protect against replays. However, in this section, all terms are provided based on IPv6 network. The Authentication Header provides authentication for IPv6 header and extension headers fields that may not change en route. For instance, the Destination Address field in the IPv6 header changes at every hop when the Type 0 Routing Header is used. In this case, the Authentication Header cannot provide the authentication of the Destination Address field. Figure 10.12 shows the format of the Authentication Header.
Figure 10.12 Authentication header.
Note that the Payload Length field is in a 4-octet unit (32-bit word), not including the first eight octets (or 2 units of 4-octet).
For Managers Only
All other IPv6 header extension length is encoded by subtracting 1 from the header length measured in 8-octet units.
Thus, with 96-bit Authentication Data value, the Payload Length will be 4. For debugging purposes, the Null authentication algorithm may be used. In this case, the Payload Length field will be 2.
The Sequence Number field is used to provide protection against antireplay . When a Security Association is established between source and destination nodes, counters at sender and receiver are both initialized to 0. It is mandatory for the sender to increment this field for every transmission; however, the receiver may elect not to process. This service is effective only if the receiver processes this field.
The Authentication Data field contains the Integrity Check Value (ICV) for this packet. The authentication algorithm, selected when the Security Association is established between the sender and the receiver, specifies the length of the ICV, the comparison rules, and the processing steps necessary. This is the value computed over the packet by the source node and verified by the destination node by comparing this value to the value recomputed at the destination node.
The Authentication header may be applied in transport or tunnel mode. The transport mode Authentication header, implemented in hosts, provides protection for the upper layer protocol header and any fields in the IPv6 header, and extension headers that do not change in transit. The tunnel mode Authentication header is applied to the original IPv6 packet, encapsulating the original packet by constructing a new IPv6 packet using a distinct IPv6 addresses, such as security gateway.
In transport mode, the Authentication header, viewed as an end-to-end payload, is placed after the IPv6 header and Hop-by-Hop, Routing, and Fragmentation extension headers. Recall that the Destination Options header may appear once before the Routing header, the options in the Destination Options header are applicable to intermediate nodes specified in the Routing header. In this case, the Authentication header comes after the Destination Options header as shown in Figure 10.13.
Figure 10.13 Header order with Authentication header in transport mode.
In tunnel mode, the Authentication Header is applied to the original IPv6 packet using distinct IPv6 addresses as communication end points (e.g., addresses of security gateways). A new IPv6 header is constructed with addresses of security gateways as source and destination addresses. Fragmentation processing may be necessary after applying the Authentication header. Thus, a newly constructed IPv6 packet may undergo further processing if necessary. Figure 10.14 shows the order of headers after applying Authentication header in tunnel mode.
Figure 10.14 Header order with Authentication header in tunnel mode.
Encapsulating Security Payload
The Encapsulating Security Payload header, used in transport mode or in tunnel mode, also provides security services in both IPv4 and IPv6 networks. The security services provided through the Encapsulating Security Payload include confidentiality, authentication (data origin authentication and connectionless integrity), an antireplay service, and limited traffic flow confidentiality. Implementation and options chosen at the time of Security Association establishment determine the security services provided.
As in the case of the antireplay service provided by the Authentication header, the source increments the Sequence Number; however, the destination node must check this field to enable the antireplay service. To provide traffic flow confidentiality service, true source and destination information should be hidden. Thus, this service requires that the Encapsulating Security Payload header be used in a tunnel mode.
Figure 10.15 shows the format of the Encapsulating Security Payload header. The Next Header value of 50 in the immediately preceding header indicates that the Encapsulating Security Payload header processing is necessary.
Figure 10.15 Encapsulating Security Payload header.
The mandatory Payload Data field contains encrypted data described by the Next Header field. The encryption algorithm used specifies the length and the location of the structure of the data within the Payload Data field. To fulfill the encryption algorithm requirement of the length of the plain text or the 4-octet boundary alignment of the Payload Data field, the use of padding may be necessary.
Figure 10.16 Header order with Encapsulating Security Payload in transport mode.
Figure 10.17 Header order with Encapsulating Security Payload in tunnel mode.
Figures 10.16 and 10.17 illustrate the sequence of an IPv6 packet with its encrypted portion when Encapsulating Security Payload headers are used in transport mode and tunnel mode, respectively.
Destination Options Header
A source node may need to convey optional information that needs to be processed by a destination node. For instance, when a mobile node is away from its home network, a home agent (i.e., a router at the home network) may be a proxy forwarding packets to the mobile node. A mobile node away from its home network needs to send control messages to its home agent so that the home agent could set up the proxy service and forwarding packets destined for the mobile node at its current address. An IPv4 network, a packet when containing options in the IPv4 header, will be subject to an examination at every hop on the path.
In an IPv6 network, such optional messages can be handled efficiently either using an extension header dedicated for handling specific optional information or using the Destination Options header. Packet fragmentation or authentication information is handled as an extension header as shown previously. The IPv6 Mobility Support Internet-Draft [ 0 ] proposes four Destination Options to support Mobile IPv6.
The optional information may be encoded either in a separate extension header or in the Destination Options header, based on the desired action to be taken at the destination node, when the node does not recognize the option. Optional information that requires a few octets whose desired action is to send an ICMP Unrecognized Type message to the sender only if the destination node is not a multicast address, may be encoded in a separate extension header.
The Destination Options header, identified by a Next Header value of 60 in the immediately preceding header, carries optional information that needs to be examined and processed only by a packets destination node (nodes, in multicast). The format is shown in Figure 10.18.
Figure 10.18 Destination Options header.
Upper-Layer Protocol Issues
The layered architecture in general shields the upper layer protocols from changes in the network layers . However, a couple of issues need to be addressed. For instance, upper layer protocols that compute checksums over packets must account for changes in IPv6 including use of 128-bit addresses and final destination, not intermediate destinations when the Routing header is used, and so forth.
It has been discussed that the time-to-live field, which behaves differently than its original definition, has been renamed to hop limit. Any upper layer protocol that relies on the original meaning of the time-to-live may have to make necessary adjustments. The maximum upper layer payload size also needs to be adjusted to reflect that the length of the IPv6 header is 40 bytes long.
Summary
In all aspects of IPv6 design, the limitations imposed upon the design of IPv4 have been resolved or improved, the inefficiency in IPv4 has been eliminated, and the additional capabilities have been added to make IPv6 suitable for next-generation IPs.
IPv6 uses 128-bit addresses, providing a greater number of addressable nodes, better support for stateless autoconfiguration, and a better address hierarchy, which in turn leads to better routing. Embedding optional information in extension heads allows efficient router implementations while being able to handle optional information directed to routers. The use of extension headers to carry optional information fixed the IPv6 header length. Combined with the Fragmentation At Source Only policy simplified the IPv6 header, thus increasing the efficiency of routers. The limit on options has been relaxed, and it is much easier to add new options using extension headers.
Further, the design of IPv6 incorporated the concept of flow, and flow labeling along with the source and the final destination information help routers maintain the state information of the flow for special handling, if necessary. The security and privacy features are built into the design of IPv6.
FAQs
Q: Where are good resources for obtaining more information on IPv6?
A: There are many sites on the net. However, these two sites can be a good starting point:
http://www.ietf.org/html. charters /ipngwg-charter.html
http:// playground.sun.com/pub/ipng/html/ipng-main.html
Q: What is the core set of RFCs specifying IPv6 header and extension headers?
A: Most of information in this chapter is based on the following RFCs. Newer RFCs may render these RFCs obsolete:
RFC2460IPv6, Hop-by-Hop Options, Routing, Fragment, and Destination Options
RFC2402IP Authentication Header
RFC2406IP Encapsulating Security Payload Header
Q: What is the implementation status?
A: It is being developed for many host systems and routers including 3Com, Cisco Systems, Digital, IBM. http:// playground.sun.com/pub/ipng/html/ipng-main.html site also has information and links providing the details.
References
[1] S. Thompson and T. Narten. IPv6 Stateless Address Autoconfiguration, RFC 2462, December 1998 .
[2] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol, RFC2401 .
[3] C. Perkins and D. Johnson. Route Optimization in Mobile IP, Internet draft, draft-ieft-mobileip-optim-07.txt, November 1997. Work in progress .
[4] S. Kent and R. Atkinson. IP Authentication Header, RFC2402.
EAN: N/A
Pages: 15