Zusammenfassung

  • RFC 9673 aktualisiert RFC 8200 und erlaubt selektive, konfigurierbare Hop-by-Hop-Verarbeitung innerhalb einer geschützten aggregierten Weiterleitungsrate.
  • Plattformen unterscheiden sich in Parserreichweite und Verarbeitungspfad; Paketankunft oder ein gemeinsames Fähigkeitslabel belegen nicht, dass eine konkrete Option ausgeführt wurde.
  • Ein belastbarer Nachweis verbindet Modell, Hardware und Build, Optionstabelle, Reihenfolge und Gesamtlänge, Route und Zeitpunkt, Knotentelemetrie, Weiterleitungseffekt und Dienstergebnis.

Die Policy war auf allen Routern gleich. Trotzdem erreichte ein Gerät das nachgelagerte Transportfeld nur bei der kurzen Variante der Extension-Header-Kette. Bei der längeren Variante leitete es weiter, ohne die erwartete Sonderverarbeitung zu liefern. Im zentralen Dashboard änderte sich nichts: „Hop-by-Hop enabled“ blieb grün.

RFC 9673 erklärt, warum ein solches Label keine vollständige Aussage sein kann. Das Dokument aktualisiert RFC 8200, damit Hop-by-Hop Options in modernen Routern und Hosts praktisch nutzbar werden. Es schreibt keine uniforme Arbeit für jeden Knoten vor. Es schützt Weiterleitung und erlaubt dem Betreiber, Option Types lokal auszuwählen.

Die gemeinsame Regel endet vor der Hardwarearchitektur

Frühe IPv6-Fassungen erwarteten die Prüfung durch alle Knoten. Bei hohen Raten kann Sonderverarbeitung in einen Slow Path oder zur Control Plane wandern, reguläre Pakete umordnen oder kritische Protokolle bedrängen. RFC 7045 beschrieb diese Realität. RFC 7872 maß Verluste bei verschiedenen Extension Headers; RFC 9098 und RFC 9288 ordnen Betriebsfolgen und Filterung ein. Historische Messwerte sind jedoch kein aktueller Befund für einen unbenannten Pfad.

RFC 9673 verlangt grundsätzlich, dass ein Router auch ohne Verarbeitung des Hop-by-Hop-Headers anhand der nachfolgenden Header normal weiterleitet und nicht allein wegen dessen Anwesenheit verwirft. Eine konfigurierte Ausnahme kann nachgelagerte, nicht kompatible Systeme schützen.

Damit sind Durchleitung und Optionsarbeit getrennt. Ein Paket kann ankommen, weil alle, einige oder keine Transitknoten die Option bearbeitet haben. Der Empfang ist ein Beleg über Paket und beobachteten Pfad, nicht über jeden Parser.

Full Forwarding Rate ist kein universeller Grenzwert

Der Begriff bezeichnet Verarbeitung ohne nachteilige Wirkung auf die aggregierte Weiterleitungsrate. RFC 9673 nennt bewusst keine für alle Plattformen gültige Anzahl oder Größe. Parserfenster, Pipeline, Mikrocode, Software, Optionsemantik, Reihenfolge, Paketrate und Verkehrsmix verändern die Kosten.

Ein Router sollte nicht für die erste Option konfiguriert werden, wenn deren Verarbeitung die Gesamtrate beeinträchtigt. Weitere Optionen sollten nur unter derselben Bedingung folgen. Als mögliche Umsetzung nennt der RFC eine konfigurierbare Lookup-Tabelle der Option Types, die bei voller Rate verarbeitet werden können.

Diese Tabelle braucht einen eindeutigen Gegenstand: Modell, Hardware-Revision, Build, Interface, Policy-Generation und Testbedingungen. Eine Controller-Aussage beweist weder identische Parser in gemischten Chassis noch die geladene Tabelle noch den tatsächlichen Pfad eines Flows.

Die Länge ist ebenfalls kein kosmetisches Feld. Je mehr Bytes vor dem Transport-Header liegen, desto wahrscheinlicher kann ein begrenztes Inspektionsfenster relevante Felder nicht erreichen. RFC 9673 und die Betriebsliteratur motivieren kurze, einfache Optionen gerade deshalb. Ein Fähigkeitslabel ohne getestete Headerform verschleiert die wichtigste Variable.

Reihenfolge ist Ressourcenpolitik

Die Quelle kann eine Option oder mehrere unter einer Größenbegrenzung senden. Bei mehreren motiviert RFC 9673 eine Reihenfolge abnehmender Bedeutung, weil Router möglicherweise nur die erste oder eine begrenzte Zahl verarbeiten.

Wer Diagnose vor Dienstfunktion stellt, kann die einzige verarbeitete Position vergeben. Die Einträge im IANA-Register für IPv6-Parameter bestätigen Typzuweisung und Spezifikation, nicht Implementierung, Aktivierung oder Priorität.

Für nicht verarbeitete Options lockert RFC 9673 in den bezeichneten Fällen auch die starren Verwerf- und ICMP-Folgen; die Entscheidung wird konfigurationsabhängig. Die Bitcodierung unbekannter Types ist ein eigenes Thema. Hier geht es darum, dass auch ein bekannter Type keine Rechenzeit erzwingen darf.

Kein ICMP ist kein positives Ergebnis

RFC 4443 definiert ICMPv6. Erreicht ein Parameter Problem die Quelle, kann es zeigen, dass mindestens ein Knoten die Option nicht erkannte. Bleibt es aus, sind Erkennung und Verarbeitung nicht bewiesen: Der Fehler kann unterdrückt, begrenzt, gefiltert oder verloren worden sein; der Router kann schlicht weitergeleitet haben.

Router Alert macht die Ressourcengefahr sichtbar. RFC 6398 behandelt die Slow-Path-Exposition. RFC 9673 lässt diese Control-Plane-Ausnahme nur mit Schutz wie ACL, Vertrauensgrenzen und Rate Limit bestehen. Eine Anweisung im Paket ist kein Anspruch auf unbegrenzte Routerressourcen.

Stärkere Evidenz kommt vom benannten Knoten: Type-spezifischer Counter oder Trace, Interface, Build, Policy und Zeit. Danach bleibt der Diensterfolg zu prüfen. Erkennen, ausführen und Nutzen erzeugen sind drei Übergänge.

Pfadtests veralten

RFC 9673 empfiehlt robuste schrittweise Nutzung: Pakete mit und ohne Option vergleichen, auf Bestätigung warten und bei fehlender Unterstützung zurückfallen. In einer Limited Domain nach RFC 8799 können Knoten gemeinsam kontrolliert werden. Im offenen Internet wechseln sie durch ECMP, Rekonvergenz und Wartung.

Ein verwertbares Protokoll bewahrt exakte Bytes, Reihenfolge, Länge, Flow-ID, sichtbare Route, Zeit, Bestätigung, ICMP, Knotentelemetrie und aggregierte Auswirkungen. Der gestrige Erfolg gehört dem gestrigen Pfad.

RFC 9673 schafft damit keine Beliebigkeit. Neue Optionen sollen einfach, kurz, bei voller Rate ausführbar, überspringbar und gegenüber Teilunterstützung robust sein. Der Standard schützt das Netz vor erzwungener Arbeit. Das Unternehmen muss verhindern, dass diese Schutzentscheidung als ausgeführte Funktion verkauft wird.

Quellen