Summary

  • In RFC 2509's inherited TCP_SPACE and NON_TCP_SPACE fields, zero was the maximum context identifier, so it still represented one context: identifier 0.
  • RFC 3544's three-octet suboption 3 could instead set the TCP or non-TCP context count to zero, overriding the older field and disabling that class.

The mismatch was easy to miss because the field name sounded like a count. It was not. TCP_SPACE and NON_TCP_SPACE encoded the maximum context identifier—the top value in a numbered space. If that maximum was zero, the space still contained CID 0. One context remained available. That was useful for a minimal configuration, but it left no way to express “compress this class not at all” through those fields alone.

RFC 3544, published in July 2003 as a Proposed Standard, updated RFC 2509's PPP negotiation option without redefining this legacy meaning. Suboption 3 supplied the missing distinction. Its type is 3, its length is 3 octets, and its one-octet parameter selects which context family to disable: value 1 says zero TCP contexts; value 2 says zero non-TCP contexts. The suboption overrides the corresponding TCP_SPACE or NON_TCP_SPACE value. Include both parameter values and compression is disabled for all packets.

This is a compatibility repair through an explicit override, not a reinterpretation of zero. An implementation can preserve the old field's established meaning while receiving the answer the field could not carry. The proposal matters precisely because a plausible-looking value was already occupied: changing it would make old peers disagree about the same bits.

The setting travels through two NCPs

PPP negotiates link parameters with Network Control Protocols. RFC 3544 defines the same compression-option format for IPv4's IPCP and IPv6's IPV6CP. Each NCP sets parameters for packets whose outer network header is that version. Thus “IPv4 compression negotiated” and “IPv6 compression negotiated” are separate control-plane results, not one universal switch.

There is a further wrinkle: IPv4 and IPv6 share a context-identifier space even though the NCP parameter values are negotiated independently. When their values differ, the compression engine must allocate from a common pool and the decompressor must use context state to interpret a packet. TCP and non-TCP/UDP/RTP, by contrast, do not share a context space. These are implementation constraints specified by the protocol, not proof that a particular peer configured or exercised them.

RFC 3544 also adds an enhanced-RTP negotiation suboption, type 2, used instead of—not alongside—the older RTP suboption 1. Along with the nine PPP protocol-field values, these options tell the receiver how a frame is classified and which negotiated forms may be used. The protocol field is the demultiplexing surface; the suboption is configuration intent.

What a negotiated option does not show

The RFC's option enables use of named protocol identifiers after successful negotiation. That does not show that an implementation sent a compressed frame, that the far end decoded it, that the datagram was delivered, or that the packet became smaller. Those are different observations at different points in the path. A configuration exchange is evidence of an agreed parameter set, not a traffic receipt.

The document is careful about one neighboring ambiguity: RFC 1332 does not say whether the option describes the sender's or receiver's capabilities. RFC 3544 says it assumes, in keeping with practice, that a Config-Req describes the sending peer's decompressor. That sentence is an explicit assumption, not a new normative clarification of RFC 1332. Treating it as stronger would erase the specification's own caveat.

The data path has its own condition. IPHC uses delta encoding for TCP and RTP, and delta-coded packets depend on context at both ends. PPP itself does not reorder packets, so the reordering safeguards are disabled by default. If multiclass Multilink PPP or another reordering mechanism is used, packets sharing a compression context must not be reordered. Negotiating a format cannot remove that transport constraint.

The historical point is modest: protocol evolution sometimes needs a second signal because the obvious value already has a valid old meaning. RFC 3544 kept the field stable, added an override, and left capability, packet use, decoding, delivery and performance as separate claims to verify.

Sources