Zusammenfassung

  • Seit RFC 1883 legen die beiden höchsten Bits eines IPv6-TLV-Optionstyps fest, wie ein verarbeitender Knoten auf einen unbekannten Typ reagiert: überspringen, das Paket verwerfen oder es verwerfen und mit einem genau zeigenden ICMPv6-Fehler melden.
  • Ein drittes Bit kennzeichnet Daten, die sich unterwegs ändern können. Diese Bits begrenzen Unwissen, garantieren aber weder Hop-by-Hop-Verarbeitung noch Durchlass durch Middleboxes oder Vertrauenswürdigkeit des Inhalts.

Alte Software konnte die Grenze verstehen

Ein Zielknoten erkennt einen Destination-Options-Header und liest darin Type, Length und Value. Für einen TLV besitzt er keinen Parser. Seine Bedeutung bleibt unbekannt, doch die Länge verrät, wo der nächste Eintrag beginnt.

RFC 1883, die erste veröffentlichte IPv6-Spezifikation vom Dezember 1995, legte zusätzlich die Folge in das Typoktett. Zwei obere Bits beschrieben die Aktion bei Nicht-Erkennen. Das dritte zeigte, ob die Daten bis zum endgültigen Ziel veränderlich waren. Die unteren fünf beteiligten sich weiter an der Typkennung.

Damit durfte der Autor einer neuen Option keine Semantik in alte Software hineinbehaupten. Er konnte nur eine begrenzte, allgemein lesbare Ausweichhandlung angeben.

Zwei Bits hatten vier Folgen

00 heißt: Option anhand ihrer Länge überspringen und mit dem Header fortfahren. 01 verwirft das Paket. 10 verwirft und sendet ICMPv6 Parameter Problem, Code 2, an die Quelle; der Pointer zeigt auf den unbekannten Option Type. 11 verhält sich ebenso, unterdrückt die Meldung aber bei einer Multicast-Zieladresse.

Das ist keine Gefahrenskala. Eine überspringbare Option kann mit lokaler Sicherheitspolitik kollidieren. Eine verwerfende Option kann legitim sein, aber Verständnis verlangen, damit ihre Wirkung erhalten bleibt. Die Bits bewerten die Folge fehlenden Wissens, nicht die Absicht des Absenders.

Der ICMP-Pointer macht aus allgemeinem Verlust einen Hinweis auf ein bestimmtes Oktett. Die Nachricht kann dennoch begrenzt, gefiltert oder verloren werden. Ihr Eintreffen belegt ein lokales Ereignis; ihr Ausbleiben unterscheidet nicht zwischen Überspringen, stillem Verwerfen und einem früheren Pfadfehler.

Multicast erhielt eine sichtbare Meldegrenze

10 und 11 unterscheiden sich nur bei Multicast. Der erste Typ fordert die Meldung auch dann, der zweite nicht. So ist am Typ erkennbar, ob ein unbekannter Multicast-TLV Rückverkehr auslösen soll.

Rate Limits und Ressourcenschutz bleiben beim Betreiber. Das Muster macht Multicast weder verdächtig noch garantiert es Zustellung. Es ordnet lediglich die vorgesehene Fehlermeldung diesem Typ zu.

Veränderliche Daten wurden nicht fälschlich eingefroren

Das nächste Bit beantwortet eine andere Frage. Null bedeutet, dass sich Option Data unterwegs nicht ändert; eins erlaubt die Möglichkeit einer Änderung. Ist ein Authentication Header vorhanden, wird das Datenfeld einer veränderlichen Option bei Berechnung und Prüfung des Authentifizierungswerts als Folge von Nulloktetten behandelt.

Ein Feld, das legitim unterwegs aktualisiert wird, kann nicht zugleich als unveränderlich authentifiziert werden. IPv6 nahm diese Zone daher aus dem stabilen Versprechen. Das ist keine allgemeine Schreibberechtigung: Wer welchen Wert ändern darf, legt weiterhin die einzelne Optionsspezifikation fest.

Alle acht Bits bildeten die Identität

RFC 2460 stellte 1998 klar, dass die drei oberen Bits kein loses Policy-Präfix für eine Fünf-Bit-Nummer waren. Der vollständige acht Bit breite Wert identifiziert die Option. Gleiche untere Bits bei anderem Präfix ergeben einen anderen Typ.

Hop-by-Hop Options und Destination Options teilen den Nummernraum, obwohl eine Spezifikation den zulässigen Header einschränken kann. Außerdem gilt Paketfolge: Optionen werden in ihrer Reihenfolge verarbeitet. Ein Empfänger darf nicht eine bekannte spätere Option vorziehen und den unbekannten Vorgänger erst danach beurteilen.

Damit bleibt Kausalität erhalten. Eine frühe Verwerfungsentscheidung kann nicht rückwirkend durch einen vertrauten späteren Wert aufgehoben werden.

Unbekannte Option war nicht unbekannter Extension Header

Die Aktionsbits liegen in einem TLV innerhalb eines bereits bekannten Options-Headers. Ein unbekannter Next-Header-Wert erhält dadurch weder automatisch eine Länge noch dieselben Handlungen.

RFC 6564 bevorzugte deshalb neue Destination Options, wenn sie ausreichen, und verlangte eine Begründung für neue Extension Headers. Unvermeidbare künftige Header bekamen ein einheitliches längentragendes Format; ältere Formate wurden nicht nachträglich vereinheitlicht.

RFC 7045 trennte die Rollen. Ein Zielhost verwirft ein Paket mit unbekanntem Extension Header. Ein weiterleitender Knoten soll nicht allein wegen seiner Unkenntnis eines neuen Headers verwerfen. Wenn er die Kette inspiziert, muss er seine Kenntnis registrierter Typen pflegen. Das ist ein anderer Vertrag als die Aktionsbits eines unbekannten TLV in einem bekannten Container.

Middleboxes zeigten die technische Grenze

Firewall, Load Balancer und schneller Router suchen häufig Transportfelder. Eine lange oder neue Kette kann Recirculation, Slow Path oder Kontrollprozessorarbeit auslösen und die gewünschte Prüfung verhindern.

RFC 8200 behielt die vier Handlungen und das Veränderungsbit, knüpfte Hop-by-Hop-Verarbeitung im Transit aber an ausdrückliche Konfiguration. RFC 9098 beschreibt die unangenehme Auswahl, wenn ein Gerät die benötigten Felder nicht findet: ungeprüft weiterleiten, verwerfen oder außerhalb des normalen schnellen Pfads arbeiten.

Selbstbeschreibung erzeugt keine Parser- oder Siliziumkapazität. Sie macht nur die Unwissenheit eines Prozessors vorhersehbar, der den TLV tatsächlich erreicht.

Was die Bits nie erlaubten

00 ist kein Sicherheitsurteil und kein Durchleitungsrecht. 11 beweist keinen Angriff. Das Veränderungsbit vergibt kein beliebiges Schreibrecht. Registrierung beweist keine Pfadunterstützung, ICMP keine Identität oder Absicht.

Der Mechanismus funktioniert wegen seiner Enge: gemeinsame Folge, lokale Ausführung, Nachweis durch laufende Pakete.

Quellen und Evidenzgrenzen

Die Semantik stammt aus RFC 1883, wurde in RFC 2460 präzisiert und steht heute in RFC 8200. Format- und Weiterleitungsgrenzen liefern RFC 6564 und 7045, Betriebsfolgen RFC 9098. Sie messen keine heutige Unterstützung oder Verlustrate aller Netze.