Zusammenfassung

  • Die Standardregel war bereits in Fassung 27 beschrieben. Fassung 28 konkretisiert den Entzug spezifischer Regeln, die Beobachtbarkeit und das Risiko eines erneuten Eintritts.
  • Wird eine spezifische Zuordnung für neue Umsetzungen entfernt, kann eine konfigurierte Regel 0.0.0.0/0: Pref6(PE) übernehmen. Ohne sie sieht der Entwurf Verwerfen und eine ICMP- oder ICMPv6-Fehlermeldung vor.
  • Jenseits einer Verwaltungsgrenze braucht die Standardregel eine ausdrückliche bilaterale Vereinbarung; ihr Ausgang muss über eine vollständige IPv4-Weiterleitungssicht für den angezogenen Verkehr verfügen.

Ein begrenzter Verkehrsraum

Der v6ops-Entwurf betrachtet ein IPv6-only Underlay über mehrere autonome Systeme. IPv4-Restverkehr wird an den Rändern durch zustandslose Adresszuordnung umgesetzt und über den IPv6-Kern geleitet, ohne dass im Datenpfad ein pro Fluss zustandsführendes Gateway erforderlich wäre. Der Raum gehört einem Betreiber oder einer Gruppe kooperierender Betreiber. Er ist nicht das offene Internet. Vorbestehende bilaterale Absprachen, abgestimmte Mapping-Präfixe, gemeinsame ICMP-Filterung und vertrauenswürdige Eingangs-PEs gehören zu seinen Voraussetzungen. Der Entwurf stellt diese Voraussetzungen nicht selbst her.

Zieht ein Betreiber die spezifische Regel für einen IPv4-Block zurück, empfiehlt Fassung 28 ihre sofortige Entfernung für neue Umsetzungen. Bereits laufende Pakete können für eine einstellbare Frist im Sekundenbereich anders behandelt werden. Für das nächste neue Paket zählt hingegen die verbleibende Regelbasis. Eine konfigurierte Standardregel kann es zu einem anderen PE schicken; fehlt sie, soll das Paket verworfen und der entsprechende Fehler signalisiert werden. Aus dem Eintrag „Regel entfernt“ lässt sich also nicht ablesen, wohin nachfolgender Verkehr tatsächlich gelangte.

Die Regel 0.0.0.0/0: Pref6(PE) bietet einen Ausweg für Ziele ohne genauere Zuordnung. Sie kann Ausfälle vermeiden, aber auch einen ungünstigen Pfad wählen, Kapazität auf ein PE konzentrieren und ein attraktives Ziel für Umleitung schaffen. Das ist keine Erfindung der jüngsten Fassung. Schon Fassung 27 führte Standardausgang und Risiken auf. Neu deutlicher sind insbesondere die Anforderungen an Bestandsabgleich, Rücknahmeverhalten und die Weiterleitung hinter der Ausgangskante.

Ein Vertrag ist kein Routingprotokoll

Abschnitt 9.4 untersagt die Bekanntgabe einer Standardregel über eine administrative Grenze ohne ausdrückliche bilaterale Vereinbarung. Eine solche Vereinbarung kann nur für bestimmte Bereiche, Präfixe, Ausgangs-PEs und Änderungsverfahren gelten. Aus früherer Zusammenarbeit folgt keine pauschale Zustimmung zur Übernahme aller Ziele, die später ihre spezifische Regel verlieren. Dass ein Paket am PE des Partners eintrifft, belegt die technische Erreichbarkeit; es belegt weder dessen aktuelle Zustimmung noch ausreichende Kapazität.

Der Verteilungsmechanismus soll wesentliche Regelfelder unverändert lassen, Reichweite und Filterung ermöglichen, den Ursprung authentifizieren und unerlaubte Bindungen von IPv4-Blöcken an Mapping-Präfixe zurückweisen. Die konkreten Protokollerweiterungen bleiben allerdings außerhalb dieses Rahmens. Der Text definiert kein allgemeines Register der bilateralen Befugnisse. Darum kann ein empfangenes Regel-Update nicht als alleiniger Nachweis für eine Vereinbarung dienen. Beide Betreiber müssen die Reichweite ihrer jeweiligen Zustimmung kennen; keiner kann die fremde Verwaltung durch einen lokalen Tabelleneintrag verpflichten.

Nach der Übersetzung fehlt die Erinnerung

Am Standardausgang wird das Paket wieder zu IPv4. Es trägt dann keine Markierung, dass es dieses Underlay bereits durchlaufen hat. Zeigt die beste IPv4-Route des Ausgangs zu einem anderen beteiligten PE, kann das Paket erneut umgesetzt werden und in denselben Ablauf zurückkehren. Die Lebensdauer des Pakets begrenzt diese Schleife irgendwann, verhindert aber nicht die Fehlentscheidung und den vorherigen Verbrauch von Netzressourcen.

Deshalb verlangt Fassung 28 vom Standardausgang eine vollständige IPv4-Weiterleitungssicht für den Verkehr, den er anzieht, und eine Route, die nicht wieder in den Rahmen führt. Überwachung, Ratenbegrenzung und ACLs für die Auffangregel gehören ebenfalls zur Sicherheitsbetrachtung. Eine belastbare Freigabe würde vor der Änderung die tatsächlichen besten Routen für betroffene Ziele untersuchen und danach Zähler, Fehler und Ausgangspfad vergleichen. Weder der Entwurf noch die Datatracker-Seite dokumentieren damit einen konkreten Vorfall oder eine bereits bestandene Betreiberprüfung.

Nachweis an der Grenze beider Betreiber

Abschnitt 8 empfiehlt Regelversionen oder Zeitstempel, Konsistenzzusammenfassungen der MR-DB, Änderungsmitteilungen, Zähler pro Regel und Managementzugriff. Das sind Bausteine für Beobachtung, keine Behauptung über die Verbreitung dieser Instrumente. Daniel Kade schlägt als redaktionelle Folgerung einen engen gemeinsamen Änderungsnachweis vor: zurückgezogener Block und Regelversion, Zeitpunkt für neue Umsetzungen, Umgang mit Paketen im Flug, verbleibende Regelstände beider Seiten, vereinbarte Reichweite, gewählter Standardausgang, Test der IPv4-Sicht und des Nicht-Wiedereintritts, Zähler, Fehler, Verantwortliche und Rückfallbedingung.

Der Entwurf schreibt ein solches Dokument nicht als IETF-Artefakt vor.

Der Nachweis würde drei Sachverhalte auseinanderhalten: Eine alte Regel endet. Eine Standardregel oder Verwerfungsentscheidung schließt die Lücke. Ein anderer Verwaltungsbereich übernimmt nur den Verkehr, dem er ausdrücklich zugestimmt hat und den er tatsächlich weiterleiten kann. Eine erfolgreiche Zustellung beweist nicht rückwirkend die Zustimmung. Umgekehrt zeigt ein unveränderter Zähler möglicherweise nur, dass noch kein einschlägiger Verkehr ankam. Erst die Verbindung aus Regelstand, Abkommensgrenze und realem Weiterleitungspfad macht die Änderung prüfbar.

Im Datatracker blieb Fassung 28 zum Prüfzeitpunkt ein aktiver v6ops-Internet-Draft mit angestrebtem Informationsstatus; im IESG befand er sich beim AD-Follow-up, mit offenen DISCUSS-Positionen. Er ist kein verabschiedeter RFC und kein Nachweis für eine produktive Einführung. Der Text kann sich weiter ändern. Bereits heute ist aber die Trennlinie klar: Ein Standardausgang kann Verfügbarkeit sichern, ohne dadurch eine fremde Zuständigkeit zu erwerben.

Quellen