Chapter 7: IPv6 Headers

Introduction

Information sent over the network is divided into pieces referred to as packets or datagrams. The datagram or packet itself is used for resource sharing, error detection and correction, and a vehicle for transporting data. A datagram consists of a stream of bytes. The particular protocol in use defines the type of content, the format of the datagram, and the semantics of their use. Another frequent use of packets is for error detection and correction based on checksums.

Datagrams usually consist of a header and data. The protocol defines the sequence of information in the header as well as other actions that might be required. Typically, a header includes such things as the version of the protocol in use, information about the source and destination address, the length or total size of the datagram, and data.

Depending on the protocol in use, the header could contain entirely different information or many more pieces of information. The data could be raw data such as a text file or an e-mail message. The data equally could be contained within another packet that has its own format and specifications.

Packets can have a general or a specific use and a given protocol could support a number of different packet formats. Each protocol has a specific set of functions with which it is designed to deal. The IPv4 and IPv6 protocols within the TCP/IP protocol suite are no exception.

The advent of IPv6 introduces changes in the IP header fields and functions. The IPv6 simplified header format helps to reduce packet handling and bandwidth cost. IPv6, along with a simplified header, has a hierarchical address structure to allow rigorous route aggregation. The IPv6 address structure is considered to be large enough to meet the needs of the Internet for the foreseeable future

The way IPv6 handles option encoding improved performance and increase the flexibility of introducing new options in the future. Two added features of IPv6 include the introduction of:

• Traffic flow labeling
• Packet-level authentication and encryption
• Plug and play autoconfiguration.

This chapter briefly:

• Reviews IPv4 and the format of the IPv4 headers.
• Summarizes the major changes between IPv4 and IPv6.
• Introduces the IPv6 header format and describes the IPv6 header fields
• Summarizes the use of the 24-bit Flow Label field in the IPv6 header by a source to label those packets for which it requests special handling by IPv6 routers.
• Describes the priority field in the IPv6 header that enables a source to label the priority status for delivery of its packets.
• Discusses the IPv6 extension headers that contain optional internet-layer information. There are a number of IPv6 extension headers.
• Describes some IPv6 implementation issues revolving around the size of packets to be transmitted over the network.
• Identifies some upper layer protocol issues revolving around implementing the IPv6 protocol headers.

Quick review IPv4 headers

This section provides a brief review of IPv4 and IPv4 headers; RFC 791, "Internet Protocol" describes this protocol in detail. The IP protocol defines the functions for the delivery of packets from a source host to a destination host. Delivery of the packet can occur within a network or over many interconnected networks.

IP fragmentation

One of the functions that the IP protocol must deal with is fragmentation. Between the source and destination the IP packet can transverse multiple networks. The packet must fit within the frame size specific to each network. Fragmentation of an internet packet is necessary when it originates in a local net that allows a large packet size and must traverse a local net that limits packets to a smaller size to reach its destination.

Specific fields within the IPv4 header handle fragmentation so the datagram can conform to the requirements of the individual networks on its path to its destination. The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled.

When fragmenting a datagram, IP creates two or more new datagrams and copies the original IP header into each new datagram. The protocol then divides the data between the new datagrams on an 8 octet boundary, sets the length field and a more-fragments flag, and sends the new datagrams on their way.

IPv4 header format

shows the IPv4 header format. Each horizontal grouping of bits is called a word and is 32 bits wide.

First 32-bit word of the IPv4 header

The first 32-bit word contains four fields: Version, IHL, Type of Service, and Total length. The Version field identifies version of the IP in use and with IPv4 implementations is set to 4. This field uses 4-bits.

Internet Header Length (IHL) field contains the length of the internet header in 32-bit words. This field points to the beginning of the data. This field uses 4-bits.

The Type of Service field indicates the type of treatment of the datagram during its transmission through the Internet. list the possible values for this field. This field uses 8 bits.

The major choice is a three way tradeoff between low-delay, high-reliability, and high-throughput. The use of the Delay, Throughput, and Reliability indications can increase the cost of the service. If a network has a concern about precedence designators, it is the responsibility of that network to control the access to, and use of the precedence designations.

The Total Length field contains the length of the datagram, measured in octets. Hosts are expected to be able to accept datagrams only up to 576 octets although the IP specifies that the maximum length of the datagram can be 65,535 octets including internet header and data.

A datagram of this length is impractical for most hosts and networks. Therefore, it is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams. This field uses 16 bits.

Second 32-bit word of the IPv4 header

The second 32-bit word contains three fields: Identifier, Flags, and Fragment Offset. These fields all provide information that helps with the fragmentation and reassembly of datagrams.

The Identification field contains an identifying value assigned by the sender. This field is used as an aid to assembling the fragments of a datagram. The identification field distinguishes the fragments of one datagram from those of another. The identification field contains a value unique for the source-destination pair for the time the datagram is active in the internet system. This field uses 16 bits.

The flags field allows the setting of one of three flags that indicate how the fragmentation and reassembly process is to be handled. list the three control flags and indicates the function of each one. This field uses 3 bits.

The Fragment Offset field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The number of 8 octet blocks in the first portion is referred to a the NFB (for Number of Fragment Blocks).

When fragmentation of a datagram occurs:

• The protocol places the first portion of the data in the first new internet datagram, sets the total length field to the length of the first datagram, and sets the more-fragments flag is set to one. ). The first fragment has offset of zero.
• The protocol places the second portion of data in another internet datagram, sets the total length field to the length of the second datagram, and sets the more-fragments flag. The protocol then sets the fragment offset to the value of that field in the long datagram plus the number of fragment blocks in the long datagram.

NOTE: The first fragment has the fragment offset zero, and the last fragment has the more-fragments flag reset to zero.

Third 32-bit word of the IPv4 header

The third 32-bit word contains three fields: Time to live, Protocol, and Header checksum.

The Time to live (TTL) field contains a value indicating the maximum amount of time the datagram is allowed to remain in the internet system. The time to live can be measured either as router hops or in units of seconds. When this field contains the value zero, the datagram is destroyed. The TTL field is modified in internet header processing. Each module that process the internet header decreases the TTL by at least one. This field uses 8 bits.

The Protocol field indicates the next higher level protocol in use in the data portion of the internet datagram. shows some examples. This field uses 8 bits.

The Header checksum field contains a checksum on the header only. This value is recomputed and verified each time the internet header is processed because some of the header fields change such as the time to live field. The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. This field uses 16 bits.

Fourth and Fifth 32-bit word of the IPv4 header

The fourth and fifth 32-bit word of the IPv4 header contain the source and destination address respectively of the datagram. These addresses are the Internet layer addresses for the datagram. Depending on the protocol in use, this address could be an OSI Network layer address rather than an Internet layer address. These fields uses 32 bits each.

Sixth 32-bit word of the IPv4 header

The sixth 32-bit work field of the IPv4 header is optional. While the options must be implemented in all IP modules, they do not need to appear in datagrams. Note that some environments might require the presence of the security option in all datagrams. RFC 791 defines the internet options listed in.

The IPv6 Protocol

IPv6 is the successor to IP version 4. The major changes from IPv4 to IPv6 fall into the following categories: Expanded addressing capabilities as discussed in Chapter 6, simplified header formatting, improved support for extensions and options, and addition of flow labeling as discussed in this chapter, and the inclusion of IP security features as discussed in Chapters 12 and 13.

The IPv6 simplified header format helps to reduce packet handling and bandwidth cost. Indeed, some IPv4 header fields have been dropped or made optional. This helps to keep the bandwidth overhead of the IPv6 header as low as possible. Even though the IPv6 addresses are four time longer than the IPv4 addresses, the IPv6 header is only twice the size of the IPv4 header.

The IPv6 protocol changes the encoding method for IP header options and provides greater flexibility for introducing new options in the future. IPv6 options are in separate headers in the packet between the IPv6 header and the transport-layer header.

IPv6 also adds flow labeling to enable the labeling of packets belonging to particular traffic flows. A sender can request special handling of packets such as real-time service. Flow labeling identifies the particular traffic flow for which the sender requests special handling.

IPv6 Header Format

The IPV6 header is approximately twice the size of an IPV4 header although the IPV6 address space is significantly larger than version 4. shows a view of the IPv6 header fields. This header, a simplified version of the IPv4 header, helps to keep the processing cost of packet handling as low as possible.

The IPV6 designers relocated some of the IPv4 header field in the in extension headers and dropped some other IPv4 header fields. The relocated or dropped header fields include the Internet Header length field, the Identifier field, Flags field, Fragment offset field, Header checksum fields, and Options and padding field.

The IPv6 header has two new fields, the Priority field and the Flow label field.

The Version field identifies version of the IP in use and with IPv6 implementations is set to 6. This field uses 4bits.

The Priority field contains a value that identifies the priority level for delivering packets. A value from 0 through 7 8 represent the priority level for congestion-controlled traffic that you are most willing to loose, such as high-fidelity video traffic. Use values eight through 15 for non-congestion-controlled traffic such as voice and video that you do not want to loose such as low-fidelity audio traffic. The priority field is described in more detail further on in this chapter. This field uses 4 bits.

The Flow Label field allows a source to label a sequence of packets for which it request special handling by an IPV6 router within the network. These packets would be on a route to a particular unicast or multicast destination. A real-time service, such as video, might use Flow labeling. A combination of the source address and a non-zero flow label identifies a flow. Packets that do not belong to a flow carry a flow label of zero. The flow label field is described in more detail further on in this chapter This field uses 24 bits.

The Payload Length field contains a 16-bit unsigned integer that defines the length of the packet following the header in octets. The IPV6 protocol specifies that a link be able to handle packets as large as 576 bytes. This means a payload could be as large as 536 bytes (576 bytes minus 40 bytes for the header). IPV6 can carry a payload as large as 65,535 bytes. IPV6 supports fragmentation of large packets if a link can not handle a packet of that size. IPV6 reassembles the packet at the destination.

A value of zero in this field indicates that the payload length is carried in a Jumbo Payload hop-by-hop option. (An option in the Hop-by-Hop header can handle payloads in excess of 65,535 bytes). The Payload length field uses 16 bits.

The Next Header field identifies the type of header that immediately follows the IPv6 header. Such a header could be an Authentication Header, an Encapsulation Security Header, a Routing Header, or the combination of all of them. Intermediate nodes on the packets path do not process information in this header field. This field uses the same values as the IPv4 Protocol field which are listed RFC 1700; shows some example entries. . This is an 8-bit field.

The Hop Limit field identifies the number of hops the packet can transverse from its source to its destination. Each node that processes the packet, decrements the value in this field by one. If the Hop limit is zero, the node discards the packet and returns an error message. Unlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. That is the reason the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6. This field uses an 8-bit unsigned integer.

The Source Address field contains the 128-bit address of the initial sender of the packet. RFC 1884 and Chapter 6 describe the source address.

The Destination Address field contains the 128-bit address of the intended recipient of the packet. If a Routing Header is present, the Destination Address is not the ultimate recipient. RFC 1884 and Chapter 6 describe the destination address.

Priority field operation

This is a 4-bit field and is a new IP header field. This field enables a source to identify the priority level for delivering packets. Different packets from the same source can have different priority levels. This field is useful for handling real-time traffic. Priority levels fall into two ranges. 0 through 7 and 8 through 15.

The values 0 through 7 identify the priority level for congestion controlled traffic. When a source provides congestion control it means that traffic backs off in response to congestion. TCP traffic is an example of congestion-controlled traffic. list the recommended Priory values for congestion-controlled traffic for particular application categories.

The values 8 through 15 identify the priority level for non-congestion controlled traffic or real-time traffic. This type of traffic does not back off in response to congestion; for example when real-time packets are being sent at a constant rate. Use the highest priority value of 15 for traffic that you really do not want to loose, such as low-fidelity audio traffic. Use the lower priority value of 8 for non-congestion-controlled traffic that you are most willing to loose, such as high-fidelity video traffic.

Flow Labels

The Flow label field is a new IP header field in IPv6. Like the Priority field, the Flow Label field is used in handling of real time data traffic. A source uses the 24-bit Flow Label field to label a sequence of packets (the flow) for which it request special handling by an IPV6 router within the network. For example, the source might request special handling for non-default quality of service or for real-time" service. Hosts or routers that do not support the functions of the Flow Label field are required to

• Set the field to zero when originating a packet
• Pass the field on unchanged when forwarding a packet
• Ignore the field when receiving a packet.

A control protocol such as a resource reservation protocol could pass the request for special handling on to the routers from the source. Or, the router could receive special handling instructions from information within the packet such as in a hop-by-hop option.

Traffic from a host can include flow traffic as well as traffic that is not associated with a flow. A combination of the source address and a non-zero flow label uniquely identifies a flow. Packets that do not belong to a flow carry a flow label of zero.

Flow Label contents

A flows source node assigns the flow label which is a pseudo-random number that falls between the range 1 and FFFFFF hex. All packets belonging to the same flow must be sent with the same source address, destination address, priority, and flow label. The allocation of the flow label is random This means that any set of bits within the Flow Label field is suitable for use as a hash key by routers, for looking up the state associated with the flow.

All datagrams that have the same (non-zero) Flow Label must have the same Destination Address, Hop-by-Hop Options header, Routing Header, and Source Address contents.

Note the following:

• The lifetime of flow-handling state that is set up explicitly must be specified as part of the specification of the explicit set-up mechanism.
• A node that has crashed and then restarted needs to avoid reusing an earlier flow label whose lifetime may not have expired yet.

Pros and Cons of Flow Labels

An Internet Service Provide could use Flow label to provide better service to customers such as lower delay or bigger bandwidth. For example, the network provider's routers might be able to recognize a large amount of traffic and use the Flow Label field to establish a special route that gives the TCP connection better service.

Conversely, using Flow Labels in individual TCP connections changes the handling of route caches in routers. Putting Flow Labels in each datagram changes the cache into a Flow Label cache. This means every TCP connection has a cache entry thus creating the potential for cache explosion.

Extension headers

An IPv6 header can carry additional intent-layer information. The protocol encodes this information in separate headers and places it between the IPv6 header and the transport-layer header in a packet. A distinct Next Header value identifies each of these extension headers of which there are but a small number. When a packet carries one or more extension headers, the Next Header field of the preceding header identifies each one as shown in.

With the exception of the hop-by-hop option header, the destination node is the only node on a packets path that examines or processes extension headers. The processing of embedded extension headers in a IPv6 header occurs strictly in the order they appear in the packet; the destination node must not scan ahead and process selected extension headers. The contents and semantics of the extension header indicates if the protocol is to proceed to the next header. If no extension header is present, processing of the IPv6 header proceeds to the upper-layer header.

If it is present, every node on a packets paths examines and process the hop-by-hop option header. This extension header immediately follows the IPv6 header. The IPv6 header identifies the presence of the hop-by-hop extension header by placing a zero in the IPv6 header Next Header field. The destination node should discard the packet and send an error message to the source node of the packet when it encounters a Next Header value of zero in any header other than an IPv6 header. The same action should be taken if a node processes a header and does not recognize the Next Header value in the current header.

Extension header order

A full implementation of IPv6 includes the following extension headers.

If more than one extension header appears in the same packet, the protocol recommends that the header appear in the following order:

• IPv6 header
• Hop-by-Hop Options header
• Destination Options header -- Position this extension header here for options to be processed by the first destination in the IPv6 header and subsequent destinations listed in the Routing header.
• Routing header
• Fragment header
• Authentication header – Refer to
Chapter 12, Chapter 13, and RFC 1827 for recommendation about the relative order of the Authentication and Encapsulating Security Payload headers.
• Encapsulating Security Payload header
• Destination Options header -- Position this extension header here for options to be processed only by the final destination of the packet.
• Upper-layer header

The Hop-by-Hop Options header is restricted to appear immediately only after an IPv6 header.

Usually an extension header appears only once except for the Destination Options header that can occur twice. If this header appears twice, the first occurrence would be before a Routing header and the second occurrence would be before the upper-layer header

When the upper-layer header is another IPv6 header, it can be followed by its own extensions headers. This can occur in the case of IPv6 being tunneled over or encapsulated in IPv6.

Type-Length Value encoded options

The Hop-by-Hop Options header and the Destination Options header can include a variable number of Type-Length-Value (TLV) encoded options that contain the fields and format described in and .

The Option Type identifiers are internally encoded. The encoding includes two bits that specify the action a process IPv6 node should take if it does not recognize the Option Type. A two bit setting of:

• 00 indicates skip over this option and continue processing the header.
• 01indicates discard the packet.
• 10 indicates discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an error message to the packet's Source Address.
• 11 indicates discard the packet and, only if the packet's Destination Address was not a multicast address, send an error to the packet's Source Address.

Padding Options

Two additional padding options, Pad1 and PadN, are used to fill out the header to a multiple of 8 octets in length and to align subsequent options. All IPv6 implementations must recognize these padding options. RFC 1883 describes these padding options, option format, and option processing in detail.

The Pad1 format does not have length and value fields and is used only when one octet of padding is needed in the Options area of a header. Use PadN options if two or more octets of padding need to be inserted in the Options area of a header. PadN option have and Opt Data Len field and an Option data field. The Opt Data Len field contains the value N-2 and the Option data field consists of N-2 zero-valued octets.

Hop-by-Hop Option header

The Hop-by-Hop Options header carries information that intermediate nodes between a source and destination need to know. Every node along a packet’s path examines the Hop-by-Hop Options header for this information. A value of zero in the Next Header field in the IPv6 header identifies the Hop-by-Hop Options header. shows the format of this header.

The 8-bit Next Header field of this option identifies the type of header that immediately follows the Hop-by-Hop Options header. Like the IPv6 header’s Next Header field, this field uses the same values as the IPv4 Protocol field. Shown previously, shows some examples of entries for this field.

The Hdr Ext Len field contains an 8-bit unsigned integer and indicates the Length of the Hop-by-Hop Options header in 8-octet units. This does not include the first 8 octets.

The Options field can contain one or more Type-Length Value (TLV) encoded options. This size of this field is variable as long as the complete Hop-by-Hop Options header is an integer multiple of 8 octets long. The options are processed in the order that they appear in the header.

The Jumbo Payload option is one of the options that can be included in the Hop-by-Hop Options header. The Jumbo Payload option is used to send IPv6 packets with payloads longer than 65,535 octets. The Payload Length field in the IPv6 header must be set to zero in every packet that carries the Jumbo Payload option. Note the following restrictions about the Jumbo Payload option:

• Implementations that fail to support this option cannot have interfaces to links whose link MTU is greater than 65,575.
• Packets that contain a Fragment header must not use the Jumbo Payload option.

Routing Header

The Routing header contains a list of one or more intermediate nodes through which the packet is to pass on its route from the packet’s source to its destination. Using a Routing header causes the packet to be routed through the specified intermediate nodes. The Routing header functions in much the same way as IPv4’s Source Route option. A value of 43 in the preceding Next Header field identifies the Routing options header. shows the format of this header.

The Next Header field identifies the type of header that is to immediately follow the Routing Header. This 8-bit field uses the same values as the IPv4 Protocol field. Shown previously, shows some examples of entries for this field.

The Hdr Ext Len field contains an 8-bit unsigned integer and indicates the Length of the Routing header in 8-octet units. This does not include the first 8 octets. If for example, this was a Type 0 Routing header, then the Hdr Ext Len is equal to two times the number of addresses in the header. This value must be an even number less than or equal to 46.

The Routing Type field indicates the particular type of routing that this header supports. RFC 1883,The IPv6 Specification, describes one variant, Routing Type 0. This field uses an 8-bit identifier.

The Segments Left field contains an 8-bit unsigned integer and indicates the number of remaining route segments the packet needs to pass through before reaching the final destination. A segment consists of an explicitly listed intermediate nodes. Maximum legal value = 23.

The Type-Specific Data field is a variable-length field. The specified Routing Type determines the information in this field and the format of this field. The length of this field is such that the complete Routing header is an integer multiple of 8 octets long.

For example, the Routing header for Routing Type 0 adds a Reserved field, the Strict/Loose Bit Map field, and an indicator for the addresses of the intermediate nodes to the Type-Specific Data field

For Routing Type 0:

• The 8-bit Reserved field initializes to zero for transmission and is ignored on reception.
• The 24-bit bit-map Strict/Loose Bit Map field is used when making a forwarding decision. This field is numbered 0 to 23, left-to right. Values in this field indicates whether or not the next segment of the route (next destination address) must be a neighbor of the preceding address.

1 = Strict and must be a neighbor. The Destination Address field of the IPv6 header in the original packet must identify a neighbor of the originating node.

0 = Loose and need not be a neighbor. The originator may use any legal, non-multicast address as the initial Destination Address.

• The Address is the vector of 128-bit addresses, numbered 1 to n.

Multicast addresses are not permissible in either a Routing header of Type 0, or in the IPv6 Destination Address field of a packet carrying a Routing header of Type 0.

A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. In that node, dispatching on the Next Header field of the immediately preceding header causes the Routing header module to be invoked.,

Fragment option header

An IPv6 source node uses the Fragment header to send packets to the destination node that are to large to fit in the Path Maximum Transmission Unit size of network. Fragmenting the datagram means that the individual packets can then can conform to the requirements of the individual networks on its path to its destination. Note that In IPv6 only the source node performs fragmentation. (In IPv4 routers along a packet’s route to its destination perform fragmentation.)

A value of 44 in the preceding Next Header field identifies the Fragment options header. shows the format of this header.

The Next Header field identifies the type of header that is to immediately follow the Fragment header. This 8-bit field uses the same values as the IPv4 Protocol field. Shown previously, shows some examples of entries for this field.

The 8-bit Reserved field is reserved for future use. This field initializes to zero for transmission and is ignored on reception.

The Fragment Offset field indicates where in the datagram this fragment belongs and is a 13-bit integer. The fragment offset is measured in units of 8 octets. This field contains the fragment offset of the data following this header, relative to the start of fragmentation in the original packet.

When fragmentation of a datagram occurs:

• Creates two or more new datagrams, and copies the original IP header into each packet, and divides the data between the new packets on an 8 octet boundary.
• The protocol places the first portion of the data in the first new internet datagram, sets the total length field to the length of the first datagram, and sets the more-fragments flag is set to one. The first fragment has offset of zero.
• The protocol places the second portion of data in another internet datagram, sets the total length field to the length of the second datagram, and sets the more-fragments flag. The protocol then sets the fragment offset to the value of that field in the long datagram plus the number of fragment blocks in the long datagram. the last fragment has the more-fragments flag reset to zero

The 2-bit Res field is reserved for future use. This field initializes to zero for transmission and is ignored on reception.

The 1-bit M flag indicates if there are more fragments to follow or if this is the last fragment:

1 = more fragments

0 = last fragment

The 32-bit Identification field contains a value generated by the source node. This value is associated with a packet that is to be fragmented and indeed accompanies each fragment to the destination. The destination node uses this value during reassembly of the packets. If the source node and destination node are identical, the Identification for a fragmented packet must be different that the Identification of a recently fragmented packet whose maximum lifetime might still be viable. If a Routing header is present, the Destination Address of concern is the final destination, not an intermittent address.

IPv6 Fragmentation

The original unfragmented large packet consists of two parts: an unfragmentable part and a fragmentable part which can be divided into fragment packets. The unfragmentable parts consists of the IPv6 header and any extension headers that must be processed before the packet reaches its destination. This includes all headers up to and including the routing header that were present in the original packet.

The fragment part contains the rest of the packet including: all extension headers that can be processed by the destination node and the upper-layer header and data. This part can be divided into fragments that are an integer multiple of 9 octets long. Each part is transmitted as a separate fragment packet.

Each fragment packet is composed of a copy of the unfragmentable part of the original packet, a Fragment header, and the fragment itself.

Fragment Reassembly

At the destination, fragment packets are reassembled into their original, unfragmented form. The following rules govern reassembly:

• The protocol only uses fragment packets that have the same Source Address, Destination Address, and Fragment Identification to reassemble the original packet.
• The reassembly process reconstructs the unfragmentable part from the first fragment packet; this is the packet whose Fragment Offset is zero. The reconstructed unfragmentable part consist of all headers up to, but not including the Fragment header of this first fragment packet. Note that the protocol:
• Obtains the Next Header field of the last header of the unfragmentable Part from the Next Header field of the first fragment's Fragment header.
• Computes the Payload Length of the reassembled packet from the length of the unfragmentable Part and the length and offset of the last fragment.
• Reassembly constructs the Fragmentable Part of the original packet from the fragments that follow the Fragment headers in each of the fragment packets. To compute the length of each fragment, the protocol subtracts the length of the headers between the IPv6 header and fragment itself; from the packet's Payload Length. The protocol computes the fragments relative position in Fragmentable Part from the fragments Fragment Offset value.
• The reassembly process does not include the Fragment header in the final, reassembled packet.

Destination Options Header

The Destination Options header carries optional information that only the packet’s destination node needs to know. A value of 60 in the preceding Next Header field identifies the Destination Options header. shows the format of this header. Note that the format for this header as shown in is identical to format of the Hop-by-Hop Options header.

The 8-bit Next Header field of this option identifies the type of header that immediately follows the Destination Options header. Like the IPv6 header’s Next Header field, this field uses the same values as the IPv4 Protocol field. Shown previously, shows some examples of entries for this field.

The Hdr Ext Len field contains an 8-bit unsigned integer and indicates the Length of the Destination Options header in 8-octet units. This does not include the first 8 octets.

The Options field can contain one or more Type-Length Value (TLV) encoded options. This size of this field is variable as long as the complete Destination Options header is an integer multiple of 8 octets long. The options are processed in the order that they appear in the header. RFC 1883 defines two destination option, Pad1 and PadN options.

There are two ways to encode optional destination information an IPv6 header. Such information can be encoder as an option within the Destination Options header or as a separate extension header such as a Fragment header or an Authentication header.

Authentication Header

RFC 1825 and RFC 1826 both describe the function and format of the Authentication header in detail. Detail information is also available in the "IP Security for IPv6 and IPv4" chapter further on in this book.

The Authentication header provides authentication and integrity assurance for IPv6 packets. It also provides protection against replays. The Authentication header does not provide confidentiality. A value of 51 in the preceding Next Header field identifies the Authentication header. shows the format of this header.

The Authentication Header (AH) may appear after any other headers that are examined at each hop, and before any other headers that are not examined at an intermediate hop. When used with IPv6, the Authentication Header normally appears after the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options.

The 8-bit Next Header field of the Authentication header identifies the next payload that follows the Authentication payload. Like the IPv6 header’s Next Header field, this field uses the same values as the IPv4 Protocol field. Shown previously, shows some examples of entries for this field.

The 8-bit Payload Length field indicates the length of the Authentication Data field in 32-bit words. A system administrator or programmer could use a null authentication algorithm for debugging purposes.

The16-bit Reserved field and is reserved for future use. This field must be set to all zeros. The Authentication Header protocol calculates the value of this field in the Authentication Data. The recipient ignores this field.

The 32-bit Security Parameters Index (SPI) field identifies the security association for this datagram. If no security association exists, the value is this field is zero. You could use a value of zero for local debugging purposes. The destination system usually selects the SPI when the sender and received establish the security association for the datagram. The Internet Assigned Numbers Authority (IANA) has reserved the SPI values of 1 through 255.

The 32-bit Sequence Number field at the time of this writing is under consideration by the IP Security Protocol Working Group (IPSEC) of the IETF. This field would be used for anti-replay services for a specific security association.

The variable length Authentication Data field is always an integral of 32-bit words. The protocol uses the combination of destination address and SPI to find the necessary information for this field. If the field is longer than needed to store the authentication data, then the protocol fills the unused bits with implementation-dependent values. This field can include explicit padding. Padding is included to ensure that the length of the AH header is an integer multiple of 8 octets long.

Encapsulating Security Payload Header

RFC 1825 and RFC 1827 both describe the function and format of the Encapsulating Security Payload (ESP) header in detail. Detail information is also available in the "IP Security for IPv6 and IPv4" chapter further on in this book.

An Encapsulating Security Payload header normally occurs before the upper layer protocol header if operating in transport mode or before an encapsulated IP header if operating in tunnel mode. A value of 50 in the preceding Next Header field identifies the Encapsulating Security Payload header.

ESP consists of an unencrypted header, encrypted header fields, and encrypted user data. The user data can consist of either an upper-layer protocol frame such as TCP or UDP, or an entire IP datagram. and the encrypted data. The field(s) of the unencrypted ESP header inform the receiver how to decrypt and process the encrypted data. The encrypted data component includes fields for the security protocol and the encrypted encapsulated IP datagram.

No Next Header

When the Next Header field of an IPv6 header or any extension header contains the value 59, it signifies that nothing follows that header. Sometimes the Payload Length field of the IPv6 header could indicate the presence of octets past the end of a header whose Next Header field contains 59. In this case, if the packet is forwarded, the protocol ignores and passes on unchanged any octets that follow Payload Length field.

IPv6 and Packet Size

When one IPv6 node has a large amount of data to send to another node, it transmits the data in a series of IPv6 packets. The IPv6 nodes tries to make these packets to be the largest size that can successfully traverse the path from the source node to the destination node. This packet size is referred to as the Path MTU.

The IPv6 protocol recommends that IPv6 nodes implement Path MTU. MTU stands for Maximum Transmission Unit of an IP interface which translates into the maximum packet size in octets, that can be conveyed in one piece over a link. Path MTU is the maximum IP datagram size for a desired path so that fragmentation of the datagram does NOT occur. RFC 1981 describes Path MTU Discovery for IPv6.

Implementing Path MTU Discovery means that the nodes could discover and take advantage of paths with MTU greater than 576 octets. This helps to eliminate fragmentation of IP packets and to utilize maximum throughput of the path being used.

There are two ways to fragment a packet if the packet is larger than a path’s MTU.; using the Fragment header to fragment the packet . A node could use the Fragment header to fragment the packet. The destination node would reassemble the packet. On the other hand, some applications can adjust their packet size to fit the measured path MTU. In this is the case, the IPv6 nodes should use Path MTU to make any such adjustments.

A few rules apply.

• Nodes must be able to accept fragmented packets that reassemble to as much as 1500 octets. The 1500 octet size includes the IPv6 header.
• Nodes can accept packets that reassemble to more than 1500 octets.
• Nodes can send packets that reassemble to more than 1500 octets only when the node knows that the destination can reassemble such a packet.
• Path MTU Discovery must be performed even in cases where a host "thinks" a destination is attached to the same link as itself.
• Nodes not implementing Path MTU Discovery use the IPv6 link MTU of 576 octets as defined in the IPv6 specification as the maximum packet size.

IPv6 and the upper layer protocol issues

The Internet Protocol is the heart of the Internet architecture. It should be noted that changes at the Internet layer effect the operation of the upper layers. The IPv6 specification (RFC 1883) discusses three of the upper layer issues in some detail: upper-layer checksums, maximum packet lifetimes, and maximum payload size. If you are developing implementations for IPv6 consider the following:"

• Revisions of upper-layer checksum and pseudo-header processing. Both TCP and UDP use a pseudo-header to incorporate the source and destination addresses into the checksum. Because address lengths have been revised, the checksum and pseudo-header processing needs revising as well. RFC 1883 and RFC 1885, the Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification both discuss the pseudo-header and its checksum computation in more detail.
• Upgrade the maximum packet lifetime mechanism for detecting and discarding obsolete packets for any upper layer protocol implementation that relies on the internet layer time-based packet lifetime. This is because the IPv4 time-to-live field could be measured in seconds or hops; the IPV6 time-to-live field can only be measured in hops.
• Upper layer protocols need to take into account the larger size of the IPv6 header relative to the IPv4 header when it computes its maximum payload size for the upper layer data. For example:
• When using TCP over IPv4, the protocol computes the maximum segment size as the maximum packet size minus 40 octets. The 40 octets value consists of 20 octets for the minimum-length IPv4 header and 20 octets for the minimum-length TCP header. Either the default maximum size value or a value learned through PathMTU discovery . determines the maximum packet size in this equation.
• When using TCP over IPv6, the protocol computes the maximum segment size as the maximum packet size minus 60 octets. A minimum-length IPv6 header is 20 octets longer than a minimum-length IPv4 header.

Form here …

This chapter introduced the new IPv6 header format, discussed the IPv6 extension and provided some information about flow labels and packet size as they apply to IPv6 implementations. For additional information, you may want to see the following:

• Chapter 6, "IPv6 Addressing", introduces the expanded addressing capabilities and addressing hierarchy of IPv6. This chapter also introduces a new type of address called an anycast address that causes a node to send a packet to any one of a group of nodes discusses IPv6 address allocation and management.
• Chapter 8 "IPv6 and Intranetwork Communications" discusses the impact of IPv6 on the RFC routing including the Internet Domain Routing Protocol (IDRP) for IPv4 and IPv6, the Routing Information Protocol (RIPing) for IPv6, and Open Shortest Path First (OSPF) Protocol for IPv6.
• Chapter 12, "IP Security for IPv6 and IPv4" discusses IP security features to support, data integrity, and optional data confidentiality
• Chapter 13 "IPv6 Key Management Issues and Protocols" discusses IP security key management features and options.