]> 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 DNS, operating systems capable of running both IPv4 and IPv6 need to make two queries when resolving a host name. This document discusses conditions, under which the 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 . Source for this draft and an issue tracker can be found at .

Introduction Most operating systems support both IPv6 and 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 IPv4 address, one for a AAAA record representing 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 need to be sent: there is no point of sending out AAAA record query if the host has no IPv6 connectivity or sending out A query if the host has no IPv4 connectivity. Such an optimization however has to consider any possible mean of obtaining connectivity for particular address family: including but not limited to IPv6 Transition Mechanisms or VPNs.

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 algorithm Whenever an application asks the stub resolver to resolve a domain name without specifying address family, stub resolver follows this algorithm for each address family supported by the operating system:

1. Read routing table of the address family.
2. Remove all routes towards Link-Local destinations from the routing table, ie. remove addresses from Section 2.5.6 of for IPv6 routing table and remove addresses from for 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.

It is necessary to consider ANY route towards non Link-Local address space and not just default route and/or default network interface. Such a detection would cause issues with Split-mode VPNs providing only particular routes for the resources reachable via VPN.

Filtering DNS results If the host does not have a 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 applications, since requires applications to try connecting to all addresses received from the stub resolver. However, in order to minimize 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 a 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 fall through the list of addresses to 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 networks, this might overload parts of the DNS infrastructure, since the number of queries doubles.

Security Considerations Reducing the number of queries allows an attacker observing the DNS traffic to figure out which address families the host uses. Sudden disabling of 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] 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 This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. This document is not an Internet Standards Track specification; it is published for informational purposes. n.d.

Acknowledgments TODO acknowledge.