Zusammenfassung

  • RFC 2516 begrenzte die PPP-MTU bei PPPoE auf 1.492 Byte: Sechs Byte PPPoE-Header und zwei Byte PPP Protocol ID belegten den Rest der 1.500 Byte großen Ethernet-Nutzlast.
  • RFC 4638 machte eine größere MTU/MRU zu einer optionalen ausgehandelten Fähigkeit. Client, Zugangs-Konzentrator, lokale Schnittstelleneinstellung und alle Ethernet-Abschnitte dazwischen mussten mitspielen, bevor eine Sitzung die zusätzlichen acht Byte transportieren konnte.

Die Grenze war eine einfache Rechnung

Eine Ethernet-Nutzlast von 1.500 Byte klingt groß genug für ein Internetpaket derselben Größe. PPPoE nahm acht Byte weg, bevor das Paket auf die Leitung kam: sechs für den eigenen Header, zwei für die PPP-Protokollkennung. Im Februar 1999 setzte RFC 2516 deshalb die PPP-MTU auf einem normalen Ethernet-Abschnitt auf 1.492 Byte.

Die Subtraktion war einfach. Die schwierigere Frage lautete: Warum sollte ein Breitbandanbieter PPP behalten, wenn das Zugangsgerät beim Kunden bereits Ethernet sprach?

Breitband wollte Ethernet und eine Sitzung pro Kunde

RFC 2516 gab eine betriebliche Antwort. Ethernet verband mehrere Geräte hinter einer Kunden-Bridge kostengünstig. PPP bewahrte den individuellen Zugangsschutz, die Abrechnung und das Dienstmodell pro Nutzer. Im Haushalt teilten sich Geräte ein lokales Medium; beim Anbieter erhielt jeder Kunde eine eigene PPP-Sitzung.

Diese Vereinbarung kostete jedes Paket acht Byte. Der Anbieter behielt die Sitzungsgrenze, während dem IP-Paket des Kunden innerhalb der üblichen 1.500 Byte Ethernet-Nutzlast acht Byte weniger Platz blieben. RFC 2516 schrieb die Grenze fest, statt die Geräte raten zu lassen, ob auf dem nächsten Link noch Platz war.

Der Unterschied wurde sichtbar, wenn eine Seite eine 1.500 Byte große PPP-Einheit erwartete und die andere 1.492 Byte aushandelte. Die Einleitung von RFC 4638 aus dem Jahr 2006 beschreibt, wie solche gemischten Breitbandpfade viele Fragmente erzeugen konnten. Die Erweiterung sollte Fragmentierung in Breitbandnetzen der nächsten Generation verringern.

Aus acht Byte wurde eine verhandelbare Fähigkeit

RFC 4638 ließ nicht jede PPPoE-Sitzung über 1.492 Byte laufen. Für die beschriebenen Breitbandnetze der nächsten Generation verlangt es jedoch, dass ein BRAS als PPPoE-Server eine Aushandlung über diesen Wert unterstützt; das optionale Tag PPP-Max-Payload entscheidet, ob ein bestimmter Client und Server den größeren Wert nutzen können. Sein Zwei-Byte-Wert gibt die maximale PPP-Nutzlast an, die der Client in beide Richtungen unterstützt. Für eine Anforderung über 1.492 Byte fügt der Client das Tag in PADI und PADR ein. Ein Server, der sie unterstützen kann, gibt es in PADO und PADS zurück.

Auch der Server hatte eine eigene Grenze. RFC 4638 erlaubt eine größere MRU, soweit lokale Konfiguration und der vom Client genannte Höchstwert es zulassen. Der ausgewählte Wert darf nicht höher sein als der kleinere Wert aus Tag und Server-Schnittstellen-MTU minus acht Byte. Ein Tag kann die Verhandlung eröffnen; es erweitert weder eine physische Schnittstelle noch ändert es die Konfiguration eines Abschnitts dazwischen.

Damit wurde aus einer Zahl eine Folge von Entscheidungen. Der Client kann mehr anfordern. Der Konzentrator antwortet nur im Rahmen seiner Fähigkeiten. Die lokale Schnittstelle muss Platz für die Kapselung lassen. Jeder Ethernet-Abschnitt auf dem Pfad muss das resultierende Paket transportieren. Eine Anzeige von 1.500 Byte beim Kunden ist keine Bestätigung, dass jeder Switch zwischen Wohnung und Konzentrator diesen Wert akzeptiert.

Der Pfad durfte ebenfalls Nein sagen

RFC 4638 beschreibt auch einen Test nach dem Sitzungsaufbau. Die sendende Seite kann eine Echo-Request in MRU-Größe durch den Empfänger und die dazwischenliegenden Ethernet-Geräte schicken. Bleibt die Echo-Reply für den größeren Test aus, während der Test mit 1.492 Byte eine Antwort erhält, darf der Sender auf dieser Sitzung keine größeren Pakete mehr verschicken.

Dieser Rückfall zählt. Wird das Tag nicht ausgetauscht oder fehlt einer Seite eine größere Einstellung, gilt weiter die 1.492-Byte-Grenze aus RFC 2516. Scheitert der größere Test am Pfad, kann die Verbindung ebenfalls auf die kleinere Grenze zurückgehen. Die alte Vereinbarung bleibt der funktionierende Boden; kompatible Pfade können nach oben verhandeln.

Eine veröffentlichte Option machte Ethernet nicht größer

RFC 4638 ist ein Informational RFC. Der angehängte IESG-Hinweis hält fest, dass zum Zeitpunkt der Veröffentlichung kein geltender IEEE-Standard Jumbo-Frames mit einer MTU über 1.500 Byte unterstützte, und warnt vor ungesicherter Interoperabilität und Zuverlässigkeit nicht standardisierter Erweiterungen. PPPoE-Endpunkte konnten einen größeren Wert anbieten; jeder Ethernet-Port musste ihn trotzdem tatsächlich annehmen.

Die Geschichte lautet deshalb nicht: „1.492 wurde automatisch zu 1.500.“ RFC 4638 ließ die alte Grenze dort bestehen, wo der Pfad sie brauchte, definierte den Fähigkeitstausch und gab Implementierungen einen Test für größere Pakete. Das Protokoll kann das Angebot formulieren. Die Geräte und der tatsächliche Pfad entscheiden, ob es gilt.

Die RFCs dokumentieren den Entwurf und das Ziel, Fragmentierung zu reduzieren, aber nicht, welche Zugangsnetze das Tag einsetzten. Für einen konkreten Einsatz bräuchte es eine datierte Konzentrator-Konfiguration oder einen aufgezeichneten PPPoE-Discovery-Austausch.

Quellen