Separate coverage from correctness
04The receiver validates the datagram format and checksum before passing the payload to an application willing to receive this coverage. A successful checksum says nothing about bytes outside its coverage.
An all-zero transmitted Checksum is invalid; it cannot mean checks disabled.
Source for this drawing: RFC 3828 · Read RFC section 3.3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The receiver interface should expose coverage or allow an application to block datagrams below its chosen coverage threshold. This teaching example assumes explicit opt-in at both ends.
- The receiver interface should expose coverage or allow an application to block datagrams below its chosen coverage threshold. This teaching example assumes explicit opt-in at both ends.
- The Internet checksum detects many accidental errors but is not a cryptographic authenticity test, and some multi-bit changes can collide.
- These are separate one-bit-damage examples after delivery by a suitable lower layer; the next chapter explains when that delivery is possible.
A codec is free to reject unusable data after transport checks. No successful checksum authenticates a sender, repairs damaged bytes, or establishes that an unchecked tail is correct.
Read the RFC section ↗