draft-ietf-v6ops-rfc6555bis-01.txt   draft-ietf-v6ops-rfc6555bis-02.txt 
Network D. Schinazi Network D. Schinazi
Internet-Draft T. Pauly Internet-Draft T. Pauly
Obsoletes: 6555 (if approved) Apple Inc. Obsoletes: 6555 (if approved) Apple Inc.
Intended status: Standards Track June 5, 2017 Intended status: Standards Track July 3, 2017
Expires: December 7, 2017 Expires: January 4, 2018
Happy Eyeballs Version 2: Better Connectivity Using Concurrency Happy Eyeballs Version 2: Better Connectivity Using Concurrency
draft-ietf-v6ops-rfc6555bis-01 draft-ietf-v6ops-rfc6555bis-02
Abstract Abstract
Many communication protocols operated over the modern Internet use Many communication protocols operated over the modern Internet use
host names. These often resolve to multiple IP addresses, each of host names. These often resolve to multiple IP addresses, each of
which may have different performance and connectivity which may have different performance and connectivity
characteristics. Since specific addresses or address families (IPv4 characteristics. Since specific addresses or address families (IPv4
or IPv6) may be blocked, broken, or sub-optimal on a network, clients or IPv6) may be blocked, broken, or sub-optimal on a network, clients
that attempt multiple connections in parallel have a higher chance of that attempt multiple connections in parallel have a higher chance of
establishing a connection sooner. This document specifies establishing a connection sooner. This document specifies
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 7, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 8 7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 8
7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 9 7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 9
8. Summary of Configurable Values . . . . . . . . . . . . . . . 10 8. Summary of Configurable Values . . . . . . . . . . . . . . . 10
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 10 9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 10
9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11 9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11
9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 11 9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 13 Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many communication protocols operated over the modern Internet use Many communication protocols operated over the modern Internet use
host names. These often correspond to multiple IP addresses, whose host names. These often resolve to multiple IP addresses, each of
performance can vary. Since specific addresses or address families which may have different performance and connectivity
(IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, characteristics. Since specific addresses or address families (IPv4
clients that attempt multiple connections in parallel have a higher or IPv6) may be blocked, broken, or sub-optimal on a network, clients
chance of establishing a connection sooner. This document specifies that attempt multiple connections in parallel have a higher chance of
establishing a connection sooner. This document specifies
requirements for algorithms that reduce this user-visible delay and requirements for algorithms that reduce this user-visible delay and
provides an algorithm. provides an example algorithm.
This documents expands on "Happy Eyeballs" [RFC6555], a technique of This documents expands on "Happy Eyeballs" [RFC6555], a technique of
reducing user-visible delays on dual-stack hosts. Now that this reducing user-visible delays on dual-stack hosts. Now that this
approach has been deployed at scale and measured for several years, approach has been deployed at scale and measured for several years,
the algorithm specification can be refined to improve its reliability the algorithm specification can be refined to improve its reliability
and generalization. This document recommends an algorithm of racing and generalization. This document recommends an algorithm of racing
resolved addresses that has several stages of ordering and racing to resolved addresses that has several stages of ordering and racing to
avoid delays to the user whenever possible, while preferring the use avoid delays to the user whenever possible, while preferring the use
of IPv6. Specifically, it discusses how to handle DNS queries when of IPv6. Specifically, it discusses how to handle DNS queries when
starting a connection on a dual-stack client, how to create an starting a connection on a dual-stack client, how to create an
skipping to change at page 4, line 22 skipping to change at page 4, line 22
Implementations MUST NOT wait for both families of answers to return Implementations MUST NOT wait for both families of answers to return
before attempting connection establishment. If one query fails to before attempting connection establishment. If one query fails to
return, or takes significantly longer to return, waiting for the return, or takes significantly longer to return, waiting for the
second address family can significantly delay the connection second address family can significantly delay the connection
establishment of the first one. Therefore, the client MUST treat DNS establishment of the first one. Therefore, the client MUST treat DNS
resolution as asynchronous. Note that if the platform does not offer resolution as asynchronous. Note that if the platform does not offer
an asynchronous DNS API, this behavior can be simulated by making two an asynchronous DNS API, this behavior can be simulated by making two
separate synchronous queries on different threads, one per address separate synchronous queries on different threads, one per address
family. If the AAAA query returns first, the first IPv6 connection family. If the AAAA query returns first, the first IPv6 connection
attempt MUST be immediately started. If the A query returns first, attempt MUST be immediately started. If the A query returns first
the client SHOULD wait for a short time for the AAAA response. This due to reordering, the client SHOULD wait for a short time for the
delay will be referred to as the "Resolution Delay". The RECOMMENDED AAAA response to ensure preference is given to IPv6 (it is common for
value for the Resolution Delay is 50 milliseconds. If the AAAA the AAAA response to follow the A response by a few milliseconds).
response is received within the Resolution Delay period, the client This delay will be referred to as the "Resolution Delay". The
MUST immediately start the IPv6 connection attempt. If, at the end RECOMMENDED value for the Resolution Delay is 50 milliseconds. If
of the Resolution Delay period, the AAAA response has not been the AAAA response is received within the Resolution Delay period, the
received but the A response has been received, the client SHOULD client MUST immediately start the IPv6 connection attempt. If, at
the end of the Resolution Delay period, the AAAA response has not
been received but the A response has been received, the client SHOULD
proceed to Sorting Addresses [Section 4] and staggered connection proceed to Sorting Addresses [Section 4] and staggered connection
attempts [Section 5] using only the IPv4 addresses returned so far. attempts [Section 5] using only the IPv4 addresses returned so far.
If the AAAA response arrives while these connection attempts are in If the AAAA response arrives while these connection attempts are in
progress, but before any connection has been established, then the progress, but before any connection has been established, then the
newly received IPv6 addresses are incorporated into the list of newly received IPv6 addresses are incorporated into the list of
available candidate addresses [Section 6] and the process of available candidate addresses [Section 6] and the process of
connection attempts will continue with the IPv6 addresses added, connection attempts will continue with the IPv6 addresses added,
until one connection is established. until one connection is established.
3.1. Handling Multiple DNS Server Addresses 3.1. Handling Multiple DNS Server Addresses
If multiple DNS server addresses are configured for the current If multiple DNS server addresses are configured for the current
network, the client may have the option of sending its DNS queries network, the client may have the option of sending its DNS queries
over IPv4 or IPv6. In keeping with the Happy Eyeballs approach, over IPv4 or IPv6. In keeping with the Happy Eyeballs approach,
queries SHOULD be sent over IPv6 first (note that this is not queries SHOULD be sent over IPv6 first (note that this is not
referring to the sending of AAAA or A queries, but rather the address referring to the sending of AAAA or A queries, but rather the address
of the DNS server itself). If DNS queries sent to the IPv6 address of the DNS server itself and IP version used to transport DNS
do not receive responses, that address may be marked as penalized, messages). If DNS queries sent to the IPv6 address do not receive
and queries can be sent to other DNS server addresses. responses, that address may be marked as penalized, and queries can
be sent to other DNS server addresses.
As native IPv6 deployments become more prevalent, and IPv4 addresses As native IPv6 deployments become more prevalent, and IPv4 addresses
are exhausted, it is expected that IPv6 connectivity will have are exhausted, it is expected that IPv6 connectivity will have
preferential treatment within networks. If a DNS server is preferential treatment within networks. If a DNS server is
configured to be accessible over IPv6, IPv6 should be assumed to be configured to be accessible over IPv6, IPv6 should be assumed to be
the preferred address family. the preferred address family.
Client systems SHOULD NOT have an explicit limit to the number of DNS Client systems SHOULD NOT have an explicit limit to the number of DNS
servers that can be configured, either manually or by the network. servers that can be configured, either manually or by the network.
If such a limit is required by hardware limitations, it is If such a limit is required by hardware limitations, it is
skipping to change at page 7, line 43 skipping to change at page 7, line 43
7. Supporting IPv6-only Networks with NAT64 and DNS64 7. Supporting IPv6-only Networks with NAT64 and DNS64
While many IPv6 transition protocols have been standardized and While many IPv6 transition protocols have been standardized and
deployed, most are transparent to client devices. The combined use deployed, most are transparent to client devices. The combined use
of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is
being deployed and requires changes in client devices. One possible being deployed and requires changes in client devices. One possible
way to handle these networks is for the client device networking way to handle these networks is for the client device networking
stack to implement 464XLAT [RFC6877]. 464XLAT has the advantage of stack to implement 464XLAT [RFC6877]. 464XLAT has the advantage of
not requiring changes to user space software, however it requires not requiring changes to user space software, however it requires
per-packet translation and does not encourage client application per-packet translation if the application is using IPv4 literals and
software to support native IPv6. On platforms that do not support does not encourage client application software to support native
464XLAT, the Happy Eyeballs engine SHOULD follow the recommendations IPv6. On platforms that do not support 464XLAT, the Happy Eyeballs
in this section to properly support IPv6-only networks with NAT64 and engine SHOULD follow the recommendations in this section to properly
DNS64. support IPv6-only networks with NAT64 and DNS64.
The features described in this section SHOULD only be enabled when The features described in this section SHOULD only be enabled when
the host detects one of these networks. A simple heuristic to the host detects one of these networks. A simple heuristic to
achieve that is to check if the networks offers routable IPv6 achieve that is to check if the networks offers routable IPv6
addressing, does not offer routable IPv4 addressing, and offers a DNS addressing, does not offer routable IPv4 addressing, and offers a DNS
resolver address. resolver address.
7.1. IPv4 Address Literals 7.1. IPv4 Address Literals
If client applications or users wish to connect to IPv4 address If client applications or users wish to connect to IPv4 address
 End of changes. 9 change blocks. 
29 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/