Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis Energy Sciences Network
buraglio@forwardingplane.net
tojens.ietf@gmail.com
Google
furry13@gmail.com
OPS v6ops IPv6 DNS64 PREF64 NAT64 CLAT 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 .
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 () 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
  • .  Introduction
  • .  Terminology
  • .  Recommendations for PREF64 Discovery
    • .  Deployment Recommendations for Endpoints
    • .  Deployment Recommendations for Operators
      • .  Mobile Network Considerations
      • .  Migration Considerations
  • .  Existing Issues with RFC 7050
    • .  Dependency on Network-Provided Recursive Resolvers
    • .  Network Stack Initialization Delay
    • .  Latency in Updates Propagation
    • .  Multihoming Implications
    • .  Security Implications
      • .  Definition of Secure Channel
      • .  Secure Channel Example of IPsec
      • .  Secure Channel Example of Link Layer Encryption
  • .  Security Considerations
  • .  IANA Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgments
  • Authors' Addresses
Introduction Devices translating between IPv4 and IPv6 packet headers 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 .
  • Translate IPv4 literals to IPv6 literals ().
  • Perform local DNS64 functions.
  • Support applications relying on IPv4 address referral ().
Dynamic PREF64 discovery is useful to keep the NAT64 prefix configuration up-to-date, particularly for unmanaged endpoints or endpoints that move between networks. introduces the first DNS64-based mechanism for PREF64 discovery per the analysis described in . However, subsequent methods have been developed to address the limitations of the mechanism described in . For instance, defines a Neighbor Discovery option for Router Advertisements (RAs) to convey PREF64 information to hosts. This approach offers several advantages (), including fate sharing with other host network configuration parameters. Due to fundamental shortcomings of the mechanism defined in (see for more details), describes the preferred solution for new deployments. Implementations should strive for consistent PREF64 acquisition methods. The DNS64-based mechanism of 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.
Terminology
DNS64:
A mechanism for synthesizing AAAA records from A records, defined in .
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 . NAT64 translators can operate in stateful mode or stateless mode (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 and operates within a framework for IPv4/IPv6 translation described in .
PREF64:
Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6 address synthesis .
RA:
Router Advertisement. A packet used by Neighbor Discovery and SLAAC to advertise the presence of the routers, together with other IPv6 configuration information.
SLAAC:
Stateless Address Autoconfiguration .
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 when, and only when, they appear in all capitals, as shown here.
Recommendations for PREF64 Discovery
Deployment Recommendations for Endpoints Endpoints SHOULD attempt to obtain PREF64 information from RAs per , instead of using the method described in . In the absence of the PREF64 information in RAs, an endpoint MAY choose to fall back to the mechanism defined in . This recommendation to prefer the mechanism defined in over the one defined in is consistent with .
Deployment Recommendations for Operators Network operators deploying NAT64 SHOULD provide PREF64 information in Router Advertisements per .
Mobile Network Considerations While support for the option specified in 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 when made practical by infrastructure upgrades or software stack feature additions.
Migration Considerations Transitioning from the heuristic procedure in to using the approach in 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 . Operators are advised to take those factors into account prior to removing support for the heuristic procedure in , noting that it is still safe to add support for the approach in since endpoints that support it will always prefer it over 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 ().
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 ). This section outlines the key issues associated with with a focus on those not discussed in or in the analysis of solutions for hosts to discover the NAT64 prefix . Signalling PREF64 in the RA Option addresses all issues outlined in this section (see for details).
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, 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 . However, it has been observed that very few implementations of the method described in support the requirements specified in 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) , 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) for NAT64. Signalling PREF64 in an RA Option decouples the PREF64 discovery from the host's DNS resolver configuration.
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 . Until a PREF64 is obtained, the endpoint's IPv4-only applications and communication to IPv4-only destinations are impaired. The mechanism defined in 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.
Latency in Updates Propagation 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 allows notifying hosts about PREF64 changes immediately by sending an RA with updated information.
Multihoming Implications 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. discusses this scenario in more details.
Security Implications As discussed in , the DNS-based PREF64 discovery is prone to DNS spoofing attacks. In addition to creating a wider attack surface for IPv6 deployments, has other security challenges, which are discussed below.
Definition of Secure Channel 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 . When the mechanism defined in is used in place of the one defined in , nodes only need to implement one defense mechanism; requiring nodes to implement two defense mechanisms creates an unnecessary risk.
Secure Channel Example of IPsec One of the two examples that 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 , 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 , which would ensure the clients know in advance that the DNS64 server supported the encryption mechanism.
Secure Channel Example of Link Layer Encryption The other example given by 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 .
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 . Security considerations related to obtaining PREF64 information from RAs are discussed in .
IANA Considerations This document has no IANA actions.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Discovering PREF64 in Router Advertisements This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts. Informative References 464XLAT Customer-side Translator (CLAT): Node Recommendations Google Google 464XLAT [RFC6877] defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution contains two key elements: provider-side translator (PLAT) and customer-side translator (CLAT). This document complements [RFC6877] and updates Requirements for IPv6 Customer Edge Routers to Support IPv4-as- a-Service (RFC8585) by providing recommendations for the node developers on enabling and disabling CLAT functions. Work in Progress Neighbor Discovery for IP version 6 (IPv6) This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] IPv6 Stateless Address Autoconfiguration This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] IPv6 Addressing of IPv4/IPv6 Translators This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] IPv6 Router Advertisement Guard Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes. Framework for IPv4/IPv6 Translation This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes. Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] 464XLAT: Combination of Stateful and Stateless Translation This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery. Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals. IP/ICMP Translation Algorithm This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. Happy Eyeballs Version 2: Better Connectivity Using Concurrency Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. Special Use Domain Name 'ipv4only.arpa' NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity. The specification for how a client discovers its local network's NAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling. Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties. This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name. It also adds similar declarations for the corresponding reverse mapping names. DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. DNS Terminology The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.
Acknowledgments The authors would like to thank the following people for their valuable contributions: , , , , , , , , , , , , and .
Authors' Addresses Energy Sciences Network
buraglio@forwardingplane.net
tojens.ietf@gmail.com
Google
furry13@gmail.com