Zusammenfassung

  • Mit PPPMuxCP bot ein Empfänger richtungsabhängig an, multiplexierte PPP-Frames anzunehmen. Eine erfolgreiche Aushandlung erlaubte das Format, verpflichtete den Peer aber nicht, es zu senden.
  • Die Default-PID legte fest, wie ein fehlender Protokollwert rekonstruiert werden sollte. Sie bewies weder PFF=0 noch ein entferntes Feld oder eingesparte Bytes.
  • Gemeinsames Framing konnte Overhead senken, zugleich aber Wartezeit und den Fehlerumfang eines äußeren Frames erhöhen. Fähigkeit, Einsatz, Rekonstruktion, Messwert und Anwendungsergebnis brauchen getrennte Belege.

Der Gewinn entstand nur durch tatsächlich geteilte Hüllen

Ein einzeln gerahmtes PPP-Paket trägt Grenzen, Protokollkennung und Prüfinformation. Aushandelbare Kompression entfernt einen Teil davon, doch bei kleinen Nutzlasten bleibt der wiederholte Anteil sichtbar. In einem L2TP-Tunnel kommt pro einzelnem PPP-Frame weiterer Overhead hinzu.

RFC 3153 bündelte mehrere PPP-Pakete als Subframes in einem äußeren PPP-Frame. Vor jedem Subframe steht ein kurzer Trenner, der die Anwesenheit der Protokollkennung und die Länge beschreibt. Nicht der Anwendungsinhalt wird komprimiert; mehrere Pakete teilen sich eine äußere Hülle.

Dafür müssen mehrere Pakete gleichzeitig verfügbar sein. Wartet der Sender auf den nächsten Kandidaten, wartet auch das erste Paket. Der RFC benennt deshalb den Zielkonflikt zwischen geringerem Overhead und zusätzlicher Multiplex-/Demultiplexverzögerung.

Unterstützung allein sagt nichts über den Saldo. Man muss äußere Frames, Subframe-Zahlen, Trenner, ausgelassene Felder, Queue-Zeit, Serialisierung und Verlustfolgen beobachten.

Der Empfänger öffnete die Richtung, der Sender bestimmte den Verkehr

PPPMuxCP wird in der NCP-Phase ausgehandelt. Der Empfänger bietet an, multiplexierte Frames in einer Richtung zu verstehen. Ohne dieses Angebot darf der Sender das Format nicht verwenden. Die Gegenrichtung ist eine eigene Vereinbarung.

Nach erfolgreichem Austausch bleibt die Nutzung freiwillig. Der Sender kann bestimmte Pakete bündeln oder alle einzeln lassen. RFC 3153 stellt ausdrücklich klar, dass Erfolg bei PPPMuxCP keine Sendepflicht erzeugt.

Ein grüner Status „aktiv“ ist daher mehrdeutig. Er kann Angebot, Configure-Ack, geladene Senderichtlinie oder beobachtete 0x0059-Daten bedeuten. Belastbare Historie verbindet den gerichteten Kontrollaustausch mit späteren Datenframes auf derselben Zeitachse.

Eine vereinbarte Default-PID sparte erst bei tatsächlicher Auslassung

PPPMuxCP handelt immer eine vom Empfänger angebotene Default-PID aus. Fehlt im ersten Subframe die Protokollkennung, setzt der Empfänger diesen Wert ein. Passt das Protokoll, darf der Sender PFF löschen und ein oder zwei Bytes auslassen.

Er darf die Kennung trotzdem senden. Der vereinbarte Wert ist eine bedingte Interpretationsregel, keine gemessene Einsparung.

Spätere Subframes mit PFF=1 tragen eine neue PID und aktualisieren Last_PID beziehungsweise Last_rcvd_PID. Bei PFF=0 gilt die letzte explizite PID weiter; am Frameanfang startet der Zustand mit der Default-PID.

Einsparungen lassen sich deshalb nur durch sequenzielles Parsen zählen. Die Anzahl äußerer Frames zeigt weder ausgelassene Felder noch Protokollwechsel.

MRU war eine Grenze, kein Füllziel

Der Trenner kombiniert PFF, LXT und LEN. LXT wählt die kurze oder erweiterte Längenform, LEN begrenzt den Subframe. Das Beispiel nutzt MAX_SF_LEN als lokale Zulassung und überschreitet nicht die durch LCP ausgehandelte MRU.

Die Sammlung endet, wenn der nächste Kandidat zu groß wäre, der Gesamtframe die MRU überschritte oder die Queue leer ist. Ein Timer kann hinzukommen. Wegen Latenz und Paketfehlern kann eine Grenze deutlich unterhalb der MRU sinnvoll sein.

Größere Aggregate verteilen den Header besser, lassen frühe Pakete aber länger warten und bringen mehr Subframes in den Fehlerbereich eines äußeren Frames. Linkrate, Fehlerquote, Burst-Verhalten und Anwendungsempfindlichkeit bestimmen die Bilanz.

MRU, MAX_SF_LEN und Timer sind daher drei verschiedene Belege: Empfangsgrenze, lokale Auswahl und Wartepolitik.

Demultiplexen bedeutete nicht Umordnen oder Zustellen

Bei 0x0059 liest der Empfänger Subframes nacheinander, übernimmt oder rekonstruiert die PID und reicht das Paket an gewöhnliches PPP weiter. Überschreitet eine Länge die verbliebenen Daten, wird der letzte Subframe verworfen; die verursachende falsche Länge kann auch früher liegen.

Multiplexierte Frames dürfen nicht verschachtelt und LCP-Frames nicht hineingelegt werden. Allein gesendete und gebündelte Pakete sollen ihre Reihenfolge behalten.

Ein Zähler rekonstruierter Pakete belegt diese Reihenfolge gegenüber benachbarten Einzel-Frames nicht. Dafür braucht man äußere Ankunft, innere Grenzen und Übergabereihenfolge.

Auch erfolgreiche Rekonstruktion ist noch keine Anwendungszustellung. Nach PPP folgen weitere Schichten und Entscheidungen.

Die Lage zu MP, CCP und ECP gehörte zum Protokoll

Bei Multilink PPP wird PPPMux für das Bundle ausgehandelt. Der Sender multiplexiert vor MP; ein MP-Header liegt außen. Multilink-Frames selbst dürfen nicht als Subframes transportiert werden.

PPPMux läuft nach bundleweitem CCP/ECP, aber vor MP und linkbezogenem CCP/ECP. Kann eine Implementierung PPPMux nicht oberhalb der linkbezogenen Form anordnen, muss sie diese bei ausgehandeltem PPPMux per Protocol-Reject ablehnen.

Eine Funktionsliste beweist diese Reihenfolge nicht. Die Reihenfolge bestimmt, welche Bytes jede Funktion sieht; auch der Messpunkt muss genannt werden. Ein ECP-Ack beweist zudem nicht, dass ein bestimmter Frame geschützt war.

Keine zusätzliche Sicherheitsbetrachtung war kein Schutzversprechen

RFC 3153 nennt keine zusätzlichen Sicherheitsbetrachtungen jenseits von PPP und Headerkompression. Das verleiht PPPMux weder Authentisierung noch Integrität, Vertraulichkeit oder Replay-Schutz.

Ungültige Längen, Parser-Unterschiede und ein abweichender PID-Zustand bleiben betriebliche Risiken. Ein korrekt dekodierter Frame kann von einem nicht ausreichend authentisierten Peer stammen.

Sicherheitsaussagen benötigen PPP-Authentisierung, tatsächlich aktives ECP, Frame-Integrität, Ablehnungsverhalten und nachgelagerte Wirkung. Formatverständnis ist Kompatibilität, nicht Vertrauen.

Die gemeinsame Regel endete vor der lokalen Optimierung

RFC 3153 machte nur das gemeinsam, was interoperabel sein musste: vorheriges Empfangsangebot, Protokollwerte, Flags, Längen, Rekonstruktion, Reihenfolge und Schichtlage. Ob die aktuelle Queue gebündelt wurde, blieb beim Sender.

Nichtnutzung nach der Aushandlung war gültig; Senden ohne Angebot war es nicht. So blieb der gemeinsame Kern deterministisch und die Adoption freiwillig.

Configure-Ack belegt Erlaubnis. 0x0059 belegt Nutzung. PFF/LXT/LEN belegen Kodierung. Empfängerprotokolle belegen Rekonstruktion. Paarmessungen belegen Bytes und Zeit. Nur die Anwendung belegt ihre Wirkung.

Die bleibende Lehre von RFC 3153 lautet deshalb nicht bloß „viele Pakete passen in einen Frame“. Sie lautet: „Ich kann es lesen“ ist nicht „du hast es gesendet“—und beides ist noch nicht „es hat geholfen“.

Quellen