Separate the sum from the stored checksum
01The Internet checksum groups bytes into 16-bit words. It adds those words with end-around carry, then flips every bit to create the value stored in the checksum field.
~0x22D0 = 0xDD2F within 16 bits. This stored HC is the input available to an incremental updater.
Source for this drawing: RFC 1624 · Read RFC section 2 ↗
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 sum C and stored checksum HC are complements, not the same value.
- RFC 1624 is Informational implementation guidance, not a new Internet Standard. Its + signs mean one’s-complement addition; overflowing high bits return to the low end.
- HC names the old stored checksum; C names the old sum with the checksum field cleared. The tilde ~ means complement all 16 bits. A prime mark means the new value after the edit.
- The RFC’s example has old word m=0x5555 and the sum of all other header words 0xCD7A. Their ordinary sum 0x122CF folds to C=0x22D0; HC=~C=0xDD2F.
A hexadecimal digit represents four bits: 0xFFFF is sixteen 1s. The aggregate “other words” is a sum, not an actual two-byte IPv4 field or a complete header. The checksum field is zero while generating the sum. Supporting RFC 1071 §1 explains generation and carry; this guide focuses on the later incremental correction.
Read the RFC section ↗