Zusammenfassung

  • Beide PPP-Gegenstellen mussten denselben gleitenden Verlauf von 8192 Byte halten; ein 12-Bit-Kohärenzzähler in jedem MPPC-Paket machte Verlust oder unerwartete Reihenfolge sichtbar.
  • Bei einer Abweichung verwarf der Empfänger das Paket und sendete Reset-Request. Der Sender leerte seinen Verlauf und markierte das nächste Paket FLUSHED; dieses setzte den Empfänger und seinen Zähler neu, ohne Reset-Ack.
  • Der Beleg bleibt eng: Er eröffnet einen neuen Kompressionsverlauf, stellt aber keine verlorenen Daten wieder her und beweist weder zuverlässige Zustellung noch Integrität, Identität, Autorisierung oder Anwendungserfolg.

Die Antwort wanderte in den Datenpfad

Das allgemeine Verfahren aus RFC 1962 ist ein Kontrollvorgang. Nach Reset-Request verwirft der Dekompressor weitere komprimierte Pakete, bis ein Reset-Ack mit passender Kennung eintrifft; daran hängt die Rückkehr zum Ausgangszustand.

RFC 2118 wählte für MPPC einen anderen Beleg. Trifft ein anderer Kohärenzzähler als erwartet ein, verwirft der Empfänger das Paket und sendet Reset-Request. Der Kompressor löscht nach Empfang der Anforderung seinen Verlauf und setzt im nächsten MPPC-Paket FLUSHED. Der Dekompressor löscht beim Eintreffen ebenfalls seinen Verlauf und übernimmt den mitgesendeten Zähler. Damit gelingt die Synchronisierung ohne Reset-Ack.

Das folgende Paket ist unabhängig vom alten Verlauf dekodierbar und bildet deshalb den laufenden Beleg für die neue Epoche. Es repariert aber nicht die Vergangenheit: Die Lücke bleibt, ein eigener Zustellbeleg für Reset-Request fehlt, und der Weg zur Anwendung ist noch nicht nachgewiesen.

Option 18 vereinbarte genau eine Transformation

MPPC war keine automatische PPP-Eigenschaft. Die CCP-Option mit Typ 18 und Länge 6 nutzte ein einziges Bit, um den Algorithmus anzufordern; bei endgültiger Uneinigkeit blieb die Verbindung unkomprimiert. Das aktuelle IANA-PPP-Register führt Option 18 weiterhin als Microsoft PPC.

MPPC-Datagramme durften erst fließen, nachdem PPP die Network-Layer-Protocol-Phase und CCP den Zustand Opened erreicht hatte. Komprimierte Datagramme trugen Protocol 0x00FD, während CCP selbst 0x80FD nutzte. Die erste Zahl kennzeichnet den Datenpfad, aber erst die vorausgehende Aushandlung benennt das Verfahren.

Nur PPP-Protokolle von 0x0021 bis 0x00FA durchliefen MPPC. Andere behielten ihre ursprüngliche Nummer. Die Zustimmung zur Option belegte daher eine verfügbare Fähigkeit, nicht die Kompression jedes Pakets.

8192 Byte gemeinsames Gedächtnis schufen Abhängigkeit

Der LZ-Kompressor führte einen fortlaufenden Verlauf. Nach 8192 komprimiert übertragenen Byte stand ein vollständiges Fenster dieser Größe bereit, solange es nicht geleert worden war. Spätere Pakete konnten dadurch frühere Muster wiederverwenden; derselbe Gewinn machte ihre Bedeutung vom identischen Zustand beider Seiten abhängig.

Bit A, FLUSHED, sagte aus, dass der Sender den Verlauf vor Erzeugung des Pakets initialisiert hatte. Bit B setzte den Verlaufzeiger an den Anfang und musste mindestens einmal je 8192 komprimierte Byte auftreten. Bit C bezeichnete die Darstellung der aktuellen Daten als komprimiert oder nicht komprimiert. Keine dieser Angaben war ein Zustellbeleg.

Auch Expansion erzeugte eine Grenze. Wurde das komprimierte Ergebnis größer, sandte der Sender die Originaldaten in einem unkomprimierten MPPC-Paket. Vor der nächsten Kompression löschte er den Verlauf und markierte das nächste Paket FLUSHED. Der Schutz vor aktuellem Mehrvolumen kostete damit den angesammelten Kontext.

Zwölf Bit fanden den Bruch, nicht die Ursache

Der Kohärenzzähler begann bei null, stieg mit jedem MPPC-Paket und sprang nach 4095 auf null zurück. Eine Abweichung zeigte Verlust oder Umordnung. Deshalb verlangte MPPC keinen zuverlässigen Link, obwohl RFC 1663 einen zuverlässigen PPP-Modus definierte.

RFC 2118 verlangte zugleich Reihenfolge, damit die Neusynchronisierung gelingt. „Kein zuverlässiger Link erforderlich“ bedeutete nicht, dass beliebige Umordnung folgenlos blieb. Ein passender Zähler prüfte auch nicht den Inhalt. Die Security Considerations erklären lediglich, dass Sicherheitsfragen nicht behandelt werden; Vertraulichkeit, kryptographische Integrität, Identität, Autorisierung und Replay-Schutz entstehen daraus nicht.

Informational und historisch lizenziert

RFC 2118 erschien im März 1997 als Informational, nicht als Internet Standard. Der Lizenzabschnitt beschränkte MPPC auf PPP-Produkte zur Interoperabilität mit MPPC/PPP und verwies auf Lizenzen von Stac Electronics. Das dokumentiert die damalige Oberfläche, nicht heutige Lizenz-, Patent- oder Einsatzverhältnisse.

Die Auslegung folgt Running-Code Primacy und Minimum Initial Specification: Jedes Signal soll nur seine kleinste überprüfbare Aussage tragen. Die Option belegt Fähigkeit, der Zähler eine Reihenfolgedifferenz, Reset-Request den Reparaturwunsch und FLUSHED einen neuen Verlauf. Keines darf Ergebnisse anderer Schichten verkünden.

Quellen und Beweisgrenze

Die Primärakte umfasst RFC 2118 als HTML, die Textfassung, den RFC-Editor-Eintrag und den Errata-Zugang, außerdem RFC 1962, RFC 1661, RFC 1663 und das IANA-Register. Die Heng-Lu-Essays lenken die Interpretation, ersetzen aber keine Protokollquelle. Belegt sind Spezifikation und Dokumentstatus, nicht heutiger Einsatz, Leistung, Sicherheit oder das Ergebnis eines realen Pakets.