PPP Bridging Control Protocol (BCP)

Frames with no LAN Frame Checksum are tagged and carried across the PPP link rather than requiring software FCS computation, because requiring FCS calculation in software would impose a severe performance penalty on Bridge/Router implementations and raises interpretation ambiguities.

In the split-bridge model, the transmitting system MUST update the RIF rather than the receiving system, so that the receiver can forward the frame without processing the RIF. If the receiving system had to determine whether the transmitter had updated the RIF, it would have to scan and conditionally update it on every frame.

PPP Source Route Bridges default to the independent-bridge model (where the PPP link is a LAN segment between two bridges) rather than the split-bridge model to ensure interoperability in the absence of option negotiation. The split-bridge model requires explicit negotiation of the Bridge-Identification option.

Tinygram Compression is provided because Ethernet-bridged protocols most likely to be bridged over low-speed (64 kbps and below) lines pad PDUs with zero octets to meet the 802.3 minimum frame size, making compression by zero-stripping straightforward and effective for interactive session traffic.

If both Management-Inline and Spanning-Tree-Protocol-Configuration Options are configure-rejected by a peer, this indicates an incomplete implementation with no spanning tree support at all; for safety the system should cease attempting to configure bridging and log the fact.

When connected to an old BCP (RFC 1638) peer, BPDUs must be sent in the old format described in Appendix A (a bare BPDU with Spanning Tree Protocol PPP protocol field, no MAC/LLC header) only when a non-NULL STP protocol is successfully negotiated and Management-Inline is configure-rejected. Implementations SHOULD implement a backward compatibility mode.

A system MUST NOT transmit a MAC Type numbered higher than 4 unless it has received a MAC-Support Configuration Option from its peer indicating willingness to receive frames of that MAC Type.

An implementation that does not support any spanning tree protocol MUST silently discard any received IEEE 802.1D BPDU packets.

BCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase; BCP packets received before this phase SHOULD be silently discarded.

Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST reach the Network-Layer Protocol phase and the Bridging Control Protocol MUST reach the Opened state.

Bridge protocols and GARP protocol data units MUST be recognized by checking IEEE-assigned destination addresses: 01-80-c2-00-00-00 (STP Bridge Group Address), 01-80-c2-00-00-10 (Bridge Management Group), 01-80-c2-00-00-20 (GMRP), and 01-80-c2-00-00-21 (GVRP).

By default, an implementation MUST either support the IEEE 802.1D spanning tree or support no spanning tree protocol at all. An implementation supporting no spanning tree MUST silently discard received 802.1D BPDUs and MUST silently discard or respond with LCP Protocol-Reject to other BPDU types.

If an implementation supports a MAC Type that is the higher-numbered format of a given MAC Type (e.g., FDDI with canonical addresses), it MUST also support the lower-numbered format (e.g., FDDI with non-canonical addresses), to ensure backward compatibility.

In the absence of a determination about protocol ordering requirements, the transmitting system MUST act as though all protocols require order preservation, since many protocols designed primarily for use on a single LAN require it.

PPP links supporting Bridging MUST negotiate an MRU large enough to support the MAC Types that are later negotiated for Bridging support, because bridged Ethernet frames are larger than the default PPP MRU of 1500 octets even when MAC headers are included.

The Bridge-Identification Configuration Option (Type 1, Length 4) carries a 12-bit LAN Segment Number and 4-bit Bridge Number for split-bridge (half-bridge) source routing models. Both peers MUST agree on the bridge number; if not agreed upon, BCP MUST NOT enter the Opened state. This option MUST NOT appear in the same Configure-Request as Line-Identification.

The Bridging Control Protocol (BCP) is a PPP Network Control Protocol (NCP) responsible for configuring, enabling, and disabling bridge protocol modules on both ends of a PPP link. It uses the same packet exchange mechanism as LCP and is identified by PPP Protocol field value 0x8031. Bridged PDUs are carried with PPP Protocol field value 0x0031.

The IEEE-802-Tagged-Frame Configuration Option (Type 8, Length 3) enables or disables support for IEEE 802.1Q tagged VLAN frames. A system that negotiates this option as disabled MUST NOT send any IEEE-802-Tagged-Frame packets. By default, Tagged Frame support is off.

The Line-Identification Configuration Option (Type 2, Length 4) carries a 12-bit LAN Segment Number and 4-bit Bridge Number for use when the PPP link is treated as an independent LAN segment in source routing. Both bridges MUST agree on the LAN segment number; disagreement prevents BCP from entering the Opened state.

The MAC-Address Configuration Option (Type 6, Length 8) allows a bridge to announce its 6-octet MAC address or request one be assigned (by sending all-zeros). A Configure-Nak MUST specify a valid physical address with multicast bit (M) zero.

The MAC-Support Configuration Option (Type 3, Length 3) is an advisory option that announces the single MAC Type an implementation is prepared to receive. Multiple instances in a Configure-Request announce multiple supported types. This option MUST NOT be included in a Configure-Nak.

The Management-Inline Configuration Option (Type 9, Length 2) signals willingness to receive IEEE-defined inter-bridge protocols (BPDUs, GARP PDUs) inline in the normal bridged frame format (sections 4.2/4.3), replacing the old RFC 1638 out-of-band BPDU mechanism. Its rejection by a peer indicates an RFC 1638-only implementation.

The Spanning-Tree-Protocol (old format) Configuration Option (Type 7) lists one or more 1-octet spanning tree protocol identifiers (0=Null, 1=IEEE 802.1D, 2=IEEE 802.1G, 3=IBM Source Route, 4=DEC LANbridge 100) in increasing numerical order. Both bridges MUST agree on the protocol; disagreement prevents BCP from entering the Opened state.

The Tinygram-Compression Configuration Option (Type 4, Length 3) contains an Enable/Disable field (1=enabled, 2=disabled). It permits compression of sub-minimum 802.3 frames by stripping trailing zero octets before the LAN FCS, reducing bandwidth on low-speed lines. Peers need not agree on the setting.

IANA assigned two new BCP option numbers introduced by this document: value 8 for IEEE-802-Tagged-Frame and value 9 for Management-Inline. The full BCP option type registry is maintained in the Assigned Numbers RFC.

registry

If a bridged PPP link comes up with a rogue peer, network topology information may be learned from forwarded multicast traffic, and denial-of-service attacks may be created by injecting loops that the spanning tree should detect and isolate, or by offering rogue load. It is recommended that links susceptible to rogue peers be configured to use PPP authentication during the LCP startup phase.

security

IEEE 802 Tagged Frame format for VLAN-aware bridged traffic over PPP: identical to the untagged format but inserts TPID (0x8100), a 16-bit Tag Control Information field (3-bit Pri, 1-bit Canonical flag C, 12-bit VLAN ID) after the Source MAC Address and before the Length/Type field. For 802.4/802.5/FDDI frames, the TPID is SNAP-encoded occupying two 32-bit words.

IEEE 802 Untagged Frame format for bridged LAN traffic over PPP: begins with HDLC FLAG, Address and Control, PPP Protocol (0x0031), a flags/pads/MAC-Type byte, Destination MAC Address (6 octets), Source MAC Address (6 octets), Length/Type (2 octets), LLC data, optional LAN FCS (4 octets), optional pad, and Frame FCS. The F flag indicates LAN FCS presence; the Z flag indicates IEEE 802.3 zero-fill padding is required.