Protocols which involve bits from the IPv4 or IPv6 headers in their checksums

I wanted to know which protocols might follow an IPv4 or an IPv6 IP header,
and whether or not they used any IP header bits in their checksum calculations.

I looked through the list of protocols at:

http://www.iana.org/assignments/protocol-numbers
http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

and selected those I recognised as likely to be used within IPv4 or IPv6.
Hopefully I haven't missed any significant protocols - at least as far as a
map-encap like scheme is concerned.

Here is what I found. The * points list the contents of the pseudo headers
which are constructed in order to contribute to the checksum calculation.

Those in bold are items from the IPv4 or IPv6 header, indicating that
changing these items in the IPv4 or IPv6 header will cause the resulting
packet not to pass the verification of the checksum in the header of the
higher layer protocol.

Protocols

Summary

This summary ignores loose or strict source routing (IPv4) and these Routing Extension Header (IPv6).

For both IPv4 and IPv6, changing any of the bits in the IP header for any of:

Source address.
Destination address.
Next Header (specifies the higher level protocol header to follow).

will result in a packet in which the checksums in the headers of the following protocols will fail to match the packet:

ICMPv6
UDP (However, UDP can be sent with no checksum with IPv4)
TCP
DCCP
UDP-Lite

In addition to the Source/Destination Addresses and the Next Header field, IPsec AH also applies the selected Integrity Check algorithm to these fields:

IPv4:

Protocol (1000).
Header Length.
Packet length.
Identification.

IPv6:

Protocol (1100).
Packet Length.

Notes

Note 1 IPv4 UDP/TCP Length

The "pseudo header" which is used as part of certain protocols (TCP and UDP)
calculating the checksum which appears in their headers is generally
referred to as containing information from the IP header which precedes it
(IPv4 originally). However, the Length field in this "pseudo header" does not
come from the IP header at all.

A 96 bit "pseudo header" is defined for the TCP checksum in:

http://tools.ietf.org/html/rfc793 Pages 16 & 17.

     +--------+--------+--------+--------+
     |           Source Address          |
     +--------+--------+--------+--------+
     |         Destination Address       |
     +--------+--------+--------+--------+
     | zero | PTCL |    TCP Length   |
     +--------+--------+--------+--------+

and a similar one is defined for UDP in:

http://tools.ietf.org/html/rfc768 Page 2.


      0      7 8     15 16    23 24    31
     +--------+--------+--------+--------+
     |          source address           |
     +--------+--------+--------+--------+
     |        destination address        |
     +--------+--------+--------+--------+
     | zero |protocol|   UDP length    |
     +--------+--------+--------+--------+

In both cases, the xxP Length values are the length of UDP or TCP
headers plus any following data.

In the case of UDP, this is easy, since the UDP header contains
such a field.

The TCP header contains no Length field. The specification for
how to calculate the value of the 16 "TCP Length" bits is:

      The TCP Length is the TCP header length plus the data length in
      octets (this is not an explicitly transmitted quantity, but is
      computed), and it does not count the 12 octets of the pseudo
      header.

Note 2 IPv6 "Upper-Layer Packet Length"

The section on "Upper-Layer Checksums":

    http://tools.ietf.org/html/rfc2460#section-8.1

specifies the creation of a pseudo header for use by upper layer protocols such
as UDP, TCP etc. when calculating the checksum which goes in those protocols'
headers.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Upper-Layer Packet Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      zero                     | Next Header |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Destination address doesn't necessarily come from the IPv6 header:

      o If the IPv6 packet contains a Routing header, the Destination
         Address used in the pseudo-header is that of the final
         destination. At the originating node, that address will be in
         the last element of the Routing header; at the recipient(s),
         that address will be in the Destination Address field of the
         IPv6 header.

Nor does the Next Header item, due to there being potentially one or more
extension headers between the IPv6 header and the UDP, TCP etc. header:

      o 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 between the IPv6 header and the upper-
         layer header.

The Upper-Layer Packet Length is actually the same as for IPv4, but is
specified in a rather different manner:

      o The Upper-Layer Packet Length in the pseudo-header is the
         length of the upper-layer header and data (e.g., TCP header
         plus TCP data). Some upper-layer protocols carry their own
         length information (e.g., the Length field in the UDP header);
         for such protocols, that is the length used in the pseudo-
         header. 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.

Note 3 UDP-Lite's Pseudo Header's "Length" field

UDP-Lite's checksum calculation includes a "pseudo header" like that specified
for TCP and UDP - see Notes 1 & 2 above.

The Length field in the UDP-Lite pseudo header is a count of the number of
octets in the UDP-Lite header and of any data which follows it. Described this
way, this is the same as with UDP.

The UDP header has a Length field, equal to the length of the UDP header and
the data which follows.

The UDP-Lite header does not have such a Length field.

So while it is sufficient to specify the value of the UDP pseudo header's
length field as being the same as the UDP header's length field, this won't do
for UDP-Lite. The specification is:

   http://tools.ietf.org/html/rfc3828#section-3.2

     The value of the Length field of the pseudo header is not taken
     from the UDP-Lite header, but rather from information provided
     by the IP module. This computation is done in the same manner
     as for TCP [RFC-793], and implies that the Length field of the
     pseudo header includes the UDP-Lite header and all subsequent
     octets in the IP payload.