Zusammenfassung

  • RFC 9805 erlaubt der abschließend aufgeführten Gruppe bestehender Protokolle die weitere Nutzung von IPv6 Router Alert, untersagt sie aber jedem künftig neu standardisierten Protokoll.
  • IANA hat das Werteregister geschlossen. Diese Verwaltungshandlung verhindert neue Zuteilungen, filtert jedoch keinen Bestandsverkehr und weist keine konkrete Control-Plane-Sicherheit nach.

Technische Schulden lassen sich einfrieren, ohne dass sie getilgt sind. Genau diese nüchterne Operation nimmt RFC 9805 vor.

Das im Juni 2025 im IETF Standards Track veröffentlichte Dokument zieht eine Zeitgrenze. Protokolle, die IPv6 Router Alert bereits verwenden, dürfen dies auch in späteren Fassungen tun. Neu standardisierte Protokolle dürfen die Option künftig nicht übernehmen. Anhang A enthält die vollständige Menge der Altanwendungen.

Auf Registrierungsebene ist der Beschluss sichtbar. IANAs IPv6-Parameterregister bezeichnet Optionstyp 0x05 als „für neue Protokolle deprecated“. Das eigene Register der Router-Alert-Werte ist geschlossen; der frühere Experimentierbereich wurde reserviert.

Ein geschlossenes Register ändert weder Firmware noch Konfiguration. Die Optionsnummer bleibt vorhanden. Pakete der zugelassenen Altprotokolle bleiben zulässig. Ob ein Router sie genauer untersucht, begrenzt, ignoriert oder verwirft, entscheiden weiterhin Implementierung und Betreiber.

Die ursprüngliche Idee war eine Beschleunigung. RFC 2711 beschrieb 1999 Kontrolldatagramme, die an ein Endziel adressiert sind, aber auch Router auf dem Weg interessieren. Jedes Paket bis in höhere Schichten zu zerlegen wäre teuer. Router Alert markierte deshalb im IPv6 Hop-by-Hop Header: Dieses Datagramm näher ansehen. Unmarkierter Normalverkehr sollte ohne zusätzliche Prüfung weiterlaufen.

Damit durfte ein Absender knappe Aufmerksamkeit bei Geräten anfordern, die gar nicht das Ziel waren. Das Kennzeichen authentifiziert diesen Anspruch nicht. Schon RFC 2711 warnte vor Leistungseinbußen durch unnötige Verwendung und vor Überlastung durch gefälschte markierte Pakete. Transitrouter durften den Verkehr begrenzen oder anders einschränken.

RFC 6398 benannte später das Selektionsproblem. Es gibt keinen bequemen universellen Mechanismus, um erwünschtes von unerwünschtem Router Alert zuverlässig zu trennen. Anders als bei einer Sitzung mit einem vorher bekannten Control Peer können Quelle und Ziel eines markierten Pakets beliebig sein. Die Aufforderung kann bis zu Core-Routern reichen.

Sie trifft zudem auf eine ungleiche Architektur. RFC 6192 beschreibt eine hochratige, oft ASIC-basierte Forwarding Plane und eine vielseitigere Control Plane auf Universalprozessoren. Letztere ist anfälliger für Überlastung durch Paketraten und programmiert zugleich den Zustand der Forwarding Plane.

Unerwünschter Verkehr sollte möglichst nahe an der Weiterleitungshardware klassifiziert und begrenzt werden. Doch RFC 9805 weist darauf hin, dass ACLs bei Feldern an festen Positionen effizienter sind. Router Alert in einem Hop-by-Hop Header zu suchen kostet mehr. Der Betreiber kann komplexe Filter einsetzen, die Option ignorieren lassen oder Hop-by-Hop-Pakete am Rand hart begrenzen beziehungsweise verwerfen. Eine offene Regel riskiert Ressourcen, eine pauschale Sperre eine legitime Funktion.

RFC 9805 löst die Klassifikation nicht mathematisch. Der Standard verhindert, dass die Zahl der legitimen Ausnahmegründe weiter wächst. Ein künftiger Protokollentwurf darf seinen lokalen Komfort nicht mehr durch eine neue Prüfpflicht aller Router auf dem Weg erkaufen.

Die Bestandsabhängigkeiten sind begrenzt, aber nicht leer. RFC 9805 nennt nur MLDv2 und MRD als breit ausgerollt. Die anderen gelisteten Anwendungen sind begrenzt, experimentell oder ohne bekannte IPv6-Implementierung; Router Alert für MPLS Ping wurde bereits verworfen.

Neue Fassungen von MLDv2 und MRD ohne Router Alert bleiben ausdrücklich künftiger Arbeit vorbehalten. Die Vorschrift enthält also keinen fertigen Migrationspfad. Zwischen „keine neue Abhängigkeit“ und „alte Abhängigkeit entfernt“ liegen Protokolldesign, Code, Rollout, Koexistenz und Funktionsnachweis.

RFC 9673 ordnet den Zusammenhang ein. Bei Hop-by-Hop-Optionen soll Verarbeitung im Allgemeinen nicht standardmäßig Pakete an die Control Plane geben. Router Alert behält eine Ausnahme, weil die genauere Prüfung sein Zweck ist. RFC 9805 schließt den Nachwuchs dieser Ausnahme, nicht ihren Bestand.

Für die Prüfung müssen getrennte Belege erhalten bleiben:

  1. RFC 9805 belegt das Verbot in künftigen Standards.
  2. IANA belegt das Ende neuer Zuteilungen.
  3. Die Altspezifikation belegt, dass ein bestimmter Flow zur Ausnahme gehört.
  4. Softwarestand und Konfiguration belegen die beabsichtigte lokale Behandlung.
  5. Paketmitschnitt und Zähler belegen Ankunft und Klassifikation.
  6. Queue-, Drop- und CPU-Werte belegen die Wirkung auf die Control Plane.
  7. Ein laufender Ersatz und das beobachtete Ende des Altverkehrs belegen die Tilgung.

Kein früher Beleg ersetzt den späteren. Ein erfolgreicher Drop ohne Prüfung der Multicast-Funktion ist ebenso unvollständig wie eine Registeränderung ohne Messung am Gerät.

Das Modell der minimalen Anfangsspezifikation, lokalisierten Zukunftsentscheidung und freiwilligen Einführung passt zu diesem Vorgehen. Die gemeinsame Regel bleibt schmal: Ausnahmemenge fixieren, Zuwachs verhindern. Netze und Protokollgemeinschaften behalten die spätere Wahl über Schutz und Ersatz.

Der Vorrang laufenden Codes setzt den Erfolgsmaßstab. Ein Registerhinweis ist kein Paketfilter. Fortschritt zeigt sich in engeren Ausnahmen, weniger markiertem Verkehr, stabiler Control Plane unter Last und intakter legitimer Funktion.

Die Realitätsebenen verhindern die Übertreibung: Auf Zuteilungsebene ist das Register wirklich geschlossen. Auf Standardisierungsebene ist die Neunutzung wirklich verboten. Der Zustand eines Produktionsnetzes ist eine andere Ebene mit eigenen Belegen. Gerade diese Begrenzung macht RFC 9805 belastbar.

Quellen