draft-ietf-v6ops-rfc6555bis-05.txt   draft-ietf-v6ops-rfc6555bis-06.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 September 10, 2017 Intended status: Standards Track October 20, 2017
Expires: March 14, 2018 Expires: April 23, 2018
Happy Eyeballs Version 2: Better Connectivity Using Concurrency Happy Eyeballs Version 2: Better Connectivity Using Concurrency
draft-ietf-v6ops-rfc6555bis-05 draft-ietf-v6ops-rfc6555bis-06
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 14, 2018. This Internet-Draft will expire on April 23, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4 3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4
3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 5 3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 5
4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 5 4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 5
5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 6 5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 6
6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 7 6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 7
7. Supporting IPv6-only Networks with NAT64 and DNS64 . . . . . 8 7. Supporting IPv6-only Networks with NAT64 and DNS64 . . . . . 7
7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8 7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8
7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 9 7.2. Host Names with Broken AAAA Records . . . . . . . . . . . 9
7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 10 7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 10
8. Summary of Configurable Values . . . . . . . . . . . . . . . 11 8. Summary of Configurable Values . . . . . . . . . . . . . . . 11
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 12 9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 12
9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12 9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 12
9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 12 9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 14 Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 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.
This document expands on "Happy Eyeballs" [RFC6555], a technique of This document defines the algorithm for "Happy Eyeballs", a technique
reducing user-visible delays on dual-stack hosts. Now that this of reducing user-visible delays on dual-stack hosts. This definition
obsoletes the original description in [RFC6555]. 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.
resolved addresses that has several stages of ordering and racing to
avoid delays to the user whenever possible, while preferring the use The Happy Eyeballs algorithm of racing resolved addresses has several
of IPv6. Specifically, it discusses how to handle DNS queries when stages of ordering and racing to avoid delays to the user whenever
starting a connection on a dual-stack client, how to create an possible, while preferring the use of IPv6. This document discusses
ordered list of destination addresses to which to attempt how to handle DNS queries when starting a connection on a dual-stack
connections, and how to race the connection attempts. client, how to create an ordered list of destination addresses to
which to attempt connections, and how to 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" [RFC2119]. "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2. Overview 2. Overview
skipping to change at page 4, line 5 skipping to change at page 4, line 5
distinct phases: distinct phases:
1. Initiation of asynchronous DNS queries [Section 3] 1. Initiation of asynchronous DNS queries [Section 3]
2. Sorting of resolved destination addresses [Section 4] 2. Sorting of resolved destination 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
Note that this document assumes that the host destination address Note that this document assumes that the host destination address
preference policy favors IPv6 over IPv4. If the host is configured preference policy favors IPv6 over IPv4. IPv6 has many desirable
differently, the recommendations in this document can be easily properties designed to be improvements over IPv4 [RFC8200]. If the
adapted. host is configured to have a different preference, the
recommendations in this document can be easily adapted.
3. Hostname Resolution Query Handling 3. Hostname Resolution Query Handling
When a client has both IPv4 and IPv6 connectivity, and is trying to When a client has both IPv4 and IPv6 connectivity, and is trying to
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 SHOULD NOT wait for both families of answers to Implementations SHOULD NOT wait for both families of answers to
skipping to change at page 7, line 7 skipping to change at page 7, line 7
yet succeeded SHOULD be cancelled. Any address that was not yet yet succeeded SHOULD be cancelled. Any address that was not yet
attempted as a connection SHOULD be ignored. At that time, the attempted as a connection SHOULD be ignored. At that time, the
asynchronous DNS query MAY be cancelled as new addresses will not be asynchronous DNS query MAY be cancelled as new addresses will not be
used for this connection. However, the DNS client resolver SHOULD used for this connection. However, the DNS client resolver SHOULD
still process DNS replies from the network for a short period of time still process DNS replies from the network for a short period of time
(RECOMMENDED at 1 second), as they will populate the DNS cache and (RECOMMENDED at 1 second), as they will populate the DNS cache and
can be used for subsequent connections. can be used for subsequent connections.
A simple implementation can have a fixed delay for how long to wait A simple implementation can have a fixed delay for how long to wait
before starting the next connection attempt. This delay is referred before starting the next connection attempt. This delay is referred
to as the "Connection Attempt Delay". One recommended value for this to as the "Connection Attempt Delay". One recommended value for a
delay is 250 milliseconds. If the client has historical RTT data, it default delay is 250 milliseconds. A more nuanced implementation's
can also use the expected RTT to choose a more nuanced delay value. delay should correspond to the time when the previous attempt is
The recommended formula for calculating the delay after starting a sending its second TCP SYN, based on TCP's retransmission timer
connection attempt is: MAX( 1.25 * RTT_MEAN + 4 * RTT_VARIANCE, 2 * [RFC6298]. If the client has historical RTT data gathered from other
RTT_MEAN ), where the RTT values are based on the statistics for connections to the same host or prefix, it can use this information
previous address used. If the TCP implementation leverages to influence its delay. Note that this algorithm should only try to
historical RTT data to compute SYN timeout, these algorithms should approximate the time of the first SYN retransmission, and not any
match so that a new attempt will be started at the same time as the further retransmissions which may be influenced by exponential timer
previous is sending its second TCP SYN. While TCP implementations back off.
often leverage an exponential backoff when they detect packet loss,
the "Connection Attempt Delay" SHOULD NOT perform such an aggressive
backoff, 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 congestion 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
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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.
10. Security Considerations 10. Security Considerations
This memo has no direct security considerations. This memo has no direct security considerations.
Note that applications should not rely upon a stable hostname-to-
address mapping to ensure any security properties, since DNS results
may change between queries. Happy Eyeballs may make it more likely
that subsequent connections to a single hostname use different IP
addresses.
11. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. 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
skipping to change at page 13, line 34 skipping to change at page 13, line 47
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, Using "Bump-in-the-Host" (BIH)", RFC 6535,
DOI 10.17487/RFC6535, February 2012, DOI 10.17487/RFC6535, February 2012,
<https://www.rfc-editor.org/info/rfc6535>. <https://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, <https://www.rfc-editor.org/info/rfc6555>. 2012, <https://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,
skipping to change at page 14, line 20 skipping to change at page 14, line 39
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://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,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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 o how to support IPv6-only networks with NAT64 and DNS64
Authors' Addresses Authors' Addresses
David Schinazi David Schinazi
Apple Inc. Apple Inc.
 End of changes. 13 change blocks. 
32 lines changed or deleted 48 lines changed or added

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