Zusammenfassung

  • Die IESG genehmigte Version 16 der Stateful-NAT64-Spezifikation als Internet Standard; der genehmigte Text trennt Zuordnungsverhalten und eingehende Filterung ausdrücklich.
  • Ein belastbarer Betriebsnachweis hält externes Tupel, Filtermodus, Protokoll, Richtung sowie positive und negative Testergebnisse in getrennten Feldern fest.

Im Abnahmeprotokoll sieht alles ordentlich aus. Dieselbe IPv6-Adresse mit demselben Port verbindet sich nacheinander zu mehreren IPv4-Zielen. Solange die Bindung lebt, vergibt der Übersetzer stets dieselbe externe IPv4-Adresse samt Port. Der Test weist Endpoint-Independent Mapping nach.

Daneben steht jedoch ein grünes Feld „unerwünschter Rückverkehr blockiert“. Es wurde nicht geprüft. Kein Paket kam von einer IPv4-Adresse, die der interne Host zuvor nicht kontaktiert hatte. Die Standardaktion und die tatsächlich installierte Filterkonfiguration fehlen. Aus einer Aussage über Wiederverwendung wurde eine Aussage über Berechtigung.

Am 4. September 2026 genehmigte die IESG Version 16 von Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers als Internet Standard. Der RFC Editor soll das Dokument unter STD 103 einordnen. Die Mitteilung bezeichnet Stateful NAT64 als breit implementiert und eingesetzt, kündigt die Ablösung von RFC 6146 an und berichtet von keiner größeren Kontroverse.

Genehmigt heißt noch nicht als neuer RFC veröffentlicht. Zum Recherchezeitpunkt führte der Datatracker-Eintrag Version 16 in der Warteschlange des RFC Editor; die Veröffentlichung war wegen benötigter Autoreneingaben blockiert. Die Dokumenthistorie belegt den Prozessstand, aber keine noch nicht vergebene Nachfolgernummer.

Ebenso wenig ist plötzlich neues Protokollverhalten entstanden. Die IESG-Mitteilung beschreibt die Behandlung der Errata 4756 und 8416 als redaktionelle oder klarstellende Korrektur ohne Auswirkung auf Verhalten und Interoperabilität. Anhang A von Version 16 zieht dieselbe Grenze. RFC 6146 bleibt bis zur Veröffentlichung der historische Ausgangspunkt. Neu ist nicht eine Firewall, sondern der Anlass, zwei schon lange getrennte Entscheidungen nicht länger zu vermischen.

Die Zuordnung bestimmt die äußere Darstellung

Stateful NAT64 hält Bindings und Sitzungszustand. Bei TCP und UDP besteht eine Transportadresse aus IP-Adresse und Port. Der Übersetzer verbindet die interne IPv6-Transportadresse mit einer externen IPv4-Transportadresse; nach Ablauf eines Timers kann eine dynamische Bindung freigegeben werden.

Endpoint-Independent Mapping bedeutet, dass dieselbe interne Adresse und derselbe Port bei verschiedenen externen Zielen innerhalb des Bindungsfensters dasselbe externe Tupel erhalten. RFC 4787 verlangt dieses Verhalten für UDP-NAT, um Anwendungen und Traversal-Verfahren vorhersehbar zu unterstützen. Zugleich hält der Text fest, dass Mapping-Varianten die Sicherheitseigenschaften nicht bestimmen. Entscheidend ist, welche Pakete die Filterung einlässt.

RFC 5382 übernimmt die Trennung für TCP. Eine Anwendung kann ein äußeres Tupel lernen und weitergeben; ein externer Peer erreicht es dennoch nur unter der Sicherheitsrichtlinie des NAT. Der Mapping-Test beantwortet damit eine Darstellungsfrage. Er enthält keine Liste zugelassener Quellen.

Die genehmigte Fassung verlangt, dass ein Stateful-NAT64-Übersetzer Endpoint-Independent Mapping anbietet, und erlaubt zusätzliche Address-Dependent-Mapping-Unterstützung. Eine Capability-Angabe zeigt, was möglich ist. Sie zeigt weder die operative Auswahl noch den Filter, der auf einer konkreten Schnittstelle läuft.

Die Filterung bestimmt die eingehende Nutzung

Version 16 stellt zwei Fälle gegenüber. Besteht ein endpoint-unabhängiges Mapping ohne Filterung, können Pakete beliebiger IPv4-Knoten an das externe Transporttupel durch die NAT64-Funktion zur internen IPv6-Transportadresse gelangen. Die Reichweite entsteht durch vorhandenen Zustand plus fehlenden Filter, nicht allein durch das Mapping.

Bei unverändertem Mapping kann ein dynamischer adressabhängiger Filter Rückverkehr auf IPv4-Adressen beschränken, die der IPv6-Host zuvor kontaktiert hat. Eine ausdrückliche Sperre oder eine Default-Deny-Regel verwirft andere Quellen. Dasselbe öffentliche Tupel besitzt dann eine andere Eingangsfläche.

Die engere Variante ist nicht automatisch die richtige. RFC 4787 empfiehlt Endpoint-Independent Filtering, wenn Anwendungstransparenz Vorrang hat, und Address-Dependent Filtering, wenn strengere Begrenzung wichtiger ist. Administratoren dürfen die Wahl konfigurieren. RFC 5382 lässt außerdem unterschiedliche Filter für TCP und UDP zu. Eine globale Konformitätsaussage kann diese Entscheidung pro Protokoll nicht ersetzen.

ICMP verlangt eine eigene Betrachtung. RFC 5508 nutzt bei Abfragen einen Identifier anstelle eines TCP- oder UDP-Ports. Die mit Erratum 4756 verbundene Klarstellung besagt, dass ICMP an der betreffenden Stelle keine analoge Address-Dependent-Filtering-Regel besitzt. Daraus folgt nicht, dass ICMP ohne jede Richtlinie auskommt. Es folgt, dass ein UDP-Prüfschema nicht unverändert übernommen werden darf.

Statische Bindungen machen Kontext unverzichtbar

Die Sicherheitsbetrachtung warnt, dass eine reine Fünf-Tupel-Filterung bei manchen statischen Zuordnungen erratbar sein kann. Ein Übersetzer darf TCP-Sequenznummern verfolgen, um insbesondere SYN und FIN genauer zu prüfen. Diese Maßnahme ist optional. Eine funktionierende Übersetzung beweist weder ihre Aktivierung noch ihren Fortbestand nach Upgrade oder Umschaltung.

Auch die Ressourcen sind begrenzt: IPv4-Adressen und Ports, Binding- und Sitzungstabellen, Fragment-Speicher und Linkkapazität. Der Entwurf nennt Begrenzungen für gespeicherte Fragmente und verlangt bei bestimmten Lebensdauerschutzmaßnahmen eine korrekte Festlegung der Internetseite. Ohne Richtung, Protokoll, Timer und Herkunft der Bindung — statisch, dynamisch oder per PCP — verliert ein Testergebnis seine spätere Aussagekraft.

RFC 7269 dokumentiert NAT64-Betriebserfahrung einschließlich Hochverfügbarkeit und Sicherheit. RFC 8683 ergänzt Leitlinien für NAT64/464XLAT. Beide stellen den Übersetzer in einen Betriebszusammenhang. Keine der beiden Quellen erklärt Tupel-Wiederverwendung zum Firewall-Nachweis.

Ein Beleg mit zwei getrennten Entscheidungen

Daniel Kade schlägt einen Zuordnungs- und Filterentscheidungsbeleg vor. Er nennt Übersetzer, Softwareversion, Schnittstelle, Richtung und Protokoll. Danach folgen getrennt Mapping-Modus, Filtermodus, Standardaktion, statische, dynamische oder PCP-Herkunft der Bindung, Binding- und Sitzungstimer, Richtlinienversion, Genehmiger, Ressourcengrenzen und Ablauf einer Ausnahme.

Auch die Ausführung erhält zwei Nachweisreihen. Verbindungen zu mehreren Zielen belegen die erwartete Wiederverwendung des externen Tupels. Pakete aus erlaubten und nicht erlaubten Quellen prüfen die Eingangsentscheidung. Installierte Regeln, Zähler, Alarme und ein Test nach Failover verbinden Vorgabe und Ergebnis.

Der Beleg zertifiziert weder das ganze Produkt noch eine dauerhafte Sicherheitslage. Er sagt eng begrenzt: Auf dieser Version, Schnittstelle und diesem Protokoll wurde so zugeordnet und so gefiltert. Softwarewechsel, neue Richtlinie, Rollenänderung, Timer-Anpassung, statische Bindung oder aktive Clusterinstanz lassen den betroffenen Teil veralten.

The Policy Mirror fragt nach dem Ort, an dem eine Regel wirksam wird: Zuordnung bei der Tupelvergabe, Filterung im Eingangspfad. Running-Code Primacy verlangt Beobachtungen an beiden Orten. Reality, Not Advocacy begrenzt die Behauptung: Der Standard beschreibt Optionen; er beweist keinen Fehler in einem nicht untersuchten Betreibernetz.

Quellen