]> RIPE NCC

ondrej@caletka.cz

OPS IPv6 operations IPv6 DNS Address records Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the v6ops Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Most operating systems support both the IPv6 and the IPv4 networking stack. When such a host is connected to a dual-stack network, whenever a process requests resolution of a DNS name, two DNS queries need to be issued - one for an A record representing an IPv4 address, and one for a AAAA record representing an IPv6 address. The results of such queries are then merged and ordered based on or used as input for the Happy Eyeballs algorithm . When such a host is connected to a single-stack network, only one DNS query needs to be performed: there is no reason for querying for a AAAA record if the host has no IPv6 connectivity. Similarly if the host does not have any IPv4 connectivity, neither native nor provided by some other mechanism like NAT64 , querying for an A record is useless. Such an optimization however has to consider any possible means of obtaining connectivity for a particular address family, including but not limited to IPv6 Transition Mechanisms or VPNs. Please note that Multicast DNS or similar link-local name resolution protocols are not considered in scope of this document.

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 when, and only when, they appear in all capitals, as shown here.

Problem statement Traditional DNS resolution uses UDP messages, capable of carrying only either A query and response containing IPv4 addresses or AAAA query and response containing IPv6 addresses. A simple dual-stack capable host has to wait until both queries are finished before it can sort the results and start establishing the connection. If the network suffers from packet loss, finishing these two DNS queries can cause delays noticeable by users. Not resolving addresses for the address family the host is not connected to can thus mitigate impact of slow DNS resolution without compromising functionality. Combining A and AAAA queries into a single DNS query mitigates the issue as well, however this depends on particular resolver supporting this feature.

Connectivity detection algorithms Whenever an application asks the stub resolver to resolve a domain name without specifying the address family, the stub resolver follows one of the algorithms specified below:

Routing table based algorithm This algorithm assumes that the host has connectivity of particular address family if there is at least one route to a destination that is not in Link-Local address space. If there are only routes for destinations in the Link-Local address space, the host is not able to send any packets towards any destination address that could be possibly obtained from the DNS. Therefore, sending an address query for that particular address family is unnecessary. For each address family supported by the operating system:

1. Read the routing table of the address family;
2. Remove all the routes towards Link-Local destinations from the routing table, ie.:
   • remove routes towards addresses from Section 2.5.6 of from the IPv6 routing table
   • remove routes towards addresses from from the IPv4 routing table
3. If the routing table is not empty, send the corresponding name query to the DNS:
   • AAAA query for IPv6
   • A query for IPv4

IP address based algorithm As an alternative to analyzing the routing tables, the stub resolver might choose to determine the connectivity by looking at the addresses configured on all network interfaces. This is similar to an application using the flag AI_ADDRCONFIG when interacting with the stub resolver using getaddrinfo() function . For each address family supported by the operating system:

1. Collect all addresses configured on all interfaces
2. Remove all Link-Local addresses from the list, ie.:
   • remove addresses from Section 2.5.6 of from the list of IPv6 addresses
   • remove addresses from from the list of IPv4 addresses
3. If the list of addresses is not empty, send the corresponding name query to the DNS:
   • AAAA query for IPv6
   • A query for IPv4

Connectivity detection considerations When detecting the connectivity presence, it is necessary to consider ANY routes towards non Link-Local address space and/or IP addresses on ALL interfaces and not just the default route and/or just the default network interface. The implementations SHOULD NOT try to determine connectivity by hardcoding a particular publicly reachable IP address . Improper detection can cause issues for:

• private networks without reachability to the Internet
• VPN tunnels using different address family than the native address family of the host, providing possibly only a limited subset of routes (split-mode VPN)

IPv4 connectivity provided by NAT64 Even if the host has no routes towards IPv4 address space and/or no IPv4 addresses on interfaces, it can still have IPv4 connectivity provided by some transition mechanism. In case of NAT64 , this leads to three possible scenarios:

1. 464XLAT is used. In this case the host has a default route towards the CLAT translator, so the A queries are not suppressed. This would be also the case for any other transition mechanism providing IPv4 as a service over IPv6 bearer.
2. Only DNS64 is used. In this case, it is correct not to do A queries because the host cannot send any native IPv4 packets.
3. The host supports converting IPv4 API calls into IPv6 API calls similarly to Bump-in-the-Host API translator alternative. In this case, such a translator can utilize A queries even if the host cannot send any native IPv4 packets. Therefore such an API translator or a high level library like SHOULD NOT suppress A queries if it is aware of the presence of NAT64 in the network.

Filtering DNS results If the host does not have full connectivity for both address families (there are no default gateways for both IPv4 and IPv6), it is possible that the IP(v6) address obtained from the DNS falls into the address space not covered by a route. This should not be problem for a properly written application, since requires applications to try connecting to all addresses received from the stub resolver. However, in order to minimize the impact on poorly designed applications, the stub resolver MAY remove addresses not covered by an entry in the routing table from the list of DNS query results sent to the application.

Filtering IPv4-mapped addresses As an extension to the filtering of DNS results, the stub resolver MAY also remove IPv4-mapped IPv6 addresses (Section 2.5.5.2 of ) from the list of DNS query results sent to the application. IPv4-mapped IPv6 addresses are not valid destination addresses , therefore they should never appear in AAAA records. Sending IPv4-mapped IPv6 address to the application might cause address family confusion for applications using IPv4 compatibility of IPv6 sockets .

Effects of not doing address record filtering The optimization described above is OPTIONAL. A stub resolver of a dual-stack capable host can always issue both A and AAAA queries to the DNS, merge and order the results and send them to the application even if it has only single-stack connectivity. Sending packets to a destination not covered by an entry in the routing table will be immediately refused, so a properly written application will quickly iterate through the list of addresses and finally select the one using the same address family as the connectivity of the host. However, it should be noted that such behavior is not only less robust against DNS resolution delays but also increases load on the DNS system. If such an optimization is removed (for instance by a software update) on a large single-stack network, this might overload parts of the DNS infrastructure, since the number of queries will double.

Security Considerations Reducing the number of queries allows an attacker observing the DNS traffic to figure out which address families the host uses. Suddendly disabling the optimization can overload parts of the DNS infrastructure due to doubling the number of queries.

IANA Considerations This document has no IANA actions.

References Normative References The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community. To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. n.d. n.d. This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. 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] Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK] 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. Apple Inc Google LLC Google LLC Google LLC Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document updates the algorithm description in RFC 8305. Internet Systems Consortium, Inc. This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS QUERY (OpCode=0).

Acknowledgments The author would like to thank these people for feedback and comments: Massimiliano Stucchi, Nick Buraglio, Jen Linkova, Gert Doering, Philip Homburg, Lorenzo Colitti