Zusammenfassung

  • RFC 1220 ließ LAN-Verkehr erst nach dem Öffnen von BNCP zu. Open belegte einen notwendigen Steuerzustand, aber weder die Übertragung eines bestimmten Frames noch dessen Ausgabe auf einem entfernten LAN.
  • Auch nach erfolgreicher Aushandlung blieben ein ausreichender MRU, Reihenfolge über parallele Leitungen, unterstützte MAC-Typen, richtungsabhängige Kompression, LAN-ID- und Spanning-Tree-Regeln sowie das Empfängerverhalten zu prüfen.
  • Der PPP-CRC schützte die Punkt-zu-Punkt-Übertragung. Ein optionaler LAN-FCS bezog sich auf den ursprünglichen LAN-Frame. Der Erfolg der einen Prüfung füllte die Beweislücke der anderen nicht.

Open war eine Erlaubnis zum Anfangen

RFC 1220, Point-to-Point Protocol Extensions for Bridging, erschien im April 1991 unter der redaktionellen Leitung von F. Baker. Der RFC-Editor-Eintrag und der IETF Datatracker führen ihn als Proposed Standard aus dem IETF-Stream und heute als durch RFC 1638 überholt. Diese Katalogangaben belegen Dokument und Status, nicht den Einsatz in einer bestimmten Bridge.

Die Spezifikation sollte LAN-Frames zwischen entfernten Bridges über eine oder mehrere serielle Leitungen tragen. Sie setzte die PPP-Leitungsdisziplin aus RFC 1171 voraus. Die Geräte an beiden Enden, so das Modell, hatten sich auf irgendeine PPP-Form verständigt, konnten weitere Protokolle multiplexen und mochten die Leitung für Remote Bridging verwenden. Aus solchen Voraussetzungen lässt sich keine beobachtete Verbindung rekonstruieren.

BNCP setzte eine zweite Reihenfolge durch. Seine Pakete mussten warten, bis LCP die Konfigurationsphase für Netzschichtprotokolle erreicht hatte. LAN-Verkehr wiederum musste warten, bis BNCP die Verbindung erstmals geöffnet hatte. Ein Datenframe sollte die Steuerung der Bridge-Endpunkte nicht überholen.

Open bedeutete damit: Die Zustandsmaschine gibt diese Verkehrsklasse jetzt frei. Es bedeutete nicht: Ein konkreter Frame wurde angenommen, eine Forwarding Database wählte den richtigen Ausgang, der entfernte Port sendete, der Zielhost empfing oder eine Anwendung funktionierte. Protokollfreigabe und Ende-zu-Ende-Ergebnis gehörten in getrennte Nachweise.

Ausbleibender Widerspruch hatte eine enge Bedeutung

Für Transparent Bridging traf RFC 1220 eine bemerkenswerte Annahme. Wenn ein Nachbar IEEE-802.1-BPDUs empfing und nicht mit PPP Protocol-Reject antwortete, durfte Transparent Bridging auf der Verbindung als zulässig gelten. Schweigen war also nicht bedeutungslos; die Spezifikation gab ihm eine begrenzte Bedeutung.

Es war dennoch keine uneingeschränkte administrative Genehmigung. Der fehlende Reject identifizierte keinen Betreiber, dokumentierte keine Freigabe und bewies weder die Spanning-Tree-Wurzel noch den Forwarding-Zustand eines Ports. Ein Administrator konnte die Leitung zudem in zwei getrennte Spanning-Tree-Domänen teilen. Dafür mussten beide Enden so konfiguriert sein, dass sie keine BPDUs austauschten; eine unerwartete Nachbar-BPDU sollte dann still verworfen werden.

Von außen konnten protokollgemäße Duldung, absichtliche Trennung und ein Fehler in nur einer Richtung gleich aussehen. Weil normaler Spanning-Tree-Verkehr überwiegend von der Root zu den Blättern lief, empfahl RFC 1220 ausdrücklich Magic-Number-Loopback-Erkennung und Link Quality Monitoring. Ein ruhiger Rückweg war noch kein gesunder Rückweg.

Verhandlung konnte Unverträglichkeit sichtbar lassen

Die BNCP-Optionen betrafen MAC-Typen, Tinygram-Kompression, LAN Identification und Ring-/Bridge-Kennungen. Eine MAC-Typ-Option sagte, welche Typen ein Empfänger entgegennehmen und bedienen wollte. Bei einer expliziten Liste sollten nicht genannte Typen verworfen werden. Ohne Liste durfte die Gegenstelle breite Unterstützung annehmen, obwohl der Empfänger weiterhin unbekannte Typen wegwerfen würde.

Noch schärfer war die Reaktion auf eine abgelehnte MAC-Typ-Ankündigung: Der Sender konnte den entsprechenden Verkehr weiterleiten, obwohl der Empfänger bereits mitgeteilt hatte, ihn zu verwerfen. Das Protokoll konnte den Dissens dokumentieren, ohne ihn automatisch in einen sicheren Stopp zu verwandeln.

Tinygram-Kompression war richtungsgebunden. Ein Endpunkt konnte Dekompression zulassen, der andere nicht. Ohne Aushandlung galt keine Kompression. Eine globale Anzeige „Kompression aktiv“ verlor daher die Richtung, in der die Aussage überhaupt zutraf.

LAN Identification war beratend und standardmäßig deaktiviert. Aktiviert beschrieb die Option, dass hinter der Gegenstelle gekennzeichnete LANs liegen könnten und bedient würden; deaktiviert bedeutete, dass gekennzeichneter Verkehr dort verworfen würde. Eine LAN-ID beschrieb eine Protokollgemeinschaft. Sie bewies keine Organisationszugehörigkeit und ersetzte keine Zugriffskontrolle.

Ein gültiger LAN-Frame konnte nicht auf die Leitung passen

RFC 1220 warnte ausdrücklich, dass der ausgehandelte MRU für alle unterstützten MAC-Typen groß genug sein müsse. Fragmentierung und Wiederzusammenbau waren nicht vorgesehen. Schon Ethernet-Frames konnten den PPP-Standard-MRU von 1.500 Oktetten überschreiten. BNCP konnte Open melden, während ein späterer, im LAN völlig zulässiger Frame für den gewählten Transportzustand zu groß war.

Parallele Punkt-zu-Punkt-Leitungen brachten ein anderes Problem. Der Sender musste feststellen, ob das gebridgte Protokoll die ursprüngliche Reihenfolge verlangte. Falls ja, musste eine Konversation auf derselben Leitung bleiben. Ohne belastbare Feststellung sollte er Reihenfolge als erforderlich annehmen. Mehr Gesamtkapazität rechtfertigte nicht, Frames beliebig über Leitungen zu verteilen.

Auch die Prüfsummen trennten zwei Behauptungen. Der PPP-CRC schützte den Frame auf der seriellen Teilstrecke. Der optionale eingebettete LAN-FCS war die vom Ursprungsgerät berechnete oder scheinbar berechnete Prüfsumme. RFC 1220 bezeichnete beide als getrennt und nicht miteinander verbunden. Fehlte der eingebettete FCS, konnte die empfangende Bridge bei der LAN-Ausgabe einen neuen berechnen lassen. Fehlerfreie PPP-Beförderung, Bewahrung des ursprünglichen LAN-Frames und erfolgreiche Zustellung waren drei verschiedene Ereignisse.

Headerbits waren keine Betriebsbeobachtung

Das Format reservierte Flags für eingebetteten FCS, LAN-ID, komprimierte Nullauffüllung und Leitungs-Padding. Das MAC-Typ-Feld bestimmte die Auslegung der folgenden Bytes. Ein Parser konnte damit prüfen, wie der Absender seinen Frame beschrieben hatte. Er konnte daraus nicht ableiten, dass die Forwarding Database den richtigen Port nannte, dass dieser Port nicht durch Spanning Tree blockiert war oder dass der Zielhost existierte.

Die Quellen enthalten keine Gerätekonfiguration, kein BNCP-Capture, keinen Snapshot einer Forwarding Database, keine Paketspur und kein Anwendungsprotokoll. Die Sicherheitsfragen werden laut RFC 1220 nicht behandelt. Darum belegt das Dokument weder Authentisierung noch Berechtigung, Vertraulichkeit, Rollback, tatsächliche Einführung oder Dienstwirkung.

Die historische Leistung von Open war seine Genauigkeit: Der Zustand bezeichnete den frühesten erlaubten Beginn des LAN-Verkehrs. Ungenau wurde erst eine spätere Erfolgsmeldung, die diesen Anfang zum Ende der Beweiskette erklärte.

Quellen