Visual RFC.
ALL RFCs / RFC 1071
Read the RFC ↗
RFC 1071 / INTERNET CHECKSUM

Pair bytes and clear the checksum field

01

Treat adjacent bytes as 16-bit words, preserving their positions and handling a final unpaired byte.

RFC 1071 · § 1EXAMPLE
4 / 4
Pair bytes and clear the checksum fieldThe16-bit complement of6834 is97cb. It is written into the original field while the final byte56 remains unpaired in the actual five-byte record.Pair bytes without changing the messageFolded sum 6834Flip all 16 bitsChecksum 97cb12 3497 cb56Store in original offsets 2–3Record length stays five bytesRFC 1071 · chapter 1 · state 4 · arithmetic example
04
Write the complemented sum

Flip all16bits of 6834 to get97cb. Store97 cb in offsets 2–3; keep the final56 as one byte, leaving five transmitted record bytes.

Source for this drawing: RFC 1071 · Read RFC section 1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

An octet is eight bits; two adjacent octets a,b make the 16-bit word a×256+b. Hexadecimal writes one byte with two digits. The final byte of an odd-length input occupies the high byte of [last,0] for this network-order model (§1).

  • An octet is eight bits; two adjacent octets a,b make the 16-bit word a×256+b. Hexadecimal writes one byte with two digits. The final byte of an odd-length input occupies the high byte of [last,0] for this network-order model (§1).
  • The zero paired with an odd final byte is for calculation. It is not an extra byte inserted into the message. Clear the actual checksum field before generating its value, then put the complement of the folded sum into that field (§1).
  • Our five-byte teaching record is 12 34 | checksum | 56, with an aligned two-byte field at offsets 2–3. It is not a complete IP, UDP or TCP header. Those protocols determine which header, data and pseudo-header octets are covered; RFC 1071 supplies arithmetic, not a universal packet layout.
  • RFC 1071 is an Informational implementation memo, not an Internet Standard or a BCP14 MUST/SHOULD/MAY specification. These algorithm steps describe how this checksum works; historical optimization suggestions are not new protocol mandates.
DETAILS

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 ↗

All chapters in RFC 1071

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗