IPv6 Foundation Part 3 - IPv6 Headers and Extension Headers

Course Index
Part 1 – Introduction: What is IPv6
Part 2 – IPv6 Addressing & Subnetting
Part 3 – IPv6 Headers & Header Extensions
Part 4 – ICMPv6 & IPv6 Neighborships
Part 5 – IPv6 Configuration, EUI-64, SLAAC & Dual Stack
Part 6 – IPv6 DHCP (DHCPv6)
Part 7 – IPv6 on Windows
Part 8 – IPv6 on Linux
Part 9 – IPv6 on Mac
Part 10 – IPv6 DNS, Monitoring & Address Management
Part 11 – IPv6 Routing
Part 12 – IPv6 Security & Tunneling
Part 13 – IPv6 Internet Connection & Address Planning

IPv6 Headers & Extension Headers

The IP packet header has similarities and differences between the two protocol versions 4 and 6. Let’s have a look.

How to IPv4 Header is set up

First, let’s do a quick recap of the IPv4 packet header and the different fields:

Offset	Octet	0	1	2	3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Version	IHL	DHCP	ECN	Total Length
4	32	Identification	Flags	Fragment Offset
8	64	Time To Live	Protocol	Header Checksum
12	96	Source IP Address
16	128	Destination IP Address
20	160	Options (if IHL > 5)

About the IPv4 Header Version Field

The first header field in an IP packet is the four-bit version field. For IPv4, this has a value of 4 (hence the name IPv4).

Internet Header Length (IHL) Field

The second field (4 bits) is the Internet Header Length (IHL), which is the number of 32-bit words in the header. Since an IPv4 header may contain a variable number of options, this field specifies the size of the header (this also coincides with the offset to the data). The minimum value for this field is 5 (RFC 791), which is a length of 5×32 = 160 bits = 20 bytes. Being a 4-bit value, the maximum length is 15 words (15×32 bits) or 480 bits = 60 bytes.

Differentiated Services Code Point (DSCP) Field

Originally defined as the Type of service field, this field is now defined by RFC 2474 for Differentiated services (DiffServ). New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP (VoIP), which is used for interactive data voice exchange.

Explicit Congestion Notification (ECN) Field

This field is defined in RFC 3168 and allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is only effective when supported by the underlying network.

Total Length Field

This 16-bit field defines the entire packet (fragment) size, including header and data, in bytes. The minimum-length packet is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 bytes — the maximum value of a 16-bit word. All hosts are required to be able to reassemble datagrams of size up to 576 bytes, but most modern hosts handle much larger packets. Sometimes subnetworks impose further restrictions on the packet size, in which case datagrams must be fragmented. Fragmentation is handled in either the host or router in IPv4.

Identification Field

This field is an identification field and is primarily used for uniquely identifying the group of fragments of a single IP datagram. Some experimental work has suggested using the ID field for other purposes, such as for adding packet-tracing information to help trace datagrams with spoofed source addresses,[13] but RFC 6864 now prohibits any such use.

Flags Field

A three-bit field follows and is used to control or identify fragments. They are (in order, from high order to low order):
bit 0: Reserved; must be zero.
bit 1: Don’t Fragment (DF)
bit 2: More Fragments (MF)

If the DF flag is set, and fragmentation is required to route the packet, then the packet is dropped. This can be used when sending packets to a host that does not have sufficient resources to handle fragmentation. It can also be used for Path MTU Discovery, either automatically by the host IP software, or manually using diagnostic tools such as ping or traceroute. For unfragmented packets, the MF flag is cleared. For fragmented packets, all fragments except the last have the MF flag set. The last fragment has a non-zero Fragment Offset field, differentiating it from an unfragmented packet.

Fragment Offset Field

The fragment offset field, measured in units of eight-byte blocks (64 bits), is 13 bits long and specifies the offset of a particular fragment relative to the beginning of the original unfragmented IP datagram. The first fragment has an offset of zero. This allows a maximum offset of (213 – 1) × 8 = 65,528 bytes, which would exceed the maximum IP packet length of 65,535 bytes with the header length included (65,528 + 20 = 65,548 bytes).

Time To Live (TTL) Field

An eight-bit time to live field helps prevent datagrams from persisting (e.g. going in circles) on an internet. This field limits a datagram’s lifetime. It is specified in seconds, but time intervals less than 1 second are rounded up to 1. In practice, the field has become a hop count—when the datagram arrives at a router, the router decrements the TTL field by one. When the TTL field hits zero, the router discards the packet and typically sends an ICMP Time Exceeded message to the sender.

The program traceroute uses these ICMP Time Exceeded messages to print the routers used by packets to go from the source to the destination.

Protocol Field

This field defines the protocol used in the data portion of the IP datagram. The Internet Assigned Numbers Authority maintains a list of IP protocol numbers which was originally defined in RFC 790.

Header Checksum Field

Main article: IPv4 header checksum

The 16-bit checksum field is used for error-checking of the header. When a packet arrives at a router, the router calculates the checksum of the header and compares it to the checksum field. If the values do not match, the router discards the packet. Errors in the data field must be handled by the encapsulated protocol. Both UDP and TCP have checksum fields. When a packet arrives at a router, the router decreases the TTL field. Consequently, the router must calculate a new checksum. RFC 1071 defines the checksum calculation:

The checksum field is the 16-bit one’s complement of the one’s complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.

For example, consider Hex 4500003044224000800600008c7c19acae241e2b (20 bytes IP header), using a machine which uses standard two’s complement arithmetic:

Step 1) 4500 + 0030 + 4422 + 4000 + 8006 + 0000 + 8c7c + 19ac + ae24 + 1e2b = 0002BBCF (32-bit sum)

Step 2) 0002 + BBCF = BBD1 = 1011101111010001 (1’s complement 16-bit sum, formed by “end around carry” of 32-bit 2’s complement sum)

Step 3) ~BBD1 = 0100010000101110 = 442E (1’s complement of 1’s complement 16-bit sum)

To validate a header’s checksum the same algorithm may be used – the checksum of a header which contains a correct checksum field is a word containing all zeros (value 0):

2BBCF + 442E = 2FFFD. 2 + FFFD = FFFF. the 1’S of FFFF = 0.

Source address Field

This field is the IPv4 address of the sender of the packet. Note that this address may be changed in transit by a network address translation device.

Destination address Field

This field is the IPv4 address of the receiver of the packet. As with the source address, this may be changed in transit by a network address translation device.

Options Field

The options field is not often used. Note that the value in the IHL field must include enough extra 32-bit words to hold all the options (plus any padding needed to ensure that the header contains an integer number of 32-bit words). The list of options may be terminated with an EOL (End of Options List, 0x00) option; this is only necessary if the end of the options would not otherwise coincide with the end of the header.

How the IPv6 Header is built

The IPv6 header is bigger by size, because the new addresses are 128 bits instead of 32 bits in size. The header is simpler at the same time!

Offset	Octet	0	1	2	3
Octet	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Version	Traffic Class	Flow Label
4	32	Payload Length	Next Header	Hop Limit
8	64	Source IPv6 Address
12	96
16	128
20	160
24	192	Destination IPv6 Address
28	224
32	256
36	288

About the IPv6 Header Version Field (4 bits)

The constant 6 (bit sequence 0110)

Traffic Class (8 bits) Field

The bits of this field hold two values. The 6 most-significant bits are used for differentiated services, which is used to classify packets. The remaining two bits are used for ECN; priority values subdivide into ranges: traffic where the source provides congestion control and non-congestion control traffic.

Flow Label (20 bits) Field

Originally created for giving real-time applications special service. The flow label when set to a non-zero value now serves as a hint to routers and switches with multiple outbound paths that these packets should stay on the same path so that they will not be reordered. It has further been suggested that the flow label be used to help detect spoofed packets.

Payload Length (16 bits) Field

The size of the payload in octets, including any extension headers. The length is set to zero when a Hop-by-Hop extension header carries a Jumbo Payload option.

Next Header (8 bits) Field

Specifies the type of the next header. This field usually specifies the transport layer protocol used by a packet’s payload. When extension headers are present in the packet this field indicates which extension header follows. The values are shared with those used for the IPv4 protocol field, as both fields have the same function (see List of IP protocol numbers).

Hop Limit (8 bits) Field

Replaces the time to live field of IPv4. This value is decremented by one at each intermediate node visited by the packet. When the counter reaches 0 the packet is discarded.

Source Address (128 bits) Field

The IPv6 address of the sending node.

Destination Address (128 bits) Field

The IPv6 address of the destination node(s).

In order to increase performance, and since current link layer technology is assumed to provide sufficient error detection, the header has no checksum to protect it.

What IPv6 Extension Headers are and why we need them

This is new with IPv6 and makes the packet smaller, and the whole thing very flexible. Optional Extension Headers can be inserted after the fixed packet header. In this case the Next Header field contains the type of Extension Header that is used (see table below).

It is possible to chain multiple Extension Headers.

IPv6 Extension Header Types

Extension Header	Type	Description
Hop-by-Hop Options	0	Options that need to be examined by all devices on the path. Router Alert for RSVP, MLD
Destination Options (before routing header)	60	Options that need to be examined only by the destination of the packet.
Routing	43	Methods to specify the route for a datagram, e.g. mandatory hops (used with Mobile IPv6).
Fragment	44	Contains parameters for fragmentation of datagrams.
Authentication Header (AH)	51	Contains information used to verify the authenticity of most parts of the packet. Used for IPsec
Encapsulating Security Payload (ESP)	50	Carries encrypted data for secure communication. Used for IPsec
Destination Options (before upper-layer header)	60	Options that need to be examined only by the destination of the packet.
Mobility (currently without upper-layer header)	135	Parameters used with Mobile IPv6.

IPv6 Fragmentation and it’s limitations

In IPv6, routers do not fragment IPv6 packets. This is a major difference to IPv4.

Hosts have to use Path MTU Discovery (PMTUD) to find out the maximum possible packet size which is supported by the end-to-end routing path from source to destination.

Packets that are too large are dropped and an ICMPv6 type 2 message (Packet too big) is sent to the source. This is very similar to setting the IPv4 don’t fragment (df) bit.

For further reading on this topic I can recommend a great Article by Geoff Huston about Evaluating IPv4 and IPv6 Packet Fragmentation and also one by CDN provider Cloudflare about why IP fragmentation is broken by design.

IPv6 Fragment Extension Header

In case the application is not able to keep the payload within range, the source host can use a Fragment Extension Header . Usually it is the application’s job to keep the packet below the maximum size.

With the Fragment Extension Header, packets are fragmented end to end .

Only the destination host will rebuild the original packet from fragments.