Zusammenfassung

  • Der aktuelle V6OPS-Entwurf definiert IPv6-Only anhand der tatsächlichen nativen Nutzung in einem benannten Bereich, nicht anhand installierter Protokollunterstützung und nicht als einheitlichen Zustand eines ganzen Netzes.
  • IPv4 kann als IPv4aaS, über NAT64, DNS64, CLAT oder SIIT-DC sowie in Upstream, Steuerung, Management und Altgeräten weiter erforderlich sein, ohne einer eng gefassten Aussage zu widersprechen.
  • Ein belastbarer Übergangsnachweis muss Bezeichnung, Objekt, Beobachtung, Restabhängigkeiten, Ausnahmen, Verantwortliche und Ablösebedingung in einem Geltungsbereichsregister zusammenhalten.

Eine abgeschlossene Migration, die keine ist

„Unser Netz ist jetzt IPv6-only“ klingt nach einem eindeutigen Endpunkt. Betriebsnetze ändern sich jedoch nicht als ein einziger Gegenstand. Ein Anbieter kann natives IPv4 aus dem Teilnehmerzugang entfernen, während das Heimnetz Dual Stack bleibt. Rechenknoten in einem Rechenzentrum können nur IPv6-Adressen tragen, während ein Grenzrelay IPv4-Kunden bedient. Ein Mobilgerät kann einen reinen IPv6-Datenkontext verwenden und seinen Anwendungen dank CLAT und NAT64 weiterhin IPv4-Kompatibilität geben.

Der V6OPS-Arbeitsgruppenentwurf IPv6-Only and IPv6-Mostly Terminology Definitions soll verhindern, dass diese Zustände in einem einzigen Etikett verschwinden. Revision 02 erschien am 11. September 2026; die I-D-Ankündigung nennt sie ein Arbeitsdokument von V6OPS. Im Datatracker befindet sie sich derzeit im Working Group Last Call. Das ist weder eine IESG-Genehmigung noch ein endgültiger RFC. Dokumenthistorie und Vergleich von 01 zu 02 belegen ihren weiterhin veränderbaren Stand.

Die entscheidende Regel im Text der Revision 02 lautet: den Bereich nennen. Der Begriff beschreibt die tatsächlich verwendete native Funktion, nicht sämtliche im Gerät vorhandenen Fähigkeiten. Ein Knoten kann IPv4 und IPv6 beherrschen, aber auf einer bestimmten Schnittstelle nur IPv6 nativ weiterleiten. IPv4 kann über denselben Link gekapselt oder übersetzt transportiert werden. Belegt ist damit „hier ist nur IPv6 nativ“, nicht „die Organisation ist von IPv4 unabhängig“.

Dieser Unterschied begrenzt Zuständigkeit. Das Zugangsteam kann für Linkkonfiguration und Messung einstehen. Es spricht damit nicht automatisch für jede Anwendung, jeden externen Dienst, jedes Kundengerät, jedes Lieferantenwerkzeug und jeden Wiederherstellungspfad. Fällt das Substantiv – Link, VLAN, Datenebene – in der Berichtskette weg, wächst die Aussage über die Belege ihres ursprünglichen Verantwortlichen hinaus.

Nicht nativ heißt nicht verschwunden

IPv6-Only bedeutet im Entwurf, dass im angegebenen Bereich nur IPv6 nativ ist. IPv4 wird dort nicht konfiguriert oder verwaltet, kann aber über IPv6 transportiert werden. IPv6-Only-Strict bezeichnet die stärkere Lage: IPv4 wird dort auch nicht übersetzt, gekapselt oder anderweitig über IPv6 getragen.

Damit werden zwei Entscheidungen getrennt. Natives IPv4 aus einer Ebene zu entfernen, kann Adressen sparen und Komplexität senken. Die Kompatibilitätsfunktion aufzugeben setzt zusätzlich voraus, dass Anwendungen, Partner, Managementwerkzeuge und externe Ziele sie nicht mehr benötigen. Der erste Schritt ist ein echter Fortschritt; er ist kein Beleg für den zweiten.

Die Übergangsmechanismen zeigen, wohin die Funktion wandert. RFC 6877 definiert 464XLAT, das Übersetzungen kombiniert, damit IPv4-Anwendungen oder -Netze über IPv6-Zugang funktionieren. RFC 6146 spezifiziert zustandsbehaftetes NAT64 zwischen IPv6-Clients und IPv4-Servern, RFC 6147 DNS64. RFC 8585 beschreibt Anforderungen an Teilnehmerrouter für IPv4-as-a-Service.

Solche Komponenten sind kein automatisches Eingeständnis gescheiterter Migration. Sie verlagern Kompatibilität und verändern deren Kontrollfläche. Übersetzerkapazität, DNS-Synthese, Protokollierung, Anwendungsverhalten, Support und Lieferantenverantwortung werden wichtiger. Weniger vergebene IPv4-Adressen können mit einer größeren Abhängigkeit von einer zentralen Übersetzungsplattform einhergehen.

Im Rechenzentrum beschreibt RFC 7755 SIIT-DC: interne IPv6-Knoten können IPv4-Clients über Grenzrelays bedienen. Das interne LAN lässt sich präzise als IPv6-only bezeichnen. Daraus folgt nicht, dass IPv4-Nachfrage, Abbildungen, Relaykapazität oder Betriebsverantwortung beendet wären. Die Abhängigkeit liegt jetzt am Rand.

Der Geltungsbereich ist Teil der Aussage

Der Entwurf unterscheidet Zugangslink, Segment, Host, Dienst, API, Datenebene, Steuerung und Management. Ein Unternehmen kann Dual-Stack-, IPv6-only- und IPv6-mostly-VLANs gleichzeitig betreiben. Im Mobilfunk kann der Transport zum Endgerät nur IPv6 nutzen, während Anwendungen und Tethering Dual Stack sehen. Eine Cloud kann einige reine IPv6-Subnetze neben anderen mit privatem IPv4 betreiben.

„Nur IPv6 in der Datenebene“ beantwortet nichts über Steuerung und Wiederherstellung. „IPv6-only-Server“ erklärt nicht, wie IPv4-Kunden ankommen. „IPv6-only-Zugang“ beschreibt nicht das Teilnehmer-LAN. „IPv6-only-Cloud“ kann unbrauchbar weit sein, wenn ihre Schnittstellen verschiedene Zustände besitzen.

Der Geltungsbereich ist deshalb keine optionale Fußnote. Er gehört logisch zum Fakt. Entfernt man ihn, entsteht eine neue, meist stärkere Behauptung. Bleibt der Bereich im technischen Inventar erhalten, verschwindet aber in der Vorstandsvorlage, wurde nicht nur gekürzt; die Schlussfolgerung wurde ohne neue Beobachtung erweitert.

Präzision schützt auch Vergleiche. Anbieter A betreibt einen nativen IPv6-Teilnehmerzugang mit zentralem NAT64. Organisation B betreibt ein striktes Laborsegment ohne irgendeinen IPv4-Transport. Beide können eine qualifizierte IPv6-only-Aussage treffen, verfolgen aber andere Ziele und tragen andere Restrisiken. Ein einzelner Reifegrad würde beides verfälschen.

Die V6OPS-Charta betont Betriebserfahrung in konkreten Umgebungen wie Providern, Unternehmen und Rechenzentren. Gemeinsame Begriffe sollen Erfahrungen austauschbar machen, nicht einen universellen Migrationspfad erzwingen. Das entspricht Heng Lus Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: Eine kleine gemeinsame Schicht lässt die folgenreichen nächsten Entscheidungen bei den lokalen Betreibern.

„Überwiegend“ ist keine Verkehrsquote

IPv6-Mostly steht im Entwurf nicht für einen Prozentanteil. Gemeint ist ein Dual-Stack-Bereich mit NAT64 und DHCPv4-Option 108, optional DNS64, in dem IPv4-only-, Dual-Stack- und IPv6-only-Clients zusammenleben. IPv4 wird nach Bedarf vergeben.

RFC 8925 definiert die Aushandlung. Ein geeigneter Client fordert Option 108 an. Erhält er einen gültigen Wert, kann er die angebotene IPv4-Adresse ablehnen und DHCPv4 für die angegebene Zeit oder bis zum nächsten Netzanschlussereignis aussetzen. Die Fähigkeit gilt je Schnittstelle und verleiht einem Gerät keinen dauerhaften Status.

Eine sinkende Zahl von IPv4-Leases misst Zuteilung, nicht sämtliche Abhängigkeiten. Native Pakete messen den Link, nicht den Übersetzer. Ein NAT64-Inventar misst Infrastruktur, nicht Anwendungswirkung. Erreichbarkeitstests messen ein Ergebnis, nicht den Notfallzugang. Erst eine benannte Fragestellung verhindert, dass eine Kennzahl als universeller Stilllegungsbeleg missverstanden wird.

Ein Register statt eines Zertifikats

Nachvollziehbarkeit verlangt keine Veröffentlichung von Topologie, Kunden, Adressen oder Sicherheitsdetails. Das Etikett muss nur an seinem Objekt haften bleiben. Ein Geltungsbereichs- und Abhängigkeitsregister kann festhalten:

  1. den genauen Dienst, die Schnittstellenklasse, den Link, das VLAN, die Anwendungskohorte, die Ebene oder das Gesamtgebiet;
  2. Begriff und Version des verwendeten Vokabulars;
  3. native Weiterleitung und Beobachtungsmethode;
  4. Gültigkeitszeitraum oder Konfigurationsstand;
  5. verbleibenden IPv4-Transport, Übersetzung, Kapselung, Adressierung und externe Erreichbarkeit;
  6. notwendige NAT64-, DNS64-, CLAT-, SIIT-DC-, Proxy- oder CDN-Funktionen;
  7. Ausnahmen für Altgeräte, Anwendungen, Steuerung, Lieferanten und Notfälle;
  8. den Betreiber jeder Abhängigkeit und die Instanz, die das Etikett ändern darf;
  9. erwartete Fehler und Rückfallweg;
  10. den Nachweis für den nächsten Zustand sowie Entscheidung und Datum der Ablösung.

Das Register ist bewusst kein Zertifikat. Ein Zertifikat legt einen abgeschlossenen allgemeinen Zustand nahe. Das Register bewahrt begrenzte, datierte und korrigierbare Entscheidungen. Betrieb kann Vereinfachung erkennen, Sicherheit eine Konzentration, Finanzen eine Adressersparnis und Produktverantwortung den Schutz älterer Kunden. Die Governance muss diese Wertungen nicht zentral vereinheitlichen; sie muss den gemeinsamen Sachverhalt schützen.

Heng Lu fordert in The Policy Mirror, dass Politik reale Systeme und Anreize widerspiegelt. Die sichtbare Anerkennung einer „beendeten“ Migration und die unsichtbare Last der Kompatibilität fallen oft auseinander. Je wertvoller das Etikett wird, desto wichtiger ist sein enger Wahrheitsbereich.

Grenzen der Belege

Die Quellen weisen keinem konkreten Betreiber eine irreführende Verwendung nach. Sie messen weder Verbreitung noch Leistung oder Kosten. Der Working Group Last Call kann den Entwurf noch verändern; auch ein späterer informativer RFC würde keine Implementierung zertifizieren.

Ebenso fordert diese Analyse keine sofortige Abschaltung von Übersetzern. Gerade sie können lokale IPv6-Einführung ohne Ausschluss ermöglichen. Verantwortlich ist die Frage, wo die Brücke liegt, wem sie gehört, welches Ergebnis sie trägt und welcher Ausfall eintritt, wenn sie verschwindet.

Ein IPv6-only-Zugangslink kann ein bedeutender Erfolg sein. Er bleibt dennoch ein Link. Beide Wahrheiten im selben Datensatz zu bewahren, macht aus technischem Fortschritt belastbare Governance.

Quellen