Zusammenfassung

  • RFC 3518 fügte PPP BCP die aushandelbare Option Bridge-Control-Packet-Indicator hinzu. War sie aktiv, musste der Sender erkannte BPDU- und GARP-Kontrollframes kennzeichnen und ihren Verlust oder eine erhebliche Verzögerung vermeiden.
  • Das C-Bit belegte eine lokale Klassifikation und eine Fähigkeit zwischen Nachbarn. Es authentisierte kein BPDU und bewies weder Annahme durch den Empfänger noch Spanning-Tree-Konvergenz oder Schleifenfreiheit.

Nutzdaten verwenden den Weiterleitungszustand, der bereits besteht. Ein BPDU kann dazu beitragen, diesen Zustand zu ändern: Root Bridge, Portrollen und gesperrte Redundanzpfade. Deshalb kann ein kleiner Kontrollframe, der hinter Massendaten warten muss, größere Folgen haben als seine Größe vermuten lässt.

PPP-Bridging war 2003 kein Neubau. RFC 1638 hatte einen frühen Mechanismus beschrieben, RFC 2878 den Bridging Control Protocol überarbeitet. Zwei Endpunkte konnten Brückeneigenschaften aushandeln und LAN-Frames über eine Punkt-zu-Punkt-Verbindung tragen. RFC 3518 erklärte RFC 2878 für obsolet, beschränkte seinen eigenen Eingriff aber auf einen klaren Zusatz.

Die Änderungsliste nannte genau zwei Punkte: die Konfigurationsoption Bridge Control Packet Indicator und eine neue Bedeutung für ein reserviertes Flag-Bit. Kein neuer Spanning Tree entstand. Sichtbar wurde vielmehr eine Kontrollklasse an der Stelle, an der Warteschlangen tatsächlich anders handeln konnten.

BCP-Optionstyp 10 handelte die Unterstützung aus. Standardmäßig war sie aus. Nach erfolgreicher Aushandlung musste ein System das C-Bit genau dann auf eins setzen, wenn der ausgehende Frame ein Bridge-Control-Frame war. Ohne Aushandlung blieb es stets null; ein nicht teilnehmendes System durfte keinen gesetzten Indikator senden oder empfangen. So blieb RFC-2878-Kompatibilität erhalten.

Die Klassifikation folgte IEEE-Ziel-MAC-Adressen. RFC 3518 bezog Spanning-Tree-BPDUs, Bridge Management sowie GMRP und GVRP ein. Der Sender erkannte die Protokolleigenschaft und trug seine Entscheidung in den Header des gebridgeten PPP-Frames ein.

Der Nutzen lag in der Behandlung. Implementierungen sollten Kontrollpakete weder verwerfen noch wesentlich verzögern. Der RFC verglich das mit hoher IP-Precedence für Routing-Updates und verwies auf den Differentiated-Services-Rahmen von RFC 2474. Eine Warteschlange konnte den markierten Frame gegenüber umfangreichen Daten bevorzugen.

Damit war echte Wirkung verbunden, aber nur am lokalen Kontrollpunkt. Der Klassifikator dokumentierte seine Zuordnung. Die Verhandlung bewies, dass der benachbarte PPP-Peer das Bit verstand. Ein Empfangszähler belegte den Linktransport. Keiner dieser Nachweise signierte den Inhalt, bestätigte die Autorität der Quelle für die Spanning-Tree-Domäne oder beobachtete alle Brücken.

Die Belegkette lässt sich nicht durch ein einziges grünes Signal ersetzen. Der IANA-Eintrag beweist die Zuweisung der Nummer 10. Configure-Request und Configure-Ack belegen eine Sitzungsfähigkeit. Ein Mitschnitt zeigt das C-Bit. Erst Zustandsänderungen des empfangenden Kontrollprozesses, Root- und Portrollen sowie Datenebenenbeobachtung können stützen, dass redundante Pfade tatsächlich blockiert wurden.

Auch Opened bleibt eine Protokollphase. RFC 1661 definiert die PPP-Zustandsmaschine, deren Austausch BCP übernimmt. RFC 3518 verhindert Opened bei bestimmten unauflösbaren Konflikten, etwa einer widersprüchlichen Wahl des Spanning-Tree-Protokolls. Der erfolgreiche Zustand besagt, dass zwei Endpunkte eine akzeptable Schnittmenge fanden; er inventarisiert nicht die Netze hinter ihnen.

Der Sicherheitsabschnitt nennt das Restrisiko ohne Umschweife. Kommt ein gebridgter Link mit einem bösartigen Peer hoch, kann weitergeleiteter Multicast Netzinformationen verraten. Der Peer kann zudem Schleifen schließen, die erkannt und isoliert werden sollten, oder bösartige Last anbieten. Formell richtige Aushandlung und gefährliche Topologie schließen einander nicht aus.

RFC 3518 empfiehlt deshalb PPP-Authentisierung während des LCP-Starts, wenn fremde oder kompromittierte Geräte denkbar sind. CHAP nach RFC 1994 stärkt über Challenge und Response die Aussage zur Peer-Identität. Es bescheinigt aber weder eine korrekte Bridge-Konfiguration noch frische BPDUs oder einen konvergierten Baum. Identität reduziert eine Unsicherheit, nicht alle.

Multilink-Verfahren arbeiten auf einer anderen Ebene. RFC 1990 verteilt Fragmente und Sequenzen über mehrere Komponenten; RFC 2686 ergänzt Klassen für unterschiedliche Verzögerungsanforderungen. Beides kann ein BPDU schneller oder regelmäßiger transportieren. Schnelle Beförderung ist dennoch kein Beleg für Annahme und Wirkung.

Für ältere BCP-Bridges bewahrte RFC 3518 zudem ein altes BPDU-Format, während regulär das gemeinsame Bridged-Frame-Format galt. Diese Ausnahme löste die Lesbarkeit beim Nachbarn. Sie gab keinen Aufschluss über die dahinterliegende Domäne.

RFC 7042 beschrieb später die Verwaltungsgrenze zwischen IETF- und IEEE-802-Parametern, und das PPP-Register führt Option 10 weiter. Register schaffen stabile Nummernautorität. Sie sehen keine Sitzung und können weder Echtheit noch Pünktlichkeit oder Topologiewirkung bestätigen.

Der historische Wert von RFC 3518 liegt in seiner Begrenzung. Das Bit stellte einer Schnittstelle gerade genug Information bereit, um Kontrollverkehr besser zu behandeln. Es erhob diese Schnittstelle nicht zum Orakel über ein verteiltes System. Markieren und priorisieren waren lokal; Konvergenz und Schleifenfreiheit blieben Ergebnisse mit eigenen Nachweisen.

Ein BPDU kann korrekt erkannt und schnell geliefert werden, obwohl es veraltet ist, von einem kompromittierten Peer stammt, in die falsche Domäne gelangt oder auf uneinige Brücken trifft. Das C-Bit erklärt die beabsichtigte Behandlung des Frames. Es erklärt nicht die Topologie für sicher.

Quellen