Zusammenfassung

  • Das zurückgesendete PPP-Max-Payload-Tag zeigt Unterstützung für eine Erweiterung an. Die lokale Schnittstelle und die anschließende LCP-Aushandlung begrenzen deren tatsächliche Nutzung.
  • Die ursprüngliche PPPoE-Grenze von 1492 Byte entstand aus 1500 Byte Ethernet-Nutzlast abzüglich sechs Byte PPPoE-Kopf und zwei Byte PPP-Protokollkennung.
  • Mit dem Umzug des PPP-Endpunkts vom PC zum Heimrouter wurde aus einer bekannten Endgerätebedingung eine Übergabe zwischen unterschiedlich großen Nutzlasten. Ein späterer Größentest konnte den Sender für die laufende Sitzung wieder auf 1492 beschränken.

Die Bestätigung bestätigt nicht alles

Man liest eine Aufzeichnung der PPPoE-Verbindungsaufnahme. Der Client kündigt eine größere Nutzlast an. Der Server schickt genau dieses Tag zurück. Später erlaubt die LCP-Aushandlung weniger als den zunächst sichtbaren Wert. Wer beide Schritte für ein einziges Versprechen hält, vermutet einen Fehler.

Der RFC 4638 vom September 2006 sieht jedoch genau diese Trennung vor. Ein unterstützender Server gibt das Tag des Clients in der Discovery-Phase zurück. Er muss den Wert dort nicht in seine eigene endgültige Obergrenze umschreiben. Seine lokalen Bedingungen wirken anschließend auf die normale PPP-Aushandlung.

Die im Dokument beschriebene Berechnung beginnt bei 1492. Nur wenn das Tag vorhanden ist und einen höheren Wert nennt, kommt eine höhere Grenze in Betracht. Diese ist der kleinere Wert aus der Ankündigung und der MTU der Schnittstelle minus acht Byte. Erst innerhalb dieses Rahmens wird die tatsächliche MRU vereinbart.

Das ist mehr als eine Reihenfolge für Implementierer. Das zurückgesendete Tag belegt gemeinsame Protokollkenntnis, nicht die Beseitigung einer lokalen Begrenzung. Selbst ein vollständig übereinstimmender Austausch kann nicht für jedes Ethernet-Segment zwischen den Teilnehmern sprechen.

Warum gerade acht Byte?

Der RFC 2516 führte im Februar 1999 PPP over Ethernet mit zwei getrennten Phasen aus. In Discovery findet der Client einen Zugangskonzentrator. PADI wird ausgesendet, PADO bietet eine Gegenstelle an, PADR fordert die ausgewählte Sitzung an, PADS bestätigt sie. Ethernet-Adressen und Sitzungskennung ordnen die folgenden Pakete zu.

Danach folgt die PPP-Sitzung. Die erfolgreiche Suche ersetzt weder die weitere Link-Konfiguration noch eine gegebenenfalls erforderliche Authentifizierung oder Netzwerkschichtkonfiguration. Sie ist erst recht kein Test jeder später verwendeten Paketgröße.

Für die ursprüngliche Größenbegrenzung rechnete RFC 2516 mit 1500 Byte maximaler Ethernet-Nutzlast. Sechs Byte benötigt der PPPoE-Kopf, zwei die PPP-Protokollkennung. Für PPP bleiben 1492 Byte. Diese Differenz gehört zur Kapselung; sie ist kein frei gewählter Sicherheitsabstand.

Wichtig ist die Bezugsgröße. 1500 meint hier nicht den vollständigen Rahmen auf dem Übertragungsmedium mit Ethernet-Kopf, Prüfsumme und weiteren Bestandteilen. Wer Nutzlast und Gesamtrahmen gegeneinander hält, erzeugt einen scheinbaren Widerspruch durch unterschiedliche Zählweisen.

Auch die Erweiterung von 2006 ließ die acht Byte nicht verschwinden. Für 1500 Byte PPP-Nutzlast muss die darunterliegende Ethernet-Nutzlast unter dieser Sechs-plus-zwei-Rechnung 1508 Byte aufnehmen. Das setzt größere Rahmenkapazität voraus. Es liefert keine universelle Zahl, die sich ungeprüft in jedes Gerätemenü eintragen ließe.

Die Grenze zog vom Rechner zum Übergang

RFC 4638 beschreibt einen Wandel des Zugangsmodells. Ursprünglich konnte der PC selbst die PPPoE-Sitzung beginnen. Die für ihn sichtbare Begrenzung auf 1492 war in diesem Modell meist akzeptabel.

Ein Residential Gateway veränderte die Lage: Auf der LAN-Seite nahm es gewöhnlichen IP-Verkehr über Ethernet entgegen, auf der Zugangsseite begann es PPPoE. Ein IP-Paket mit 1500 Byte traf damit auf eine Verbindung, deren PPP-Nutzlast herkömmlich auf 1492 begrenzt war. Der Erzeuger dieses Pakets war nicht mehr selbst der Teilnehmer der betroffenen PPP-Aushandlung.

Das Dokument behandelt außerdem Übergänge von PPPoA zu PPPoE und berichtet über damals eingesetzte PPPoA-Endgeräte, die 1492 nicht unterstützen konnten. Diese Aussage beschreibt den historischen Anlass. Sie ist weder eine aktuelle Bestandsaufnahme noch eine Behauptung über jedes Gerät dieser Art.

PPP über ATM war seinerseits nicht grenzenlos. Nach RFC 2364 vom Juli 1998 durfte die MRU bei PPP over AAL5 die maximale CPCS-SDU des Verkehrsvertrags für die betreffende Richtung der virtuellen Verbindung nicht übersteigen. Eine Migration wechselte also zwischen unterschiedlichen unteren Rahmenbedingungen.

Die politische Ökonomie dieser kleinen technischen Änderung liegt in der Übergabe: Der LAN-Rechner konnte normale Erwartungen behalten, während das Gateway und der Zugang deren Vereinbarkeit herstellen mussten. Diese Analyse erklärt Verantwortlichkeiten; sie ist keine Behauptung über verborgene Absichten der RFC-Verfasser.

Eine Empfangsgrenze ist kein Füllbefehl

Der RFC 1661 vom Juli 1994 definiert die Maximum-Receive-Unit für Information und Padding. Protokollfeld, Rahmenbildung und deren Prüffelder gehören nicht dazu. Die gewöhnliche PPP-Vorgabe beträgt 1500 Byte, doch sie hebt die besondere PPPoE-Beschränkung nicht einfach auf.

Eine MRU teilt dem Gegenüber mit, welche Größe empfangen werden kann oder welche kleinere Größe gewünscht ist. Sie verlangt nicht, dass jedes Paket diesen Raum ausnutzt. Deshalb sind zulässiger Höchstwert, tatsächlich ausgehandelter Wert und beobachtete Paketgröße verschiedene Messgrößen.

PPP-Max-Payload ergänzt dafür einen Schritt vor LCP. Ein Client, der mehr als 1492 nutzen will, muss das Tag sowohl in PADI als auch in PADR senden. Ein Server mit entsprechender Unterstützung muss es nach Empfang in PADO und PADS zurückgeben. Erst die beiderseitige Anzeige schafft die Voraussetzung, die historische Obergrenze zu verlassen.

Der Tag-Typ lautet 0x0120, dezimal 288. Sein zwei Byte langer Binärwert bezeichnet die maximale PPP-Nutzlast, die der Client sowohl senden als auch empfangen kann. 288 ist also ein Kennzeichen und keine angekündigte Nutzlast. Die Tag-Daten sind auch nicht zusätzliche Kopfkosten jedes späteren Sitzungspakets.

Fehlt die beiderseitige Anzeige, bleibt es bei 1492. Ältere Implementierungen können unbekannte Discovery-Tags ignorieren. Daraus darf keine stillschweigende Zustimmung zur Erweiterung entstehen. Ein Tag-Wert von höchstens 1492 öffnet ebenfalls keinen größeren Spielraum.

Selbst ein Wert oberhalb von 1500 setzt die tatsächliche MRU nicht automatisch entsprechend herauf. Sind die Erweiterungsbedingungen erfüllt, aber wird kein größerer MRU ausgehandelt, bleibt der normale PPP-Standardwert 1500 bestehen. Die Fähigkeitserklärung ist eine Obergrenze, nicht der fertige Betriebszustand.

Die Zwischenstrecke hat nicht mitverhandelt

Ein Ethernet-Bridge kann die kleinen Kontrollnachrichten transportieren und trotzdem größere Rahmen nicht weiterreichen. Discovery und LCP enthalten keine Abstimmung aller dazwischenliegenden Geräte über deren Kapazität.

Deshalb ergänzt RFC 4638 einen betrieblichen Vergleich. Nach Öffnung der Sitzung und Aushandlung einer MRU oberhalb von 1492 sollte der Sender die Möglichkeit haben, eine oder mehrere LCP-Echo-Requests in MRU-Größe zu senden. Bleiben Antworten aus, darf er mit 1492 Byte wiederholen. Kommen darauf Antworten, darf er in dieser Sitzung keine größeren Pakete als 1492 mehr senden.

Die Abstufung der Vorschrift zählt. Die Testmöglichkeit sollte standardmäßig aktiv und konfigurierbar sein; bei vorhandenem Wissen über das Netz darf sie deaktiviert werden. Das Dokument schreibt nicht jedem Betreiber eine identische Zahl von Versuchen oder einen bestimmten Warteabstand vor.

Der Vergleich begrenzt Verhalten, ohne eine genaue Fehlerstelle auszuweisen. Groß ohne Antwort und klein mit Antwort ist ein anderer Befund als zweimal ohne Antwort. Ein kleines erfolgreiches Paket ist keine Bestätigung für ein großes. Auch eine erfolgreiche große Anfrage beweist nicht zeitlich unbegrenzte Kapazität in beiden Richtungen.

Nach RFC 1661 gehören Echo-Request und Echo-Reply in den Zustand LCP Opened. Die Antwort übernimmt die passende Identifier-Kennung. Daraus folgt aber keine allgemeine Garantie, dass die Antwort genauso groß wie die Anfrage ist. Eine Auswertung muss deshalb tatsächliche Größen und Richtungen festhalten, statt nur ein grünes Prüfsymbol zu speichern.

Nicht der gesamte Internetpfad

Die PPPoE-Prüfung ist von Path MTU Discovery zu unterscheiden. RFC 1191 beschrieb im November 1990 für IPv4, wie eine Quelle mit gesetztem Nicht-fragmentieren-Bit ihre Größenannahme anpasst. Ein Router, der ein Paket nicht ohne Fragmentierung weiterleiten kann, verwirft es und meldet den Bedarf über ICMP.

Damit ist auch die pauschale Formulierung falsch, jedes zu große Paket werde einfach fragmentiert. Das DF-Bit verändert den Ablauf. Und eine bestandene Größenprüfung innerhalb des PPPoE-Zugangs sagt noch nichts Abschließendes über engere Stellen hinter diesem Zugang aus.

Diese Grenze schützt die Aussagekraft des Tests. Er ist nützlich, weil er eine konkrete Sitzung betrifft. Würde man daraus ein Zertifikat für beliebige Internetziele machen, wäre der behauptete Nachweis größer als die gemessene Strecke.

Die Nummer bekam einen gemeinsamen Ort

RFC 4638 erschien als Informational-Dokument, nicht als Internet Standard. Die vorangestellte IESG-Anmerkung warnte vor dem damaligen normativen Umfeld größerer Ethernet-Nutzlasten. Das ist eine Aussage aus dem Jahr 2006, keine Beschreibung des Normenstands von 2026.

Im Juni 2007 regelte RFC 4937 die IANA-Registrierung der 16-Bit-Tag-Typen und führte PPP-Max-Payload unter 288 auf. Das heute erfasste IANA-Register für PPPoE-Parameter dokumentiert dieselbe Zuordnung.

Ein gemeinsamer Codepunkt verhindert unterschiedliche Bedeutungen desselben Feldes. Er verteilt aber weder Puffer noch größere Schnittstellen auf bestehende Geräte. Die zeitliche Folge — Kapselung 1999, Erweiterung 2006, Registerregelung 2007 — sollte deshalb nicht als ein einziger flächendeckender Umstellungstermin erzählt werden.

Der Wert, den der Server zurückschickte, blieb eine präzise begrenzte Aussage. Der Gewinn lag darin, diese Aussage von Aushandlung und Betrieb zu unterscheiden. Acht Byte wurden nicht wegverhandelt; ihre Beförderung erhielt überprüfbare Bedingungen.