Distinguish generation from receiver verification
04A receiver can sum the received header including its checksum and look for all ones. That is different from regenerating a checksum and comparing its bits to the received field.
Regeneration gives 0x0000 while the old shortcut’s received field is 0xFFFF. That bit-comparison implementation sees a mismatch.
Source for this drawing: RFC 1624 · Read RFC section 5 ↗
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.
A receiver passing this example does not prove the updater produced the canonical bits.
- Section 5 recommends receiver verification as in RFC 1071: include the checksum field in the one’s-complement sum, and compare the result with 0xFFFF.
- For the published edited-header sum 0xFFFF, adding either 0x0000 or 0xFFFF leaves a folded sum of 0xFFFF. Both pass that sum check in this specific example.
- A receiver which instead regenerates a checksum with the field cleared obtains 0x0000, so comparing that value with the old shortcut’s 0xFFFF exposes the difference. RFC 1624 recommends corrected update and all-ones verification; it does not introduce a normative MUST to use a particular implementation.
The states are separate verification cases over the same worked header sum, not successive accept/reject events on one packet. Recompute-and-compare is shown because the RFC reports such implementations, not as the recommended algorithm. Neither check authenticates the sender or substitutes for protocol-specific validation.
Read the RFC section ↗