Check received bytes and see what can escape
03An all-ones result passes this arithmetic check, while some changed messages can still pass.
Separate collision example:0001,f203 changes to 0002,f202 while0dfb stays. Both fold to ffff, illustrating an undetected change without implying all errors pass.
Source for this drawing: RFC 1071 · Read RFC section 1 ↗
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.
To check, sum the same covered octets including the received checksum field. A folded result ffff passes the RFC 1071 check; other results fail (§1). The checksum field remains in place during verification.
- To check, sum the same covered octets including the received checksum field. A folded result ffff passes the RFC 1071 check; other results fail (§1). The checksum field remains in place during verification.
- The five-byte teaching record12 34 97 cb 56 yields1234+97cb+5600=ffff. Changing12 to 13 without changing the field yields a folded result 0100, so the selected checker reports failure. Protocol-specific discard/retry handling is outside this helper.
- Commutativity is useful for implementations but limits error detection: different changes in different words can cancel. In the separate example0001+f203 and 0002+f202 both sum tof204, so the same checksum 0dfb passes. Passing the arithmetic check is not proof that no bytes changed (§2(A); historical IEN45 discussion, pp13–15).
- This checksum has no secret key. Our explicit collision is not a signature or authentication mechanism; a matching sum does not establish who sent the bytes. Do not infer a universal error probability from the historical appendix’s simplified discussion. IEN45 explores alternative codes; it does not replace the Internet checksum algorithm taught here.
Educational arithmetic, not a protocol stack or a portable replacement for old assembly/C. Each protocol defines its own covered octets and checksum-field rules.
Read the RFC section ↗