Summary

  • RFC 768 gave zero two deliberately different meanings: a computed zero became all ones, while an all-zero field declared that no checksum had been generated.
  • Reports of undetected errors turned a local efficiency choice into an end-to-end evidence problem; IPv6 therefore made the UDP checksum the default requirement.
  • The later IPv6 tunnel exception is not ordinary UDP freedom. It is port-scoped, endpoint-configured and accompanied by integrity, path and security duties.

The field could decline to testify

UDP's eight-byte header looked minimal, but its checksum covered more than payload. RFC 768 prefixed a conceptual IP pseudo-header containing source and destination addresses, protocol number and UDP length. The result could detect damage and also the accidental delivery of a datagram to the wrong network endpoint.

One's-complement arithmetic can calculate a result of zero. The specification reserved all ones for that valid result. A field of all zeroes meant something else: the transmitter had generated no checksum, perhaps for debugging or because a higher layer did not care.

That encoding matters historically. Zero did not say “the data passed.” It said that this layer supplied no verdict.

A private saving created a public blind spot

RFC 1122 still allowed an application to control checksum generation, but required checksumming to be on by default. Its discussion recorded numerous undetected errors after applications confined to local-area networks turned the checksum off for efficiency.

The sender saved work immediately. Every receiver, application and operator downstream lost an independent way to reject corruption or misdelivery. A local choice changed the evidence available to strangers who had not approved it.

This is the difference between mechanism and authority. UDP could represent absence; that did not prove that one endpoint should decide, for an unknown path and an unknown receiver, that the evidence was dispensable.

IPv6 restored a minimum common verdict

IPv4 checked its own header, though not the UDP payload. IPv6 deliberately has no internet-layer header checksum. RFC 2460 therefore made UDP's checksum mandatory and told receivers to discard packets whose checksum field was zero. The transport checksum's pseudo-header became part of the protection for the IPv6 addresses and delivery context.

RFC 8200 preserves that default. An IPv6 originator computes the checksum and converts a computed zero to hexadecimal FFFF; a receiver discards a zero-checksum UDP packet and should log the error.

The change was not a claim that a 16-bit checksum authenticates a sender. It does not. It was a decision that minimum delivery evidence should not disappear merely because the sender preferred less work.

Partial coverage disclosed what it left exposed

Some media applications prefer a damaged payload to no payload. UDP-Lite, standardised in RFC 3828, answered that need without pretending the risk had vanished. The application can choose partial coverage, yet the UDP-Lite header and IP pseudo-header remain inside the checksum. An all-zero transmitted checksum is forbidden.

The protected and unprotected regions are therefore declared. A receiver opts into partial coverage and can set its own minimum. The design localises the choice instead of converting “no evidence” into a universal convention.

The tunnel exception named its owners

High-speed tunnel endpoints sometimes need to encapsulate already protected packets without reading an entire outer payload. RFC 6935 updated IPv6 to permit a zero UDP checksum in constrained situations, primarily tunnel transports. RFC 6936 supplied the missing constitution.

Zero mode remains disabled by default. An application or protocol selects the sending and receiving ports. A receiving port that accepts zero must also accept calculated checksums. Designers must consider checksummed UDP and UDP-Lite first, protect control information and state, account for fragmentation and corruption, verify paths that may contain intolerant middleboxes, and resist injection or overload.

These rules change the locus of permission. The exception belongs to a named tunnel relationship whose endpoints and operator can configure, monitor and withdraw it. It is not a blank cheque carried by every sender into the public Internet.

Sources and limits

The history is documented in RFC 768, RFC 1122, RFC 2460, RFC 3828, RFC 6935, RFC 6936, RFC 8085 and RFC 8200. They establish protocol rules and recorded concerns, not uniform deployment or a measured global error rate. The checksum detects classes of accidental corruption; it is not cryptographic authentication.