IPv6 Extension Headers and UDP/TCP/ICMPv6 Checksums

Question

Should the checksum for IPv6 packets (UDP, TCP, ICMPv6, etc.) change if extension headers are present? For example, will a UDP packet without a Hop-By-Hop extension header have a different checksum than an identical UDP packet with a Hop-By-Hop extension header added?

Here's my problem:

+---+       +---+       +---+
| A | ----> | B | ----> | C |
+---+       +---+       +---+

I have 3 devices:

• A is sending a UDP packet to C. The UDP packet does not contain a Hop-By-Hop extension header.
• B receives A's UDP packet, adds a Hop-By-Hop extension header and forwards the modified packet to C.
• C rejects the packet because of an invalid checksum.

The source of my confusion comes from the Wikipedia pages for UDP, TCP, and ICMPv6 which state that the checksum is computed with a pseudo-header where the next header field is set to the protocol: 17 for UDP, 6 for TCP, 58 for ICMPv6.

My interpretation of the above is that the pseudo-header does not depend on the packet's next header field. Therefore, Device C is incorrectly computing the checksum.

Answer 1

If I understand you question correctly, you want to ask the following:

Is the "next header" field in the "pseudo-header", which is used for TCP checksum calculation, identical to the "next header" field in the IPv6 header?

This would mean that the TCP checksum depends on the extension headers because the value used for checksum calculation would be 6 for TCP if there are no extension headers and 44 if there is a fragmentation header...

Or is it identical to the "next header" value describing the layer-4 protocol (e.g. 6 for TCP)?

This means that the TCP checksum does not depend on the extension headers.

RFC 8200 (see Ron Maupin's answer) states:

The Next Header value in the pseudo-header identifies the upper-layer protocol (e.g., 6 for TCP or 17 for UDP). It will differ from the Next Header value in the IPv6 header if there are extension headers ...

This means that the content of the "pseudo-header", which is used for TCP checksum calculation, does not depend on the extension headers. Therefore, the TCP checksum itself does also not depend on the extension headers.

Answer 2

Should the checksum for IPv6 packets (UDP, TCP, ICMPv6, etc.) change if extension headers are present?

IPv6 packets do not have checksums. That was one of the improvements made for IPv6, so that the routers between the source and destination do not need to calculate the checksum to see if the packet header is corrupt, not do they need to recalculate the checksum when decrementing the Hop Count field.

If you mean the transport protocol datagram, that is just the payload of the IPv6 packet, and IPv6 really has no idea what is in its payload. The transport protocols will build a checksum, and it is based on the pseudo header that include the IPv6 source and destination addresses. That has nothing to do with extension headers.

B receives A's UDP packet, adds a Hop-By-Hop extension header and forwards the modified packet to C.

Intermediate routers do not add extension headers, and in fact, must ignore extension headers, except the Hop-by-Hop extension header. All the other extension headers are for the destination host. Having the intermediate node (B) insert an extension header is not allowed. See RFC 8200, Internet Protocol, Version 6 (IPv6) Specification:

Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

It appears that your Host B, which is inserting an extension header (in violation of the IPv6 standard), is not updating the Payload Length in the IPv6 header. The Payload Length field is the size of the packet payload, including the the extension headers. That would really mess up the TCP pseudo-header length field, and that could be the source of your checksum error:

Other protocols (such as TCP) do not carry their own length information, in which case the length used in the pseudo-header is the Payload Length from the IPv6 header, minus the length of any extension headers present between the IPv6 header and the upper-layer header.

In any case, Host B should not be modifying anything in the IPv6 packet, other than decrementing the Hop Limit field in the IPv6 packet header. What you say it is doing violates the IPv6 standard, and you should not expect it to work correctly.