Summary

  • RFC 9872 recommends learning PREF64 from the RFC 8781 Router Advertisement option when available; DNS-based RFC 7050 discovery remains a fallback for absence and legacy support.
  • A prefix value is not enough in a multihomed host: the operational evidence is a time-bounded association among prefix, advertising router, source address, next hop and translator outcome.

The failure begins after discovery has apparently succeeded. A laptop has two usable uplinks. A DNS64 answer reveals a valid synthesis prefix. The host combines it with an IPv4 destination, chooses a source address and sends the packet through the other provider. Nothing is malformed. The translator simply lives on the path not taken.

RFC 9872, published as an Informational IETF consensus document in September 2025, turns that scenario into deployment guidance. Endpoints should attempt to obtain PREF64 through the Router Advertisement option specified by RFC 8781. Operators deploying NAT64 should advertise it there. The older DNS method in RFC 7050 remains an allowed fallback when the option is absent or an endpoint cannot process it.

PREF64 is the IPv6 prefix used to synthesize destinations for translation toward IPv4. Its format comes from RFC 6052. Knowing it lets a host perform local DNS64 under RFC 6147, support CLAT in the 464XLAT architecture, and translate IPv4 literals as described by Happy Eyeballs Version 2. Those are capabilities. None says which egress can reach the translator.

RFC 7050 learns the prefix from synthetic AAAA answers for ipv4only.arpa.. RFC 8880 formalizes special handling for that name. The method depends on the network's DNS64 resolver, or on applications and local resolvers recognizing the exception. If a user chooses another recursive resolver, or a split-tunnel VPN replaces DNS while leaving some traffic on the local link, discovery can fail or return context that the endpoint cannot associate with the applicable path.

Multihoming exposes the deeper defect. Different providers can return different prefixes. The DNS response does not reliably identify the upstream, IPv6 source prefix or default gateway to which each PREF64 belongs. A host can therefore possess every relevant value and still assemble the wrong tuple. The error is not “bad DNS” or “bad routing” in isolation; it is loss of provenance between the two.

The Router Advertisement option keeps that provenance closer to the decision. IPv6 Neighbor Discovery already uses RAs to convey routers and link parameters. RFC 8781 adds the NAT64 prefix and a scaled lifetime. A host can remember which router advertised which prefix, prefer a route consistent with that first hop, and remove a prefix when a zero lifetime withdraws it. This is fate sharing, not certification: an RA can still be rogue, a route can fail, and a translator can be unhealthy.

Timing changes as well. DNS discovery needs a query after the network stack is otherwise ready. RA delivery can make the address, router and PREF64 available in one configuration event. With DNS caching, an operator may have to wait for TTL expiry and may not control an external DNS64 server's TTL. A fresh RA can announce a change immediately. The difference is operational authority over withdrawal, not just fewer milliseconds at attachment.

Security moves rather than disappears. DNS spoofing no longer controls the discovery value when the endpoint uses the RA option, but first-hop protection becomes decisive. RFC 6105 describes RA-Guard, while RFC 8781 carries its own security limits. RFC 9463 can advertise network-designated encrypted resolvers; encrypted DNS protects a resolver exchange but still does not attach a prefix to the correct uplink.

Migration creates a deliberate overlap. Operators may need to keep RFC 7050 while older endpoint software remains. RFC 9872 notes that conforming modern endpoints prefer the RA option, so it can be added before the heuristic is removed. It also records a real equipment boundary: mobile operating systems may understand the option while mobile-network infrastructure cannot insert it into RAs. The official RFC record establishes publication, not implementation by any named network.

Heng Lu's running-code primacy gives the correct test: keep the common signal narrow and let endpoints verify the resulting path. His minimum-initial-specification doctrine separates interoperable syntax from local adoption and response. His warning about the permanent dual-stack tax identifies who pays when resolver, router, translator and endpoint states coexist indefinitely.

RFC 9872 is valuable because it refuses to treat discovery as proof. A prefix becomes actionable only when the host can show where it came from, how long it remains valid, which route used it and whether the translator and application completed the journey.

Sources