As we saw in the previous topic, IPv6 datagrams use a structure that includes a regular header and optionally, one or more extension headers. This regular header is like the header of IPv4 datagrams, though it has a different format, as we will see shortly. The standards don’t give this header a name; it is just “the IPv6 header”. To differentiate it from IPv6 extension headers, I call it the main header.
Main Header Format
The IPv6 main header is required for every datagram. It contains addressing and control information that are used to manage the processing and routing of the datagram. The main header format of IPv6 datagrams is described in Table 68 and illustrated in Figure 105.
|
Field Name |
Size (bytes) |
Description |
|
Version |
1/2 |
Version: Identifies the version of IP used to generate the datagram. This field is used the same way as in IPv4, except of course that it carries the value 6 (0110 binary). |
|
Traffic Class |
1 |
Traffic Class: This field replaces the Type Of Service (TOS) field in the IPv4 header. It is used not in the original way that the TOS field was defined (with Precedence, D, T and R bits) but using the new Differentiated Services (DS) method defined in RFC 2474. That RFC actually specifies quality of service (QOS) techniques for both IPv4 and IPv6; see the IPv4 format description for a bit more information. |
|
Flow Label |
2 1/2 |
Flow Label: This large field was created to provide additional support for real-time datagram delivery and quality of service features. The concept of a flow is defined in RFC 2460 as a sequence of datagrams sent from a source device to one or more destination devices. A unique flow label is used to identify all the datagrams in a particular flow, so that routers between the source and destination all handle them the same way, to help ensure uniformity in how the datagrams in the flow are delivered. For example, if a video stream is being sent across an IP internetwork, the datagrams containing the stream could be identified with a flow label to ensure that they are delivered with minimal latency. Not all devices and routers may support flow label handling, and use of the field by a source device is entirely optional. Also, the field is still somewhat experimental and may be refined over time. |
|
Payload Length |
2 |
Payload Length: This field replaces the Total Length field from the IPv4 header, but it is used differently. Rather than measuring the length of the whole datagram, it only contains the number of bytes of the payload. However, if extension headers are included, their length is counted here as well. In simpler terms, this field measures the length of the datagram less the 40 bytes of the main header itself. |
|
Next Header |
1 |
Next Header: This field replaces the Protocol field and has two uses. When a datagram has extension headers, this field specifies the identity of the first extension header, which is the next header in the datagram. When a datagram has just this “main” header and no extension headers, it serves the same purpose as the old IPv4 Protocol field and has the same values, though new numbers are used for IPv6 versions of common protocols. In this case the “next header” is the header of the upper layer message the IPv6 datagram is carrying. See below for more details. |
|
Hop Limit |
1 |
Hop Limit: This replaces the Time To Live (TTL) field in the IPv4 header; its name better reflects the way that TTL is used in modern networks (since TTL is really used to count hops, not time.) |
|
Source Address |
16 |
Source Address: The 128-bit IP address of the originator of the datagram. As with IPv4, this is always the device that originally sent the datagram. |
|
Destination Address |
16 |
Destination Address: The 128-bit IP address of the intended recipient of the datagram; unicast, anycast or multicast. Again, even though devices such as routers may be the intermediate targets of the datagram, this field is always for the ultimate destination. |
|
|
IPv6 Next Header Field
The Next Header field is one of the most important additions to the IPv6 datagram format. When an IPv6 datagram uses extension headers, this field contains an identifier for the first extension header, which in turn uses its own Next Header to point to the next header, and so on. The last extension header then references the encapsulated higher-layer protocol—since the higher-layer protocol’s header appears at the start of the IPv6 Data field, it is like the “next header” to the device receiving the datagram. For some folks this is a bit tough to see conceptually; much more detail on how the field works (including a useful illustration) can be found in the next topic, describing extension headers. Some of the most common values for Next Header in IPv6 are shown in Table 69.
|
Value (Hexadecimal) |
Value (Decimal) |
Protocol / Extension Header |
|
00 |
0 |
Hop-By-Hop Options Extension Header |
|
01 |
1 |
ICMPv4 |
|
02 |
2 |
IGMPv4 |
|
04 |
4 |
IP in IP Encapsulation |
|
06 |
6 |
TCP |
|
08 |
8 |
EGP |
|
11 |
17 |
UDP |
|
29 |
41 |
IPv6 |
|
2B |
43 |
Routing Extension Header |
|
2C |
44 |
Fragmentation Extension Header |
|
2E |
46 |
Resource Reservation Protocol (RSVP) |
|
32 |
50 |
Encrypted Security Payload (ESP) Extension Header |
|
33 |
51 |
Authentication Header (AH) Extension Header |
|
3A |
58 |
ICMPv6 |
|
3B |
59 |
No Next Header |
|
3C |
60 |
Destination Options Extension Header |
The total length of the main IPv6 header format is 40 bytes. This is double the size of the IPv4 header without options, largely because of the extra 24 bytes needed for the monstrous IPv6 addresses. There are only 8 bytes of non-address header fields in the IPv6 main header, compared to 12 in the IPv4 header.
Key Changes to Main Header Between IPv4 and IPv6
To summarize, the IPv6 main header compares to the IPv4 header as follows:
- Unchanged Fields: Three fields are used the same way and retain the same name (though they have different content and/or size): Version, Source Address and Destination Address.
- Renamed Fields: Two fields are used the same way but renamed: Traffic Class and Hop Limit.
- Modified Fields: Two fields are used in a way similar way to their IPv4 predecessors but are slightly different in meaning and also renamed: Payload Length and Next Header.
- Added Fields: There is one new field: Flow Label.
- Removed Fields: To cut down on header length and unnecessary work, five IPv4 header fields are removed from the IPv6 header:
- Internet Header Length: No longer needed, as the main IPv6 header is fixed in length at 40 bytes.
- Identification, Flags, Fragment Offset: These are used for fragmentation, which is done less in IPv6 than IPv4, so these fields are now found only when needed in the Fragmentation extension header.
- Header Checksum: The decision was made to eliminate header checksum calculations in IPv6. It was viewed as redundant with higher-layer error-checking and data link layer CRC calculations. This saves processing time for routers and 2 bytes in the datagram header.
In addition, while options were formerly considered part of the main header in IPv4, they are separate in IPv6.