]> 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, the same way there is no reason to look for an A record if the host has no IPv4 connectivity. 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.

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)

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

Acknowledgments TODO acknowledge.