Summary

  • The IESG approved revision 16 of the stateful NAT64 specification as an Internet Standard, but the approved text keeps endpoint mapping and inbound filtering deliberately separate.
  • An operator should record mapping behavior, filtering policy and observed results as different facts; proof of a stable external tuple is not proof of a security boundary.

The change review looks reassuring. An engineer opens flows from one IPv6 address and port to several IPv4 destinations. Every flow receives the same external IPv4 address and port while the binding remains alive. The implementation has demonstrated endpoint-independent mapping, the behavior the approved stateful NAT64 specification says a translator must offer.

Then the review takes one step too many. The result is copied into the security column as evidence that unsolicited IPv4 traffic cannot return through the translator. No packet from an uncontacted source was tested. No filtering configuration was read. Nobody recorded whether the translator used endpoint-independent filtering, address-dependent filtering or no filtering for that traffic. A valid mapping test has been promoted into an invalid access-control conclusion.

That distinction matters more now because the specification is moving from familiar practice to the standards ledger. On 4 September 2026, the IESG approved revision 16 of Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers as an Internet Standard and asked the RFC Editor to place it under STD 103. The notice says the document obsoletes RFC 6146 and describes stateful NAT64 as widely implemented and deployed. It also says no major controversy was identified.

Approval is not the same as final publication. At this article's cutoff, the Datatracker record placed revision 16 in the RFC Editor queue and showed publication blocked for author input. The document history records how the draft reached that state. There was no replacement RFC number to print as a completed fact.

Nor should the event be sold as a sudden change to packet behavior. The approval notice characterizes the handling of errata 4756 and 8416 as editorial or clarifying. Appendix A of revision 16 says neither erratum has protocol implications. The former RFC 6146 remains the historical baseline until its successor is published. The useful governance question is therefore not “what new firewall did the IETF create?” It is “what did an operator actually configure, and what evidence supports that answer?”

A mapping answers a representation question

Stateful NAT64 connects IPv6-only clients to IPv4 servers by maintaining translation state. For TCP and UDP, a transport address combines an IP address and a port. The translator associates an internal IPv6 transport address with an external IPv4 transport address so return packets can be translated back to the initiator.

Endpoint-independent mapping is a rule about reuse. If the same IPv6 source address and port sends to different IPv4 destinations during a binding window, the translator reuses the same external IPv4 address and port. RFC 4787 made the same separation for UDP NAT behavior: mapping choices do not determine a NAT's security properties; filtering does. RFC 5382 carries the principle into TCP and says an external peer can use a learned mapping only subject to the NAT's security policy.

That reuse supports application transparency and traversal. It tells an application whether the public tuple learned in one conversation can remain useful in another. It does not name the IPv4 sources authorized to send back, set a default-deny rule or prove that any installed filter matches its intended configuration.

The approved NAT64 text says this directly: a translator must offer endpoint-independent mapping, but the security properties are determined by filtering behavior and filtering configuration, not by address-mapping behavior. A compliance worksheet that merges those rows discards an explicit distinction in the specification.

Filtering decides what may cross existing state

Suppose the IPv6 host has created a mapping. Without filtering, the draft explains, a packet from any IPv4 node addressed to the mapped external transport address can traverse the NAT64 function and be forwarded internally. The mapping is necessary state, but it is not a source authorization.

With filtering enabled, the result changes without altering the mapping mode. A dynamic address-dependent filter can allow return traffic only from IPv4 addresses that the IPv6 host previously contacted. An explicit deny or a default-deny policy can discard other packets. Endpoint-independent mapping can therefore coexist with a narrower effective reachability rule.

There is a genuine choice here, not a universal ranking. For UDP, RFC 4787 recommends endpoint-independent filtering when application transparency matters most and address-dependent filtering when greater stringency matters most. It allows the behavior to be administrator-configurable. For TCP, RFC 5382 makes a similar trade-off and notes that TCP filtering may differ from UDP filtering. “The box is compliant” cannot identify which option a particular protocol and interface are using.

ICMP requires additional care. RFC 5508 uses an ICMP Query identifier where TCP and UDP use ports. Revision 16 resolves erratum 4756 by clarifying that ICMP does not have an address-dependent filtering rule analogous to the TCP/UDP processing in question. A test suite that copies one UDP label across TCP and ICMP may produce tidy output while describing no real configuration.

Static bindings expose the cost of vague evidence

The distinction becomes sharper around static mappings. The security section warns that filtering based only on a five-tuple may be guessable in some static-mapping cases. A translator may track TCP sequence numbers to verify sequencing of SYNs and FINs, but that is an optional additional defense. The presence of a static mapping, or even a correct translation result, says nothing by itself about whether that defense exists.

Stateful translation also owns finite resources. IPv4 transport addresses, binding and session tables, fragment memory and link capacity can be consumed. The specification discusses limiting fragment storage and deciding which interface faces the Internet when applying lifetime defenses. Those decisions depend on direction and policy. A screenshot that says only “EIM passed” cannot show which side was treated as external, which packet created state, how long it survived or what an unapproved source could do with it.

Operational guidance does not erase the gap. RFC 7269 discusses deployment experience, high availability and security for NAT64, while RFC 8683 gathers further deployment guidance. Both broaden the operating context. Neither turns tuple reuse into a firewall attestation.

Keep two decisions in one verifiable receipt

Operators need not invent a new protocol to preserve the distinction. They need a better record. A mapping-and-filtering decision receipt should identify the translator and software version; interface direction; protocol; mapping mode; filtering mode; default action; whether a binding was static, dynamic or created through PCP; binding and session timers; policy version and approver; resource caps; and exception expiry.

The receipt should then join intent to observation. One test proves that the same internal tuple receives the expected external tuple across multiple destinations. Separate positive and negative tests show which IPv4 sources can use that mapping. Installed-rule output, counters and alarms establish what the platform actually accepted. The change event explains why the evidence is still current.

This record does not certify the whole device. It makes a smaller statement that can survive review: on this version, interface and protocol, the translator reused state in this way and enforced these inbound decisions, with these exceptions. A software upgrade, policy change, failover, timer change or new static binding expires the relevant part of the receipt.

The Policy Mirror asks where a rule acquires force. In this case, mapping acquires force in tuple allocation; filtering acquires force in the inbound decision path. Running-Code Primacy requires evidence that each one operated, rather than a label that collapses them. Reality, Not Advocacy sets the final limit: the approved standard establishes choices and behavior, not proof that any named deployment made the right choice.

Sources