Summary

  • IPv4's 16-bit checksum covers the header only, protecting the information used to process and forward a datagram while leaving payload errors to other mechanisms.
  • Every processing point verifies it and recomputes it after mutable fields change; a later incremental-update correction preserved exact one's-complement behavior at the two representations of zero.

Protecting the forwarding decision

RFC 791 defines the checksum as the one's complement of the one's-complement sum of every 16-bit word in the IPv4 header. During the calculation, the checksum field itself is treated as zero. The result occupies 16 bits in the header that routers already need to parse.

Its scope is deliberate. The header carries the destination, length, fragmentation state, lifetime and protocol identifier used to handle the datagram. RFC 791 says the checksum verifies that this processing information was transmitted correctly, while explicitly allowing that the data may still contain errors. If the header check fails, the detecting entity must discard the datagram immediately.

IPv4 is therefore not claiming end-to-end integrity for the packet's contents. It places a guard around the network-layer control information whose corruption could misdirect forwarding or make the header internally inconsistent. Payload protection belongs to whatever other link, transport or application mechanism is present; the IPv4 checksum says nothing about which one exists.

A checksum that cannot stay fixed

Unlike an end-to-end seal, the IPv4 header checksum changes legitimately in transit. Time to Live is reduced as routers process the datagram. Fragmentation creates new headers. Source routing and address modification can alter other covered words. RFC 791 consequently requires the checksum to be recomputed and verified at every point where the Internet header is processed.

That rule makes the checksum local and renewable. A router first checks the header it received, performs the permitted header transition, and leaves a checksum consistent with the header it forwards. The next processing point can repeat the same discipline without needing the original header.

The design also exposes a cost. Recomputing a sum over the whole header after changing one word is simple, but not always necessary. An implementation can update the checksum from the old value and the changed field instead—provided the shortcut is arithmetically identical to starting again.

The edge case hidden in zero

RFC 1624 documented why that proviso mattered. Incremental update is useful for routine operations such as TTL changes, fragmentation and source-route updates. Yet the method standardized in RFC 1141 could produce a different stored checksum from full recomputation in a narrow case.

The cause was one's-complement arithmetic, which has two representations of zero: all zero bits and all one bits, conventionally called positive and negative zero. A formula that distributed complementation as if the arithmetic had only one zero could select the wrong representation. Some verification methods still accepted the packet, but implementations that computed the checksum and compared the stored field could observe the difference.

RFC 1624 corrected the incremental equation and recommended it for intermediate systems. The wire field did not change. What changed was the implementation rule needed to guarantee that the fast path produced the same checksum as a complete recomputation.

Sources