Summary

  • On 2 November, the IESG opened Last Call on draft-ietf-v6ops-nat64-wkp-1918-10, with comments due 23 November. It proposes allowing private and shared IPv4 addresses under 64:ff9b::/96.
  • Revision 10 newly recommends that managed translators expose their default treatment of non-global addresses. It also preserves the existing drop default for compliant installed PLATs.

The rule used to make the decision for you

RFC 6052 gives NAT64's well-known prefix, 64:ff9b::/96, a hard boundary. It must not represent non-global IPv4 addresses, and translators must drop packets that combine the prefix with such a destination. For an IPv6-only client seeking an internal IPv4 service, that rule closes a familiar route.

The 2 November Last Call puts a different arrangement before the community. Revision 10 would permit the prefix to represent RFC 1918 private addresses and RFC 6598 shared space. An unmanaged client-side translator, or CLAT, would translate by default. A provider-side translator, or PLAT, would translate unless configured otherwise and must provide a way to disable that behavior. The universal drop becomes an operator-controlled route and filter decision.

Why not hand clients two prefixes, one for public targets and one for private ones? The draft says widely deployed NAT64 prefix discovery gives a client no mapping from a discovered prefix to a particular IPv4 subset. With two prefixes, local synthesis can produce two addresses even for a public target. It also reports inconsistent CLAT behavior today: some implementations obey the existing drop rule, while others translate. The document offers no measured vendor-by-vendor population.

Revision 10 asks the machine to show its hand

The proposed permission and PLAT configuration switch were present in revision 09. The notable addition in revision 10 is section 4.3. It recommends a way for managed translators to expose their default treatment of non-global destinations. Operators should verify that actual behavior matches their intended policy, through explicit configuration or monitoring. Routing policy at the translator or neighboring routers remains part of making a path work.

Section 5 adds a migration constraint with teeth. Existing managed PLATs that comply with RFC 6052 and drop by default should keep that default when upgraded. New specifications can point toward translation while installed machines retain a blocking factory setting. Both can be legitimate; neither can be inferred from a box marked “NAT64.”

The useful receipt is concrete: software version, factory default, explicit override, route to the private destination, ACL or NAT filter, and a packet test that shows where traffic goes. The public record contains no configuration or test result for a named network. Those facts would decide whether its private services become reachable.

Sources