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
- Treat the data as a sequence of 16-bit big-endian integers; pad the last byte with zero if needed.
- Sum them with carries wrapped around (one’s-complement addition).
- 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
| Output | 16 bits |
|---|---|
| Standard | RFC 1071 (1988); RFC 1141, 1624 (incremental updates) |
| Throughput | Trivial; computable in hardware at any line rate |
| Status | Non-cryptographic; minimum-viable accidental-corruption detector |
Where it shows up
- IPv4 header , the
Header Checksumfield (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.