]> The University of Tokyo/WIDE Project

momoka.my6@gmail.com

Keio University/WIDE Project

yas-nyan@sfc.wide.ad.jp

Ops v6ops DNS IPv6 By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers can operate in an IPv6-only environment. When a specific DNS zone is only served by an IPv4-only authoritative server, the iterative resolver will translate the IPv4 address to IPv6 to access the authoritative server's IPv4 address via stateful NAT64. This mechanism allows IPv6-only iterative resolvers to initiate communications to IPv4-only authoritative servers. Discussion Venues Discussion of this document takes place on the IPv6 Operations Working Group mailing list (v6ops@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document describes how an IPv6-only iterative resolver can use stateful NAT64 to connect to an IPv4-only authoritative server by performing IPv4 to IPv6 translation when sending a query. When a specific DNS zone is only served by an IPv4-only authoritative server (which has only an A record), an IPv6-only iterative resolver cannot resolve that zone due to having no access to an IPv4 network. However, by performing IPv4 to IPv6 translation and utilizing the stateful NAT64, accessing an IPv4-only authoritative server will be possible.

Terminology

• Iterative resolver: A DNS server that repeatedly makes non-recursive queries and follows referrals and/or aliases. The iterative resolution algorithm is described in Section 5.3.3 of
• IPv6-only iterative resolvers: Iterative resolvers that only have IPv6 connectivity.
• IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 packets and vice versa. It is only required that the communication initiated from the IPv6 side be supported.
• IPv4-only authoritative server: An authoritative server with only IPv4 connectivity, or an authoritative server with only an A record registered so it can only be accessed by IPv4.

Motivation and Problem Solved An iterative resolver is one of the applications that require IPv4 connectivity. As stated in BCP91 , “every recursive name server SHOULD be either IPv4-only or dual stack.” This is because some authoritative servers do not support IPv6. As of 2023, even some of the most frequently queried authoritative servers cannot be accessed via IPv6. Without the utilization of NAT64, IPv6-only resolvers need to forward queries to a dual-stack recursive name server performing the iterative queries. The current situation where an iterative resolver cannot operate without IPv4 reachability may hinder the operation of a network's own iterative resolver in an IPv6-only network. Therefore, this document describes how iterative resolvers can be used without issues in IPv6-only networks by utilizing NAT64. The NAT64/DNS64 mechanism enables IPv6-only clients in a network to communicate with remote IPv4-only nodes. However, using literal IPv4 addresses instead of DNS names will fail (unless 464XLAT is used). An iterative resolver cannot use the DNS64 because it is a service that uses literal IP addresses. This problem can be solved by the iterative resolver converting IPv4 addresses to IPv6 by adding the Pref64::/n prefix, and thus the IPv6 packet conveying the query is directed to a stateful NAT64 gateway that converts the IPv6 packet to an IPv4 packet. With this implementation, an iterative resolver can be operated even inside an IPv6-only network.

Deployment Scenarios and Examples The deployment of IPv6-only networks is in progress, as demonstrated by . By operating an IPv6-only network and limiting IPv4 reachability to NAT64 devices, operators can reduce IPv4 usage and concentrate on IPv6 operations, which is generally believed to lower operational costs and optimize operations compared to a dual-stack environment. In examples of past RFCs, name resolvers have always had an IPv4 address. For example, all three use cases for DNS64 in RFC 6147 are dual-stack name servers.

Example network setup of the use of DNS64 described in RFC6147 Section7.1

Example network setup of the use of DNS64 described in RFC6147 Section7.2

However, it is necessary to consider the existence of an IPv6 single-stack full-service resolver. In this document we consider an IPv6-only network where the iterative resolver is inside the IPv6-only network and does not have an IPv4 address. This is to restrict IPv4 management to the NAT64 device.

Network example referenced in this document with an IPv6-only iterative resolver

Solution with existing protocols This section provides the mechanism of an IPv6-only capable resolver utilizing stateful NAT64. We will assume we have one or more IPv6/IPv4 translator boxes connecting an IPv6 network to an IPv4 network. The stateful NAT64 device provides translation service and bridges the two networks, allowing communication between IPv6-only hosts and IPv4-only hosts. The IPv6-only capable resolver proposed in this document performs the IPv4 to IPv6 synthesis for the resolver to communicate with IPv4 servers via stateful NAT64. By using stateful NAT64, this IPv6-only iterative resolver can be considered dual stack in the sense of BCP91 .

Finding an Authoritative server with only IPv4 addresses Before the iterative resolver sends queries to start a resolution, it may sort the SLIST data structure described in to use the authoritative servers with IPv6 addresses first, and use servers with only an IPv4 address later. If the resolver finds only an A record for an authoritative server, the resolver should perform address synthesis to the IPv4 address of the authoritative server, converting IPv4 addresses to IPv6 by adding the prefix Pref64::/n, so that the IPv6 packet carrying the query is routed to a stateful NAT64 gateway, which converts the IPv6 packet to an IPv4 packet. It is not recommended to synthesise an IPv4 address of an authoritative server if it also has an IPv6 address.

Generation of the IPv6 Representations of IPv4 Addresses

Obtaining the Pref64::/n of the stateful NAT64 The iterative resolver can obtain the Pref64::/n used by the network's stateful NAT64 either by static configuration or by using discovery mechanisms. Static configuration may be the most likely scenario, as the iterative resolver server may also serve as a DNS64 server. The Port Control Protocol or Router Advertisements are two options available to the resolver if it wishes to use a discovery mechanism to find the Pref64::/n. Using the mechanisms described in or may not work because they require a resolver to work.

Performing the Synthesis The address translation can be performed by following Section 2.3 of . After the synthesis is done, the IPv6-only iterative resolver can send a query to the converted IPv6 address.

Use of the iterative resolver as DNS64 As the iterative resolver is used within an IPv6-only network, the server can also perform as DNS64 when an AAAA record is queried from a STUB resolver but the domain only has an A record.

Deployment Notes TODO

Security Considerations This algorithm does not change any part of the DNS message, just the packet type from IPv4 to IPv6 and the destination IP address from an IPv4 address to the synthesised IPv6 address, so there should be no problems with DNSSEC.

IANA Considerations This document has no IANA actions.

Implementation Status BIND has a WIP branch. https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6334/commits Unbound has a PR from a contributor. https://github.com/NLnetLabs/unbound/issues/721

References Normative References 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] This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] Informative References Huawei Technologies Huawei Technologies The IPv6 Company Verizon Inc. China Telecom This document provides an overview of IPv6 deployment status in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036. Technical University of Liberec This document specifies how to discover the NAT64 pools in use and DNS servers providing DNS64 service to the local Nodes. The discovery made via SRV records allows the assignment of priorities to the NAT64 pools and DNS64 servers. It also allows Nodes to have different DNS providers than NAT64 providers while providing a secure way via DNSSEC validation of provided SRV records. This way, it provides DNS64 service regardless of DNS operator and DNS transport protocol. China Telecom China Telecom CERNET Center/Tsinghua University Verizon Inc Orange Swisscom For the IPv6 transition, dual-stack deployments require both IPv4 and IPv6 forwarding capabilities to be deployed in parallel. IPv6-only is considered as the ultimate stage where only IPv6 transfer capabilities are used while ensuring global reachability for both IPv6 and IPv4 (usually known as IPv4aaS). This document specifies requirements and proposes a framework for deploying IPv6-only as the underlay in multi-domain networks, discusses the requirements of service traffic, major components and interfaces, IPv6 mapping prefix allocation, typical procedures for service delivery. The document also discusses related considerations with security. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. 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. 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. 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. 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.

Acknowledgments TODO: acknowledge people. Thank you for reading this draft.