| Internet-Draft | IPv6 only Resolver | March 2023 |
| Yamamoto & Toyota | Expires 10 September 2023 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the IPv6 Operations Working Group mailing list (v6ops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/v6ops/.¶
Source for this draft and an issue tracker can be found at https://github.com/momoka0122y/draft-momoka-ipv6-only-resolver.¶
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 10 September 2023.¶
Copyright (c) 2023 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.¶
This document describes how an IPv6-only iterative resolver can use stateful NAT64 [NAT64] to connect to an IPv4-only authoritative server by performing IPv4 to IPv6 translation [RFC6052] 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.¶
An iterative resolver is one of the applications that require IPv4 connectivity. As stated in BCP91 [RFC3901], “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 [RFC6877] 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.¶
The deployment of IPv6-only networks is in progress, as demonstrated by [draft-xie-v6ops-framework-md-ipv6only-underlay]. 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.¶
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| +-------------+ | Internet |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +------------+ | 192.0.2.1 |
| |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| +--------+ | Internet |
| |-----| Name |----| |
| +-----+ | | server | | +----+ |
| | H1 | | +--------+ | | H2 | |
| |with |---| | | +----+ |
| |DNS64| | +------------+ | 192.0.2.1 |
| +----+ |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
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.¶
+--------------------------+ +----------------------+
| IPv6 network | | IPv4 |
| | | Internet |
| | | | |
| +----------+ | | | +--------------+ |
| |IPv6-only | | | | |Authoritative | |
| |Iterative | | | | |server | |
| |resolver |---| +------------+ | +--------------+ |
| +----------+ |---| IPv6/IPv4 |--| 192.0.2.1 |
| | | Translator | | |
| +------------+ | |
| | | |
+--------------------------+ +----------------------+
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 [NAT64] 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 [RFC3901].¶
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 [RFC7225] or Router Advertisements [RFC8781] 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 [RFC7050] or [draft-hunek-v6ops-nat64-srv] may not work because they require a resolver to work.¶
The address translation can be performed by following Section 2.3 of [RFC6052]. After the synthesis is done, the IPv6-only iterative resolver can send a query to the converted IPv6 address.¶
As the iterative resolver is used within an IPv6-only network, the server can also perform as DNS64 [DNS64] when an AAAA record is queried from a STUB resolver but the domain only has an A record.¶
TODO¶
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.¶
This document has no IANA actions.¶
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¶
TODO: acknowledge people.¶
Thank you for reading this draft.¶