Summary

  • A PPP Configure-Ack was not allowed to improve, reorder or reinterpret a proposal. It had to repeat the latest Configure-Request exactly, turning acceptance into byte-level evidence rather than an inference.
  • Link Control Protocol agreement was bilateral. Each endpoint negotiated principally for its own receive direction, and Opened required an Ack both sent and received; a Nak offered another value, while a Reject ended negotiation for the listed option.

An acceptance that changed one number was not an acceptance

Imagine one endpoint asking to receive frames no larger than a stated Maximum-Receive-Unit. The peer likes the idea but writes a slightly different size into its Configure-Ack. To a human reader, that might look like a reasonable compromise. To PPP, it is an invalid reply.

RFC 1661 requires a valid Configure-Ack to copy the Identifier of the latest request and reproduce its options in the same order, without modification. Every option must already be recognisable and acceptable. The receiver may say yes, but it may not edit while saying yes.

This severity solved a distributed-state problem. If an Ack could contain improvements, the sender would have to decide whether the reply accepted its request, replaced it, or accidentally described some third configuration. Packet loss and crossed messages would make that guess harder. Exact repetition instead gives both sides one narrow test: these bytes are the proposal that was accepted.

An Identifier binds the answer to an attempt. It changes when the option contents change and after a valid response to the preceding request; a retransmission may reuse it. The number does not authenticate the peer. It prevents one conversation about configuration from being mistaken for another.

A counterproposal needed a different verb

PPP did not force every disagreement into rejection. Configure-Nak exists for an option that is understood and negotiable but carries an unacceptable value. The Nak lists the unacceptable options and can replace their values with ones its sender would accept. It may also ask for a locally required option that the requester omitted.

That reply is not an edited Ack. It does not alter the outstanding request on the wire or make the suggested value effective. The requester must decide whether to send a new Configure-Request. New content receives a new Identifier, creating a fresh proposition that can be acknowledged exactly.

Configure-Reject expresses a harder boundary. It applies when an option is unrecognised or not open to negotiation under local administration. The rejected option is copied from the request, rather than rewritten into a preferred substitute. In the next attempt the requester should remove it.

The distinction carries authority. A Nak says, “I understand this question and could agree within another range.” A Reject says, “This is not a question this endpoint will negotiate.” Boolean options, which have no alternative value to suggest, use Reject. Neither response licenses the peer to change local policy invisibly.

One wire contained two negotiations

The phrase “negotiate a link” sounds singular. LCP made it two-sided. Unless an option specifies otherwise, it applies in a half-duplex fashion, typically to the receive direction viewed from the Configure-Request sender. Endpoint A proposes how it is prepared to receive traffic from B. Endpoint B sends its own request about traffic in the other direction.

The two proposals can cross. A may receive an exact Ack for its request while still deciding whether to Ack, Nak or Reject B's request. RFC 1171 already named that condition Ack-Received: an Ack has arrived, but the endpoint has not yet transmitted one. Receiving consent did not manufacture consent in the reverse direction.

By RFC 1331, the Link Establishment rule was explicit: LCP reaches Opened only after a Configure-Ack has been both sent and received. One peer therefore cannot announce a configuration and unilaterally convert physical connectivity into an open PPP link. Each side controls what it proposes for its own direction and what it accepts from the other.

This was not symmetry for appearance's sake. Receive capacity can differ. One side may require authentication while the other does not. Compression support or asynchronous control-character handling may not match. Separate requests let the common link exist without pretending the machines are identical.

Defaults made omission meaningful

A Configure-Request contains changes from standard defaults, not a complete inventory of the endpoint. RFC 1661 says options carrying default values should not be included. If an option is absent, its defined default applies.

That choice kept the shared language small, but it made defaults part of the evidence. An operator who records only explicit options cannot reconstruct the effective link. The negotiated state is the accepted request plus every applicable default, interpreted in the correct direction.

Options are considered together. An Ack accepts the entire ordered list at once. A Nak filters out acceptable options and reports the disputed ones. A Reject reports the ones that cannot participate. This gives the exchange atomic meaning without requiring the peer to accept every capability it possesses or expose every local preference.

The control language survived disagreement about compression

Negotiation changes the very frame that later packets use. That creates a bootstrapping trap: if one endpoint starts compressing fields because it believes an option took effect while the other still reads the default frame, even the packets needed to repair the disagreement might become unreadable.

RFC 1548 and RFC 1661 preserve an escape from that trap. LCP configuration, termination and Code-Reject packets are sent as if no configuration options were enabled. Address, control and protocol-field compression are not applied to that control set.

The stable encoding does not prove the peers agree. It preserves a language in which disagreement remains visible. Data-plane efficiency is permitted only after the control plane has retained a recognisable path back to the defaults.

Silence and endless bargaining had limits

Loss is ordinary on the kinds of links PPP was designed to cross. Configure-Request therefore uses a Restart timer and a counter. RFC 1661 requires Max-Configure to be configurable and recommends ten transmissions before treating the peer as unable to respond.

Responses can arrive and still fail to converge. The specification recommends a separate Max-Failure counter, with five as its default. After repeated Naks without an Ack, further Naks for the peer's requested options become Rejects, and the receiver stops appending its own desired options.

This is a notable refusal to negotiate forever. A suggestion is useful only while it can lead to a new proposal. When repeated counterproposals produce no acceptable state, narrowing the option set is safer than allowing one unresolved preference to hold the link indefinitely.

Timers and counters do not prove malice, incompatibility or physical failure. They bound how long uncertain evidence can occupy the state machine. An exhausted counter is a locally observable reason to stop the attempt, not a global verdict about the other endpoint.

Link agreement was not network readiness

The four configuration codes appeared in RFC 1134 in November 1989 and remained through RFC 1171, RFC 1331, RFC 1548 and the final July 1994 base standard. The evolving documents also clarified a layered sequence.

A lower layer first reports that the physical path is available. LCP then establishes link-independent parameters. If an authentication protocol was negotiated, authentication follows. Network Control Protocols subsequently configure each network-layer protocol, such as IP, independently. Only after the relevant NCP reaches Opened may that network-layer traffic use the link.

A Configure-Ack therefore proves much less than a green status light often implies. It does not prove identity, successful authentication, IP address configuration, route availability or application reachability. It proves that one exact LCP proposal was acceptable to the endpoint that answered.

The current IANA PPP registry still records Configure-Request, Ack, Nak and Reject as codes 1 through 4 and maintains the option namespace. Registration preserves the common vocabulary. It is not a census of present use or evidence that every implementation applies the state machine correctly.

Thin agreement made different machines interoperable

PPP's configuration exchange succeeded by refusing to make “agreement” vague. Acceptance had a byte-exact form. Counterproposal and refusal had separate forms. Direction had separate state. Time and repetition had explicit bounds. Later layers had to earn their own readiness.

No central coordinator chose a universal frame size, authentication method or compression policy. Nor did either endpoint gain command over the other. The shared standard assigned a small set of statements that both machines could verify locally, while leaving each endpoint responsible for its own requirements.

That is the institutional achievement hidden inside four small packet codes. Interoperability did not require one machine to win. It required every reply to carry no more authority than its evidence could support.

Sources and limits

RFC 1134, RFC 1171, RFC 1331, RFC 1548 and RFC 1661 establish the protocol's published evolution, packet grammar, directional model, phases and convergence bounds. The IANA registry establishes current assignments. These sources do not establish modern deployment share, vendor conformity, carrier practice, performance gains or one universal operational timeout. The interpretation of exact echoing as thin bilateral authority is an inference from the mechanism.