RFC 9872

Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis

📅 published September 2025, from ietf

RFC 9872 🎀 Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis

  • Published by: Internet Engineering Task Force (IETF) 🌸
  • Number and title: RFC 9872, Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis
  • Authors: N. Buraglio (Energy Sciences Network), T. Jensen, and J. Linkova (Google) 🫶
  • Category: Informational (not a Standards Track spec, just vibes and guidance 💅)
  • ISSN: 2070-1721
  • Date: September 2025
  • Obsoletes / Updates: nothing is listed in the header 🙈

Abstract

okay so on networks that do IPv4-IPv6 translation ([RFC 7915]), hosts and other endpoints need to know the IPv6 prefix(es) used for translation. that's the NAT64 prefix (RFC 6052) 🧚 this doc gives guidelines for finding that NAT64 prefix, and the big recommendation is to grab it from the Router Advertisement option (RFC 8781) whenever that's available 🦋

Status of This Memo

not gonna lie, this section is kind of a formal vibe, but here's the tea 🍓 this document is not an Internet Standards Track specification. it's published for informational purposes.

it is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🤓

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9872 ✨

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. please actually read those, because they spell out your rights and restrictions for this doc. also, any Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License ⚖️💖

Table of Contents

1.  Introduction
2.  Terminology
3.  Recommendations for PREF64 Discovery
  3.1.  Deployment Recommendations for Endpoints
  3.2.  Deployment Recommendations for Operators
    3.2.1.  Mobile Network Considerations
    3.2.2.  Migration Considerations
4.  Existing Issues with RFC 7050
  4.1.  Dependency on Network-Provided Recursive Resolvers
  4.2.  Network Stack Initialization Delay
  4.3.  Latency in Updates Propagation
  4.4.  Multihoming Implications
  4.5.  Security Implications
    4.5.1.  Definition of Secure Channel
    4.5.2.  Secure Channel Example of IPsec
    4.5.3.  Secure Channel Example of Link Layer Encryption
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

so devices that translate between IPv4 and IPv6 packet headers [RFC7915] use a NAT64 prefix to map IPv4 addresses into the IPv6 address space, and the other way around too. when a network has NAT64, it's really good for endpoints to get the network's NAT64 prefixes (PREF64) 💜 knowing the PREF64 lets endpoints:

  • Implement the customer-side translator (CLAT) function of the 464XLAT architecture [RFC6877].
  • Translate IPv4 literals to IPv6 literals (Section 7.1 of [RFC8305]).
  • Perform local DNS64 [RFC6147] functions.
  • Support applications that rely on IPv4 address referral (Section 3.2.2 of [RFC7225]).

dynamic PREF64 discovery keeps the NAT64 prefix config up to date, which matters a lot for unmanaged endpoints or endpoints that hop between networks 🌈 [RFC7050] brought in the first DNS64-based mechanism for PREF64 discovery, following the analysis in [RFC7051]. but later methods were built to fix the limitations of the [RFC7050] mechanism, so it's not the only option anymore 🦋

for example, [RFC8781] defines a Neighbor Discovery [RFC4861] option for Router Advertisements (RAs) that carries PREF64 info to hosts. this approach has several advantages (Section 3 of [RFC8781]), including fate sharing with other host network configuration parameters 🧚

because of the fundamental shortcomings of the [RFC7050] mechanism (see Section 4 for more details), [RFC8781] describes the preferred solution for new deployments 👑 implementations should strive for consistent PREF64 acquisition methods. the DNS64-based mechanism of [RFC7050] should be employed only when RA-based PREF64 delivery is unavailable, or as a fallback for legacy systems that can't process the PREF64 RA Option 🫶

2. Terminology 📚

  • DNS64: a mechanism for synthesizing AAAA records from A records, defined in [RFC6147].
  • NAT64: a mechanism for translating IPv6 packets to IPv4 packets, and vice versa. the translation happens by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC7915]. NAT64 translators can operate in stateful mode [RFC6144] or stateless mode [RFC6877] (e.g., customer-side translator (CLAT)). this document uses "NAT64" as a generalized term for a translator that uses the stateless IP/ICMP Translation Algorithm defined in [RFC7915] and operates within a framework for IPv4/IPv6 translation described in [RFC6144] 🦋
  • PREF64: Pref64::/n or NAT64 prefix. an IPv6 prefix used for IPv6 address synthesis [RFC6146] 💖
  • RA: Router Advertisement. a packet used by Neighbor Discovery [RFC4861] and SLAAC to advertise the presence of routers, along with other IPv6 configuration information 📡
  • SLAAC: Stateless Address Autoconfiguration [RFC4862] 🌸

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. so if you see them in ALL CAPS, that's the official requirement energy 💅 lowercase ones are just regular words 🙈

3. Recommendations for PREF64 Discovery 🎀

3.1. Deployment Recommendations for Endpoints

okay this is the main ask for endpoints 🫶 endpoints SHOULD attempt to get PREF64 info from RAs per [RFC8781], instead of using the method described in [RFC7050]. if there's no PREF64 info in the RAs, an endpoint MAY choose to fall back to the mechanism defined in [RFC7050]. this preference for [RFC8781] over [RFC7050] lines up with Section 5.1 of [RFC8781], so it's not a random opinion, it's consistent 💜

3.2. Deployment Recommendations for Operators

network operators deploying NAT64 SHOULD provide PREF64 info in Router Advertisements per [RFC8781]. operators, this one's for you 👑✨

3.2.1. Mobile Network Considerations 📱

ngl, this part is a little sad 😭 support for the option in [RFC8781] is widely built into modern operating systems on mobile endpoints, but the gear deployed in mobile networks often can't put the PREF64 Option into RAs. so turning on PREF64 right away may not be feasible for mobile operators right now, and the recommendations in this document are not presently applicable to mobile network operators. those environments are encouraged to adopt the option in [RFC8781] once infrastructure upgrades or software stack feature additions make it practical 🌈

3.2.2. Migration Considerations 🦋

moving from the heuristic procedure in [RFC7050] to the approach in [RFC8781] might need a stretch of time where both mechanisms coexist 🕰️ how long that takes depends on the endpoint footprint, especially how many endpoints run older operating systems that don't support the option in [RFC8781]. operators are advised to think about those factors before removing support for the heuristic procedure in [RFC7050]. still, it's safe to add support for the approach in [RFC8781] now, since endpoints that support it will always prefer it over [RFC7050] if they follow RFC requirements 💖

moving away from DNS64-based discovery also cuts down on dependency on DNS64 in general, which gets rid of DNSSEC and DNS64 incompatibility concerns (Section 6.2 of [RFC6147]) 🔥

to be continued in part 2 🎀

4.2. Network Stack Initialization Delay ✨

okay so bestie, picture this 🧚 when an IPv6 host is using SLAAC, it usually only needs a single RA to get its whole network setup 💅. and for IPv6-only endpoints, getting the PREF64 fast is literally everything 😭. like, anything doing local DNS64 or NAT64 stuff, such as CLAT [RFC6877], is lowkey stuck without it. until the endpoint has a PREF64, its IPv4-only apps and anything talking to IPv4-only destinations are just... impaired 💀. the mechanism in [RFC7050] doesn't bundle PREF64 info with the rest of the network config, and it needs at least one round-trip time (send a DNS request, get a response) after the network stack is already configured. so it's not it 🙈

but advertising PREF64 in an RA? iconic 👑 it means there's no awkward window where the host has IPv6 addresses and default routers but no PREF64 yet. main character energy ✨

4.3. Latency in Updates Propagation 🦋

okay so [RFC7050] Section 3 says this:

The node SHALL cache the replies it receives during the Pref64::/n discovery procedure, and it SHOULD repeat the discovery process ten seconds before the TTL of the Well-Known Name's synthetic AAAA resource record expires.

so basically once a node finds a PREF64, it keeps using it until the TTL runs out or it disconnects from the network 🫶 and there's no way for an operator to force a rediscovery without yanking the node off the network first. 😭 if the operator wants to change the PREF64, they have to lower the TTL on the DNS64 server ahead of time. and that's giving two big problems:

  • lots of networks use external DNS64 servers, so they have zero control over the TTL if the PREF64 needs changing or withdrawing 💀
  • PREF64 changes have to be planned at least TTL seconds in advance. if the operator needs to tell nodes a prefix must NOT be used (like during an outage, or if nodes learned a rogue PREF64 from an attack), it might not be possible without interrupting connectivity for the affected nodes 🙈

the mechanism in [RFC8781] fixes this 🔥 it lets hosts know about PREF64 changes immediately by sending an RA with the updated info. no cap, it's the glow-up 🌸

4.4. Multihoming Implications 🍓

okay so [RFC7050] Section 3 says a node has to look at all the received AAAA resource records to discover one or more PREF64s, and use all the prefixes it learns. ngl this gets messy in some multihomed setups 😭 where DNS64 servers from different ISPs might hand back different PREF64s. in those cases it's crucial that traffic going to synthesized addresses goes to the right NAT64, and that the source address for those flows is from that ISP's address space 🫶. so the node needs to link each discovered PREF64 to its upstream info, including the IPv6 prefix and default gateway. right now there's no reliable way for a node to map a DNS64 response (and the prefix learned from it) to a specific upstream, so the node might pick the wrong source address for a PREF64 and/or send traffic out the wrong uplink. yikes 💀

advertising PREF64 in RAs lets hosts track which router advertised which PREF64 and use that to pick the correct next hop 💖. [CLAT] Section 8 goes into this scenario in more detail ✨

4.5. Security Implications 🔥

okay so as Section 7 of [RFC7050] talks about, DNS-based PREF64 discovery is prone to DNS spoofing attacks 😱. on top of making a wider attack surface for IPv6 deployments, [RFC7050] has other security challenges too, which we'll go through below 🫶

4.5.1. Definition of Secure Channel 🎀

[RFC7050] requires a node's communication channel with a DNS64 server to be a "secure channel", which it defines as "a communication channel a node has between itself and a DNS64 server protecting DNS protocol-related messages from interception and tampering". ngl this requirement is kinda redundant 🙄 because RAs are another IPv6 config mechanism that can already be defended against tampering, for example by enabling RA-Guard [RFC6105]. when [RFC8781] is used instead of [RFC7050], nodes only need to implement ONE defense mechanism. making nodes implement two creates an unnecessary risk 💀

4.5.2. Secure Channel Example of IPsec 🦋

one of the two examples [RFC7050] gives for a communication channel with a DNS64 server to count as "secure" is an "IPsec-based virtual private network (VPN) tunnel". as of writing, no common OS DNS client supports this as a practice 😭. they could, sure, and there have also been multiple mechanisms defined for DNS-specific encryption, such as the ones in [RFC9499], which would be way better scoped to just the relevant DNS traffic 🧚. these are also compatible with encrypted DNS advertisement by the network using Discovery of Network-designated Resolvers [RFC9463], which would make sure clients know in advance that the DNS64 server supports the encryption mechanism 💜

the other example from [RFC7050] that would let a channel to a DNS64 server count as "secure" is a "link layer utilizing data encryption technologies". as of writing, most common link layer implementations already encrypt data with zero extra effort from network nodes 🙄. sounds like a trivial way to meet the requirement, BUT it makes the requirement meaningless 💀 because any node along the path can still read the higher-layer DNS traffic containing the translation prefix. which seems to clash with the definition of "secure channel", as explained in Section 2.2 of [RFC7050] 🙈

5. Security Considerations 😱

okay bestie, this part is SO important 🚨 obtaining PREF64 info using RAs improves the overall security of an IPv6-only endpoint, because it mitigates all attack vectors related to a spoofed or rogue DNS response, as discussed in Section 7 of [RFC7050] 🛡️✨. security considerations for getting PREF64 info from RAs are discussed in Section 7 of [RFC8781] 💖. please go read those sections, no cap 🫶

6. IANA Considerations 🌸

this document has no IANA actions 💅

7. References 📚

7.1. Normative References 🎀

7.2. Informative References 📖

Acknowledgments 🙏✨

okay bestie, the authors wanna give a HUGE thank-you to everyone who helped make this doc happen 🫶 their contributions were seriously valuable, so shoutout to:

  • Mike Bishop 💜
  • Mohamed Boucadair 🌸
  • Lorenzo Colitti 🦋
  • Tom Costello 🎀
  • Charles Eckel 🍓
  • Susan Hares 🧚
  • Nick Heatley ⭐
  • Ted Lemon 🌈
  • Gábor Lencse 👑
  • David Lou 💅
  • Peter Schmitt 🔥
  • Éric Vyncke ✨
  • Chongfeng Xie 🫶

the way these people showed up for the doc?? iconic behaviour, honestly 😭

Authors' Addresses 💌

Nick Buraglio Energy Sciences Network Email: buraglio@forwardingplane.net

Tommy Jensen Email: tojens.ietf@gmail.com

Jen Linkova Google Email: furry13@gmail.com

and that's the whole doc, bestie!! 🎀💖 the authors are literally the main characters here, slay 👑✨

📦 where this page comes from