Summary
- RFC 793 reserved six TCP header bits for future use and required senders to transmit them as zero.
- RFC 3168 assigned two of those positions to ECE and CWR, creating an endpoint signaling loop for Explicit Congestion Notification while leaving the base header boundary intact.
- RFC 9293 now records four reserved bits and requires unimplemented future bits to be zero when sent and ignored when received.
Empty by rule, not by accident
The original TCP header was already crowded with fields that governed sequence space, acknowledgment, flow control and connection state. Immediately after the four-bit Data Offset, RFC 793 set aside six bits. It did not describe an optional feature hiding there. It called them reserved for future use and required them to be zero.
That instruction established only a small piece of an extensibility contract. A sender had no authority to invent private meanings for the positions. A receiver could see a stable base layout in which the bits carried no standardized signal. The space was therefore inert, but it remained visible in every segment.
This is different from the Data Offset mechanism next to it. Data Offset tells a receiver where the payload begins after a possibly longer header. Reserved bits do not lengthen the header or locate data. They preserve positions inside the fixed portion of the wire image so that a later standards action can assign them.
Two positions acquire a congestion language
RFC 3168 supplied the clearest historical demonstration. It designated bit 9 of the former Reserved field as ECN-Echo, or ECE, and bit 8 as Congestion Window Reduced, or CWR. The six-bit reservation became four bits of still-unassigned space plus two named control flags.
The value was not merely that two spare switches existed. RFC 3168 gave them roles in a larger mechanism. An ECN-capable router can mark an IP packet with the Congestion Experienced codepoint instead of relying only on packet loss. The receiver reports the mark to the sender by setting ECE in a TCP acknowledgment. The sender responds to the congestion indication and then sets CWR to tell the receiver that it has reduced its congestion window.
Negotiation matters. RFC 3168 defines an ECN-capable setup exchange, so the endpoints establish support before treating these bits as operational signals. The allocation did not make every old endpoint understand ECN; it gave cooperating endpoints standardized positions and meanings while preserving the familiar header shape.
The current rule has two directions
RFC 9293's consolidated TCP specification describes four reserved bits rather than RFC 793's six. For features an implementation does not support, it states both sides of the compatibility rule: the bits must be zero in generated segments and ignored in received segments.
Those directions do different work. Zero on transmission prevents an implementation from emitting accidental or private signals into unassigned space. Ignore on receipt prevents a host that lacks a future feature from treating the mere presence of its bit as a malformed base TCP segment. Together, they protect a narrow evolutionary lane between unauthorized invention and automatic rejection.
IANA's TCP Header Flags registry supplies the allocation boundary. RFC 9293 lists CWR and ECE with the six familiar control flags and retains offsets 4 through 7 for future use. A reserved position is thus not ownerless. Its future meaning depends on a public specification and managed assignment.
What the mechanism does not prove
The clean standards progression can be overstated. Reserved space does not guarantee deployment. Middleboxes can make assumptions that differ from endpoint rules; implementations can lag; a new flag may need negotiation, state-machine changes and operational evidence beyond the bit itself. The cited RFCs do not measure those deployment frictions.
Nor does the 1981 reservation show that TCP's designers predicted ECN. The defensible historical claim is narrower: they preserved wire positions for future control use, and a later standard used two of them for a specific congestion-feedback mechanism.
That distinction is the lasting design lesson. Extensibility is not produced by spare bits alone. It depends on disciplined default behavior, a recognized assignment process and explicit semantics when the space is finally used.
Sources
- RFC 793, “Transmission Control Protocol” (September 1981)
sources/rfc793.txt - RFC 3168, “The Addition of Explicit Congestion Notification (ECN) to IP” (September 2001)
sources/rfc3168.txt - RFC 9293, “Transmission Control Protocol (TCP)” (August 2022)
sources/rfc9293.txt
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
