Zusammenfassung

  • IPv4-as-a-Service beseitigt die IPv4-Abhängigkeit nicht, sondern verlagert sie in DNS64, Präfix-Erkennung, CLAT, PLAT-Zustand und geteilte Ports.
  • Natives IPv6 kann gesund bleiben, während nur IPv4-Namen, Literale oder bereits bestehende übersetzte Sitzungen ausfallen.
  • Ein Betriebsnachweis muss Resolver-Antwort, Pref64, CLAT-Pfad, PLAT-Zustand und Failover, zeitliche Zuordnung und Grenzen für eingehendes IPv4 verbinden.

Ein Kunde ändert den DNS-Resolver seines Heimrouters. IPv6-native Dienste funktionieren weiter. Ein Ziel mit ausschließlich A-Record erhält keine synthetische AAAA-Adresse mehr und verschwindet. Auf einem anderen Gerät bleibt dasselbe Ziel erreichbar, weil dessen CLAT IPv4-Pakete annimmt und das Übersetzungspräfix auf anderem Weg lernt. Beide Anschlüsse melden „online“.

Dieser selektive Fehler zeigt die Betriebslogik von IPv4-as-a-Service, kurz IPv4aaS. Ein Netzbetreiber kann natives IPv4 aus Zugang oder Kern entfernen und die restliche IPv4-Welt per Übersetzung erreichbar halten. Kompatibilität ist dann keine einem Kunden durchgängig zugeteilte Adresse, sondern das Ergebnis mehrerer Systeme.

Eine synthetische Adresse verspricht einen Pfad

RFC 6147 definiert DNS64. Gibt es auf eine AAAA-Abfrage nur einen A-Record, kann DNS64 die IPv4-Adresse in ein IPv6-Übersetzungspräfix Pref64::/n einbetten. Der Client sendet anschließend IPv6 an diese Darstellung.

Das Präfix muss zum NAT64 führen, das dieselbe Abbildung versteht. Resolver und Übersetzer stimmen sich nicht bei jeder Anfrage neu ab. Eine erfolgreiche DNS-Antwort beweist die Synthese, nicht Kapazität, Präfix-Konsistenz oder Sitzungsfortbestand am PLAT.

DNSSEC schärft die Grenze, weil DNS64 eine Antwort verändert. Validierung und Synthese lassen sich bewusst anordnen. Der Nachweis muss Resolver, A/AAAA-Sätze, DNSSEC-Ergebnis und verwendetes Pref64 enthalten.

CLAT rettet Literale, aber kein vollständiges IPv4

RFC 6877 beschreibt 464XLAT. Ein zustandsloser CLAT im Endgerät oder Kundenrouter übersetzt IPv4 nach IPv6. Der zustandsbehaftete PLAT des Providers übersetzt zurück. Namensbasierte Anwendungen können DNS64 und eine einzige zustandsbehaftete Übersetzung nutzen; IPv4-Literale und alte APIs benötigen den CLAT als erste Stufe.

Darum wirkt ein fremder Resolver nicht überall gleich. RFC 8683 zeigt: Bei NAT64 ohne CLAT kann ein externer Resolver ohne DNS64 IPv4-only-Ziele unzugänglich machen. 464XLAT kann ohne DNS64 weiterarbeiten, wenn der CLAT das richtige Pref64 lernt. Synthetisiert der Resolver ein anderes Präfix, zeigt die Adresse womöglich nicht auf den vorgesehenen PLAT.

464XLAT bildet auch nicht alle Eigenschaften nativen IPv4 nach. RFC 6877 umfasst das Client-Server-Modell zu global adressierten IPv4-Servern, nicht automatisch beliebigen IPv4-Eingang oder Peer-to-Peer-Verkehr. Diese Grenze gehört in Produkt und Support.

Pref64 hat Geltungsbereich und Lebensdauer

RFC 8781 definiert eine PREF64-Option in IPv6-Router-Advertisements. Sie enthält Präfixlänge und Lebensdauer; null bedeutet, dass das Präfix nicht weiter genutzt werden soll. Hosts sollen es der empfangenden Schnittstelle und gegebenenfalls der Provisioning Domain zuordnen. Router sollen widersprüchliche Angaben auf demselben Link erkennen und protokollieren.

Der Betriebsbeleg braucht daher Erkennungsverfahren, Wert, Restlaufzeit, Schnittstelle oder PvD und Konsistenz der Ankündigungen. Ein altes Präfix kann einen ausgemusterten Übersetzer überleben; eine kurze Laufzeit kann vor der nächsten gültigen Anzeige enden.

Geräte-Failover ist noch keine Zustandsübernahme

RFC 6146 definiert zustandsbehaftetes NAT64. Der PLAT hält Bindings und Sitzungen, damit Rückpakete den IPv6-Client erreichen. Ressourcen für Fragmente müssen begrenzt werden. Die RFC garantiert aber keine gemeinsame Sitzungstabelle zwischen zwei Übersetzern.

Nach einer Umschaltung können neue Verbindungen gelingen, während laufende Downloads, Zahlungen oder Tunnel abbrechen. Ein Monitor, der erst danach TCP öffnet, meldet Erholung. Der Test muss dieselbe Sitzung über das Ereignis führen und aktiven PLAT, Zustandsreserve, Ereigniskennung und erwartetes Verhalten vorhandener Abbildungen erfassen.

RFC 9099 nennt Zustandserschöpfung, die Wechselwirkung von DNS64 und DNSSEC sowie Probleme für die meisten IPsec-Szenarien ohne UDP-Kapselung. 464XLAT ohne DNS64 vermeidet die Synthese, nicht die übrigen Grenzen.

Adresseffizienz verlagert die Abrechnung

RFC 9313 vergleicht fünf IPv4aaS-Verfahren. Bei 464XLAT hält das Provider-NAT64 Zustand pro Datenstrom und vergibt öffentliche Ports dynamisch. Das nutzt IPv4 effizient, konzentriert aber Kapazität, Wiederherstellung und Protokollierung.

Teilen mehrere Kunden eine öffentliche Adresse, braucht die Zuordnung von Adresse und Port einen Zeitpunkt. Jede Sitzung zu protokollieren ist genau und teuer. Portblöcke für längere Zeit reduzieren Logs und verschlechtern die Portausnutzung. Auch das Recht spielt mit; die RFC legt keine weltweite Frist fest.

Provider-Zustand stellt zudem nicht automatisch einen öffentlichen Eingangsport bereit. Für Server können PCP oder explizite Abbildungen nötig sein. Das ist eine Architekturgrenze, kein rätselhafter Defekt.

Die Quellen liefern weder eine weltweite Verbreitung für 2026 noch universelle Leistung oder typische Ausfallraten. Sie liefern eine prüfbare Kontrollkette.

Quellen

  1. RFC 6146 — Stateful NAT64
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — NAT64/464XLAT-Betrieb
  5. RFC 8781 — PREF64 in Router Advertisements
  6. RFC 9099 — Betriebssicherheit in IPv6-Netzen
  7. RFC 9313 — IPv4aaS-Technologien