]> The University of Tokyo/WIDE Project

momoka.my6@gmail.com

Keio University/WIDE Project

yas-nyan@sfc.wide.ad.jp

Ops v6ops DNS IPv6 This document outlines how IPv6-only iterative resolvers can use stateful NAT64 to establish communications with IPv4-only authoritative servers. It outlines a mechanism for translating the IPv4 addresses of authoritative servers to IPv6 addresses to initiate communications. Through the mechanism of IPv4-to-IPv6 address translation, these resolvers can operate in an IPv6-only network environment. 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 address translation when generating 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 address translation and utilising the stateful NAT64, it will be possible to access an IPv4-only authoritative server. This document is meant to exemplify how existing tools can be used to allow IPv6-only resolvers to reach IPv4-only resolvers. DNS is thus seen as an application that uses NAT64. The document focuses on the exchanges between iterative resolvers and authoritative resolvers but can be generalized to cover communications between IPv6-only recursive resolvers and IPv4-only resolvers.

Terminology

• Iterative resolver: A DNS server that repeatedly makes non-recursive queries and follows referrals and/or aliases, as defined in DNS Terminology
• IPv6-only iterative resolvers: Iterative resolvers with only IPv6 connectivity.
• IPv6/IPv4 translator: A function 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 that either has only IPv4 connectivity or is registered with only an A record, making it accessible solely via 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 an IPv6/IPv4 translation mechanism, 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 utilising NAT64 as an IPv6/IPv4 translation mechanism. The NAT64/DNS64 mechanisms enable IPv6-only clients in an IPv6-only network to communicate with remote IPv4-only nodes. However, applications that rely upon IPv4 address literals instead of DNS names will fail (unless 464XLAT is used). An iterative resolver is a service that uses literal IP addresses, so it cannot use the DNS64. This problem can be solved by the iterative resolver converting IPv4 addresses to IPv6 addresses using the Pref64::/n NAT64 prefix and following the address translation algorithm in . In doing so, an IPv6 packet conveying the query is directed to a stateful NAT64 function 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 functions, operators can optimize IPv4 address 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 are dual-stack name servers.

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

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

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

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

Solution with Existing Protocols This section describes the mechanism of an IPv6-only capable resolver utilising stateful NAT64. We assume that one or more IPv6/IPv4 translators are connecting an IPv6 network to an IPv4 network. The stateful NAT64 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-only servers via stateful NAT64. By using stateful NAT64, this IPv6-only iterative resolver aligns with the dual-stack requirements of BCP91 .

Finding an Authoritative Server with only IPv4 addresses Before initiating a query, an iterative resolver may prioritize authoritative servers with IPv6 addresses by sorting the SLIST data structure, as described in . 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 following the algorithm in . With this the IPv6 packet carrying the query is routed to a stateful NAT64 function, which will convert the IPv6 packet with a destination IPv4-converted IPv6 address that matches the NAT64 prefix to an IPv4 packet. It is not recommended to synthesize IPv4 addresses of an authoritative server if it also has an IPv6 address.

Generating IPv4-converted IPv6 Addresses

Obtaining the Pref64::/n of a NAT64 The iterative resolver can obtain the Pref64::/n used by the network's stateful NAT64 either by static configuration or by using a discovery mechanism. 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 does not work because they require a resolver to work.

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

Security Considerations The use of NAT64 for address translation does not affect DNSSEC operations as no part of the DNS message is altered.

IANA Considerations This document has no IANA actions.

Implementation Status BIND has a work-in-progress branch available at: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6334/commits Unbound has an implementation in source, available from below PR: https://github.com/NLnetLabs/unbound/pull/722 Building from source or using a version after Version 1.19 will allow to use this function.

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. Informative References Huawei Technologies Huawei Technologies The IPv6 Company Verizon Inc. China Telecom This document provides an overview of the status of IPv6 deployment 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 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 allows providing the NAT64/DNS64 services 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. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. 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. 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] 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 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.