Zusammenfassung

  • RFC 1473 führte getrennte Konfigurations- und Betriebstabellen für IP über PPP. Ein administratives open speiste ein Ereignis in den IPCP-Zustandsautomaten ein; es versprach nicht den späteren Zustand Opened.
  • Eine geänderte Kompressionspräferenz wurde erst beim nächsten Neustart der Verbindung wirksam. Davor waren ausgegebene Protokoll- und Slotwerte undefiniert; danach belegten sie ausgehandelte Parameter, keinen zugestellten IP-Datenverkehr.

Der im Juni 1993 veröffentlichte RFC 1473 definierte die PPP IP Group, also verwaltbare Objekte für das IP Network Control Protocol. Die Auswahl war absichtlich klein. Ein Objekt sollte für Fehler- oder Konfigurationsmanagement erforderlich und gegenwärtig nützlich sein; ableitbare Werte und reine Debug-Hilfen blieben außen vor.

Gerade dadurch wurde die MIB zu einem präzisen historischen Modell. Sie unterschied den Wunsch eines Operators, das Ergebnis eines Protokollablaufs und die nachfolgende Wirkung auf der Leitung.

Open war ein Ereignis, keine Erfolgsmeldung

pppIpConfigAdminStatus gehörte zur beschreibbaren Konfiguration. Der Wert open erzeugte ein administratives Open-Ereignis für den IPCP-Zustandsautomaten, close entsprechend ein Close-Ereignis.

Ein angenommenes Schreibkommando belegt deshalb nur, dass der Management-Agent eine zulässige Anweisung erhielt. Der Automat braucht womöglich noch eine verfügbare untere Schicht, Antworten des Peers, akzeptable Optionen und Zeit. Zwischen akzeptiertem Auftrag und erreichtem Zustand liegt die Hoheit anderer Komponenten.

Der spätere RFC 1661 behielt diese Architektur bei. Jedes Netzschichtprotokoll wurde durch ein eigenes Network Control Protocol konfiguriert, und jedes NCP ließ sich unabhängig öffnen und schließen. Selbst auf derselben PPP-Verbindung musste ein IPCP-Fehler nicht den Zustand anderer NCPs bestimmen.

Die Konfiguration wartete auf eine Grenze

pppIpConfigCompression war das zweite beschreibbare Objekt. Es wählte, ob der lokale Knoten keine Kompression oder Van-Jacobson-TCP/IP-Headerkompression auszuhandeln versuchen sollte. Seine Definition enthielt eine entscheidende Zeitangabe: Eine Änderung wurde beim nächsten Neustart der Verbindung wirksam.

Der gespeicherte Wert war somit kein Abbild der aktiven Sitzung. Er war eine Vorgabe für einen künftigen Übergang. Für einen belastbaren Wirksamkeitsnachweis brauchte es die bestätigte Speicherung, einen bestimmten Neustart, die darauf folgende IPCP-Aushandlung und deren Zustandsergebnis.

RFC 1332 beschrieb die Verhandlung dahinter. Die Option IP-Compression-Protocol hatte standardmäßig keine Kompression. Sie teilte mit, welches komprimierte Protokoll eine Seite empfangen konnte. Für Kompression in beide Richtungen musste daher jede Seite ihren Empfangswunsch eigenständig aushandeln.

Aus einer lokalen Einstellung folgte weder ein Neustart noch die Zustimmung des Peers. Und aus der Zustimmung für eine Richtung folgte kein symmetrisches Ergebnis für die andere.

Ein gültiger Datentyp konnte noch keine gültige Aussage sein

Die Betriebstabelle stellte pppIpOperStatus sowie Kompressionsprotokoll und maximalen Slotbezeichner für beide Richtungen bereit. RFC 1473 begrenzte jedoch, wann die ausgehandelten Werte verfügbar waren: erst nach abgeschlossener PPP-Optionsaushandlung, angezeigt durch IPCP im Zustand Opened.

Vor Opened war ihr Inhalt undefiniert. Welchen Wert eine Implementierung trotzdem zurückgab, blieb ihr überlassen.

Das ist nicht dasselbe wie ein möglicherweise veralteter Messwert. Ein alter Wert verweist immerhin auf einen früheren Zustand. Ein undefinierter Wert darf Rest, Null, Voreinstellung oder eine andere Implementierungswahl sein, ohne diese Verhandlung zu beschreiben. Eine technisch erfolgreiche Abfrage mit korrekt typisierter Ganzzahl schafft keine semantische Evidenz.

Nach Opened blieb außerdem die Richtung maßgeblich. local-to-remote beschrieb den Versand der lokalen Seite, remote-to-local den umgekehrten Weg. Max-Slot-Id war nur zusammen mit Van-Jacobson-Kompression aussagekräftig; sonst musste es Null sein. Status, Richtung und Protokoll bildeten gemeinsam den Kontext des Zahlenwerts.

Opened erlaubte Verkehr, bestätigte ihn aber nicht

Nach RFC 1332 mussten PPP die Network-Layer Protocol Phase und IPCP den Zustand Opened erreichen, bevor IP-Pakete übertragen werden konnten. RFC 1661 verlangte später, Pakete eines Netzschichtprotokolls vor geöffnetem NCP zu verwerfen.

Opened war damit eine wirksame Schranke. Es blieb aber eine Tatsache des Zustandsautomaten. Der Zustand nannte kein Paket, erhöhte keinen Zähler, belegte keine korrekte Dekompression, keine Route und keine Antwort einer Anwendung.

RFC 1144 zeigte den Nutzen der TCP/IP-Headerkompression auf langsamen seriellen Leitungen: Wiederkehrende Headerinformationen ließen sich anhand eines Verbindungszustands verkürzt darstellen. Doch eine ausgehandelte Fähigkeit ist noch kein komprimiertes Paket, ein Paket noch keine richtige Rekonstruktion und diese noch kein nutzbares Ergebnis.

Eine ehrliche Verwaltung bewahrt die Übergänge

RFC 1473 trennte die schreibbare Konfiguration auch deshalb, damit sie in einer eigenen Managementsicht geschützt werden konnte. Der Sicherheitsteil warnte vor den Risiken von PPP-Konfiguration und -Steuerung. Im selben Dokumentensatz behandelte RFC 1471 LCP, während RFC 1472 die Authentifizierungskonfiguration absonderte. Kein einzelner Status sollte alles behaupten.

Ein heutiges Änderungssystem müsste daher eine Beweiskette führen: Wer verlangte die Kompression, welche Konfigurationsgeneration speicherte der Agent, welcher Neustart nahm sie auf, welche Option bot jede Richtung an, was bestätigte oder verwarf der Peer, wann wechselte IPCP nach Opened und welche Paket-, Fehler- und Anwendungsspuren folgten?

Fehlt diese Kette, wird aus einer vorgemerkten Einstellung eine scheinbar aktive, aus einem undefinierten Rückgabewert eine Messung und aus Opened eine vermeintliche Zustellung. RFC 1473 erinnert daran, dass ein gutes Managementsystem auch die noch nicht entstandene Tatsache ausweist.

Quellen