Summary

  • An LCP link in Opened state did not imply support for every PPP Protocol value. An unknown value required an LCP Code 8 Protocol-Reject.
  • The reply carried a two-octet Rejected-Protocol and an MRU-bounded portion of the inducing packet’s information, enough to scope the refusal without claiming to reproduce the whole frame.
  • Rejecting an ordinary NCP could be an RXJ+ event within normal operation. Rejecting LCP itself was RXJ-, because the shared control language needed to contain the failure had itself been denied.

The disagreement began after the link had agreed

PPP did not define a point-to-point link as a pipe for only one kind of network packet. RFC 1134, published in 1989, proposed transmitting datagrams from multiple network-layer protocols over the same kind of link. Link Control Protocol established and managed the common carrier. A family of Network Control Protocols configured the particular network-layer uses placed above it.

That separation made a partial contradiction possible. Two peers could have LCP open while one sent a value in the PPP Protocol field that the other did not implement. The receiver had understood the PPP frame well enough to find the type. What it lacked was a handler for that type.

The early specification did not collapse the condition into total link failure. If LCP was Open, the receiver had to send an LCP packet with Code 8, Protocol-Reject, and identify the received protocol. One multiplexed occupant had failed admission; the common link still had a language in which to report why.

RFC 1331 sharpened the distinction in 1992. A supported protocol arriving while its corresponding NCP was not Opened was silently discarded. An unknown Protocol value, by contrast, required Protocol-Reject while LCP was Opened. The first condition concerned phase. The second concerned capability.

Silence consequently proved little. LCP might not be Opened, an NCP might not be Opened, a packet might have been lost, or an implementation might be nonconforming. A visible rejection was narrower evidence too. It did not by itself prove a physical break, failed authentication or loss of every network-layer service. It proved a typed incompatibility inside an established LCP context.

Code 8 returned evidence under the same size contract

The mature packet in RFC 1661 begins with Code 8. Its Identifier must change for each Protocol-Reject sent. Rejected-Protocol occupies exactly two octets and contains the PPP Protocol field from the rejected packet.

Rejected-Information starts with that packet’s Information field. It excludes Data Link Layer headers and the frame check sequence. It must also be truncated to comply with the peer’s established Maximum-Receive-Unit. An error report did not receive permission to exceed the receiver’s negotiated limit simply because it was diagnostic.

The result was enough returned context to recognize the stimulus, not a complete forensic copy. Link-layer fields were absent by definition and the information might end at the MRU boundary. The Identifier was not a durable incident number or a universal correlation token. Protocol-Reject offered bounded, typed evidence: this Protocol value was refused, and this much of its information fit in the control response.

RFC 1548 retained the mechanism in 1993. RFC 1661 stabilized it in 1994. That continuity shows that limited negative evidence was part of PPP’s mature architecture; it does not establish that every product implemented the behavior correctly.

The sender inherited the duty to stop

On receiving Protocol-Reject, RFC 1661 requires an implementation to stop sending packets of the indicated protocol at the earliest opportunity. The phrase leaves room for work that has already entered a queue or the link. It does not turn an explicit capability refusal into an invitation for indefinite retries.

The NCP family makes the scope concrete. RFC 1332 defines IPCP to establish and configure IP over PPP. RFC 5072 defines IPv6CP. They are examples of separate control protocols, not evidence that either was active on a particular observed link.

If one NCP was rejected, its network-layer service could not be treated as available merely because LCP remained Opened. Another protocol could continue only if it was separately supported and properly configured. Containment preserved the chance of other service; it did not manufacture an alternative.

Protocol-Reject could be sent only in LCP Opened. A Protocol-Reject received in any other LCP state should be silently discarded. The state rule was an authority boundary. A refusal could direct the peer only after both sides shared the control context that made the message meaningful.

The same rejection crossed two severity classes

RFC 1331 classified a permitted rejection as RXJ+. A Protocol-Reject of an NCP was its explicit example. The event fell within the scope of normal operation: the implementation stopped the offending packet type, but LCP did not have to terminate.

RXJ- was catastrophic. A Protocol-Reject of LCP itself was an unrecoverable error that terminated the connection. The Code 8 packet had not changed shape. Its object had changed layer.

An NCP could be removed while LCP remained available to describe the removal. If LCP was the protocol the peer claimed not to support, the endpoints no longer shared the language used to configure, test and close the link. The mechanism that localized the failure had become the failure.

This makes “the link stayed up” a deliberately narrow outcome. An application dependent on the rejected NCP might experience complete unavailability even while LCP stayed Opened. Carrier continuity and service continuity were different measurements, and the protocol never promised to make them equal.

The registry decoded a number, not a deployed capability

The current IANA PPP Numbers registry lists LCP Code 8 as Protocol-Reject and records assignments in the PPP Protocol field. It provides authoritative names for numbers. It does not prove that a device implements an assigned protocol, that an NCP has reached Opened, that traffic is being carried or that a present network still uses the feature.

RFC 3818 revised the allocation policy for PPP namespaces to an IETF Consensus process. It demonstrates governance for an extensible protocol family, not deployment. An operational claim needs registry decoding, configuration, state, packet evidence and the behavior that followed the refusal.

The Protocol-Reject history therefore turns on a modest form of honesty. A peer could say exactly what it did not know without pretending the whole link had vanished. That statement remained safe only because it was typed, bounded by the negotiated receiver limit, confined to the proper LCP state and interpreted according to which layer had been rejected.

Sources