Summary

  • RFC 9872 recommends that endpoints learn the NAT64 synthesis prefix from the RFC 8781 PREF64 Router Advertisement option before attempting DNS-based discovery.
  • The change is about authority and scope, not only speed: an on-link advertisement can bind a prefix, lifetime and upstream context to the network where the translator is expected to exist.

The awkward moment comes before the first translated packet. A host has joined an IPv6-only network and has an IPv4 destination, but local address synthesis requires an IPv6 prefix that the network's NAT64 translator recognises. If the host learns the wrong prefix—or learns the right prefix from the wrong network—its synthetic destination can be perfectly formed and operationally useless.

RFC 9872 places that configuration where the attachment happens. Endpoints should first obtain PREF64 from Router Advertisements using the option defined by RFC 8781. Operators deploying NAT64 should provide the same information in those advertisements. RFC 7050's DNS-based method remains available when the option is absent or an endpoint cannot process it, but it becomes the fallback rather than the default source of truth.

A routing signal carries more than a prefix

RFC 8781 assigns Neighbor Discovery option type 38 to PREF64. The option carries prefix bits, a prefix-length code and a lifetime measured in units of eight seconds. A zero lifetime withdraws the prefix. The specification advises against a PREF64 lifetime shorter than the default-router lifetime, because the translation prefix can otherwise expire while the router that led the host to it still appears usable.

Those fields make the advertisement a small control surface. The host can associate the prefix with the network on which it arrived, and a host that supports Provisioning Domains must bind it to the corresponding PvD. When several PREF64s are advertised, the host may use any one with a nonzero lifetime. When several discovery mechanisms are available, RFC 8781 recommends choosing one source rather than merging potentially inconsistent answers.

That last rule matters in multihomed systems. A prefix learned from one upstream is not merely a reusable string. Traffic for addresses synthesized with it must reach a translator that serves it. RFC 9872 therefore treats the relationship among prefix, interface and upstream as part of correct discovery.

DNS remains useful, but its viewpoint can move

RFC 7050 discovers PREF64 by asking a DNS64 resolver for a specially defined IPv4-only name and extracting the common IPv6 prefix from synthesized AAAA answers. The method works, but its authority depends on which resolver actually answers. Encrypted DNS, a VPN, or a manually selected resolver may sit outside the access network and may know nothing about that network's translator. DNS policy can therefore move independently of packet forwarding.

Caching creates a second control problem. DNS-discovered information follows DNS TTL behavior. An operator that needs to change or withdraw a prefix must account for cached answers. Router Advertisements can carry an updated prefix or a zero lifetime directly on the link, making change control visible in the same channel that supplied the route context.

The primary recommendation is RFC 9872. The wire option and host processing rules are in RFC 8781; the DNS alternative is RFC 7050. RFC 6052 defines IPv4-embedded IPv6 address formats, while RFC 7915 specifies stateless translation. None of these documents proves current deployment, translator health or vendor support.

Discovery establishes none of five broader claims: it does not authenticate the Router Advertisement, prove that a translator is reachable, demonstrate deployment or performance, or make RFC 6052's Well-Known Prefix valid on every NAT64 network. The learned prefix remains scoped configuration whose authority and data path require separate evidence.