Zusammenfassung

  • RFC 1474 führte Medienstatus pro PPP-Link und MAC-Typ. Lokales accept beschrieb die eigene Verarbeitung; entferntes accept nur die Überzeugung der lokalen Instanz über ihren Peer.
  • Nach RFC 1220 durfte Schweigen wie breite Unterstützung behandelt werden, obwohl der Empfänger unverstandene Typen verwerfen konnte. Selbst eine Ablehnung konnte mit weiterer Übertragung an den verwerfenden Empfänger zusammenfallen.

RFC 1474 erschien im Juni 1993 als MIB für das Bridge Network Control Protocol über PPP. Es machte Konfiguration, Protokollzustand und medientypspezifische Fähigkeiten sichtbar, ohne daraus eine lückenlose Geschichte des Frames zu bauen.

Gerade die begrenzte Aussage war eine Stärke. Das Dokument nannte nicht nur das vermeintliche Objekt des Wissens, sondern auch dessen Beobachter.

Zwei gleiche Werte, zwei verschiedene Zeugen

pppBridgeMediaTable war über ifIndex und pppBridgeMediaMacType indiziert. Eine Zeile galt für genau einen Link und einen MAC-Typ. Sie durfte weder auf andere Medien noch auf alle Verbindungen des Geräts übertragen werden.

Bei pppBridgeMediaLocalStatus=accept sagte die lokale Instanz zu, Pakete dieses Typs anzunehmen und richtig zu verarbeiten. dont-accept bedeutete, dass empfangene Pakete nicht richtig verarbeitet würden. Hier beschrieb das System sein eigenes Verhalten.

pppBridgeMediaRemoteStatus wechselte die Erkenntnisquelle. Es zeigte, ob die lokale Instanz glaubte, die Gegenstelle werde denselben Typ annehmen. Der Gegenstand war entfernt, die Schlussfolgerung lokal.

Eine Oberfläche kann beide Felder grün darstellen und damit den Unterschied beseitigen. Eigene Fähigkeit lässt sich mit lokaler Konfiguration und Ausführung verbinden. Die Fähigkeit des Peers wird aus Optionen, ausgelegtem Schweigen und dem gespeicherten Aushandlungszustand abgeleitet.

Schweigen war eine Kompatibilitätsregel

RFC 1220 definierte MAC Type Selection. Ein Knoten konnte mitteilen, welche Verkehrsarten er empfangen und bedienen konnte. Mehrere Typen benötigten mehrere Optionen im Configure-Request.

Ohne Mitteilung durfte der Nachbar Unterstützung für alle MAC-Typen annehmen. Gleichzeitig durfte der Empfänger Typen verwerfen, die er nicht verstand. Der Default gab dem Sender eine Handlungsregel; er erzeugte keine Fähigkeit auf der anderen Seite.

Eine ausdrückliche Liste erklärte nicht genannte Typen für unbrauchbar. Auch Configure-Reject war kein sauberer Beleg dafür, dass nichts mehr gesendet würde. RFC 1220 beschrieb den Fall, dass Verkehr weiter über den Link geleitet wird, obwohl der Empfänger angekündigt hatte, ihn zu verwerfen.

Der entfernte Status brauchte deshalb Herkunft: ausdrückliche Option oder Default, Antwort, Link, Typ und Aushandlungsgeneration.

Später hieß die Option ausdrücklich „advisory“

Der Nachfolger RFC 1638 empfahl 1994 die MAC-Support-Aushandlung nachdrücklich. Eine Mitteilung konnte unnötigen Verkehr vermeiden und Bandbreite sparen. Dennoch bezeichnete der Text die Option ausdrücklich als nur beratend.

Für MAC-Typen mit Nummern über 4 kam eine engere Regel hinzu: Ohne empfangene Bereitschaftserklärung des Peers durfte ein System sie nicht senden. Das begrenzte neue Erweiterungen stärker. Es machte aus der Bereitschaftserklärung noch keinen beobachteten Empfang.

Rückwärtskompatibilität, Effizienz und sichere Erweiterbarkeit erzeugten unterschiedliche Regeln. Sie verbesserten lokale Entscheidungen, ohne die Distanz zum tatsächlichen Ergebnis aufzuheben.

Medienfähigkeit war keine Forwarding-Datenbank

Eine Bridge kann einen Frame-Typ verstehen und trotzdem nicht wissen, welchem Port eine konkrete Zieladresse zugeordnet ist. RFC 1493 legte diese Information in eine separate Forwarding- und Filtertabelle für einzelne Unicast-MAC-Adressen und gelernte oder konfigurierte Ports.

RFC 1474 fragte nach der Form des Verkehrs auf einem PPP-Link. Die FDB fragte nach der Behandlung einer Adresse. Auch ein FDB-Eintrag war keine Quittung des Endsystems.

Eine belastbare Beweiskette müsste lokale Richtlinie, angewandte Neustartgeneration, BNCP-Austausch, Grundlage der Peer-Annahme, gesendeten Frame, Verarbeitung am Peer, Forwarding-Entscheidung und Endbeobachtung getrennt erhalten.

RFC 1661 setzte eine weitere Schwelle: Erst nach Opened des zugehörigen NCP trug PPP dessen Pakete. Vorher empfangene Pakete waren zu verwerfen. Opened erlaubte Verkehr, bestätigte aber keinen einzelnen Frame.

Ein Status braucht ein Erkenntnissubjekt

RFC 1474 trennte schreibbare Konfiguration und warnte vor den Sicherheitsrisiken der PPP-Steuerung. Geschützte MIB Views konnten den Zugriff begrenzen. Sie änderten nicht die Bedeutung des geschützten Wertes.

Eine heutige Anzeige „Peer unterstützt“ sollte Link, MAC-Typ, Konfigurationsgeneration, Neustart, NCP-Zustand, Option oder Default, Peer-Antwort und Berechnungszeit mitführen. Sonst wird aus „mein Modell sagt ja“ nach einigen Systemgrenzen „der Peer hat empfangen“.

Verteilte Systeme benötigen Annahmen. Gefährlich wird es, wenn ihre Urheber verschwinden und nur die visuelle Autorität des Ergebnisses bleibt.

RFC 1474 bewahrte den Urheber im Objekttext.

Quellen