Previous Page
Next Page

IPv6 Packet Format

The structure of the IP packet header was modified in IPv6. These changes reflect some of the lessons learned from years of operating IPv4, and they have a significant impact on the protocol operation. For these reasons, the IPv6 packet format is briefly reviewed in the next section.

IPv6 Versus IPv4 Basic Header Format

To understand what motivated the choices made with respect to the IPv6 packet header structure, it is important to review the structure of its predecessor.

A packet has two components: the header that contains the layer 3 information, and the payload that carries the data and the upper-layer protocol information. RFC 791 defines the following fields for the IPv4 packet header:

  • Version (4 bits) Represents the version of the IP protocol. In this case, the field is set to 4.

  • Header Length (4 bits) The length in octets of the packet header.

  • Type of Service (ToS) (8 bits) This field carries information that enables routers to classify and forward packet in a differentiated manner. It is an important service identifier used in implementing quality of service (QoS).

  • Total Length (16 bits) The length in octets of the entire packet, header plus payload. With 16 bits available in this field, the maximum length of an IPv4 packet is 65,535 octets.

  • Identification (16 bits), Flags (3 bits), Fragment Offset (13 bits) These three fields enable IPv4 networks to support packet fragmentation to negotiate forwarding over links supporting various maximum transmission units (MTUs). Fragmentation is done as needed by the routers along the path of the packet.

  • Time To Live (8 bits) It is important to protect a network's resources from packets that loop due to routing problems. This field is used to count down the number of routers that switched the packet. The packet is discarded when the value of this field is 0.

  • Protocol Number (8 bits) The Protocol Number lists the upper-layer protocol (TCP, UDP, ICMP, and so on) that is present in the packet payload. The numbers that represent these protocols are assigned by IANA (http://www.iana.org/assignments/protocol-numbers).

  • Header Checksum (16 bits) The integrity of the packet header is verified by comparing the computed checksum with the value listed in this field.

  • Source IPv4 Address (32 bits) The IPv4 address of the node that sourced the packet.

  • Destination IPv4 Address (32 bits) The IPv4 address of the packet destination node.

  • Options (variable length) This field is meant as a placeholder for the information relevant to proper handling of the data carried by the packet, information that is not represented in the other fields of the header. Because of this field, the IPv4 header has a variable length, justifying the need for the Header Length field.

  • Padding (variable length) Is used to align the variable-length Options field to the 32-bit boundary.

Figure 2-15 shows the IPv4 packet header structure.

Figure 2-15. IPv4 and IPv6 Packet Header Structure


The relevancy of the highlighted fields has been re-evaluated in the process of developing IPv6. The structure of the new header observes several new rules:

  • Fixed length for the basic header The Options field leads to an IPv4 header of variable length (minimum 20 bytes). By contrast, IPv6 has the main header length fixed at 40 bytes, a benefit to fast header processing because routers do not have to implement lookup processes that account for variable-length headers. The fixed length makes the Header Length field obsolete. The functionality provided by the options is delivered through extension headers, a concept described later in the section. The options and padding are also removed from the main packet header.

  • Fragmentation is done only by the traffic source Before sending IPv6 traffic, the source does Path MTU (PMTU) Discovery. It then sends packets at the discovered PMTU, thus freeing the routers from having to fragment them. For this reason, the three IPv4 header fields related to fragmentation (Identification, Flags, and Fragment Offset) become irrelevant in IPv6.

    Note

    The PTMU Discovery can be processing intensive. It is important to remember, however, that in IPv6 the MTU on any link should not be smaller than 1280 bytes, as specified in RFC 2460.


  • Header checksums are eliminated The IP header checksum has to be recalculated by every node switching the packet due to changing Time To Live (TTL) values, thus taxing router resources. Improvements on data-link technologies and their 32-bit cyclic redundancy check (CRC) support since the introduction of IPv4 combined with layer 4 checksums provides sufficient protection to make the layer 3 header checksum unnecessary. For this reason, the packet Header Checksum was eliminated in IPv6 and is in turn enforced at upper layers. It is important to note the fact that both UDP and TCP will calculate the checksum on a pseudo-header that contains critical information from the IPv6 header such as SA and DA.

Based on these rules, RFC 2460 defines the following IPv6 header fields:

  • Version (4 bits) IP protocol version, the value is set to 6.

  • Traffic Class (8 bits) It performs the same function as the Type of Service field in the IPv4 header.

  • Flow Label (20 bits) This field identifies a flow and it is intended to enable the router to identify packets that should be treated in a similar way without the need for deep lookups within those packets. The specification for this header field is presented in RFC 3697. The field is set by the source and should not be changed by routers along the path to destination.

    Note

    The Flow Label together with the SA and DA can uniquely identify IPv6 flows. This ID can map in the main header traffic characteristics that are deeper in the packet, providing routers with the capability to appropriately handle packets without the need to look deep into them. The Flow Label can also provide the router with relevant information (such as TCP/UDP port and so on) that would not be otherwise available because the packet payload is encrypted. This would be a valuable feature when peer-to-peer security is used.

    The Flow Label field is unique to IPv6, but it is recognized to be a powerful tool and similar extensions are being proposed for IPv4. Applications are envisioned where the field is used just as a tag as well as more complex ones that maintain label state on the nodes using a signaling protocol. The Flow Label can be used with differentiated services (DiffServ) as well as integrated services (IntServ) and Resource ReSerVation Protocol (RSVP2).


  • Payload Length (16 bits) With the header length fixed at 40 bytes, it is enough to indicate the length of the payload to determine the length of the entire packet.

    Note

    Note that the extension headers are considered part of the packet payload.


  • Next Header (8 bits) This field expands the functionality of the Protocol Number in the IPv4 header. It prefaces the information type immediately following the basic header. This can be an extension header or the upper-layer protocol in the payload.

  • Hop Limit (8 bits) In IPv6, the IPv4 TTL was appropriately renamed Hop Limit because it is a variable that is decremented at each hop, and it does not have a temporal dimension.

  • Source IPv6 Address (128 bits) The IPv6 address of the node that sourced the packet.

  • Destination IPv6 Address (128 bits) The IPv6 address of the packet destination node.

Figure 2-15 shows the IPv6 header next to the IPv4 header to underline their differences and similarities. The Flow Label is highlighted because it represents a new functionality introduced by IPv6.

IPv6 Extension Headers

The basic IPv6 header is sufficient to perform the functions of simple packet forwarding and ToS-or Flow Labelbased QoS. There is, however, more to end-to-end IP communication than what is covered by the basic header capabilities. With the basic header at a fixed size, IPv6 had to find another way to implement the functionality offered by the Options field in IPv4. It does that through the concept of extension headers.

Note

In fact, IPv6 offers, through extension headers, more space for option-like information. The IPv4 options are limited to 40 bytes, whereas the IPv6 extension headers are limited only by the packet size.


Predefined placeholders for additional information that relates to the packet payload or the packet handling, the extension headers provide the means to complement in a modular way the functionality of the basic packet header. The format of each extension header type supports certain functions. All extension headers, however, are aligned on 8-byte boundaries to maintain 8-octet alignment.

Extension headers are chained together as needed. The Next Header field of each header starting with the basic one is a pointer to the type of the following header in the chain. The Next Header field of the last extension header in the chain contains the code for the upper-layer protocol in the payload. Figure 2-16 shows an IPv6 packet without extension headers and one with extension headers. There is a specific code for each extension header type as well as for the upper-layer (UL) protocols.

Figure 2-16. Chaining Extension Headers to the Basic IPv6 Packet Header


RFC 2460 defines the IPv6 extension headers. You can find detailed descriptions of the extension headers, their format, and functionality in most introductory IPv6 books. This section provides just a brief review of this topic.

Hop-by-Hop Options Header

The Hop-by-Hop header (identified by a Next Header field value of 0) is the only extension header that has to be processed by all the nodes on the path of the packet other than the destination. For this reason, this extension header, when present, always follows the basic IPv6 header. It is used, for example, to facilitate forwarding of Jumbograms, as described later in this section, or to provide routers with forwarding instructions.

The Hop-by-Hop header may carry multiple options containing other parameters that should be used in processing the packet. The options are encoded in Type-Length-Value (TLV) format, as shown in Figure 2-17.

Figure 2-17. TLV-Encoded Options Format


Every node that receives an IPv6 packet with a Hop-by-Hop extension header will process the options. If an option is not understood, an Internet Control Message Protocol (ICMP) error message might be sent to the source.

Note

There is no restriction on how many times an option type shows up in a Hop-by-Hop header. Not all option types generate ICMP error messages. These characteristics of the options can potentially be used in low-bandwidth denial-of-service attacks.

It is important to consider the performance impact of the hop-by-hop processing on the routers.


One use of the Hop-by-Hop extension header is to support the use of large packets. The 16-bit-long Payload Length field in the basic header can represent payload lengths no larger than 65,536 (216) octets.

The Hop-by-Hop extension header contains a 32-bit-long field that can represent larger packets called Jumbograms. The Payload Length field is set to 0 when the hop-by-hop options are used to identify a Jumbogram.

RFC 2711 defines the Router Alert option of the Hop-by-Hop extension header that is used to provide intermediate routers with forwarding instructions. This feature could be used, for example, for resource reservation with RSVP. It is also used in Multicast Listener Discovery packets to alert routers that they have to process these packets (see Chapter 6).

Destination Options Header

As the name indicates, the information carried in the Destination Options extension header is intended for the packet's destination only. The Destination Options header is used, for example, with MIPv6. Besides the Hop-by-Hop header, the Destination Header is the only one that also carries options in the same format presented in Figure 2-17. The Destination Options header is identified by a Next Header field value of 60.

Routing Header

The Routing extension header (identified by a Next Header field value of 43) is used to enforce a certain path for the packet. This path is defined by the source, and is most likely different from the one computed by the routing protocols operating in the network. The functionality implemented through the Routing extension header is similar to IPv4's Loose Source and Record Route option.

The Routing header contains a Type field that defines the precise functionality of the extension header. At the time of this writing, two types have been defined:

  • Type 0, specified in RFC 2460, identifies a Routing header that contains an ordered list of router addresses that must be visited by the packet on the way to destination. Note that each visited router modifies the DA in the basic header to that of the next router in the list. This way the routers that are not on the Routing extension header list do not need to process the extension header. This provides the source-routing capability to IPv6.

  • Type 2, specified in RFC 3775, identifies a Routing header used with MIPv6. It contains a single unicast address, the address of the home address, and enables the corresponding node to forward traffic directly to the mobile node, a forwarding option called route optimization and available only with IPv6 (see Chapter 8, "Advanced ServicesIPv6 Mobility").

This is a developing topic, and other types are being proposed (but those have not yet reached RFC status).

Fragment Header

Fragmentation is processing intensive, and it could be taxing on the resources of network elements. To protect the network infrastructure resources, it was decided that routers in the path of an IPv6 packet should not perform fragmentation. Before sending the packet, the source must go through the PMTU Discovery process, as described later in the chapter in the section "Internet Control Message Protocol for IPv6." It determines the largest packet that it can use without fragmentation along the way. Although the routers are saved the fragmentation trouble, the destination still needs to know how to reassemble the received fragments. It will receive these instructions from the source via the Fragment Options header. The first packet exchanged, however, must contain all the information used in forwarding it between the two endpoints: IPv6 basic header and any extension headers that need to be processed along the way. This is called the unfragmentable part of the original packet.

Note

Two new rules in IPv6 relate to MTU handling: The MTU of a link should not be smaller than 1280 bytes, and routers do not do packet fragmentation. In today's networks, these two requirements are not as stringent as they might seem. Links with small MTUs are becoming less common, so the MTU of a typical Ethernet host is likely to be close to the PMTU it will use for most of its communication.


Authentication Header

This header is similar to the IPv4 IPsec Authentication Header defined in RFC 2402. It provides packet source authentication and data integrity protection. The AH header is identified by a Next Header field value of 51.

Encapsulating Security Payload Header

This header is similar to the IPv4 IPsec Encapsulating Security Payload (ESP) header defined in RFC 2406. It is identified by a Next Header field value of 50. The ESP and AH extension headers are used the same way as in IPv4.

Mobility Header

RFC 3775 describes this extension header and its use in the communication between the mobile nodes, correspondent nodes, and home agents in establishing and managing bindings (for more details, see Chapter 8). It is identified by a Next Header field value of 135.

Linking Multiple Extension Headers

The various extension headers are chained based on the information that needs to be provided to the destination or intermediary hops along with the payload data. The following set of extension headers Hop-by-Hop, Destination, Routing, Fragmentationcan follow, for example, a basic IPv6 header. The sequence in which these extension headers are added to the basic header is not random. There is a recommended order in which extension headers should be chained in an IPv6 packet, but the only strict requirement is for the Hop-by-Hop (if present) to be ahead of any other extension header type. Table 2-7 lists the extension header in the recommended chaining order along with the Next Header codes that identify them and the codes for three common layer 4 protocols.

Table 2-7. Order in Which Headers Can Be Chained and Their Next Header IDs

Order

Header Type

Next Header Code

1

Basic IPv6 header

2

Hop-by-Hop Options

0

3

Destination Options (with Routing Options)

60

4

Routing header

43

5

Fragment header

44

6

Authentication header

51

7

Encapsulation Security Payload header

50

8

Destination Options

60

9

Mobility header

135

 

No Next header

59

Upper layer

TCP

6

Upper layer

UDP

17

Upper layer

ICMPv6

58


Extension headers are an important aspect of IPv6, and their capabilities will be leveraged more and more in optimizing the operation of production deployments. They make IPv6 easily extensible compared to its predecessor, and that could prove to be one of its most significant benefits besides the larger address space. The modular concept of the extension headers represents a scalable and improved alternative to the variable-length Options field in the IPv4 header. At the same time, note that extension headers can pose security risks (see Chapter 9, "Securing IPv6 Networks"). The presence of extension headers could also impact packet-forwarding performance the same way options had in the case of IPv4. Routers have to process upper-layer information that now is moved deeper into the packet and would require the processing of the entire extension header chain.

IPv6 and Data-Link Technologies

In conjunction with the analysis of a layer 3 protocol, it is important to analyze its mapping at layer 2 of the OSI model. IPv6 operates over various data-link technologies, as specified in the following RFCs:

  • Ethernet (RFC 2464), also used on IPv6 over WiFi (802.11).

  • FDDI (RFC 2467).

  • Token Ring (RFC 2470).

  • PPP (RFC 2472).

  • Generic Packet Tunneling (RFC 2473).

  • Non Brodcast Multiple Access (NBMA) (RFC 2491).

  • ATM (RFC 2492).

  • Frame Relay (RFC 2590).

  • Dynamic Packet Transport (DPT) and Spatial Reuse Protocol (SRP), defined in RFC 2982, support IPv6 even though this is not standardized as it is for the other technologies listed.

These RFCs (except for DPT/SRP which uses mechanisms similar to Ethernet) also define mechanisms for building the IPv6 Interface ID for each of these media transport types.

The layer 2 PDU format is independent of the transported upper-layer protocol. However, the Protocol ID field of the layer 2 header indicates the type of layer 3 protocol it carries in the payload. For example, Table 2-8 shows the value of this field for several commonly used data-link technologies.

Table 2-8. Example of Frame Header Protocol ID Field Values for IPv6

Data-Link Technology

IPv4 Protocol ID

IPv6 Protocol ID

Ethernet

0x0800 (Ethertype)

0x86DD (Ethertype)

ATM

0x0800

0x86DD

PPP (IPCP)

0x8021

0x8057

Cisco HDLC

0x0800

0x86DD


The frame format, in particular the Protocol ID, is important when layer 2 filtering is used to differentiate between IPv4 and IPv6 traffic.

A good understanding of the IPv6 packet structure and the structure of the corresponding layer 2 framing is important not only for a better understanding of the protocol operation but also in developing IPv6 troubleshooting expertise.

The rest of the chapter presents several important IPv6-specific control-plane mechanisms. To facilitate their clear description, the subsequent sections are prefaced at this point with a list of relevant terms used henceforth:

  • Node A device running IP.

  • Neighbors Nodes attached to the same link.

  • Host a node that is not a router.

  • Router A node that routes (forward received packets) packets not addressed to itself.

  • Link-layer address The identifier for an interface at layer 2.

  • On-link address An IP address that is within the same layer 2 domain or link.

  • Off-link address An IP address that is on a different layer 2 domain or link.

  • Next hop IP address of the gateway used to reach the destination. The next hop computed by a node for a given destination is one of its neighbor.


Previous Page
Next Page