Summary

  • RFC 1474 indexed bridge-media status by PPP link and MAC type. Its local accept value described what the local bridge would receive and properly process; its remote accept value described only what the local bridge believed about its peer.
  • RFC 1220 made that belief operationally awkward: silence could default to apparent support even though unknown types would be discarded, while rejection could leave traffic forwarded toward a receiver that had said it would discard it.

RFC 1474, published in June 1993, defined managed objects for the Bridge Network Control Protocol carried by PPP. It did not try to tell the entire story of a bridged frame. It exposed a compact control surface: whether the bridge NCP was open, which options had been negotiated, what the local configuration requested and which MAC media types each side appeared prepared to handle.

The smallest word in that design carried the largest warning. The MIB could report accept for the remote side, but the description did not say “the remote bridge accepts.” It said the local bridge believes that it will.

Two accept cells made different claims

The media-status table was indexed by ifIndex and pppBridgeMediaMacType. A row therefore belonged to one PPP link and one media type. Ethernet-like traffic, Token Ring traffic and other MAC forms were not compressed into one universal “bridging works” indicator.

For the local column, RFC 1474 used direct capability language. If pppBridgeMediaLocalStatus was accept, packets of the indicated type would be received and properly processed. If it was dont-accept, received packets of that type would not be properly processed.

The remote column was deliberately weaker. pppBridgeMediaRemoteStatus recorded whether the local PPP bridging entity believed the remote entity would accept packets of that type on that link. The value was about the peer, but the observer and owner of the conclusion remained local.

That asymmetry is not pedantry. A local implementation can know its own configured capability. It knows a peer through messages, defaults and state retained from a negotiation. One status is an assertion about the reporting system's behavior; the other is a model of someone else's behavior.

Silence could look broader than knowledge

The protocol behind the table came from RFC 1220. Its MAC Type Selection option let a node advertise the kinds of traffic it was prepared to receive and service. Multiple types required multiple options in a Configure-Request.

The default was unexpectedly permissive in appearance. If a system did not announce supported MAC types, it could be assumed to support all of them. Yet RFC 1220 immediately added that the system would discard types it did not understand.

That is not a contradiction once the layers are kept separate. The default told a sender how to proceed in the absence of a narrower advertisement. It did not manufacture decoding capability inside the receiver. A local table could rationally derive a usable remote belief from the protocol default while the next unknown frame was still destined for discard.

An explicit announcement narrowed the picture: unspecified types would be discarded. But even rejection was not a clean safety signal. RFC 1220 described rejection of a MAC-type announcement as a situation in which traffic of that type could still be forwarded over the link although the receiving system had indicated that it would discard it.

The table therefore summarized a negotiation environment, not an end-to-end warranty.

Later text called the option advisory

RFC 1638 replaced the earlier bridging specification in 1994 and kept the mechanism recognizable. It strongly recommended MAC-Support negotiation, explained that an announcement could save bandwidth by stopping unsupported types and explicitly called the option advisory only.

It also tightened one edge: a system had to refrain from transmitting a MAC type numbered above 4 unless its peer had advertised willingness to receive it. That rule is useful evidence about the protocol's evolution. It does not turn the earlier status table into a historical packet trace, and it does not prove that any named implementation followed either version.

The evolution instead exposes a design tension. Defaults kept old peers interoperable. Advertisements improved efficiency. Stronger rules protected newer type codes. None of those choices removed the need to say exactly what had been observed and what had merely been inferred.

Capability was not forwarding

A peer may accept a media type and still lack forwarding information for a particular destination. The contemporary RFC 1493 Bridge MIB modeled that later problem separately. Its forwarding database held information about specific unicast MAC addresses and the ports learned or configured for them.

The two tables answer different questions. RFC 1474 asks whether this kind of bridged frame is supported across this PPP link. RFC 1493 asks how a bridge may propagate or filter a frame for this address. Neither table is the destination host's receipt.

An honest evidence chain would need to preserve local configuration, the link restart to which it applied, the Bridge NCP exchange, the basis for the remote-status belief, the frame actually sent, the peer's processing result, the forwarding decision and whatever endpoint observation came after it.

RFC 1661 supplied another boundary: a network protocol's packets were carried only after its NCP reached Opened, and packets received before that state were discarded. Opened was necessary protocol state. It still did not prove that a particular bridged frame crossed the link.

A status display should name its witness

RFC 1474 separated writable configuration from operational status and warned that PPP management could create security risk. Protected views could control who read or changed the objects. That protection governed the management surface; it did not strengthen the semantic reach of a value.

For modern automation, a remote-capability field should carry its witness: negotiated advertisement, default assumption, cached generation, active link identity and observation time. A green label without that provenance encourages a system to turn “my peer model says yes” into “the peer received it.”

The lesson is larger than PPP bridging but narrower than distrust. Inference is necessary to operate distributed systems. The mistake is not having a belief. The mistake is storing it in the same visual grammar as a direct fact and then forgetting who believed it.

RFC 1474 did not forget. It put the limitation inside the object's definition, where every management station could have kept it.

Sources