Checksum

Internet checksum

The 16-bit one’s-complement sum that sits in the header of every IPv4 packet, every ICMP packet, and every UDP / TCP segment. Specified in RFC 1071 (1988) by Braden, Borman, and Partridge. Designed for hardware that could not afford to do CRC at line rate; still adequate for the small failures it was built to catch.

How it works

1. Treat the data as a sequence of 16-bit big-endian integers; pad the last byte with zero if needed.
2. Sum them with carries wrapped around (one’s-complement addition).
3. Take the one’s complement of the result. That’s the checksum.

At the receiver, sum everything including the checksum field; a valid packet sums to 0xFFFFin one’s complement (equivalently, 0 after taking the one’s complement of the sum).

At a glance

Where it shows up

• IPv4 header , the Header Checksum field (the IP payload is not covered).
• ICMP , covers the entire ICMP message.
• UDP / TCP , covers header + payload + a pseudo-header bridging the IP layer.
• IPv6 , no header checksum (relies on the link layer and upper-layer checksums).

Limitations

• Misses any two-byte error that swaps equal magnitudes between positions.
• Misses byte reordering (commutativity is built in).
• Trivially defeated by adversaries.
• Routers historically had to recompute it on every hop because IPv4 TTL decrements; IPv6 dropped it for this reason.

Incremental updates

Because one’s-complement addition is associative and commutative, you can update an Internet checksum after a small change without rehashing the whole thing , just subtract the old word and add the new one (RFC 1141, 1624). Critical for routers that adjust the TTL field on every hop.

References

• RFC 1071 , Computing the Internet Checksum
• RFC 1141 , Incremental Updating of the Internet Checksum
• RFC 1624 , Computation of the Internet Checksum via Incremental Update
• CRC-32 · Fletcher