Summary

  • On 4 September 2026, the IESG approved the Stateful NAT64 revision as an Internet Standard. The decision recognizes a mature, widely deployed mechanism; it does not certify a product, size an address pool, validate a filter or prove a production failover.
  • A real deployment gives many IPv6 clients temporary claims on scarce IPv4 transport addresses. Binding, session, timer, filtering, logging and replication records must remain distinguishable if an operator wants to prove capacity, continuity or attribution.

Stateful NAT64 resolves a practical asymmetry. The client has only IPv6. The service still speaks IPv4. A translator rewrites the packet and lends the client an IPv4-side transport address drawn from a much smaller pool. With DNS64, neither endpoint needs to know that translation occurred.

That smooth appearance can hide the governing mechanism. A public IPv4 address is not simply “the translator's address.” At a particular instant, one of its UDP or TCP ports may be bound to one IPv6 transport address and associated with one or more sessions. A moment later, the claim may be refreshed, expired, reassigned or reconstructed on another translator. The service can look stateless to both endpoints because the operator holds the state for them.

The IESG announcement of 4 September approved draft-ietf-v6ops-rfc6146-bis-16 as an Internet Standard. It says the eventual document will obsolete RFC 6146 and asks the RFC Editor to place it under STD 103. The Datatracker record shows “Approved-announcement sent” while IANA work remains in progress. The reviewed record does not yet assign the final RFC number. That distinction matters: the technical decision is made, while publication mechanics are still completing.

The approval is a maturity judgment. It is not a deployment receipt.

The revision preserves the protocol and exposes its operating context

The approved version 16 text is unusually clear about what changed. Appendix A says that two errata were resolved without changing protocol behaviour, references were updated, port-parity wording was clarified and an operational-considerations section was added. The original RFC 6146 remains the behavioural foundation; the surrounding IPv4/IPv6 translation architecture comes from RFC 6144.

The announcement also points to widespread implementation. Version 16 names commercial products, open-source implementations, cloud services and operating platforms. The same section states its own limit: the entries are drawn from public information, are not IETF endorsements and were not formally confirmed by interoperability testing for this publication. RFC 7942, which guides implementation-status sections, treats such reports as aids to standards work rather than certification marks.

This is the first reality boundary. Internet Standard status says the IETF considers the specification mature under its process. A vendor name says public material associates a product with Stateful NAT64. Neither tells a buyer which version is running, which optional behaviour is selected, how much state it can preserve, or what happens when one node fails.

Lu Heng's Running-Code Primacy supplies the right order. A standard earns operational meaning through observable implementation. The label should direct attention to the machine and its evidence, not substitute for them.

The scarce object is an IPv4 transport address

Stateful NAT64 shares one or more public IPv4 addresses among many IPv6-only clients. To do so, it normally translates both address and port. The allocable object is therefore an IPv4 transport address: an address plus a UDP or TCP port, or an address plus an ICMP identifier.

This is a temporary claim on a finite namespace. The translator tries to preserve familiar port ranges and parity where resources permit. If no appropriate transport address is available, it may return an ICMPv6 error; local policy can suppress even that signal. A client timeout, therefore, does not identify the failed layer. It might reflect pool exhaustion, a filtering choice, silent error policy, routing, translation, an IPv4 server or the application.

Port sharing improves IPv4 efficiency. The operational section notes the bargain: assigning ports dynamically across the pool can serve more subscribers with fewer public addresses, but it produces larger logs than fixed port-range allocation. RFC 6269 explains the wider consequences of IP address sharing, including attribution and application limits. RFC 6888 gives common CGN logging requirements that also matter here.

A useful ledger therefore begins with the claim, not the address. It records the public address, port or identifier, transport protocol, internal IPv6 transport address, allocation and expiry times, translator generation, and the rule that admitted the allocation. Without the port and clock, the public address is a crowd, not an identity.

A binding is not a session

The specification separates two kinds of state. Three Binding Information Bases—UDP, TCP and ICMP query—associate an IPv6 transport address with an IPv4 transport address. Three session tables describe the actual communicating pairs and their protocol state.

That separation is not database ornament. One endpoint-independent binding can support sessions to several IPv4 destinations. A manually configured binding may have no session row and can remain until explicitly deleted. A session can expire while a binding remains. In TCP, transitory, established and closing states carry different timers and transitions. ICMP uses identifiers rather than ports. A single “active translations” counter collapses these different claims.

The control record needs stable identifiers for both layers and a link between them. It should show when a BIB entry was created, what pool generation supplied it, which sessions used it, which packet refreshed a timer, and which event retired it. If a mapping is restored after failover with a new BIB identifier, the ledger should preserve the succession instead of pretending there was one uninterrupted row.

This is the practical use of Heng's reality-layer discipline. “NAT64 enabled” is configuration reality. A BIB row is translator state. A session row is a protocol claim. A translated packet is an observed event. A completed user transaction is an application outcome. All can be true or false independently.

Mapping does not decide who may return

Stateful NAT64 requires endpoint-independent mapping. Once an IPv6 transport address receives an external IPv4 transport address, the same external mapping can be reused across destinations within the binding lifetime. That property helps applications and peer-to-peer behaviour.

It does not determine exposure. The specification says security properties are set by filtering behaviour and configuration. With no filtering, traffic from any IPv4 source that reaches a live mapping may traverse it. With address-dependent filtering, return traffic can be limited to IPv4 addresses previously contacted by the IPv6 host. RFC 4787 provides the underlying UDP terminology; RFC 5382 supplies corresponding TCP behavioural and timer requirements.

The operational error is to report the mapping mode as though it also proves the filter. A conformance sheet can truthfully say “endpoint-independent mapping” while two installations expose different return paths. The evidence package must name mapping mode, filtering mode, default policy, exceptions, static bindings, the configuration version and a packet test from an allowed and disallowed source.

The same caution applies to direction. The translator can be deployed with different notions of which side is external. The security section allows an operator to stop packets arriving from the configured Internet side from refreshing state, limiting an attacker's ability to keep a binding alive. If the side is misidentified, a reasonable timer rule acts in the wrong direction. The name of the interface is not proof; the route and observed refresh behaviour are.

Timers exercise authority over continuity and scarcity

Every dynamic claim lives on a clock. UDP and ICMP sessions have lifetimes. TCP entries move through a state machine with transitory, established and closing timeouts. Fragment queues have bounded storage and waiting periods. Expiry releases addresses, ports and memory for reuse.

The timer is not housekeeping. It decides when the system stops recognizing a client's claim. A value that is too short can break an idle but legitimate session. A value that is too long can strand scarce ports or let hostile traffic occupy memory. The operational section notes that QUIC depends on reasonable UDP session lifetimes and warns that QUIC Connection IDs must not be used as NAT state keys.

An aggregate occupancy graph cannot explain these decisions. Operators need distributions by protocol, state and configuration epoch: creation rate, refresh source, age, scheduled expiry, early deletion, allocation failure, silent error, fragment memory, SYN-held state and port-range pressure. An abrupt drop can mean recovered capacity or lost sessions. The ledger must say which.

The translator is a designed concentration point

The security section makes resource concentration explicit. Attackers on the IPv6 side can consume IPv4 transport addresses by varying source transport addresses. Fragments can consume bounded memory. IPv4 or IPv6 SYN traffic can create session or binding pressure. Periodic packets may try to keep state alive.

These are protocol-recognized risks, not evidence that a current attack exists. The sources establish no named outage or exhausted deployment. They do explain why capacity must be measured at several layers: free public addresses, available ports by range and protocol, BIB occupancy, session occupancy, memory reserved for fragments, CPU, links, allocation latency and error policy.

RFC 9693 provides a methodology for benchmarking stateful NAT gateways. A benchmark result is still bounded by device, software, configuration, traffic mix, packet size and test method. It cannot be inherited from another model or converted into a universal subscriber ratio.

The standard is deliberately thin about deployment choices. Heng's Minimum Initial Specification helps explain why that is sound: common rules should cover what interoperability requires, while local operators remain accountable for topology, capacity, policy and future change. The mistake is not that the RFC avoids a universal pool size. The mistake would be for a buyer to treat that silence as proof that local design no longer matters.

High availability means preserving claims, not keeping a box alive

A health check can prove that a standby translator responds. It cannot prove that the standby knows the bindings and sessions created by the active node. RFC 7269 and RFC 8683 collect deployment experience, including high-availability considerations. They do not turn redundancy into one universal mechanism.

The required receipt is a state-continuity test. Record the active generation, standby generation, replication watermark, missing BIBs, missing sessions, timer skew and pool ownership before cutover. Then observe which established UDP, TCP and ICMP exchanges survive, which are recreated, which fail, and whether the old node can return without issuing duplicate external claims.

Split-brain risk is particularly important. Two healthy translators that allocate from the same pool without reconciled ownership can produce conflicting claims. Conversely, a conservative standby may avoid conflict by dropping every unreplicated session. Availability and uniqueness pull in different directions. Leadership must decide the failure behaviour rather than letting an implementation default decide silently.

Logs are evidence only when the clocks and generations join

Shared addressing makes naive attribution dangerous. An IPv4 address may serve thousands of clients. An address-and-port pair is narrower, but it is still incomplete without protocol, time, timezone, clock uncertainty, translator instance, mapping generation and retention integrity. A user identifier adds another custody and legal boundary; it does not transform a translation log into proof of a human action.

RFC 8158 defines IPFIX information elements for NAT resource monitoring. Such telemetry can expose pool and port consumption, threshold events and allocation behaviour. It does not automatically reconcile the BIB row, session row, packet observation, identity system and application audit trail.

For investigation, preserve the chain in both directions. Starting with an external tuple and time, identify the owning pool generation, translator, BIB and session, then the internal IPv6 tuple and network subscriber context. Starting with a client, reproduce the external claim and its valid interval. Record clock synchronization and uncertainty at each system. If the two paths disagree, report uncertainty rather than forcing a name onto the event.

This is where the Internet Standard label reaches its boundary. The specification defines interoperable translation behaviour. It does not grant evidentiary authority to an operator's logs, settle privacy law, identify a subscriber, prove an application command, or assign liability.

What the approval does—and does not—settle

The IESG decision is consequential. It moves Stateful NAT64's core mechanism to the highest maturity level in the IETF standards track. It recognizes long operational experience and folds fifteen years of related work into a clearer specification. It gives implementers and operators a stronger common reference.

It does not make the system stateless. It does not remove the IPv4 dependency hidden behind an IPv6-only access path. It does not prove that a specific filter, timeout, pool, logger, standby or application is correct. It does not convert the implementation list into certification. It does not show that a named network has deployed version 16, passed a failover drill or retained lawful attribution data.

The mature response is not scepticism toward the standard. It is precision about what the standard can carry. Use it to define the minimum common mechanism. Then demand local receipts for every allocation, policy and outcome that only the operator can observe.

Sources