Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)

LAN Frame Checksum Preservation is optimized as the primary mode because IEEE 802.1 requires the Extended LAN to maintain the same probability of undetected error as an individual LAN. Frames without a precalculated FCS are tagged and carried across the line rather than requiring software FCS calculation.

The Bridge Control Packet Indicator bit was added (a new BCP option from RFC 2878) to give bridge control packets (STP BPDUs, GARP PDUs) preferential forwarding treatment analogous to IP precedence values 6-7 for routing protocol updates, preventing topology instability from delayed control traffic.

The transmitting side (not the receiver) is assigned responsibility for updating the RIF in the split-bridge Source Routing model so that the receiving system can forward frames without inspecting or modifying the RIF, preserving algorithmic simplicity and ensuring interoperability.

By default, PPP Source Route Bridges use the independent-bridge model. To use the split-bridge model, a system MUST successfully negotiate the Bridge-Identification Configuration Option; the Line-Identification option is strongly recommended for the independent-bridge model to verify LAN Segment ID configuration.

When connected to an old BCP bridge (RFC 1638), a system has three options: terminate the connection, run without spanning tree on the link (dangerous), or send Configure-Ack and operate in RFC 1638-compatible mode using the old BPDU format from Appendix A.

A spanning tree protocol negotiated via the old Spanning-Tree-Protocol option MUST be agreed upon by both bridges; if not agreed upon (except when one side supports no STP), BCP MUST NOT enter the Opened state.

A system MUST NOT transmit a MAC Type numbered higher than 4 unless it has received from its peer a MAC-Support Configuration Option indicating that the peer is willing 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 received before PPP reaches the Network-Layer Protocol 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 protocols data units MUST be recognized by checking the destination addresses assigned by IEEE (e.g., 01-80-c2-00-00-00 for STP, 01-80-c2-00-00-20 for GMRP, 01-80-c2-00-00-21 for GVRP).

For the Bridge-Identification option, the two half bridges MUST agree on the bridge number; if a bridge number is not agreed upon, the Bridging Control Protocol MUST NOT enter the Opened state.

For the Line-Identification option, the two bridges MUST agree on the LAN segment number; if not agreed upon, the Bridging Control Protocol MUST NOT enter the Opened state.

If an implementation supports a MAC Type that is the higher-numbered format of that MAC Type, then it MUST also support the lower-numbered format of that MAC Type (e.g., FDDI canonical requires FDDI non-canonical support).

If the Bridge Control Packet Indicator option is disabled, a system MUST set the Bridge Control Packet Indicator bit to 0 for all frames, preserving backward compatibility with RFC 2878.

In split-bridge Source Routing model, the system that transmits an Explorer frame onto the PPP link MUST update the RIF on behalf of both systems, ensuring the receiving system can forward the frame without processing the RIF.

In the absence of a determination about protocol ordering requirements, the transmitting system MUST act as though all protocols require order preservation when using multiple PPP links.

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.

The Bridging Control Protocol (BCP) is the PPP NCP responsible for configuring, enabling, and disabling bridge protocol modules on both ends of a point-to-point link. It uses the same packet exchange mechanism as LCP and operates at PPP protocol type hex 8031.

The MAC Type field identifies the LAN technology and address bit ordering: values 1-4 cover IEEE 802.3/Ethernet (canonical), 802.4 (canonical), 802.5 (non-canonical), and FDDI (non-canonical); values 11 and 12 cover 802.5 and FDDI with canonical addresses for backward compatibility.

The Management-Inline configuration option (Type=9, Length=2) indicates willingness to receive IEEE-defined inter-bridge protocols (BPDUs, GARP PDUs) in the standard frame format. Its rejection signals an old RFC 1638-compatible peer, requiring fallback to the old Spanning-Tree-Protocol option.

Tinygram Compression removes trailing zero octets from undersized IEEE 802.3 PDUs (below minimum PDU size) before transmission over low-speed lines, tagging compressed frames with the Z flag bit. The receiver pads the frame back to minimum 802.3 length (60 octets) with zeroes.

This document adds BCP Option Type 10 (Bridge-Control-Packet-Indicator) to the IANA-maintained BCP option number registry. The full current list of BCP option types 1-10 is defined, with type 5 (LAN-Identification) noted as obsoleted.

registry

If a bridged PPP link comes up with a rogue peer, network topology information may be learned from forwarded multicast traffic, or denial-of-service attacks may be created by closing loops that should be isolated or by offering rogue spanning tree load. PPP authentication during LCP startup is recommended to mitigate these risks.

security

The Bridge-Identification configuration option (Type=1, Length=4) encodes a 12-bit LAN Segment Number and 4-bit Bridge Number in a single 16-bit field following the Type and Length bytes.

The IEEE 802 Tagged Frame format extends the untagged format by inserting a 2-byte TPID (0x8100 for 802.3) followed by a 16-bit Tag Control Information field containing a 3-bit priority (Pri), 1-bit canonical flag (C), and 12-bit VLAN ID between the Source MAC Address and the Length/Type field.

The IEEE 802 Untagged Frame format for PPP bridging includes an 8-bit Flags field (F=LAN FCS present, Z=zero-pad to minimum size, B=bridge control packet) and a MAC Type byte, followed by Destination MAC, Source MAC, LLC data, optional LAN FCS, optional padding, and PPP Frame FCS. PPP Protocol field is 0x0031.

The MAC-Address configuration option (Type=6, Length=8) carries six octets of MAC address in IEEE 802.1 Canonical order, with the Local Assignment (L) and Multicast (M) bits explicitly shown in the least-significant bits of the first octet.