Keep the two zero representations distinct
03One’s-complement arithmetic has two bit patterns for zero. The older shortcut can return all ones when a fresh IPv4 header checksum calculation returns all zeros.
Equation 3 yields 0x0000; old Equation 2 yields 0xFFFF. Use the corrected result before storing this example’s header checksum.
Source for this drawing: RFC 1624 · Read RFC section 4 ↗
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 numerical zero equivalence does not guarantee the same stored bit pattern.
- 0x0000 is called +0; 0xFFFF is called −0. With a nonzero field in the IPv4 header, the generated checksum can be 0x0000 but cannot be 0xFFFF, as explained in §3.
- The old Equation 2, HC′ = HC + m + ~m′, assumes a distributive step that fails at this zero boundary. It gives 0xFFFF for the RFC’s example instead of the fresh calculation’s 0x0000.
- This is a computation mismatch, not a claim that every receiver rejects such a packet. Section 5 separately explains why an all-ones-sum verifier can accept either representation in this example.
This chapter is about the IPv4-header context used by the RFC, whose other fields ensure a nonzero sum input. Do not generalize “0xFFFF can never occur” to all possible toy buffers or to protocol-specific encodings. The rejected path means “do not generate with the old shortcut”; it is not a simulated network error.
Read the RFC section ↗