draft-ietf-v6ops-happy-eyeballs-04.txt   draft-ietf-v6ops-happy-eyeballs-05.txt 
v6ops D. Wing v6ops D. Wing
Internet-Draft A. Yourtchenko Internet-Draft A. Yourtchenko
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: March 17, 2012 September 14, 2011 Expires: April 29, 2012 October 27, 2011
Happy Eyeballs: Success with Dual-Stack Hosts Happy Eyeballs: Success with Dual-Stack Hosts
draft-ietf-v6ops-happy-eyeballs-04 draft-ietf-v6ops-happy-eyeballs-05
Abstract Abstract
When the IPv4 server and path is working but the IPv6 server or IPv6 When the IPv4 server and path is working but the IPv6 server or IPv6
path is down, a dual-stack client application experiences significant path is down, a dual-stack client application experiences significant
connection delay compared to an IPv4-only client. This is connection delay compared to an IPv4-only client. This is
undesirable because it causes the dual-stack client to have a worse undesirable because it causes the dual-stack client to have a worse
user experience. This document specifies requirements for algorithms user experience. This document specifies requirements for algorithms
that reduce this delay, and provides an example algorithm. that reduce this delay, and provides an example algorithm.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 17, 2012. This Internet-Draft will expire on April 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 35 skipping to change at page 2, line 35
5.7. Connection time out . . . . . . . . . . . . . . . . . . . 10 5.7. Connection time out . . . . . . . . . . . . . . . . . . . 10
5.8. Interaction with Same Origin Policy . . . . . . . . . . . 10 5.8. Interaction with Same Origin Policy . . . . . . . . . . . 10
5.9. Happy Eyeballs in an Operating System . . . . . . . . . . 11 5.9. Happy Eyeballs in an Operating System . . . . . . . . . . 11
6. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . 11 6. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informational References . . . . . . . . . . . . . . . . . 12 10.2. Informational References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 13
A.1. changes from -03 to -04 . . . . . . . . . . . . . . . . . 14 A.1. changes from -03 to -04 . . . . . . . . . . . . . . . . . 14
A.2. changes from -02 to -03 . . . . . . . . . . . . . . . . . 14 A.2. changes from -03 to -04 . . . . . . . . . . . . . . . . . 14
A.3. changes from -01 to -02 . . . . . . . . . . . . . . . . . 14 A.3. changes from -02 to -03 . . . . . . . . . . . . . . . . . 14
A.4. changes from -00 to -01 . . . . . . . . . . . . . . . . . 15 A.4. changes from -01 to -02 . . . . . . . . . . . . . . . . . 14
A.5. changes from -00 to -01 . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
In order to use applications over IPv6, it is necessary that users In order to use applications over IPv6, it is necessary that users
enjoy nearly identical performance as compared to IPv4. A enjoy nearly identical performance as compared to IPv4. A
combination of today's applications, IPv6 tunneling, IPv6 service combination of today's applications, IPv6 tunneling, IPv6 service
providers, and some of today's content providers all cause the user providers, and some of today's content providers all cause the user
experience to suffer (Section 3). For IPv6, a content provider may experience to suffer (Section 3). For IPv6, a content provider may
ensure a positive user experience by using a DNS white list of IPv6 ensure a positive user experience by using a DNS white list of IPv6
skipping to change at page 10, line 42 skipping to change at page 10, line 42
and will consume ports if IPv4 addresses are shared. For these and will consume ports if IPv4 addresses are shared. For these
reasons, it is RECOMMENDED that connection attempts be paced to give reasons, it is RECOMMENDED that connection attempts be paced to give
connections a chance to complete. It is RECOMMENDED that connections connections a chance to complete. It is RECOMMENDED that connections
attempts be paced 150-250ms apart. Stateful algorithms are expected attempts be paced 150-250ms apart. Stateful algorithms are expected
to be more aggressive (that is, make connection attempts closer to be more aggressive (that is, make connection attempts closer
together), as stateful algorithms maintain an estimate of the together), as stateful algorithms maintain an estimate of the
expected connection completion time. expected connection completion time.
5.8. Interaction with Same Origin Policy 5.8. Interaction with Same Origin Policy
Web browsers implement same origin policy [I-D.ietf-websec-origin] Web browsers implement a Same Origin Policy [I-D.ietf-websec-origin]
which causes subsequent connections to the same hostname to go to the which causes subsequent connections to the same hostname to go to the
same IPv4 (or IPv6) address as the previous successful connection. same IPv4 (or IPv6) address as the previous successful connection.
This is done to prevent certain types of attacks. This is done to prevent certain types of attacks.
The same-origin policy harms user-visible responsiveness if a new The same-origin policy harms user-visible responsiveness if a new
connection fails (e.g., due to a transient event such as router connection fails (e.g., due to a transient event such as router
failure or load balancer failure). While it is tempting to use Happy failure or load balancer failure). While it is tempting to use Happy
Eyeballs to maintain responsiveness, web browsers MUST NOT change Eyeballs to maintain responsiveness, web browsers MUST NOT change
their same origin policy because of Happy Eyeballs, as that would their Same Origin Policy because of Happy Eyeballs, as that would
create an additional security exposure. create an additional security exposure.
5.9. Happy Eyeballs in an Operating System 5.9. Happy Eyeballs in an Operating System
Applications would have to change in order to use the mechanism Applications would have to change in order to use the mechanism
described in this document, by either implementing the mechanism described in this document, by either implementing the mechanism
directly, or by calling APIs made available to them. To improve IPv6 directly, or by calling APIs made available to them. To improve IPv6
connectivity experience for legacy applications (e.g., applications connectivity experience for legacy applications (e.g., applications
which simply rely on the operating system's address preference which simply rely on the operating system's address preference
order), operating systems may consider more sophisticated approaches. order), operating systems may consider more sophisticated approaches.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
10.2. Informational References 10.2. Informational References
[Andrews] Andrews, M., "How to connect to a multi-homed server over [Andrews] Andrews, M., "How to connect to a multi-homed server over
TCP", January 2011, <http://www.isc.org/community/blog/ TCP", January 2011, <http://www.isc.org/community/blog/
201101/how-to-connect-to-a-multi-h omed-server-over-tcp>. 201101/how-to-connect-to-a-multi-h omed-server-over-tcp>.
[Experiences] [Experiences]
skipping to change at page 13, line 19 skipping to change at page 13, line 13
<http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf>. <http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf>.
[I-D.ietf-6man-addr-select-opt] [I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6", "Distributing Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-01 (work in progress), draft-ietf-6man-addr-select-opt-01 (work in progress),
June 2011. June 2011.
[I-D.ietf-websec-origin] [I-D.ietf-websec-origin]
Barth, A., "The Web Origin Concept", Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-04 (work in progress), draft-ietf-websec-origin-06 (work in progress),
August 2011. October 2011.
[Perreault] [Perreault]
Perreault, S., "Happy Eyeballs in Erlang", February 2011, Perreault, S., "Happy Eyeballs in Erlang", February 2011,
<http://www.viagenie.ca/news/ <http://www.viagenie.ca/news/
index.html#happy_eyeballs_erlang>. index.html#happy_eyeballs_erlang>.
[RFC1671] Carpenter, B., "IPng White Paper on Transition and Other [RFC1671] Carpenter, B., "IPng White Paper on Transition and Other
Considerations", RFC 1671, August 1994. Considerations", RFC 1671, August 1994.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
April 2010. April 2010.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059,
skipping to change at page 14, line 6 skipping to change at page 14, line 4
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011. June 2011.
[whitelist] [whitelist]
Google, "Google IPv6 DNS Whitelist", January 2009, Google, "Google IPv6 DNS Whitelist", January 2009,
<http://www.google.com/intl/en/ipv6>. <http://www.google.com/intl/en/ipv6>.
Appendix A. Changes Appendix A. Changes
A.1. changes from -03 to -04 A.1. changes from -03 to -04
o Make RFC3363 a non-normative reference.
A.2. changes from -03 to -04
o Better explained why IPv6 needs to be preferred o Better explained why IPv6 needs to be preferred
o Don't query A6. o Don't query A6.
A.2. changes from -02 to -03 A.3. changes from -02 to -03
o Re-casted this specification as a list of requirements for a o Re-casted this specification as a list of requirements for a
compliant algorithm, rather than trying to dictate a One True compliant algorithm, rather than trying to dictate a One True
algorithm. algorithm.
A.3. changes from -01 to -02 A.4. changes from -01 to -02
o Now honors host's address preference (RFC3484 and friends) o Now honors host's address preference (RFC3484 and friends)
o No longer requires thread-safe DNS library. It uses getaddrinfo() o No longer requires thread-safe DNS library. It uses getaddrinfo()
o No longer describes threading. o No longer describes threading.
o IPv6 is given a 200ms head start (Initial Headstart variable). o IPv6 is given a 200ms head start (Initial Headstart variable).
o If the IPv6 and IPv4 connection attempts were made at nearly the o If the IPv6 and IPv4 connection attempts were made at nearly the
skipping to change at page 14, line 49 skipping to change at page 15, line 4
serious affect to Smoothed P. serious affect to Smoothed P.
o encourages that every 10 minutes the exception cache and Smoothed o encourages that every 10 minutes the exception cache and Smoothed
P be reset. This allows IPv6 to be attempted again, so we don't P be reset. This allows IPv6 to be attempted again, so we don't
get 'stuck' on IPv4. get 'stuck' on IPv4.
o If we didn't get both A and AAAA, abandon all Happy Eyeballs o If we didn't get both A and AAAA, abandon all Happy Eyeballs
processing (thanks to Simon Perreault). processing (thanks to Simon Perreault).
o added discussion of Same Origin Policy o added discussion of Same Origin Policy
o Removed discussion of NAT-PT and address learning; those are only o Removed discussion of NAT-PT and address learning; those are only
used with IPv6-only hosts whereas this document is about dual- used with IPv6-only hosts whereas this document is about dual-
stack hosts contacting dual-stack servers. stack hosts contacting dual-stack servers.
A.4. changes from -00 to -01 A.5. changes from -00 to -01
o added SRV section (thanks to Matt Miller) o added SRV section (thanks to Matt Miller)
Authors' Addresses Authors' Addresses
Dan Wing Dan Wing
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 16 change blocks. 
21 lines changed or deleted 24 lines changed or added

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