Bound the implementation and its promises
05A wider machine accumulator still has to implement sixteen-bit complements and repeat carry folding. A checksum update follows the changed word; it does not prove authenticity or define every transport’s checksum encoding.
Toy words0x0001,0x0002 and0x0002,0x0001 both sum to3 and produce0xFFFC. Matching checksums do not authenticate content or its sender.
Source for this drawing: RFC 1624 · Read RFC section 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.
Keep the arithmetic width, covered bytes and security purpose explicit.
- Limit every complement to 16 bits. Fold high carry bits back until none remain; one fold is not always enough for three summed words. These are the one’s-complement arithmetic operations used by the RFC, not ordinary truncation.
- The unchanged-value case remains valid with correct arithmetic: HC=0x0000, m=m′=0x5555 updates to 0x0000. Do not invent a prohibition on a no-op replacement from an unapproved erratum.
- The errata list has three Held for Document Update reports (4782, 5864, 5865), not verified corrections. Their discussion concerns no-op arithmetic, repeated carries and complement width; the drawing demonstrates the underlying arithmetic without promoting their proposed text to an approved requirement.
The TTL (Time to Live) example edits one byte in its 16-bit word together with the unchanged Protocol byte; header bytes are in network order. The chosen fixture shows only the 20-byte IPv4 header: Total Length40 includes 20 payload bytes not shown, and this checksum covers the header only. Source192.0.2.10 and destination198.51.100.20 are documentation addresses, not live hosts. Equation 4 is a recommended alternative with borrow semantics; no machine-speed benchmark is claimed. RFC 1624 §8 does not discuss security. The separate collision example is a direct mathematical consequence of the checksum sum, not a cryptographic design or a live attack.
Read the RFC section ↗