Zusammenfassung

  • Bei einem IPv6-Jumbogramm verweist Payload Length null auf eine Jumbo-Payload-Option im unmittelbar folgenden Hop-by-Hop-Options-Header.
  • Die Option trägt die tatsächliche Länge in 32 Bit und ist nur oberhalb von 65.535 Oktetten zulässig; die Null allein beweist weder Leere noch korrekten Aufbau.
  • Ein regelkonformer Header-Verbund garantiert noch keine tragfähige Route, und ein ausbleibender ICMPv6-Fehler ist kein Zustellnachweis.

Eine Null gibt die Zuständigkeit weiter

Der feste IPv6-Basis-Header ist 40 Oktette lang. Sein 16-Bit-Feld Payload Length zählt im Normalfall alles danach, einschließlich der Erweiterungs-Header. Bei 65.535 ist Schluss. RFC 2675 vergrößert nicht den Header jedes gewöhnlichen Pakets, sondern reserviert null als Sentinel und verlagert die maßgebliche Zahl in eine selten benötigte Option.

Die Übergabe ist an Bedingungen gebunden. Sieht ein Knoten die Basislänge null, Hop-by-Hop Options als nächsten Header und tatsächlich weitere Oktette, muss er diesen Erweiterungs-Header bearbeiten. Der unsignierte 32-Bit-Wert Jumbo Payload Length umfasst alle Erweiterungs-Header und Nutzdaten hinter dem Basis-Header, nicht aber dessen 40 Oktette. Er muss größer als 65.535 sein.

Wer aus einem Trace nur „Payload Length = 0“ übernimmt, archiviert den Wegweiser und verwirft sein Ziel. Für einen belastbaren Befund braucht es Next Header, Vorhandensein und Position der Option, ihren Wert und den tatsächlich aufgezeichneten Umfang. Bei gekürzten Mitschnitten kann ein fehlender Paketteil eine Grenze der Sonde statt einen Fehler auf der Leitung zeigen.

Gültig wird erst die Kombination

RFC 2675 grenzt die Widersprüche genau ab. Basislänge null mit einem Hop-by-Hop-Header ohne Jumbo-Option ist fehlerhaft. Eine Jumbo-Option bei einer Basislänge ungleich null ebenfalls. Ein Jumbo-Wert unter 65.536 ist unzulässig. Jumbo-Option und Fragment-Header dürfen nicht im selben Paket stehen.

Der Nachweis besteht folglich aus einer Beziehung. Die Null überträgt die Längenhoheit, die Option antwortet mit dem Wert, und die Header-Reihenfolge bestätigt den ordnungsgemäßen Übergang. Ein Parser, der jede Null als „leer“ ausgibt, unterschlägt gültige Jumbogramme. Ein Parser, der jede Null großzügig als Jumbogramm akzeptiert, lässt genau jene Widersprüche passieren, die verworfen werden sollen.

Fehler können ICMPv6 Parameter Problem auslösen. RFC 4443 ordnet ein fehlerhaftes Header-Feld Type 4 Code 0 zu; das Paket wird verworfen und unter den geltenden Regeln sollte eine Antwort gesendet werden. Das Ausbleiben dieser Antwort bestätigt jedoch nichts. Filter, Ratenbegrenzung, asymmetrisches Routing oder ein fehlender Rückweg können die Meldung unsichtbar machen.

UDP verwendet eine zweite, eigene Null

Auch UDP besitzt ein 16-Bit-Längenfeld. In einem IPv6-Jumbogramm darf es null sein, wenn die tatsächliche UDP-Länge 65.535 überschreitet. Der Empfänger leitet sie aus Jumbo Payload Length ab und zieht zuvor liegende Erweiterungs-Header ab. In die Prüfsumme geht die so ermittelte reale Länge ein, nicht null.

Beide Nullen sind abgestimmt, aber nicht austauschbar. Die IPv6-Null verweist auf die Jumbo-Option; die UDP-Null aktiviert die Transportregel. Aus der einen darf die andere nicht ergänzt werden. TCP hat kein entsprechendes Paketlängenfeld. Für Jumbogramme gilt eine MSS von 65.535 als unbegrenzt, während Path MTU Discovery weiterhin die praktisch mögliche Segmentgröße bestimmt.

Regelkonform heißt noch nicht routenfähig

Jumbogramme sind nur auf Links mit einer MTU oberhalb von 65.575 Oktetten sinnvoll: 40 Oktette Basis-Header plus mehr als 65.535 Oktette Payload. Implementierungen ohne Verbindung zu solchen Links müssen sie nicht unterstützen. RFC 8201 definiert die Path MTU zusätzlich als kleinste Link-MTU der Route. Ein zu großes Paket kann unterwegs verworfen werden und Packet Too Big auslösen.

Syntax reserviert also keinen Platz im Tunnel und keine Kapazität im Zwischenknoten. Sender, Empfänger und erster Link können das Format beherrschen, während ein späteres Gerät es nicht trägt. Umgekehrt verwirft eine pauschale Sperre allein wegen der Jumbo-Option auch standardkonforme Pakete. RFC 9288 hebt diesen Unterschied bei Empfehlungen zur Filterung von IPv6-Erweiterungs-Headern hervor.

Eine Untersuchung sollte drei Aussagen getrennt halten: Was erklärte das Paket, war die Erklärung intern konsistent, und was geschah auf der Route? Vollständige Felder beantworten die erste Frage, Validierung die zweite. Für die dritte braucht es Empfangsnachweise, Zähler, Packet Too Big, kontrollierte Sonden oder korrespondierende Mitschnitte. Die Null kann keine dieser Ebenen ersetzen.

Auch die Zuschreibung bleibt mehrteilig. RFC 2675 nennt David Borman, Steve Deering und Robert M. Hinden; RFC 8200 nennt Steve Deering und Bob Hinden. Das IETF-Profil beschreibt Hinden als einen der Miterfinder von IPv6. Daraus folgt weder eine alleinige Urheberschaft des Mechanismus noch Kontrolle über seine Umsetzung in fremden Netzen.

Quellen