Summary

  • IETF draft revision 10 proposes allowing the well-known NAT64 prefix 64:ff9b::/96 to represent private and shared IPv4 addresses. It is in IESG Last Call through 23 November 2026, not yet an RFC.
  • The proposed text makes unmanaged client translators translate such traffic by default. A managed provider translator must be able to turn the behavior off; the draft advises existing managed implementations to retain their current drop default on upgrade.
  • The operating bargain is plain: one prefix can serve public and internal IPv4 destinations, but access to an internal address must be decided by explicit routing and filtering policy rather than an old translation prohibition.

The most helpful firewall in some IPv6 networks has no firewall rule. It is a sentence in a 2010 addressing standard telling a translator to throw away packets aimed at private IPv4 destinations through a particular IPv6 prefix. Operators who never wrote an access rule may still have benefited from the drop. A new IETF draft proposes removing that sentence's veto. The network then has to say for itself which private service is reachable.

Section 3.1 of RFC 6052 forbids the well-known prefix, 64:ff9b::/96, from representing non-global IPv4 addresses. A translator receiving such a composed destination must drop the packet. The point was understandable: 10.0.0.1 has no globally unique owner. Two networks can each use it for unrelated machines. Letting a universal-looking IPv6 prefix carry that local number can send traffic toward an address whose meaning changes with the network boundary.

But a prohibition is also a blunt instrument. An IPv6-only employee may need an internal IPv4-only payroll system, a plant controller, or a service that has never had an IPv6 endpoint. Its address may be private under RFC 1918, or a provider's shared address may fall under RFC 6598. Dropping every such translated packet refuses both unwanted access and the access the operator meant to provide. The draft's argument is that the second decision belongs to the operator.

The one-prefix trap

The tempting workaround is to keep the well-known prefix for public IPv4, then reserve a network-specific or local-use prefix for private destinations. In a centrally managed DNS64 deployment, the DNS server can choose which IPv6 answer to synthesize. A client-side translator, or CLAT, may instead synthesize an IPv6 destination itself from a literal IPv4 address. It needs to know which prefix to use before any DNS64 policy can help.

The draft says common discovery mechanisms do not tell a client which IPv4 ranges belong to which NAT64 prefix. RFC 7050 discovery and RFC 8781 router advertisements reveal a prefix, not a destination-specific assignment table. Teach a client both prefixes and it may synthesize both for public addresses. Two plausible routes to the same destination are an invitation to inconsistent filtering and ugly incident calls. The alternative local-use prefix in RFC 8215 does not solve that selection problem when it is paired with the well-known one.

The proposal therefore changes the rule at its source. Where RFC 6052 says the well-known prefix MUST NOT carry a non-global IPv4 address and the translator MUST drop it, draft revision 10 says it MAY carry one. An unmanaged CLAT would MUST translate such packets by default. A managed provider translator, or PLAT, would MUST translate unless configured otherwise and MUST provide a disabling option. Those modal verbs are the architecture of a power transfer: a previous standards-level prohibition becomes a configurable operating decision.

This is still a proposal. The IETF Datatracker lists revision 10, dated 2 November, in IESG Last Call ending 23 November. The old RFC remains the current published rule. Treating the draft as already deployed policy would be the very kind of invisible handoff the draft tries to make explicit.

A default drop is a poor constitution

The draft's security section admits that managed operators may have been relying on RFC 6052's mandatory drop as an implicit barrier around private IPv4 infrastructure. It tells existing compliant PLAT implementations not to change that drop default merely because software is upgraded. A conscious administrator can enable translation after reviewing local policy; a routine version bump should not unexpectedly open the gate. The proposed disabling switch is a real requirement, not decorative reassurance.

Then the work begins. The translator must know where to route the private address. A firewall or ACL must decide which IPv6 source may reach which translated destination and port. The operator must inspect overlaps: one 10.0.0.1 in a branch network may be a printer, another behind a different interconnect may be a controller. The shared number is a coordinate only inside a particular administrative realm. Passing it through one well-known prefix does not settle which realm is meant.

Nor does a successful translation attest to authorization. A packet converted from IPv6 to IPv4 has crossed a protocol boundary, not a governance boundary. The authority to reach a payroll server, a customer network or an operations console comes from an operator's access policy and accountable routing design. Heng Lu's distinction between technical capability and practical authority applies with unusual literalness here: the translator can make the packet possible; the operator must decide whether that packet belongs.

The draft describes mixed current behavior among CLAT implementations. Some honor the old drop; others already translate private destinations. It gives no count of either population and no measured reduction in incidents or support tickets. The decisive missing fact for an individual network is its own inventory: which clients synthesize private destinations, which managed translators drop them, and which internal services those destinations actually name. Test that inventory before changing the policy; a standards text cannot discover the second 10.0.0.1 for you.

A well-designed migration would make the implicit rule visible before removing it. Record current drop counters and attempted private destinations, map those destinations to routing realms, write source-and-destination permissions, and test both allowed and forbidden flows from actual client types. The first surprise is likely to be a broken internal application that suddenly works. The more expensive surprise is an internal application that suddenly works for the wrong users.

The IETF draft does not allocate a new prefix or ask IANA for an action. Its change is smaller and more political: it stops pretending that an address-translation standard can act as a permanent access policy. A standards ban was a cheap guardrail, but it could not distinguish a legitimate internal service from a forbidden one. If the IETF removes it, the people operating the network finally have to put their names on that distinction.

Sources: IETF draft · RFC 6052 · RFC 1918 · RFC 6598 · RFC 7050 · RFC 8781 · RFC 8215