draft-ietf-v6ops-rfc6555bis-02.txt   draft-ietf-v6ops-rfc6555bis-03.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 July 3, 2017 Intended status: Standards Track August 2, 2017
Expires: January 4, 2018 Expires: February 3, 2018
Happy Eyeballs Version 2: Better Connectivity Using Concurrency Happy Eyeballs Version 2: Better Connectivity Using Concurrency
draft-ietf-v6ops-rfc6555bis-02 draft-ietf-v6ops-rfc6555bis-03
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 January 4, 2018. This Internet-Draft will expire on February 3, 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 26 skipping to change at page 2, line 26
3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 4 3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 4
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 . . . . . 7 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 . . . . . . . . . . . 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 . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 13 Appendix A. Differences from RFC6555 . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 if the application is using IPv4 literals and per-packet translation if the application is using IPv4 literals and
does not encourage client application software to support native does not encourage client application software to support native
IPv6. On platforms that do not support 464XLAT, the Happy Eyeballs IPv6. On platforms that do not support 464XLAT, the Happy Eyeballs
engine SHOULD follow the recommendations in this section to properly engine SHOULD follow the recommendations in this section to properly
support IPv6-only networks with NAT64 and 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 network 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
literals, the Happy Eyeballs engine will need to perform NAT64 literals, the Happy Eyeballs engine will need to perform NAT64
address synthesis for them. The solution is similar to "Bump-in-the- address synthesis for them. The solution is similar to "Bump-in-the-
Host" [RFC6535] but is implemented inside the Happy Eyeballs library. Host" [RFC6535] but is implemented inside the Happy Eyeballs library.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
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 o Last Resort Local Synthesis Delay (Section 7.2): The time to wait
after starting the last IPv6 attempt and before sending the A after starting the last IPv6 attempt and before sending the A
query. RECOMMENDED at 2 seconds. query. RECOMMENDED at 2 seconds.
As time advances, it is expected that the properties of networks will The delay values described in this section were determined
evolve. For that reason, it is expected that these values will empirically by measuring the timing of connections on a very wide set
change over time. Implementors should feel welcome to use different of production devices. They were picked to reduce wait times noticed
values without changing this specification. In particular, IPv6 by users while minimizing load on the network. As time passes, it is
issues are expected to be less common, therefore the Resolution Delay expected that the properties of networks will evolve. For that
SHOULD be increased with time as client software is updated. reason, it is expected that these values will change over time.
Implementors should feel welcome to use different values without
changing this specification. Since IPv6 issues are expected to be
less common, the delays SHOULD be increased with time as client
software is updated.
9. 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.
9.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 pass 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. One solution is to use Packetization
Layer Path MTU Discovery [RFC4821].
9.2. Application Layer 9.2. Application Layer
If the DNS returns multiple addresses for different application If the DNS returns multiple addresses for different application
servers, the application itself may not be operational and functional servers, the application itself may not be operational and functional
on all of them. Common examples include Transport Layer Security on all of them. Common examples include Transport Layer Security
(TLS) and the Hypertext Transport Protocol (HTTP). (TLS) and the Hypertext Transport Protocol (HTTP).
9.3. Hiding Operational Issues 9.3. Hiding Operational Issues
skipping to change at page 12, line 14 skipping to change at page 12, line 14
13. References 13. References
13.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>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>. <http://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
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, <http://www.rfc-editor.org/info/rfc6146>. April 2011, <http://www.rfc-editor.org/info/rfc6146>.
 End of changes. 8 change blocks. 
13 lines changed or deleted 22 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/