]> Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses Google, LLC
warren@kumari.net
Google, LLC
furry13@gmail.com
Operations and Management IPv6 Operations ipv6 nat64 wkp This document modifies the deployment guidance provided in Section 3.1 of RFC 6052 (IPv6 Addressing of IPv4/IPv6 Translators) that IPv4/IPv6 Translators must not use the Well-Known Prefix 64:ff9b::/96 to represent non-globally reachable IPv4 addresses, such as those defined in RFC 1918 (Address Allocation for Private Internets) or listed in Section 2.2.2 of RFC 6890 (Special-Purpose IP Address Registries). This change enables IPv6-only nodes to reach IPv4-only services with specific non-globally reachable addresses by leveraging the Well-Known Prefix. This document updates RFC 6052 to allow packets in which an address is composed of the Well-Known Prefix and specific non-globally reachable IPv4 addresses to be translated. About This Document Status information for this document may be found at . Discussion of this document takes place on the IPv6 Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction The deployment guidance in prohibits IPv4/IPv6 translators from using the Well-Known Prefix (WKP, 64:ff9b::/96) to represent non-globally reachable IPv4 addresses, such as those defined in or listed in . That guidance was meant to avoid ambiguous translation that might be experienced with such non-globally unique addresses. However, there are deployment contexts where that consideration is not an issue. This restriction is relatively straightforward to implement in DNS64 : a DNS64 server simply avoids synthesizing an AAAA resource record using the WKP if the original A resource record contains a non-globally reachable IPv4 address. However, this deployment guidance introduces operational challenges for systems that do not rely on DNS64 and instead use local synthesis such as Customer-side Translator (CLAT) or similar approaches. Enterprise and other closed networks may require IPv6-only nodes to communicate with both internal (e.g., using addresses) and external (Internet) IPv4-only destinations. The restriction in prevents such networks from utilizing the WKP and, consequently, from relying on public DNS64 servers (e.g., forwarding requests for external zones to public DNS64 servers) that utilize the WKP in order to maximize compatibility. Using two Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) prefixes — the WKP for Internet destinations and a Network-Specific Prefix (NSP) for non-globally reachable IPv4 addresses — is not a feasible solution for nodes performing local synthesis or running CLAT. None of the widely deployed NAT64 Prefix Discovery mechanisms (, ) provide a method to map a specific NAT64 prefix to the subset of IPv4 addresses for which it should be used. According to , a node must use all learned prefixes when performing local IPv6 address synthesis. Consequently, if a node discovers both the WKP and an NSP, it will use both prefixes to represent globally reachable IPv4 addresses. This duplication significantly complicates security policies, troubleshooting, and other operational aspects of the network. Combining the WKP with the Local-Use prefix (64:ff9b:1::/48) is also not feasible as it introduces the same challenges as using the WKP with an NSP. Prohibiting the WKP from representing private IPv4 addresses and shared addresses offers no substantial benefit to IPv6-only or IPv6-mostly deployments. It also substantially complicates network design and the behavior of nodes. Given the recent operational experience in deploying IPv6-only and IPv6-mostly networks, it is desirable to allow translators to use a single prefix (including the WKP) to represent IPv4 addresses regardless of their globally reachable or non-globally reachable status. In particular, allowing translators to use the WKP to represent private IPv4 addresses (, ) will improve the utility of the WKP in enterprise networks, in particular. This document updates to relax a restriction on the use of the WKP (). provides examples to illustrate the updated behavior.
Conventions and Definitions 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.
Terminology This document reuses terms defined in and .
RFC 6052 Update This document updates ("Restrictions on the Use of the Well-Known Prefix") as follows. discusses recommendations for existing implementations in more details. OLD TEXT:
The Well-Known Prefix MUST NOT be used to represent non-global IPv4 addresses, such as those defined in or listed in Section 3 of . Address translators MUST NOT translate packets in which an address is composed of the Well-Known Prefix and a non-global IPv4 address; they MUST drop these packets.
NEW TEXT:
The Well-Known Prefix MAY be used to represent non-global IPv4 addresses, such as those listed in and . Unmanaged client-side translators (CLATs) MUST translate packets in which an address is composed of the Well-Known Prefix and these non-globally reachable IPv4 address (defined in and ) by default. Provider-side translators (PLATs) MUST translate such packets unless configured otherwise. Because administrators may rely on dropping these packets as an implicit security policy, the translator MUST provide a configuration option to disable translation of such packets.
Operational Considerations There may be cases in which it is desirable to ignore translation of private IPv4 addresses due to internal policy or overlapping internal networks. In such envinronments, operators need to create configurations which address the filtering of private use IPv4 addressing if there is an expectation of compliance with the original .
Existing Behavior Testing and operational experience with existing CLAT implementations (both mobile and non-mobile) have revealed highly inconsistent behavior regarding the original restriction in . While some implementations strictly comply with the original guidance and drop packets destined for non-globally reachable IPv4 addresses, many other widely deployed CLATs completely ignore this restriction and translate the packets. This inconsistency creates significant operational challenges. Network operators are unable to predictably determine how unmanaged, client-side devices will handle traffic directed to internal IPv4 services. This unpredictable dropping or translating of packets on the client side severely complicates network design, security policies, and troubleshooting. By formalizing the requirement that unmanaged CLAT implementations must translate these packets by default (as updated in Section 3), and allowing PLAT devices to translate these packets, this document provides clear, standardized instructions to implementers. This resolves the current operational ambiguity, ensuring predictable behavior across all client ecosystems and aligning the standard with the practical realities of modern IPv6-mostly and IPv6-only deployments. Furthermore, where client-side translation and local synthesis are used, it is not feasible at the time of writing this document to employ more than one translation prefix, especially if different prefixes must be used for different IPv4 destinations. None of the widely deployed NAT64 Prefix Discovery mechanisms (, ) provide a method to map a specific NAT64 prefix to a subset of IPv4 addresses for which it should be used.
Use of Network-Specific or Local-Use Prefix Use of an NSP or the Local-Use prefix (64:ff9b:1::/48) does not preclude the removal of as a "MUST" level recommendation. Whether a network employs an NSP or 64:ff9b:1::/48, the behavior of synthesizing a private use
IPv4 address is not prohibited by . The changes specified in
this document are not impactful to networks using NSPs or the Local-Use prefix as defined in . As discussed in , utilizing an NSP or the Local-Use prefix will typically prevent the use of a public DNS64 resolver in the vast majority of cases, as large scale public DNS64 resolvers use the WKP to maximize compatibility.
Security Considerations Legitimizing packets where the IPv6 destination address is composed of the WKP and a non-globally reachable IPv4 address does not, inherently, introduce new security considerations. Whether a specific traffic flow between an IPv6-only source and a non-globally reachable IPv4 destination (or any flow to a non-globally reachable IPv4 destination) is legitimate is a matter of local network topology and administrative policy. However, existing NAT64 implementations compliant with are expected to drop such packets. Administrators may be relying on this implicit filtering as a built-in security mechanism to prevent unauthorized access to private IPv4 infrastructure, rather than implementing explicit security policies. This reliance is particularly prevalent in managed NAT64 (PLAT) environments. Modifying the recommended behavior to allow such address compositions may, in the absence of explicit filtering, enable traffic flows that were previously prohibited by the translator's default logic. To mitigate this risk, existing managed PLAT implementations compliant with SHOULD NOT alter their default dropping behavior. As specified in , PLAT implementations must provide a configuration knob to control this functionality, ensuring that the transition to supporting non-globally reachable addresses is an intentional administrative action accompanied by a review of local security policies. Furthermore, administrators should not rely on the internal verification logic of a translator to enforce security boundaries. Instead, explicit policies such as Access Control Lists (ACLs), firewall policies, or NAT filtering rules must be used to define authorized traffic patterns through the translator.
IANA Considerations This document has no IANA actions.
References Normative References Address Allocation for Private Internets This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] IANA-Reserved IPv4 Prefix for Shared Address Space This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document. This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice. Updates to the Special-Purpose IP Address Registries This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries. This memo updates RFC 6890. 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. 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. Informative References Special Use IPv4 Addresses This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice. 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. Special-Purpose IP Address Registries This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. 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. 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. Local-Use IPv4/IPv6 Translation Prefix This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. Errata ID 5547: NAT64 Well-Known Prefix SHOULD NOT be used for Private Use IPv4 Addresses n.d. Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers UC3M The IPv6 Company This document specifies a 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 stateful NAT64 translator are shared among several IPv6-Only clients. Stateful NAT64 translation also supports IPv4-initiated communications to a subset of the IPv6 hosts through configured bindings in the stateful NAT64 translator. When the stateful NAT64 translation is used in conjunction with DNS64, no changes are required in either the IPv6 client or the IPv4 server. This document obsoletes RFC 6146.
Erratum 5547 As noted in Erratum 5547 :
IPv4 packets with private destination addresses are routinely translated to IPv4 packets with global destination addresses in NAT44. Similarly, an IPv6 packet with a destination address representing a private IPv4 address can be translated to an IPv4 packet with a global destination > address by NAT64 [RFC6146]. If a 464XLAT CLAT cannot translate a private IPv4 address to an IPv6 address using the NAT64 /96 prefix and that IPv4 address , then the packet may not > be translated to an IPv4 packet with a global address by the 464XLAT PLAT (stateful NAT64). This changes the intent of the sender, and in so doing violates the end to end principle.
Removing the restriction in addresses this errata.
Example Flow To illustrate the updated normative behavior, consider an IPv6-only network utilizing 464XLAT where an administrator want to provide access to an internal, IPv4-only corporate service hosted at 10.1.2.3.
Scenario A: Unmanaged CLAT to Managed PLAT Flow An IPv4-only application on an unmanaged client device generates an IPv4 packet destined for 10.1.2.3. The local CLAT intercepts the IPv4 packet and synthesizes an IPv6 destination address by prepending the WKP per the translation rules defined in : 64:ff9b::10.1.2.3. CLAT Behavior: Under the updated guidance in Section 3, the CLAT must translate this packet by default, ignoring the non-globally reachable nature of the embedded IPv4 address, and forward the resulting IPv6 packet to the network. The IPv6 network forwards the packet to a managed PLAT (NAT64 function). PLAT Behavior: Upon receiving the packet destined for 64:ff9b::10.1.2.3, the PLAT evaluates its local configuration: Permit: If the administrator has explicitly enabled translation for non-globally reachable addresses (or left the default translation behavior enabled), the PLAT translates the packet back to IPv4 and forwards it to 10.1.2.3 if it has a valid route for that address. Drop: If the administrator relies on a default-drop posture for non-globally reachable addresses or has explicitly configured an ACL rule blocking this range, the PLAT drops the packet.
Scenario B: Native IPv6 Host to Managed PLAT An IPv6-capable host (without a local CLAT) needs to communicate with the same internal service. It acquires the destination address 64:ff9b::10.1.2.3 (e.g., via DNS64, local synthesis, or explicit application configuration). The host transmits the IPv6 packet, which is routed to a PLAT. PLAT Behavior: The PLAT applies the same configuration logic as in Scenario A. It translates the packet to IPv4 and forwards it to 10.1.2.3 unless local administrative policy configures it to drop such packet.
Acknowledgments The authors would like to thank Mikael Abrahamsson, Mohamed Boucadair, Nick Buraglio, Lorenzo Colitti, Brian Carpenter, Goetz Goerisch, Wes Hardaker, Suresh Krishnan, Ted Lemon, Jordi Palet, XiPeng Xiao, and Andrew Yourtchenko for their helpful comments and suggestions on this document.