RFC 1122
CURRENTRequirements for Internet Hosts — Communication Layers
R. Braden (ed.), IETF Host Requirements WG · October 1989 · original status: Standard · current status: Internet Standard (STD 3)
updated by: RFC 1349, RFC 4379, RFC 5884, RFC 6093, RFC 6298, RFC 6633, RFC 6864, RFC 8029, RFC 9293
Still a live Internet Standard (STD 3) — the closest thing TCP hosts have to a law book. Repeatedly updated (RTO → RFC 6298, urgent pointer → RFC 6093, source quench retired → RFC 6633, core TCP text → RFC 9293); this module teaches the TCP sections as amended.
This module teaches CURRENT behaviour
This document
- RFC 1122 §1.3.2 — MUST / SHOULD / MAY terminology
- RFC 1122 §4.2.3.2 — when to send an ACK (delayed ACK rules)
- RFC 1122 §4.2.3.3 — when to send a window update (receiver SWS avoidance)
- RFC 1122 §4.2.3.4 — when to send data (sender SWS avoidance + Nagle)
- RFC 1122 §4.2.2.17 — zero-window probing (MUST)
- RFC 1122 §4.2.3.6 — keep-alives (MAY, default off, ≥ 2 h)
Where the current rules live
- RFC 9293 (updates 1122's TCP text; the host requirements remain STD 3)
Host Requirements — the TCP Law Book
New to these ideas? Switch to the beginner level for a from-zero concept primer.
The problem this document answered
RFC 1122 turned a decade of hard-won implementation lessons (including RFC 813's and 896's) into graded requirements. Its §4.2 is where delayed ACKs got their 0.5 s bound, SWS avoidance became mandatory, zero-window probing became a MUST, and keepalives were tamed. Reading captures against it is how you judge a stack 'compliant'.
Historical context
Produced by the IETF Host Requirements working group (R. Braden, ed., October 1989) as one of two companion volumes (1122 communication layers, 1123 applications). It elevated the best fixes of the memo era into obligations and remains the reference point 'compliant TCP' is measured against.
Current practice
STD 3, current, amended nine times. RFC 9293 now carries the core TCP text but explicitly updates — not replaces — the host requirements. The MUST/SHOULD/MAY vocabulary (later formalised for authors by RFC 2119) started here as enforceable grades.
Interactive laboratory
Requirement language (RFC 1122 §1.3.2)
- MUST / MUST NOT
- Absolute requirement or prohibition. Violating it is non-compliance — expect interoperability failures. (Also written REQUIRED / SHALL.)
- SHOULD / SHOULD NOT
- Do it unless you have understood, weighed, and can justify the exception for your specific case. 'We didn't get around to it' is not an exception.
- MAY
- Truly optional; implementations choose based on their needs. Peers must interoperate whether or not the option is present (e.g. keepalives).
Guided walkthroughs — coached, packet by packet
Watch it on the wire
A 4-segment transfer with RFC 1122 §4.2.3.2 delayed ACKs: one ACK per two full segments, and a lone trailing segment ACKed only when the 200 ms timer expires.
The receiver's window closes and stays closed for three seconds. A compliant sender probes it — 500 ms, then 1 s, then 2 s — so the reopening can never be lost, then finishes the transfer.
Every data segment is being lost, and this sender retries at a FIXED interval instead of doubling it. Read the timer events: is this host compliant?
Data arrives intact — and vanishes. No ACK ever covers it. Watch the sender retry with growing patience and finally give up. Which host broke the rules, and which packets prove it?
The receiver advertises window 0 — and this sender keeps transmitting anyway. Watch the receiver discard the overrun segments and re-ACK the same edge, over and over.
The server app sips 200 bytes at a time and the stack advertises every tiny opening (no SWS avoidance) — watch the connection degenerate into 200-byte crumbs.
Identical sipping application, but the stack follows RFC 9293: window updates held until worth advertising, no crumb segments sent. Same app, healthy wire.
Compare correct vs historic / naive behaviour
The same 4½-segment transfer ACKed two ways: a receipt per segment versus RFC 1122's one-per-two-full-segments with a bounded timer.
⇄ Silly Window Syndrome vs SWS avoidanceThe identical sipping application on a historic stack (every tiny window opening advertised) and on an RFC 9293-compliant stack (updates held, crumbs suppressed).
Original RFC vs current standard
Requirement force
- Original behaviour
- The memo era (813/879/896): good algorithms as advice; adoption voluntary and spotty.
- Current behaviour
- RFC 1122: the same algorithms as graded MUST/SHOULD requirements with a compliance checklist.
- What changed
- Advice became law with an explicit severity scale.
- Why it changed
- Voluntary adoption failed — one bad host on a shared path taxes everyone (SWS, tinygrams, ACK storms).
📷 In a capture: Modern captures look uniform across vendors precisely because the MUSTs constrain them; violations stand out like fingerprints.
Common misconceptions
- ✗“SHOULD means optional” — it means mandatory unless you can defend the exception in writing; casual deviation is non-compliance in spirit.
- ✗“RFC 9293 replaced RFC 1122” — 9293 UPDATES it; the host-requirements layer remains STD 3.
- ✗“Keepalives are a TCP feature that's always running” — they're a MAY, default OFF, minimum two hours, only if the application asks.
- ✗“A compliant stack can't perform badly” — compliance sets the floor; quality-of-implementation still varies widely.
Glossary terms used here
Knowledge check
1/5 · A capture shows a receiver holding its ACK for 800 ms after a lone data segment. Compliant?
2/5 · Which behaviour would make a SENDER non-compliant with the host requirements?
3/5 · Compliance verdict — open 'Compliance case · No exponential backoff' in the explorer. The timer_set events read 1000, 1000, 1000 ms while every retry is lost. Your ruling?
4/5 · Compliance verdict — in 'The receiver that never acknowledges', data arrives (recv events exist) yet no ACK ever covers it and the sender eventually gives up. Which host violated what?
5/5 · The peer advertises window 0 for ten minutes. What does a compliant sender do?