]> The University of Tokyo/WIDE Project

momoka.my6@gmail.com

Keio University/WIDE Project

yasnyan@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 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 NAT64 to connect to an IPv4-only authoritative server by performing IPv4 to IPv6 translation . 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 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 Over the past decade, IPv6 capabilities have been widely deployed, and IPv6 traffic is growing faster than IPv4 traffic. An overview of IPv6 deployment status and how network operators are implementing IPv6 is provided by the document . Most IPv6 deployments as of 2022 use a dual-stack strategy . However, the deployment of IPv6-only networks is also 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. 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 2022, even some of the most frequently queried authoritative servers cannot be accessed via IPv6. Without the utilization of NAT64, IPv6-only recursive resolvers need to forward queries to a dual-stack recursive name server performing the iterative queries. The current situation where an iterative resolver cannot be operated 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 (and also because the DNS64 may depend on the resolver itself). This problem can be solved by the iterative resolver converting IPv4 addresses to IPv6 by adding the Pref64::/n prefix, which instructs the NAT64 to convert the IPv6 packets to IPv4 packets. With this implementation, an iterative resolver can be operated even inside an IPv6-only network.

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

Finding an Authoritative server with only IPv4 addresses Before the server sends queries, it may sort the SLIST data structure described in to use the servers with IPv6 addresses first and use servers with only an IPv4 address to be used later. If the resolver only finds an A record for the authoritative server, the resolver should perform address synthesis to the IPv4 address of the authoritative server. It is not recommended to synthesize IPv4 addresses 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 NAT64 The iterative resolver can obtain the Pref64::/n used by the NAT64 of the network by either static configuration or by using discovery mechanisms. Static configuration may be the most likely scenario, given that the iterative resolver server may also serve as a DNS64 server. The Port Control Protocol or Router Advertisements are two options the resolver has if it wants to use a discovery mechanism to find the Pref64::/n. Using the mechanisms described in or may not function because these need 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 Since the iterative resolver will be used inside an IPv6-only network, the server can also perform DNS64 when an AAAA record is queried from a STUB resolver but the domain only has an A record.

Deployment Notes TODO

Deployment Scenarios and Examples 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. However, it is necessary to consider the existence of an IPv6 single-stack full-service resolver with DNS64 capabilities.

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, 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 contain IPv4 management to only the NAT64 device.

A network example this document refers to

Security Considerations TODO Security Write about DNSSEC Validators and DNS64. This algorithm does not alter any part of the DNS message but only changes the packet type from IPv4 to IPv6 and the destination IP Address from an IPv4 address to the synthesized IPv6 address, so there shouldn't be any problems with DNSSEC.

IANA Considerations This document has no IANA actions.

Implementation Status TODO: write this part and mail BIND. Bind has an 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 Inside Products The IPv6 Company Verizon Inc. China Telecom This document provides an overview of IPv6 deployment status in early 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 clients. The discovery made via SRV records allows the assignment of priorities to the NAT64 pools and DNS64 servers. It also allows clients 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 specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. [STANDARDS-TRACK] This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications. 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.