draft-ietf-v6ops-rfc6555bis-00.txt   draft-ietf-v6ops-rfc6555bis-01.txt 
Network T. Pauly Network D. Schinazi
Internet-Draft D. Schinazi Internet-Draft T. Pauly
Obsoletes: 6555 (if approved) Apple Inc. Obsoletes: 6555 (if approved) Apple Inc.
Intended status: Standards Track April 8, 2017 Intended status: Standards Track June 5, 2017
Expires: October 10, 2017 Expires: December 7, 2017
Happy Eyeballs Version 2: Better Connectivity Using Concurrency Happy Eyeballs Version 2: Better Connectivity Using Concurrency
draft-ietf-v6ops-rfc6555bis-00 draft-ietf-v6ops-rfc6555bis-01
Abstract Abstract
Many communication protocols operated over the modern Internet uses 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
requirements for algorithms that reduce this user-visible delay and requirements for algorithms that reduce this user-visible delay and
provides an example algorithm. provides an example algorithm.
Status of This Memo Status of This Memo
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 October 10, 2017. This Internet-Draft will expire on December 7, 2017.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Hostname Resolution Query Handling . . . . . . . . . . . . . 3 3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4
3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 4 3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 4
4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 4 4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 5
5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 5 5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 6
6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 6 6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 7
7. Summary of Configurable Values . . . . . . . . . . . . . . . 6 7. Supporting IPv6-only Networks with NAT64 and DNS64 . . . . . 7
8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8
8.1. Path Maximum Transmission Unit Discovery . . . . . . . . 7 7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 8
8.2. Application Layer . . . . . . . . . . . . . . . . . . . . 7 7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 9
8.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 8 8. Summary of Configurable Values . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 9 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many communication protocols operated over the modern Internet uses Many communication protocols operated over the modern Internet use
host names. These often correspond to multiple IP addresses, whose host names. These often correspond to multiple IP addresses, whose
performance can vary. Since specific addresses or address families performance can vary. Since specific addresses or address families
(IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network,
clients that attempt multiple connections in parallel have a higher clients that attempt multiple connections in parallel have a higher
chance of establishing a connection sooner. This document specifies 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 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
skipping to change at page 3, line 14 skipping to change at page 3, line 33
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
ordered list of addresses to which to attempt connections, and how to ordered list of addresses to which to attempt connections, and how to
race the connection attempts. race the connection attempts.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" RFC 2119 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
[RFC2119].
2. Overview 2. Overview
This document defines a method of connection establishment, defined This document defines a method of connection establishment, named
as "Happy Eyeballs Connection Setup". This approach has several "Happy Eyeballs Connection Setup". This approach has several
distinct phases: distinct phases:
1. Initiation of asynchronous DNS queries [Section 3] 1. Initiation of asynchronous DNS queries [Section 3]
2. Sorting of resolved addresses [Section 4] 2. Sorting of resolved addresses [Section 4]
3. Initiation of asynchronous connection attempts [Section 5] 3. Initiation of asynchronous connection attempts [Section 5]
4. Establishment of one connection, which cancels all other attempts 4. Establishment of one connection, which cancels all other attempts
skipping to change at page 3, line 48 skipping to change at page 4, line 18
establish a connection with a named host, it needs to send out both establish a connection with a named host, it needs to send out both
AAAA and A DNS queries. Both queries SHOULD be made as soon after AAAA and A DNS queries. Both queries SHOULD be made as soon after
one another as possible, with the AAAA query made first, immediately one another as possible, with the AAAA query made first, immediately
followed by the A query. followed by the A query.
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 platforms does not resolution as asynchronous. Note that if the platform does not offer
offer an asynchronous DNS API, this behavior can be simulated by an asynchronous DNS API, this behavior can be simulated by making two
making two separate synchronous queries on different threads, one per separate synchronous queries on different threads, one per address
address family. If the AAAA query returns first, the first IPv6 family. If the AAAA query returns first, the first IPv6 connection
connection attempt MUST be immediately started. If the A query attempt MUST be immediately started. If the A query returns first,
returns first, the client SHOULD wait for a short time for the AAAA the client SHOULD wait for a short time for the AAAA response. This
response. This delay will be referred to as the "Resolution Delay". delay will be referred to as the "Resolution Delay". The RECOMMENDED
The RECOMMENDED value for the Resolution Delay is 50 milliseconds. value for the Resolution Delay is 50 milliseconds. If the AAAA
If the AAAA response is received within the Resolution Delay period, response is received within the Resolution Delay period, the client
the client MUST immediately start the IPv6 connection attempt. If, MUST immediately start the IPv6 connection attempt. If, at the end
at the end of the Resolution Delay period, the AAAA response has not of the Resolution Delay period, the AAAA response has not been
been received but the A response has been received, the client SHOULD 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
skipping to change at page 5, line 17 skipping to change at page 5, line 37
First, the client MUST sort the addresses using Destination Address First, the client MUST sort the addresses using Destination Address
Selection ([RFC6724], Section 6). Selection ([RFC6724], Section 6).
If the client is stateful and has history of expected round-trip If the client is stateful and has history of expected round-trip
times (RTT) for the routes to access each address, it SHOULD add a times (RTT) for the routes to access each address, it SHOULD add a
Destination Address Selection rule between rules 8 and 9 that prefers Destination Address Selection rule between rules 8 and 9 that prefers
addresses with lower RTTs. If the client keeps track of which addresses with lower RTTs. If the client keeps track of which
addresses it has used in the past, it SHOULD add another destination addresses it has used in the past, it SHOULD add another destination
address selection rule between the RTT rule and rule 9, which prefers address selection rule between the RTT rule and rule 9, which prefers
used addresses over unused ones. This helps servers that use the used addresses over unused ones. This helps servers that use the
client's IP address for authentication, as is the case for TCP Fast client's IP address during authentication, as is the case for TCP
Open ([RFC7413]) and some HTTP cookies. This historical data MUST Fast Open ([RFC7413]) and some HTTP cookies. This historical data
NOT be used across networks, and SHOULD be flushed on network MUST NOT be used across networks, and SHOULD be flushed on network
changes. changes.
Next, the client SHOULD modify the ordered list to interleave address Next, the client SHOULD modify the ordered list to interleave address
families. Whichever address family is first in the list should be families. Whichever address family is first in the list should be
followed by an address of the other address family; that is, if the followed by an address of the other address family; that is, if the
first address in the sorted list is IPv6, then the first IPv4 address first address in the sorted list is IPv6, then the first IPv4 address
should be moved up in the list to be second in the list. An should be moved up in the list to be second in the list. An
implementation MAY want to favor one address family more by allowing implementation MAY want to favor one address family more by allowing
multiple addresses of that family to be attempted before trying the multiple addresses of that family to be attempted before trying the
other family. The number of contiguous addresses of the first other family. The number of contiguous addresses of the first
address family will be referred to as the "First Address Family address family will be referred to as the "First Address Family
Count", and can be a configurable value. Count", and can be a configurable value. This is performed to avoid
waiting through a long list of addresses from a given address family
if connectivity over that address family is impaired.
5. Connection Attempts 5. Connection Attempts
Once the list of addresses has been constructed, the client will Once the list of addresses has been constructed, the client will
attempt to make connections. In order to avoid unreasonable network attempt to make connections. In order to avoid unreasonable network
load, connection attempts SHOULD NOT be made simultaneously. load, connection attempts SHOULD NOT be made simultaneously.
Instead, one connection attempt to a single address is started first, Instead, one connection attempt to a single address is started first,
followed by the others in the list, one at a time. Starting a new followed by the others in the list, one at a time. Starting a new
connection attempt does not affect previous attempts, as multiple connection attempt does not affect previous attempts, as multiple
connection attempts may occur in parallel. Once one of the connection attempts may occur in parallel. Once one of the
skipping to change at page 6, line 21 skipping to change at page 7, line 10
previous is sending its second TCP SYN. While TCP implementations previous is sending its second TCP SYN. While TCP implementations
often leverage an exponential backoff when they detect packet loss, often leverage an exponential backoff when they detect packet loss,
the "Connection Attempt Delay" SHOULD NOT such an aggressive backoff, the "Connection Attempt Delay" SHOULD NOT such an aggressive backoff,
as it would harm user experience. as it would harm user experience.
The Connection Attempt Delay MUST have a lower bound, especially if The Connection Attempt Delay MUST have a lower bound, especially if
it is computed using historical data. More specifically, a it is computed using historical data. More specifically, a
subsequent connection MUST NOT be started within 10 milliseconds of subsequent connection MUST NOT be started within 10 milliseconds of
the previous attempt. The recommended minimum value is 100 the previous attempt. The recommended minimum value is 100
milliseconds, which is referred to as the "Minimum Connection Attempt milliseconds, which is referred to as the "Minimum Connection Attempt
Delay". This minimum value is required to avoid congestive collapse Delay". This minimum value is required to avoid congestion collapse
in the presence of high packet loss rates. The Connection Attempt in the presence of high packet loss rates. The Connection Attempt
Delay SHOULD have an upper bound, referred to as the "Maximum Delay SHOULD have an upper bound, referred to as the "Maximum
Connection Attempt Delay". The current recommended value is 2 Connection Attempt Delay". The current recommended value is 2
seconds. seconds.
6. DNS Answer Changes during Happy Eyeballs Connection Setup 6. DNS Answer Changes during Happy Eyeballs Connection Setup
If, during the course of connection establishment, the DNS answers If, during the course of connection establishment, the DNS answers
change either by adding resolved addresses (for example, due to DNS change either by adding resolved addresses (for example, due to DNS
push notifications [DNS-PUSH]), or removing previously resolved push notifications [DNS-PUSH]), or removing previously resolved
skipping to change at page 6, line 45 skipping to change at page 7, line 34
If an address is removed from the list that already had a connection If an address is removed from the list that already had a connection
attempt started, the connection attempt SHOULD NOT be cancelled, but attempt started, the connection attempt SHOULD NOT be cancelled, but
rather be allowed to continue. If the removed address had not yet rather be allowed to continue. If the removed address had not yet
had a connection attempt started, it SHOULD be removed from the list had a connection attempt started, it SHOULD be removed from the list
of addresses to try. of addresses to try.
If an address is added to the list, it should be sorted into the list If an address is added to the list, it should be sorted into the list
of addresses not yet attempted according to the rules above of addresses not yet attempted according to the rules above
(Section 4). (Section 4).
7. Summary of Configurable Values 7. Supporting IPv6-only Networks with NAT64 and DNS64
While many IPv6 transition protocols have been standardized and
deployed, most are transparent to client devices. The combined use
of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is
being deployed and requires changes in client devices. One possible
way to handle these networks is for the client device networking
stack to implement 464XLAT [RFC6877]. 464XLAT has the advantage of
not requiring changes to user space software, however it requires
per-packet translation and does not encourage client application
software to support native IPv6. On platforms that do not support
464XLAT, the Happy Eyeballs engine SHOULD follow the recommendations
in this section to properly support IPv6-only networks with NAT64 and
DNS64.
The features described in this section SHOULD only be enabled when
the host detects one of these networks. A simple heuristic to
achieve that is to check if the networks offers routable IPv6
addressing, does not offer routable IPv4 addressing, and offers a DNS
resolver address.
7.1. IPv4 Address Literals
If client applications or users wish to connect to IPv4 address
literals, the Happy Eyeballs engine will need to perform NAT64
address synthesis for them. The solution is similar to "Bump-in-the-
Host" [RFC6535] but is implemented inside the Happy Eyeballs library.
When an IPv4 address is passed in to the library instead of a host
name, the device queries the network for the NAT64 prefix using
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
[RFC7050] then synthesizes an appropriate IPv6 address (or several)
using the encoding described in "IPv6 Addressing of IPv4/IPv6
Translators" [RFC6052]. The synthesized addresses are then inserted
into the list of addresses as if they were results from DNS queries;
connection attempts follow the algorithm described above (Section 5).
7.2. Host Names with Broken AAAA Records
At the time of writing, there exist a small but non negligible number
of host names that resolve to valid A records and broken AAAA
records, which we define as AAAA records that contain seemingly valid
IPv6 addresses but those addresses never reply when contacted on the
usual ports. These can be for example caused by:
o Mistyping of the IPv6 address in the DNS zone configuration
o Routing black holes
o Service outages
While an algorithm complying with the other sections of this document
would correctly handle such host names on a dual-stack network, they
will not necessarily function correctly on IPv6-only networks with
NAT64 and DNS64. Since DNS64 recursive resolvers rely on the
authoritative name servers sending negative ("no error no answer")
responses for AAAA records in order to synthesize, they will not
synthesize records for these particular host names, and will instead
pass through the broken AAAA record.
In order to support these scenarios, the client device needs to query
the DNS for the A record then perform local synthesis. Since these
types of host names are rare, and in order to minimize load on DNS
servers, this A query should only be performed when the client has
given up on the AAAA records it initially received. This can be
achieved by using a longer timeout, referred to as the "Last Resort
Local Synthesis Delay" and RECOMMENDED at 2 seconds. The timer is
started when the last connection attempt is fired. If no connection
attempt has succeeded when this timer fires, the device queries the
DNS for the IPv4 address and on reception of a valid A record, treats
it as if it were provided by the application (Section 7.1).
7.3. Virtual Private Networks
Some Virtual Private Networks (VPN) may be configured to handle DNS
queries from the device. The configuration could encompass all
queries, or a subset such as "*.internal.example.com". These VPNs
can also be configured to only route part of the IPv4 address space,
such as 192.0.2.0/24. However, if an internal hostname resolves to
an external IPv4 address, these can cause issues if the underlying
network is IPv6-only. As an example, let's assume that
"www.internal.example.com" has exactly one A record, 198.51.100.42,
and no AAAA records. The client will send the DNS query to the
company's recursive resolver and that resolver will reply with these
records. The device now only has an IPv4 address to connect to, and
no route to that address. Since the company's resolver does not know
the NAT64 prefix of the underlying network, it cannot synthesize the
address. Similarly, the underlying network's DNS64 recursive
resolver does not know the company's internal addresses, so it cannot
resolve the hostname. Because of this, the client device needs to
resolve the A record using the company's resolver then locally
synthesize an IPv6 address, as if the resolved IPv4 address were
provided by the application (Section 7.1).
8. Summary of Configurable Values
The values that may be configured as defaults on a client for use in The values that may be configured as defaults on a client for use in
Happy Eyeballs are as follows: Happy Eyeballs are as follows:
o Resolution Delay (Section 3): The time to wait for a AAAA response o Resolution Delay (Section 3): The time to wait for a AAAA response
after receiving an A response. RECOMMENDED at 50 milliseconds. after receiving an A response. RECOMMENDED at 50 milliseconds.
o First Address Family Count (Section 4): The number of addresses o First Address Family Count (Section 4): The number of addresses
belonging to the first address family (such as IPv6) that should belonging to the first address family (such as IPv6) that should
be attempted before attempting another address family. be attempted before attempting another address family.
skipping to change at page 7, line 22 skipping to change at page 10, line 30
connection attempts in the absence of RTT data. RECOMMENDED at connection attempts in the absence of RTT data. RECOMMENDED at
250 milliseconds. 250 milliseconds.
o Minimum Connection Attempt Delay (Section 5): The minimum time to o Minimum Connection Attempt Delay (Section 5): The minimum time to
wait between connection attempts. RECOMMENDED at 100 wait between connection attempts. RECOMMENDED at 100
milliseconds. MUST NOT be less than 10 milliseconds. milliseconds. MUST NOT be less than 10 milliseconds.
o Maximum Connection Attempt Delay (Section 5): The maximum time to o Maximum Connection Attempt Delay (Section 5): The maximum time to
wait between connection attempts. RECOMMENDED at 2 seconds. wait between connection attempts. RECOMMENDED at 2 seconds.
o Last Resort Local Synthesis Delay (Section 7.2): The time to wait
after starting the last IPv6 attempt and before sending the A
query. RECOMMENDED at 2 seconds.
As time advances, it is expected that the properties of networks will As time advances, it is expected that the properties of networks will
evolve. For that reason, it is expected that these values will evolve. For that reason, it is expected that these values will
change over time. Implementors should feel welcome to use different change over time. Implementors should feel welcome to use different
values without changing this specification. In particular, IPv6 values without changing this specification. In particular, IPv6
issues are expected to be less common, therefore the Resolution Delay issues are expected to be less common, therefore the Resolution Delay
SHOULD be increased with time as client software is updated. SHOULD be increased with time as client software is updated.
8. Limitations 9. Limitations
Happy Eyeballs will handle initial connection failures at the TCP/IP Happy Eyeballs will handle initial connection failures at the TCP/IP
layer, however other failures or performance issues may still affect layer, however other failures or performance issues may still affect
the chosen connection. the chosen connection.
8.1. Path Maximum Transmission Unit Discovery 9.1. Path Maximum Transmission Unit Discovery
Since Happy Eyeballs is only active during the initial handshake and Since Happy Eyeballs is only active during the initial handshake and
TCP does not pas the initial handshake, issues related to MTU can be TCP does not pass the initial handshake, issues related to MTU can be
masked and go unnoticed during Happy Eyeballs. Solving this issue is masked and go unnoticed during Happy Eyeballs. Solving this issue is
out of scope of this document. out of scope of this document.
8.2. Application Layer 9.2. Application Layer
If the DNS returns multiple application servers for a given service, If the DNS returns multiple addresses for different application
the application itself may not be operational and functional on all servers, the application itself may not be operational and functional
of them. Common examples include Transport Layer Security (TLS) and on all of them. Common examples include Transport Layer Security
the Hypertext Transport Protocol (HTTP). (TLS) and the Hypertext Transport Protocol (HTTP).
8.3. Hiding Operational Issues 9.3. Hiding Operational Issues
It has been observed in practice that Happy Eyeballs can hide issues It has been observed in practice that Happy Eyeballs can hide issues
in networks. For example, if a misconfiguration causes IPv6 to in networks. For example, if a misconfiguration causes IPv6 to
consistently fail on a given network while IPv4 is still functional, consistently fail on a given network while IPv4 is still functional,
Happy Eyeballs may impair the operator's ability to notice the issue. Happy Eyeballs may impair the operator's ability to notice the issue.
It is recommended that network operators deploy external means of It is recommended that network operators deploy external means of
monitoring to ensure functionality of all address families. monitoring to ensure functionality of all address families.
9. Security Considerations 10. Security Considerations
This memo has no direct security considerations. This memo has no direct security considerations.
10. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgments 12. Acknowledgments
The authors thank Dan Wing, Andrew Yourtchenko, and everyone else who The authors thank Dan Wing, Andrew Yourtchenko, and everyone else who
worked on the original Happy Eyeballs design ([RFC6555]), Josh worked on the original Happy Eyeballs design ([RFC6555]), Josh
Graessley, Stuart Cheshire, and the rest of team at Apple that helped Graessley, Stuart Cheshire, and the rest of team at Apple that helped
implement and instrument this algorithm, and Jason Fesler and Paul implement and instrument this algorithm, and Jason Fesler and Paul
Saab who helped measure and refine this algorithm. The authors would Saab who helped measure and refine this algorithm. The authors would
also like to thank Nick Chettle, Paul Hoffman, Philip Homburg, Joe also like to thank Fred Baker, Nick Chettle, Lorenzo Colitti, Igor
Touch and James Woodyatt for their input and contributions. Gashinsky, Geoff Huston, Jen Linkova, Paul Hoffman, Philip Homburg,
Erik Nygren, Jordi Palet Martinez, Rui Paulo, Jinmei Tatuya, Dave
Thaler, Joe Touch and James Woodyatt for their input and
contributions.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<http://www.rfc-editor.org/info/rfc6147>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535,
DOI 10.17487/RFC6535, February 2012,
<http://www.rfc-editor.org/info/rfc6535>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>. 2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
12.2. Informative References [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<http://www.rfc-editor.org/info/rfc7050>.
13.2. Informative References
[DNS-PUSH] [DNS-PUSH]
Pusateri, T. and S. Cheshire, "DNS Push Notifications", Pusateri, T. and S. Cheshire, "DNS Push Notifications",
Work in Progress, draft-ietf-dnssd-push, March 2017. Work in Progress, draft-ietf-dnssd-push, March 2017.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>. <http://www.rfc-editor.org/info/rfc7413>.
Appendix A. Differences from RFC6555 Appendix A. Differences from RFC6555
"Happy Eyeballs: Success with Dual-Stack Hosts" [RFC6555] mostly "Happy Eyeballs: Success with Dual-Stack Hosts" [RFC6555] mostly
concentrates on how to stagger connections to a hostname that has an concentrates on how to stagger connections to a hostname that has an
AAAA and an A record. This document additionally discusses: AAAA and an A record. This document additionally discusses:
o how to perform DNS queries to obtain these addresses o how to perform DNS queries to obtain these addresses
o how to handle multiple addresses from each address family o how to handle multiple addresses from each address family
o how to handle DNS updates while connections are being raced o how to handle DNS updates while connections are being raced
o how to leverage historical information o how to leverage historical information
o how to support IPv6-only networks with NAT64 and DNS64
Authors' Addresses Authors' Addresses
Tommy Pauly David Schinazi
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
US US
Email: tpauly@apple.com Email: dschinazi@apple.com
David Schinazi Tommy Pauly
Apple Inc. Apple Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, California 95014 Cupertino, California 95014
US US
Email: dschinazi@apple.com Email: tpauly@apple.com
 End of changes. 37 change blocks. 
68 lines changed or deleted 207 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/