Summary

  • RFC 2153 reserved a common proprietary envelope so vendors would not secretly self-assign conflicting PPP Code and Configuration Option Type values.
  • The OUI identifies who administers a meaning; the Kind and Values remain vendor-defined, so a syntactically valid frame may still be unknown, misunderstood or locally forbidden.
  • A Configure-Ack records acceptance of one exact option set. Feature activation, bidirectional use, security, network traffic and service outcome need later receipts.

A perfectly addressed opaque message

Imagine a PPP trace that parses without error. The control Code is 0. The length is valid. A three-octet OUI and one-octet Kind sit exactly where the decoder expects them. The record can be attributed to the namespace of an organization, yet the receiver may still have no module that knows the Kind, no definition for the Values, and no policy authorizing the feature.

That is the productive tension in RFC 2153. Published in May 1997, the Informational memo created a general envelope for proprietary PPP mechanisms. Its purpose was modest and useful: vendors should not secretly appropriate ordinary LCP or NCP Code and Configuration Option Type values and thereby create collisions. A stable outer namespace lets implementations sort private messages without pretending that their inner semantics have become standards.

The RFC Editor record and IETF Datatracker show that the document updates RFC 1661 and RFC 1962 and was later updated by RFCs 5342 and 7042. Those relationships establish documentary lineage, not current implementation.

One envelope, two different surfaces

RFC 2153 defines a Vendor Specific control packet and a Vendor-Specific Configuration Option. Their similar names conceal a decisive difference.

The control packet uses Code 0 in LCP or an NCP. It carries an Identifier that must change for every new packet, a four-octet Magic-Number, the OUI, the Kind and optional Values. It may be sent at any time, even before LCP has reached Opened. Receipt causes an RXR or RUC event in the base PPP automaton, while the response itself is vendor specific. A Code-Reject should produce RXJ+, the permitted-rejection event.

This is receipt, not agreement. The common state machine knows that a packet arrived and can tolerate the peer rejecting its Code. It does not know what the proprietary values meant or whether any effect followed.

The configuration option uses Type 0 and has a minimum length of six octets. Here the RFC is unusually explicit: before accepting the option, an implementation must verify that OUI and Kind specify a known mechanism and that all vendor-specific negotiation values are fully understood. The check is semantic, not merely structural.

OUI locates the dictionary; it does not supply it

The OUI names the organization that administers the message's meaning. Within that namespace, Kind is a one-octet subtype with no common standardization. The vendor may extend Kind through the following Values, whose details are implementation specific. A generic decoder can therefore show the correct OUI and Kind without possessing the relevant dictionary.

Nor is the OUI a credential. It does not authenticate the sender, prove that the sender is the named organization, grant a licence, or express an operator's approval. RFC 2153 even allows its control packet before the PPP link is Opened, while RFC 1661 places optional peer authentication after link establishment. The older memo's security section simply says that security issues are not discussed.

The registry history reinforces the distinction. RFC 2153 created a CF0000 series for software-only vendors without an IEEE OUI. RFC 5342, later replaced by RFC 7042, deprecated new assignments and closed the series without changing the packet format. The current IANA PPP registry preserves a few entries and reserves the remainder. That table is valuable provenance for numbers. It is not an inventory of installed code.

Ack, Nak and Reject are different evidence

The base PPP rules prevent one convenient but damaging collapse. Under RFC 1661, Configure-Ack is permitted only when every option is recognizable and every value acceptable; the reply must reproduce the option set exactly. Configure-Nak means the option is recognizable but some values are unacceptable. Configure-Reject means an option is unrecognizable or administratively unavailable for negotiation.

For a vendor option, this yields an evidence ladder. Parsing the length proves framing. Recognizing the OUI and Kind proves that a decoder claims a dictionary. Fully understanding the Values proves semantic coverage for that version. Local policy answers whether negotiation is allowed. Configure-Ack records that one peer accepted the exact request in one generation. None of those facts alone proves the mechanism was installed, used in both directions, or carried working traffic.

The later RFC 3772 adds dedicated PPP vendor protocol numbers and warns that the security of vendor protocols remains the responsibility of those protocols. Namespace engineering can reduce collision without reviewing a proprietary algorithm.

Keep six receipts instead of one green flag

An auditable implementation should first retain the framing receipt: control protocol, Code or Type, Identifier, Length, Magic-Number, OUI, Kind, a hash of Values, direction, timestamp and link generation.

The meaning receipt identifies the vendor specification or decoder module and version that interpreted Kind and Values. The authority receipt identifies the local configuration or administrator that permitted use. The negotiation receipt preserves the exact Configure-Request and its matching Ack, Nak or Reject. The activation receipt shows the parameters installed and the first mechanism-specific packet processed. Only after that do link and service receipts establish NCP Opened, network-layer traffic and a correlated application result.

The RFC 2153 errata record and later standards history help maintain the documentary layer. Heng Lu's Running-Code Primacy explains why the executable layer must answer what actually ran. Minimum Initial Specification supports the narrow common envelope, while Reality Layers warns against promoting a symbolic label into an operational outcome.

Sources