|
|
|
|
|
|
IETF RFC 9872
Last modified on Wednesday, October 1st, 2025
 Permanent link to RFC 9872
 Search GitHub Wiki for RFC 9872
 Show other RFCs mentioning RFC 9872
Internet Engineering Task Force (IETF) N. Buraglio
Request for Comments: 9872 Energy Sciences Network
Category: Informational T. Jensen
ISSN: 2070-1721
J. Linkova
Google
September 2025
Recommendations for Discovering IPv6 Prefix Used for IPv6 Address
Synthesis
 Abstract
On networks providing IPv4-IPv6 translation (RFC 7915), hosts and
other endpoints need to know the IPv6 prefix(es) used for translation
(the NAT64 prefix (RFC 6052)). This document provides guidelines for
NAT64 prefix discovery, specifically recommending obtaining the NAT64
prefix from the Router Advertisement option (RFC 8781) when
available.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/RFC 9872.
Copyright Notice
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in 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
Devices translating between IPv4 and IPv6 packet headers [RFC 7915]
use a NAT64 prefix to map IPv4 addresses into the IPv6 address space,
and vice versa. When a network provides NAT64, it is advantageous
for endpoints to acquire the network's NAT64 prefixes (PREF64).
Discovering the PREF64 enables endpoints to:
* Implement the customer-side translator (CLAT) function of the
464XLAT architecture [RFC 6877].
* Translate IPv4 literals to IPv6 literals (Section 7.1 of
[RFC 8305]).
* Perform local DNS64 [RFC 6147] functions.
* Support applications relying on IPv4 address referral
(Section 3.2.2 of [RFC 7225]).
Dynamic PREF64 discovery is useful to keep the NAT64 prefix
configuration up-to-date, particularly for unmanaged endpoints or
endpoints that move between networks. [RFC 7050] introduces the first
DNS64-based mechanism for PREF64 discovery per the analysis described
in [RFC 7051]. However, subsequent methods have been developed to
address the limitations of the mechanism described in [RFC 7050].
For instance, [RFC 8781] defines a Neighbor Discovery [RFC 4861] option
for Router Advertisements (RAs) to convey PREF64 information to
hosts. This approach offers several advantages (Section 3 of
[RFC 8781]), including fate sharing with other host network
configuration parameters.
Due to fundamental shortcomings of the mechanism defined in [RFC 7050]
(see Section 4 for more details), [RFC 8781] describes the preferred
solution for new deployments. Implementations should strive for
consistent PREF64 acquisition methods. The DNS64-based mechanism of
[RFC 7050] should be employed only when RA-based PREF64 delivery is
unavailable or as a fallback for legacy systems incapable of
processing the PREF64 RA Option.
2. Terminology
DNS64: A mechanism for synthesizing AAAA records from A records,
defined in [RFC 6147].
NAT64: A mechanism for translating IPv6 packets to IPv4 packets, and
vice versa. The translation is done by translating the packet
headers according to the IP/ICMP Translation Algorithm defined in
[RFC 7915]. NAT64 translators can operate in stateful mode
[RFC 6144] or stateless mode [RFC 6877] (e.g., customer-side
translator (CLAT)). This document uses "NAT64" as a generalized
term for a translator, which uses the stateless IP/ICMP
Translation Algorithm defined in [RFC 7915] and operates within a
framework for IPv4/IPv6 translation described in [RFC 6144].
PREF64: Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6
address synthesis [RFC 6146].
RA: Router Advertisement. A packet used by Neighbor Discovery
[RFC 4861] and SLAAC to advertise the presence of the routers,
together with other IPv6 configuration information.
SLAAC: Stateless Address Autoconfiguration [RFC 4862].
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 [RFC 2119] [RFC 8174] when, and only when, they appear in all
capitals, as shown here.
3. Recommendations for PREF64 Discovery
3.1. Deployment Recommendations for Endpoints
Endpoints SHOULD attempt to obtain PREF64 information from RAs per
[RFC 8781], instead of using the method described in [RFC 7050]. In
the absence of the PREF64 information in RAs, an endpoint MAY choose
to fall back to the mechanism defined in [RFC 7050]. This
recommendation to prefer the mechanism defined in [RFC 8781] over the
one defined in [RFC 7050] is consistent with Section 5.1 of [RFC 8781].
3.2. Deployment Recommendations for Operators
Network operators deploying NAT64 SHOULD provide PREF64 information
in Router Advertisements per [RFC 8781].
3.2.1. Mobile Network Considerations
While support for the option specified in [RFC 8781] is widely
integrated into modern operating systems on mobile endpoints,
equipment deployed in mobile network environments often lacks
abilities to include the PREF64 Option into RAs. Therefore, the
immediate deployment and enablement of PREF64 by mobile operators may
not currently be feasible and the recommendations outlined in this
document are not presently applicable to mobile network operators.
These environments are encouraged to incorporate the option specified
in [RFC 8781] when made practical by infrastructure upgrades or
software stack feature additions.
3.2.2. Migration Considerations
Transitioning from the heuristic procedure in [RFC 7050] to using the
approach in [RFC 8781] might require a period of time where both
mechanisms coexist. How long this may take depends on the endpoint
footprint, particularly the presence and number of endpoints running
outdated operating systems that do not support the option in
[RFC 8781]. Operators are advised to take those factors into account
prior to removing support for the heuristic procedure in [RFC 7050],
noting that it is still safe to add support for the approach in
[RFC 8781] since endpoints that support it will always prefer it over
[RFC 7050] if they follow RFC requirements.
Migrating away from DNS64-based discovery also reduces dependency on
DNS64 in general, thereby eliminating DNSSEC and DNS64
incompatibility concerns (Section 6.2 of [RFC 6147]).
4. Existing Issues with RFC 7050
DNS-based discovery of the NAT64 prefix introduces some challenges,
which make this approach less preferable than the latest developed
alternatives (such as the PREF64 RA Option [RFC 8781]). This section
outlines the key issues associated with [RFC 7050] with a focus on
those not discussed in [RFC 7050] or in the analysis of solutions for
hosts to discover the NAT64 prefix [RFC 7051].
Signalling PREF64 in the RA Option addresses all issues outlined in
this section (see Section 3 of [RFC 8781] for details).
4.1. Dependency on Network-Provided Recursive Resolvers
The presence or absence of NAT64 functionality, as well as its
associated prefix (if present), are network-dependent attributes.
Therefore, [RFC 7050] requires the endpoint discovering the prefix to
use the DNS64 resolvers provided by the network. If the device or an
application is configured to use other recursive resolvers or runs a
local recursive resolver, the corresponding name resolution APIs and
libraries are required to recognize 'ipv4only.arpa.' as a special
name and give it special treatment. This issue and remediation
approach are discussed in [RFC 8880]. However, it has been observed
that very few implementations of the method described in [RFC 7050]
support the requirements specified in [RFC 8880] for special treatment
of 'ipv4only.arpa.'. As a result, configuring such systems and
applications to use resolvers other than the one provided by the
network breaks the PREF64 discovery, leading to degraded user
experience.
VPN applications may override the endpoint's DNS configuration, for
example, by configuring enterprise DNS servers as the node's
recursive resolvers and forcing all name resolution through the VPN.
These enterprise DNS servers typically lack DNS64 functionality and
therefore cannot provide information about the PREF64 used within the
local network. If the VPN is configured in so-called "split
tunneling" mode (when only a subset of network traffic is routed into
the VPN tunnel), endpoints may not discover the necessary PREF64,
which negatively impacts their connectivity on IPv6-only networks.
If both the network-provided DNS64 and the endpoint's resolver happen
to utilize the Well-Known Prefix (64:ff9b::/96) [RFC 6052], the
endpoint would end up using a PREF64 that's valid for the current
network. However, if the endpoint changes its network attachment, it
can't detect if the new network lacks NAT64 entirely or uses a
network-specific prefix (NSP) [RFC 6144] for NAT64.
Signalling PREF64 in an RA Option decouples the PREF64 discovery from
the host's DNS resolver configuration.
4.2. Network Stack Initialization Delay
When using SLAAC, an IPv6 host typically requires a single RA to
acquire its network configuration. For IPv6-only endpoints, timely
PREF64 discovery is critical, particularly for those performing local
DNS64 or NAT64 functions, such as CLAT [RFC 6877]. Until a PREF64 is
obtained, the endpoint's IPv4-only applications and communication to
IPv4-only destinations are impaired. The mechanism defined in
[RFC 7050] does not bundle PREF64 information with other network
configuration parameters and requires at least one round-trip time
(to send a DNS request and receive a response) after the network
stack configuration is completed.
On the other hand, advertising PREF64 in an RA eliminates the period
when the host obtains IPv6 addresses and default routers but no
PREF64.
4.3. Latency in Updates Propagation
Section 3 of [RFC 7050] states:
| 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.
As a result, once a PREF64 is discovered, it will be used until the
TTL expires or until the node disconnects from the network. There is
no mechanism for an operator to force the PREF64 rediscovery on the
node without disconnecting the node from the network. If the
operator needs to change the PREF64 value used in the network, they
need to proactively reduce the TTL value returned by the DNS64
server. This method has two significant drawbacks:
* Many networks utilize external DNS64 servers and therefore have no
control over the TTL value if the PREF64 needs to be changed or
withdrawn.
* The PREF64 changes need to be planned and executed at least TTL
seconds in advance. If the operator needs to notify nodes that a
particular prefix must not be used (e.g., during a network outage
or if the nodes learned a rogue PREF64 as a result of an attack),
it might not be possible without interrupting the network
connectivity for the affected nodes.
The mechanism defined in [RFC 8781] allows notifying hosts about
PREF64 changes immediately by sending an RA with updated information.
4.4. Multihoming Implications
Section 3 of [RFC 7050] requires a node to examine all received AAAA
resource records to discover one or more PREF64s and to utilize all
learned prefixes. However, this approach presents challenges in some
multihomed topologies where different DNS64 servers belonging to
different ISPs might return different PREF64s. In such cases, it is
crucial that traffic destined for synthesized addresses is sent to
the correct NAT64 and the source address selected for those flows
belongs to the prefix from that ISP's address space. In other words,
the node needs to associate each discovered PREF64 with upstream
information, including the IPv6 prefix and default gateway.
Currently, there is no reliable way for a node to map a DNS64
response (and the prefix learned from it) to a specific upstream in a
multihoming scenario. Consequently, the node might inadvertently
select an incorrect source address for a given PREF64 and/or send
traffic to the incorrect uplink.
Advertising PREF64 in RAs allows hosts to track which PREF64 was
advertised by which router and use that information to select the
correct next hop. Section 8 of [CLAT] discusses this scenario in
more details.
4.5. Security Implications
As discussed in Section 7 of [RFC 7050], the DNS-based PREF64
discovery is prone to DNS spoofing attacks. In addition to creating
a wider attack surface for IPv6 deployments, [RFC 7050] has other
security challenges, which are discussed below.
4.5.1. Definition of Secure Channel
[RFC 7050] requires a node's communication channel with a DNS64 server
to be a "secure channel", which it defines to mean "a communication
channel a node has between itself and a DNS64 server protecting DNS
protocol-related messages from interception and tampering". This
need is redundant when another communication mechanism of
IPv6-related configuration, specifically RAs, can already be defended
against tampering, for example, by enabling RA-Guard [RFC 6105]. When
the mechanism defined in [RFC 8781] is used in place of the one
defined in [RFC 7050], nodes only need to implement one defense
mechanism; requiring nodes to implement two defense mechanisms
creates an unnecessary risk.
4.5.2. Secure Channel Example of IPsec
One of the two examples that [RFC 7050] defines to qualify a
communication channel with a DNS64 server is the use of an "IPsec-
based virtual private network (VPN) tunnel". As of the time of this
writing, this is not supported as a practice by any common operating
system DNS client. While they could, there have also since been
multiple mechanisms defined for performing DNS-specific encryption,
such as those defined in [RFC 9499], that would be more appropriately
scoped to the applicable DNS traffic. These are also compatible with
encrypted DNS advertisement by the network using Discovery of
Network-designated Resolvers [RFC 9463], which would ensure the
clients know in advance that the DNS64 server supported the
encryption mechanism.
4.5.3. Secure Channel Example of Link Layer Encryption
The other example given by [RFC 7050] that would allow a communication
channel with a DNS64 server to qualify as a "secure channel" is the
use of a "link layer utilizing data encryption technologies". As of
the time of this writing, most common link layer implementations use
data encryption already with no extra effort needed on the part of
network nodes. While this appears to be a trivial way to satisfy
this requirement, it also renders the requirement meaningless since
any node along the path can still read the higher-layer DNS traffic
containing the translation prefix. This seems to be at odds with the
definition of "secure channel", as explained in Section 2.2 of
[RFC 7050].
5. Security Considerations
Obtaining PREF64 information using RAs improves the overall security
of an IPv6-only endpoint as it mitigates all attack vectors related
to a spoofed or rogue DNS response, as discussed in Section 7 of
[RFC 7050]. Security considerations related to obtaining PREF64
information from RAs are discussed in Section 7 of [RFC 8781].
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC 2119, March 1997,
<https://www.rfc-editor.org/info/RFC 2119>.
[RFC 7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC 7050, November 2013,
<https://www.rfc-editor.org/info/RFC 7050>.
[RFC 8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC 8174,
May 2017, <https://www.rfc-editor.org/info/RFC 8174>.
[RFC 8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", RFC 8781, DOI 10.17487/RFC 8781, April
2020, <https://www.rfc-editor.org/info/RFC 8781>.
7.2. Informative References
[CLAT] Colitti, L., Linkova, J., and T. Jensen, "464XLAT
Customer-side Translator (CLAT): Node Recommendations",
Work in Progress, Internet-Draft, draft-ietf-v6ops-claton-
08, 17 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
claton-08>.
[RFC 4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC 4861, September 2007,
<https://www.rfc-editor.org/info/RFC 4861>.
[RFC 4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC 4862, September 2007,
<https://www.rfc-editor.org/info/RFC 4862>.
[RFC 6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC 6052, October 2010,
<https://www.rfc-editor.org/info/RFC 6052>.
[RFC 6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC 6105, February 2011,
<https://www.rfc-editor.org/info/RFC 6105>.
[RFC 6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC 6144,
April 2011, <https://www.rfc-editor.org/info/RFC 6144>.
[RFC 6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC 6146,
April 2011, <https://www.rfc-editor.org/info/RFC 6146>.
[RFC 6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC 6147, April 2011,
<https://www.rfc-editor.org/info/RFC 6147>.
[RFC 6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC 6877, April 2013,
<https://www.rfc-editor.org/info/RFC 6877>.
[RFC 7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of
Solution Proposals for Hosts to Learn NAT64 Prefix",
RFC 7051, DOI 10.17487/RFC 7051, November 2013,
<https://www.rfc-editor.org/info/RFC 7051>.
[RFC 7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225,
DOI 10.17487/RFC 7225, May 2014,
<https://www.rfc-editor.org/info/RFC 7225>.
[RFC 7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC 7915, June 2016,
<https://www.rfc-editor.org/info/RFC 7915>.
[RFC 8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC 8305, December 2017,
<https://www.rfc-editor.org/info/RFC 8305>.
[RFC 8880] Cheshire, S. and D. Schinazi, "Special Use Domain Name
'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC 8880, August
2020, <https://www.rfc-editor.org/info/RFC 8880>.
[RFC 9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
and T. Jensen, "DHCP and Router Advertisement Options for
the Discovery of Network-designated Resolvers (DNR)",
RFC 9463, DOI 10.17487/RFC 9463, November 2023,
<https://www.rfc-editor.org/info/RFC 9463>.
[RFC 9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC 9499, March 2024,
<https://www.rfc-editor.org/info/RFC 9499>.
Acknowledgments
The authors would like to thank the following people for their
valuable contributions: 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, and
Chongfeng Xie.
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
RFC TOTAL SIZE: 23781 bytes
PUBLICATION DATE: Wednesday, October 1st, 2025
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
