NAT64 WKP

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 6 May 2026.¶

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

Section 3.1 of [RFC6052] prohibits IPv4/IPv6 translators from using the Well-Known Prefix (WKP, 64:FF9B::/96) to represent non-global IPv4 addresses, such as those defined in [RFC1918] or listed in Section 3 of [RFC5735].¶

This restriction is relatively straightforward to implement in DNS64 [RFC6147]: a DNS64 server simply avoids synthesizing an AAAA record using the WKP if the original A record contains a non-global IPv4 address. However, this requirement introduces significant operational challenges for systems that do not rely on DNS64 and instead use local synthesis such as CLAT (Customer-side Translator, [RFC6877]), or similar approaches.¶

Enterprise and other closed networks often 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.¶

Using two NAT64 prefixes — the WKP for Internet destinations and a Network-Specific Prefix (NSP) for non-global 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 a 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 the NSP, it will use both prefixes to represent global IPv4 addresses. This duplication significantly complicates security policies, troubleshooting, and other operational aspects of the network.¶

Prohibiting the WKP from representing non-global IPv4 addresses offers no substantial benefit to IPv6-only or IPv6-mostly deployments. Simultaneously, it 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 all IPv4 addresses, regardless of their global or non-global status. This simplification would greatly improve the utility of the WKP in enterprise networks.¶

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. RFC6052 Update

This document updates Section 3.1 of [RFC6052] ("Restrictions on the Use of the Well-Known Prefix") as follows:¶

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 defined in [RFC1918] or listed in Section 3 of [RFC5735]. Address translators MUST translate packets in which an address is composed of the Well-Known Prefix and a non- global IPv4 address; they MUST NOT drop these packets.¶

===¶

4. Operational Considerations

5. Security Considerations

TODO Security¶

6. IANA Considerations

This document has no IANA actions.¶

7. References

Acknowledgments

The authors would like to thank .... for their helpful comments and suggestions on this document.¶

Authors' Addresses