Section 2.2. The Fields in the IPv6 Header
2.2. The Fields in the IPv6 HeaderBy becoming familiar with the fields of the IPv6 header, you will better understand how IPv6 works.
Figure 2-1 provides an overview of the IPv6 header. The fields are discussed in detail in the following paragraphs. Figure 2-1. Fields in the IPv6 header Figure 2-1 shows that even though the header has a total size of 40 bytes, which is twice as long as a default IPv4 header, it has actually been streamlined because most of the header is taken up by the two 16-byte IPv6 addresses. That leaves only 8 bytes for other header information. 2.2.1. Version (4 Bits)This is a 4-bit field containing the version of the protocol. In the case of IPv6, the number is 6. The version number 5 could not be used because it had already been assigned to the experimental stream protocol. 2.2.2. Traffic Class (1 Byte)This field replaces the "Type of Service" field in IPv4. It facilitates the handling of real-time data and any other data that requires special handling, and sending nodes and forwarding routers can use it to identify and distinguish between different classes or priorities of IPv6 packets. RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," explains how the Traffic Class field in IPv6 can be used. RFC 2474 uses the term DS Field to refer to the "Type of Service" field in the IPv4 header, as well as to the Traffic Class field in the IPv6 header. Refer to Chapter 6 for more information. 2.2.3. Flow Label (20 Bits)This field distinguishes packets that require the same treatment in order to facilitate the handling of real-time traffic. A sending host can label sequences of packets with a set of options. Routers keep track of flows and can process packets belonging to the same flow more efficiently because they do not have to reprocess each packet's header. The flow label and address of the source node uniquely identify the flow. Nodes that do not support the functions of the Flow Label field are required to pass the field unchanged when forwarding a packet and to ignore the field when receiving a packet. All packets belonging to the same flow must have the same Source and Destination IP address.
2.2.4. Payload Length (2 Bytes)This field specifies the payload i.e., the length of data carried after the IP header. The calculation in IPv6 is different from the one in IPv4. The Length field in IPv4 includes the length of the IPv4 header, whereas the Payload Length field in IPv6 contains only the data following the IPv6 header. Extension headers are considered part of the payload and are therefore included in the calculation. The fact that the Payload Length field has 2 bytes limits the maximum packet payload size to 64 KB. IPv6 has a Jumbogram Extension header , which supports bigger packet sizes if needed. Jumbograms are relevant only when IPv6 nodes are attached to links that have a link MTU greater than 64 KB; they are specified in RFC 2675. 2.2.5. Next Header (1 Byte)In IPv4, this field is called the Protocol Type field, but it was renamed in IPv6 to reflect the new organization of IP packets. If the next header is UDP or TCP, this field will contain the same protocol numbers as in IPv4for example, protocol number 6 for TCP or 17 for UDP. But if Extension headers are used with IPv6, this field contains the type of the next Extension header. Extension headers are located between the IP header and the TCP or UDP header. Table 2-1 lists possible values in the Next Header field.
Header type numbers derive from the same range of numbers as protocol type numbers, and therefore should not conflict with them.
2.2.6. Hop Limit (1 Byte)This field is analogous to the TTL field in IPv4. The TTL field contains a number of seconds, indicating how long a packet can remain in the network before being destroyed. In IPv4, most routers simply decrement this value by one at each hop. This field has been renamed Hop Limit in IPv6. The value in this field now expresses a number of hops instead of a number of seconds. Every forwarding node decrements the number by one. If a router receives a packet with a Hop Limit of 1, it decrements it to 0, discards the packet, and sends the ICMPv6 message "Hop Limit exceeded in transit" back to the sender. 2.2.7. Source Address (16 Bytes)This field contains the IP address of the originator of the packet. 2.2.8. Destination Address (16 Bytes)This field contains the IP address of the intended recipient of the packet. This can be the ultimate destination or if, for example, a Routing header is present, the address of the next hop router. Figure 2-2 shows the IPv6 header in the trace file. Figure 2-2. The IPv6 header in a trace file This trace file shows all of the header fields discussed and how they can be presented in a trace file. The Version field is set to 6 for IPv6. The Traffic Class (Priority) and Flow Label fields are not used in this packet and are set to 0. The Payload Length is 40, and the Next Header value is set to 58 for ICMPv6. The Hop Limit is set to 128, and the Source and Destination addresses contain the link local addresses of my IPv6 nodes. The first line in the detail window shows Ethertype 0x86DD. This value indicates that this is an IPv6 packet. For IPv4, the value would be 0x0800. This field can be used to set an analyzer filter for all IPv6 packets.
|
