Zusammenfassung

  • Der IESG billigte am 4. September 2026 die Überarbeitung von Stateful NAT64 als Internet Standard. Die Entscheidung bestätigt Reife und breite Praxis, zertifiziert aber kein Produkt, keine Poolgröße, keine Filterregel und keine Hochverfügbarkeit.
  • Viele IPv6-Teilnehmer teilen zeitlich begrenzte IPv4-Transportadressen. BIB, Sitzung, Filter, Frist, Replikationsstand und Anwendungsergebnis müssen getrennte Belege bleiben.

Die IESG-Mitteilung genehmigt draft-ietf-v6ops-rfc6146-bis-16 als Internet Standard. Das spätere RFC soll RFC 6146 ablösen und unter STD 103 geführt werden. Im Datatracker ist die Genehmigungsmitteilung versandt; die IANA-Arbeit läuft. Eine endgültige RFC-Nummer war in den geprüften Unterlagen noch nicht vorhanden.

Der technische Beschluss ist gefallen, die Veröffentlichung aber noch nicht vollständig abgewickelt. Diese zeitliche Trennung schützt die Nachricht vor zwei Fehlern: Sie ist keine bloße Absicht, und sie ist noch kein nummeriertes Enddokument.

Standardsreife ersetzt keine Konformitätsprüfung

Die gebilligte Fassung 16 behebt zwei Errata ohne Protokolländerung, aktualisiert Verweise, präzisiert die Porterhaltung und ergänzt nichtnormative Betriebshinweise. Grundlage bleibt RFC 6146, eingebettet in den Übersetzungsrahmen aus RFC 6144.

Die Implementierungsliste nennt viele Hersteller, offene Projekte, Clouds und Betriebssysteme. Sie erklärt zugleich, dass ihre Angaben aus öffentlichen Quellen stammen, keine IETF-Empfehlung darstellen und für diese Veröffentlichung nicht formal interoperabilitätsgeprüft wurden. RFC 7942 versteht solche Listen als Hilfe bei der Standardisierung, nicht als Gütesiegel.

Aus einem Produktnamen folgen also weder laufende Fassung noch Filtermodus, Kapazität, Zustandssicherung oder Protokollqualität. Running-Code Primacy ordnet die Belege: Der Standard beschreibt den gemeinsamen Prüfgegenstand; laufender Code und beobachtete Ergebnisse beschreiben die Anlage.

Knapp ist die IPv4-Transportadresse

Stateful NAT64 verbindet reine IPv6-Clients über UDP, TCP oder ICMP mit IPv4-Servern. Wenige öffentliche IPv4-Adressen werden geteilt. Der Übersetzer vergibt deshalb eine Kombination aus Adresse und Port beziehungsweise Adresse und ICMP-Kennung.

Dieser Anspruch gilt nur für ein Zeitfenster. Danach kann dieselbe Kombination einem anderen Client gehören. Eine öffentliche Adresse ist daher keine Person und kein einzelner Datenstrom. Selbst Adresse und Port bleiben ohne Protokoll, Uhrzeit, Uhrunsicherheit und Übersetzergeneration mehrdeutig.

Der Übersetzer versucht Portbereich und Parität zu erhalten. Fehlt eine passende Transportadresse, kann er ICMPv6 senden; lokale Regeln dürfen die Meldung unterdrücken. Ein Timeout weist nicht eindeutig auf Erschöpfung hin. Filter, stille Fehler, Route, Übersetzung, IPv4-Ziel und Anwendung bleiben alternative Grenzen.

RFC 6269 beschreibt Probleme geteilter IP-Adressen. RFC 6888 enthält allgemeine Protokollierungsanforderungen für große Übersetzer. Fassung 16 benennt den Tausch ausdrücklich: Mehr dynamisch genutzte Ports pro Adresse sparen IPv4, vergrößern aber die Protokolldateien.

Ein belastbarer Datensatz enthält externe Adresse, Port oder Kennung, Protokoll, internes IPv6-Transportpaar, Beginn, Ende, Zeitgüte, Instanz, Poolgeneration und Zulassungsregel.

Bindung und Sitzung haben verschiedene Lebensläufe

Für UDP, TCP und ICMP-Abfragen gibt es getrennte Binding Information Bases. Eine BIB verbindet eine IPv6- mit einer IPv4-Transportadresse. Daneben stehen drei Sitzungstabellen mit den tatsächlich kommunizierenden Paaren und Zuständen.

Eine zielunabhängige Bindung kann mehrere Sitzungen tragen. Eine manuelle Bindung kann ohne Sitzung bestehen und nur ausdrücklich gelöscht werden. Eine Sitzung endet möglicherweise vor der Bindung. TCP unterscheidet Übergangs-, Aufbau- und Abbauphasen mit eigenen Fristen.

Ein gemeinsamer Zähler „NAT-Einträge“ verwischt diese Rechte. Das Register braucht getrennte Kennungen und ihre Verbindung: Erzeugung, Poolquelle, verwendende Sitzungen, letzter auffrischender Verkehr, Löschgrund und spätere Wiedervergabe. Nach einer Umschaltung ist eine rekonstruierte Zeile Nachfolgerin, nicht dieselbe Zeugin.

Die Wirklichkeitsebenen halten das sauber: Aktivierte Funktion, BIB, Sitzung, übersetztes Paket und abgeschlossene Anwendungshandlung sind unterschiedliche Tatsachen.

Mapping entscheidet nicht über den Rückweg

Stateful NAT64 verlangt endpoint-unabhängiges Mapping. Innerhalb der Bindungsfrist kann dieselbe externe Transportadresse gegenüber verschiedenen Zielen gelten. Wer von IPv4 zurückkehren darf, bestimmt jedoch die Filterung.

Ohne Filter kann eine beliebige IPv4-Quelle eine lebende Zuordnung erreichen. Bei adressabhängiger Filterung wird der Rückweg auf zuvor kontaktierte IPv4-Adressen begrenzt. RFC 4787 liefert die UDP-Begriffe; RFC 5382 behandelt TCP-Verhalten und Zeitgeber.

Ein Datenblatt mit „Endpoint-Independent Mapping“ beschreibt daher noch keine Zugriffspolitik. Erforderlich sind Mapping, Filter, Standardregel, Ausnahmen, statische BIBs, Konfigurationsfassung sowie Paketprüfungen aus erlaubten und unerlaubten Quellen.

Auch die Definition der Außenseite ist wirksam. Der Betreiber kann verhindern, dass Verkehr von der Internetseite Fristen verlängert. Ist die Seite falsch zugeordnet, wirkt die Schutzregel in die falsche Richtung. Nicht der Schnittstellenname, sondern Route und beobachtete Aktualisierung entscheiden.

Zeitgeber teilen Kontinuität und Ressourcen

UDP- und ICMP-Sitzungen verfallen. TCP hat Zustände mit unterschiedlichen Fristen. Fragmente belegen begrenzten Speicher für eine begrenzte Zeit. Ablauf gibt Ports und Speicher wieder frei.

Kurze Werte brechen legitime Ruhephasen; lange Werte halten knappe Ressourcen und erleichtern künstliche Verlängerung. Die Betriebshinweise verlangen vernünftige UDP-Fristen für QUIC und verbieten, QUIC Connection IDs als NAT-Zustandsschlüssel zu verwenden.

Messbar sein müssen Erzeugung, Auffrischungsrichtung, Alter, Sollablauf, Frühentfernung, Zuteilungsfehler, stille Meldung, Fragmentpuffer und TCP-Zustand je Konfigurationsepoche. Sinkende Belegung kann Freigabe oder Unterbrechung bedeuten.

Ein Konzentrationspunkt braucht mehrdimensionale Kapazität

Die Sicherheitsbetrachtung nennt endliche IPv4-Adressen und Ports, Speicher, Prozessor und Leitung. Unterschiedliche IPv6-Quellen können Bindungen verbrauchen, Fragmente und SYNs Speicher belegen und periodische Pakete Zustand erhalten.

Das ist kein Nachweis eines aktuellen Angriffs. Die Quellen belegen keinen Ausfall eines bestimmten Betreibers. Sie begründen getrennte Messungen für freien Pool, Portbereiche, BIBs, Sitzungen, Fragmentbereich, Zuteilungslatenz und Ablehnungen.

RFC 9693 bietet eine Benchmark-Methode für zustandsbehaftete NAT-Gateways. Jeder Wert gehört zu Gerät, Software, Konfiguration, Verkehrsmischung, Paketgröße und Testverfahren. Er ist keine übertragbare Teilnehmergarantie.

Die Lehre der minimalen Anfangsspezifikation erklärt die Zurückhaltung: Gemeinsame Regeln sichern Interoperabilität, lokale Betreiber entscheiden Kapazität und Topologie. Gerade deshalb müssen sie diese Entscheidungen nachweisen.

Hochverfügbarkeit muss Anspruchszustand übernehmen

RFC 7269 und RFC 8683 sammeln NAT64-Betriebserfahrung einschließlich Hochverfügbarkeit. Sie bestätigen nicht die Replikation eines konkreten Clusters.

Vor einer Umschaltung gehören Aktiv- und Ersatzgeneration, Replikationsmarke, Verzögerung, fehlende BIBs, fehlende Sitzungen, Zeitabweichung und Poolbesitz ins Protokoll. Danach werden bestehende UDP-, TCP- und ICMP-Kommunikationen auf Fortsetzung, Neuaufbau oder Verlust geprüft.

Bei Teilung können zwei gesunde Knoten denselben Pool beanspruchen. Doppelte Vergabe verletzt Eindeutigkeit. Das Verwerfen unbekannter Zustände schützt Eindeutigkeit und verletzt Kontinuität. Diese Priorität darf kein verborgener Produktstandard setzen.

Zuordnung braucht Uhren und Generationen

RFC 8158 definiert IPFIX-Elemente zur Überwachung von NAT-Ressourcen. Sie zeigen Verbrauch und Ereignisse, verbinden aber nicht automatisch BIB, Sitzung, Teilnehmer, Paket und Anwendungsjournal.

Eine Stichprobe muss in beide Richtungen auflösbar sein. Von externer Transportadresse und Zeitpunkt zu Pool, Instanz, Generation, BIB, Sitzung und IPv6-Kontext; vom Client zurück zum damals gültigen externen Anspruch. Zeitversatz und Unsicherheit begleiten jede Verknüpfung. Widerspruch bleibt Widerspruch.

Der Internet Standard normalisiert Übersetzungsverhalten. Er verleiht Betreiberlogs keine automatische Beweishoheit, entscheidet kein Datenschutzrecht, identifiziert keinen Menschen und bestätigt keine Anwendungshandlung.

Die IETF-Entscheidung ist gerade wegen dieser Grenze wertvoll. Sie liefert eine reife gemeinsame Basis. Pool, Filter, Fristen, Ersatzknoten und Protokolle bleiben lokale Machtmittel. Lokale Macht braucht ein zurechenbares Register.

Quellen