Summary

  • RFC 1220 required the Bridge Network Control Protocol to open before LAN traffic could cross a PPP link. Open was a protocol prerequisite, not a receipt for a frame delivered across an extended LAN.
  • The RFC separated several conditions that a single “link up” indicator could hide: a large enough MRU, required ordering across parallel links, supported MAC types, directional compression, advisory LAN IDs, spanning-tree treatment and LAN FCS handling.
  • Even the same packet carried two different integrity records. The PPP CRC protected the point-to-point frame; an optional LAN FCS represented the originating LAN frame. Success at one layer did not establish success at the other.

Open was the start line

RFC 1220, Point-to-Point Protocol Extensions for Bridging, appeared in April 1991 under the editorship of F. Baker. The RFC Editor record and IETF Datatracker catalogue it as a Proposed Standard from the IETF stream and mark it obsolete in favor of RFC 1638. Those records establish document identity and status. They do not show that a bridge implemented either specification.

The problem was to carry LAN frames between remote bridges over one or more serial links while still behaving, in selected respects, like one extended LAN. RFC 1220 built on the PPP line discipline described in RFC 1171. It assumed that the devices had agreed to use PPP in some form and might be willing to use the link for remote bridging. Those were model inputs, not observed facts about a named pair of devices.

The Bridge Network Control Protocol, or BNCP, supplied a visible gate. It could not begin until LCP had reached the network-layer protocol configuration phase. LAN traffic, in turn, could not be exchanged until BNCP had opened the connection. This ordering prevented a bridged frame from outrunning the protocol intended to configure the bridge endpoints.

But Open meant that the RFC’s control state allowed the next class of traffic. It did not say which frame later crossed, which interface forwarded it, whether the target LAN emitted it, or whether an application received useful data. A state-machine transition and an end-to-end result belonged to different ledgers even in 1991.

Silence carried only a narrow meaning

For transparent bridging, RFC 1220 made an unusual protocol assumption. If a neighbor received IEEE 802.1 BPDUs without answering with PPP Protocol-Reject, transparent bridging was treated as permitted on that link. The absence of a rejection therefore had defined significance inside this protocol model.

It did not become unlimited authorization. The signal did not identify an operator, prove a matching human decision, certify the spanning-tree root or show that ordinary LAN frames would be forwarded. It was also not the only possible policy. A network manager could divide the link into separate spanning-tree domains, but both ends had to be configured not to exchange BPDUs. A bridge in that mode silently discarded an unexpected neighbor BPDU.

The same observed silence could consequently sit behind different states: acceptance under the RFC’s default assumption, intentional BPDU suppression, a one-way fault, or simply no topology event that generated reverse traffic. RFC 1220 strongly recommended magic-number loop detection and link-quality monitoring because normal spanning-tree traffic was largely unidirectional. A quiet reverse path was not proof of a healthy reverse path.

Capability statements had defaults and asymmetries

BNCP options covered MAC types, tinygram compression, LAN Identification and token-ring ring/bridge identifiers. Each option narrowed a question; none answered every downstream question.

A bridge could announce the MAC types it was prepared to receive and service. If it announced a set, omitted types were to be discarded. If it announced none, the peer could assume broad support, while the receiver would still discard a type it did not understand. Even more sharply, rejection of a MAC-type announcement could leave the sender forwarding that traffic although the receiver had already indicated it would discard it. A negotiation transcript could therefore document a disagreement without preventing loss.

Tinygram compression was directional. One endpoint might be willing to decompress while the other was not; no negotiation meant no compression. “Compression enabled” was not a symmetric property of the whole link unless both directions were recorded separately.

LAN Identification was advisory and disabled by default. An enabled value meant labeled LANs might exist beyond the peer and the peer was prepared to service them. Disabled meant labeled traffic would be dropped there. The field described a community boundary, but the packet alone did not prove the selected LAN ID matched an intended organizational group or that an egress interface enforced it correctly.

A frame could be valid and still be unsuitable

RFC 1220 explicitly warned that the negotiated maximum receive unit had to be large enough for the MAC types being supported. The bridge format supplied no fragmentation and reassembly. Even Ethernet could exceed PPP’s default 1,500-octet MRU. A control protocol could open successfully while a later legal LAN frame was simply too large for the chosen link state.

Parallel point-to-point links created another boundary. The transmitter had to decide whether the bridged protocol required original order. If it did, one conversation had to stay on one link; if the transmitter lacked evidence, it had to assume ordering mattered. More aggregate capacity did not automatically preserve LAN semantics.

The checksum fields make the layered distinction concrete. The PPP frame’s CRC protected carriage across the point-to-point link. An optional embedded LAN FCS was the checksum calculated, or apparently calculated, by the originating station. RFC 1220 called the two separate and unrelated. A receiver could accept a PPP frame whose LAN FCS was absent; a downstream bridge could then cause a new FCS to be generated on LAN emission. Link integrity, preservation of the original LAN frame and successful delivery were three different claims.

The format recorded possibilities, not an event

RFC 1220 also defined flags for an embedded FCS, LAN ID, compressed zero padding and trailing line padding. Its MAC-type field selected the interpretation of the following bytes. The format could tell a parser what the sender claimed to have included. It could not prove that a forwarding database selected the right egress, that a spanning-tree port was forwarding rather than blocked, or that the destination existed.

The document contains no operator configuration, negotiation capture, forwarding-table snapshot, traffic trace or application log. Its security section says security issues are not discussed. It therefore cannot establish authentication, policy authority, confidentiality, safe rollback or any observed service outcome.

The lasting lesson is not that BNCP Open was weak. It was precise. It answered when the protocol allowed bridged LAN traffic to begin. Trouble starts only when that bounded answer is promoted into a claim that the extended LAN worked.

Sources