Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 May 2027.¶

Copyright Notice

Copyright (c) 2026 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

The deployment guidance in Section 3.1 of [RFC6052] 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 [RFC1918] or listed in Section 2.2.2 of [RFC6890]. 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 [RFC6147]: 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) [RFC6877] or similar approaches.¶

Enterprise and other closed networks may require IPv6-only nodes to communicate with both internal (e.g., using [RFC1918] addresses) and external (Internet) IPv4-only destinations. The restriction in Section 3.1 of [RFC6052] 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 [I-D.ietf-v6ops-rfc6146-bis] — 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 ([RFC7050], [RFC8781]) provide a method to map a specific NAT64 prefix to the subset of IPv4 addresses for which it should be used.¶

According to Section 3 of [RFC7050], 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) [RFC8215] 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 [RFC1918] and shared addresses [RFC6598] 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 ([RFC1918], [RFC6598]) will improve the utility of the WKP in enterprise networks, in particular.¶

This document updates [RFC6052] to relax a restriction on the use of the WKP (Section 3). Appendix B provides examples to illustrate the updated behavior.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. RFC 6052 Update

This document updates Section 3.1 of [RFC6052] ("Restrictions on the Use of the Well-Known Prefix") as follows. Section 5 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 [RFC1918] or listed in Section 3 of [RFC5735]. 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 [RFC1918] and [RFC6598].¶

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 [RFC1918] and [RFC6598]) 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.¶

4. 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 Section 3.1 of [RFC6052].¶

5. 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 [RFC6052] 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 [RFC6052] SHOULD NOT alter their default dropping behavior. As specified in Section 3, 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.¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Appendix A. Erratum 5547

As noted in Erratum 5547 [EID5547]:¶

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 [RFC6052] 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 [RFC6052], 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 Section 3.1 of [RFC6052] addresses this errata.¶

Appendix B. Example Flow

To illustrate the updated normative behavior, consider an IPv6-only network utilizing 464XLAT [RFC6877] where an administrator want to provide access to an internal, IPv4-only corporate service hosted at 10.1.2.3.¶

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.¶

Authors' Addresses