Summary

  • RFC 3518 added a negotiable Bridge-Control-Packet-Indicator to PPP BCP. When enabled, a sender marked recognized BPDU and GARP-class frames so that a link could avoid dropping or seriously delaying them.
  • The C bit proved a local classification, not BPDU authenticity, receiver acceptance, spanning-tree convergence or loop freedom. The RFC itself warned that a rogue peer could close loops that should have been isolated.

A bridge-control frame has unusual leverage. Ordinary data follows the forwarding state that already exists. A spanning-tree BPDU can help change that state: which bridge is root, which ports forward and which redundant paths remain blocked. Delaying control traffic can therefore preserve an obsolete view of the topology long enough to matter.

PPP bridging had already learned how to carry LAN frames across a point-to-point link. RFC 1638 defined the earlier machinery, and RFC 2878 revised the Bridging Control Protocol, or BCP. The bridge at each end could negotiate framing and bridging characteristics, then transport bridged traffic through PPP. RFC 3518, published in April 2003, obsoleted RFC 2878 with a strikingly narrow improvement.

Its change list named two items: add the Bridge Control Packet Indicator as a configuration option, and give one previously reserved bit in the flags field a new meaning. That economy is the point of the history. The standard did not invent a new spanning-tree algorithm. It added a way to distinguish control frames inside an existing carriage mechanism.

BCP option type 10 advertised support for the indicator. Support was disabled by default. If the peers negotiated the option, the sender had to set the C bit to 1 if and only if an outgoing frame was a bridge-control frame. Without negotiation, the bit had to remain zero, and a non-negotiating system could neither send nor receive a frame with it set. The rule kept older RFC 2878 peers interoperable.

Classification was grounded in frame content. RFC 3518 identified spanning-tree BPDUs and GARP PDUs and required recognition through IEEE-assigned destination MAC addresses. That included addresses used by the bridge group, bridge management, GMRP and GVRP. Once recognized, a control frame received an explicit signal in the PPP bridged-frame header.

The operational promise concerned treatment. Bridge-control traffic should not be dropped or significantly delayed. RFC 3518 compared the idea with giving routing updates high IP precedence, drawing on the differentiated-services vocabulary of RFC 2474. A marked frame could enter a preferred local queue instead of competing blindly with bulk data.

This was real control, but it was local control. The sender's classifier decided that a frame belonged to a class. Negotiation established that the adjacent PPP peer understood the flag. A scheduler could then give that frame favorable treatment on the link. None of those facts inspected the contents as an authenticated assertion, established the sender's authority over the spanning-tree domain, or watched every bridge reach a consistent result.

The distinction becomes clearer by following the receipts. An IANA registry entry proves that option number 10 is assigned. A successful option exchange proves a shared capability between two peers. A C bit proves what the transmitting implementation classified. Arrival proves carriage to the adjacent peer. Only the receiving bridge's control process can decide how to use the BPDU, and only observations across the domain can support a claim about convergence and blocked redundant paths.

BCP's Opened state belongs to the same discipline. PPP's RFC 1661 state machine uses Opened after the relevant Configure-Ack exchanges. RFC 3518 also prevented BCP from entering that state for certain incompatible choices, including unresolved spanning-tree protocol disagreement. Passing such negotiation means the two ends found an acceptable configuration intersection. It does not mean every bridge and link behind them has been examined.

The RFC's security section refuses that leap. A bridged link that comes up with a rogue peer may disclose network information through forwarded multicast traffic. Worse, the peer may create denial of service by closing loops that should have been detected and isolated, or by offering rogue load. If a negotiated, marked control path itself proved topology safety, that warning would make no sense.

RFC 3518 recommended PPP authentication during LCP startup where a foreign or compromised device might appear. CHAP, specified in RFC 1994, can challenge a peer without repeatedly sending a reusable password. Authentication improves the answer to “which peer is on this point-to-point link?” It still cannot answer “is every advertised bridge fact correct?” or “has the whole topology converged without a loop?” Identity narrows trust; it does not replace operational evidence.

Other PPP machinery preserves the same boundary. Multilink PPP in RFC 1990 can fragment and sequence traffic over several component links. Multiclass Multilink PPP in RFC 2686 can reduce delay for selected classes. Those facilities affect how promptly a marked control frame travels. They do not transform prompt transport into proof that the control algorithm accepted the frame or produced a safe data plane.

Even the old-format exception is informative. RFC 3518 retained a backward-compatible BPDU form for older BCP bridges while ordinarily carrying bridge and GARP PDUs in the shared bridged-frame format. Interoperability required recognizing what the peer could parse. It did not require pretending that one framing choice described the state of an entire spanning-tree domain.

RFC 7042 later documented the administrative boundary between IETF and IEEE 802 parameters, while the PPP Numbers registry continues to record BCP option 10. These are authority records. They stabilize names and numbers so implementations can meet. They cannot report whether a particular frame was genuine, timely, accepted or effective.

RFC 3518 matters because its modest bit was neither trivial nor magical. It exposed a control class at the exact interface where differentiated handling could help, while leaving the bridge algorithm and topology evidence outside that interface. The standard localized power: classify here, prioritize here, negotiate with this peer.

The historical mistake would be to read the mark as a verdict. A control frame can be correctly recognized and promptly transported while carrying stale information, coming from a compromised peer, reaching the wrong administrative domain or arriving amid a topology that has not converged. The C bit says what the frame is for. It does not say that the world the frame describes is safe.

Sources