Zusammenfassung

  • In den übernommenen Feldern TCP_SPACE und NON_TCP_SPACE aus RFC 2509 war null die höchste Kontext-ID; CID 0 blieb also ein verfügbarer Kontext.
  • Die drei Oktette lange Suboption 3 in RFC 3544 konnte die Zahl der TCP- oder Nicht-TCP-Kontexte ausdrücklich auf null setzen und diese Klasse damit abschalten.

Die Falle lag im Feldnamen. TCP_SPACE und NON_TCP_SPACE zählten keine Kontexte, sondern gaben die höchste Kennung ihres jeweiligen ID-Raums an. Bei einem Höchstwert von null enthielt der Raum weiterhin CID 0. Für eine minimale Konfiguration konnte das genügen; „Pakete dieser Klasse überhaupt nicht komprimieren“ ließ sich mit diesen Feldern allein jedoch nicht sagen.

RFC 3544 erschien im Juli 2003 als Proposed Standard und überarbeitete die PPP-Aushandlungsoption aus RFC 2509, ohne deren bisherige Nullsemantik zu ändern. Suboption 3 lieferte die fehlende Unterscheidung: Typ 3, Länge 3 Oktette, dazu ein ein Oktett langer Parameter. Wert 1 bedeutet null TCP-Kontexte, Wert 2 null Nicht-TCP-Kontexte. Die Suboption überschreibt den entsprechenden Wert in TCP_SPACE oder NON_TCP_SPACE. Werden beide Parameter angegeben, ist die Kompression für alle Pakete abgeschaltet.

Das ist eine Kompatibilitätskorrektur mit ausdrücklicher Überschreibung, keine Neudeutung der Null. Die alten Felder behalten ihren etablierten Sinn; ein zusätzliches Signal transportiert die Absicht, für die dort kein Wert frei war. Eine Änderung der Bitbedeutung hätte alte und neue Gegenstellen dieselben Bits unterschiedlich lesen lassen.

Zwei NCPs handeln getrennt aus

PPP handelt Linkparameter über Network Control Protocols aus. RFC 3544 definiert dasselbe Optionsformat für IPCP bei IPv4 und IPV6CP bei IPv6. Jedes NCP stellt die Kompression für Pakete ein, deren äußerer Netzwerkheader zur jeweiligen Version gehört. IPv4- und IPv6-Kompression sind damit getrennte Ergebnisse der Steuerungsebene, kein gemeinsamer Schalter.

Eine weitere Feinheit: IPv4 und IPv6 teilen sich den Kontext-ID-Raum, obwohl die Parameter unabhängig ausgehandelt werden. Bei unterschiedlichen Werten muss der Kompressor IDs aus einem gemeinsamen Pool vergeben; der Dekompressor muss den Kontextzustand prüfen, um die richtigen Parameter anzuwenden. TCP und Nicht-TCP/UDP/RTP teilen dagegen keinen Kontextbereich. Das sind Protokollvorgaben für den Betrieb, aber kein Beleg dafür, dass eine konkrete Gegenstelle sie konfiguriert oder genutzt hat.

RFC 3544 ergänzt außerdem die RTP-Suboption Typ 2 für Enhanced RTP. Sie wird anstelle der älteren RTP-Suboption 1 ausgehandelt, nicht zusätzlich zu ihr. Zusammen mit neun PPP-Protokollfeldwerten ermöglichen die Optionen, Frames einzuordnen und zulässige ausgehandelte Formate zu erkennen. Das Protokollfeld dient der Demultiplexierung; die Suboption signalisiert Konfigurationsabsicht.

Aushandlung ist kein Datenpfad-Nachweis

Nach erfolgreicher Aushandlung dürfen die genannten Protokollkennungen verwendet werden. Daraus folgt nicht, dass ein Gerät tatsächlich komprimierte Frames gesendet hat, die Gegenstelle sie dekodierte, das Datagramm zugestellt wurde oder kleiner ausfiel. Das sind unterschiedliche Beobachtungen an unterschiedlichen Stellen des Pfads. Der Konfigurationsaustausch belegt vereinbarte Parameter, nicht den Empfang von Verkehr.

Das Dokument markiert eine benachbarte Unklarheit ausdrücklich: RFC 1332 sagt nicht, ob die Option die Fähigkeit des Senders oder des Empfängers beschreibt. RFC 3544 nimmt entsprechend der damaligen Praxis an, dass eine Config-Req den Dekompressor der sendenden Gegenstelle beschreibt. Das ist eine offen ausgewiesene Annahme, keine normative Klarstellung von RFC 1332. Eine stärkere Behauptung würde den Vorbehalt des Textes unterschlagen.

Auch der Datenpfad hat eine eigene Bedingung. IPHC verwendet Delta-Kodierung für TCP und RTP; komprimierte Pakete hängen daher vom Kontext an beiden Enden ab. PPP sortiert Pakete selbst nicht um, weshalb Schutzmechanismen gegen Umordnung standardmäßig deaktiviert sind. Werden Multiclass Multilink PPP oder andere Mechanismen mit möglicher Umordnung eingesetzt, dürfen Pakete desselben Kompressionskontexts nicht vertauscht ankommen. Die ausgehandelte Formatwahl hebt diese Transportbedingung nicht auf.

Die historische Aussage ist begrenzt: Bei der Weiterentwicklung eines Protokolls braucht es mitunter ein zweites Signal, weil der naheliegende Wert bereits eine gültige Bedeutung hat. RFC 3544 ließ das Feld unverändert, ergänzte eine ausdrückliche Überschreibung und beließ Fähigkeit, Senden, Dekodieren, Zustellung und Leistung als getrennt zu prüfende Tatsachen.

Quellen