One document matched: draft-ietf-v6ops-happy-eyeballs-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.tuexen-sctp-udp-encaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tuexen-sctp-udp-encaps.xml">
<!ENTITY rfc4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY rfc1671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1671.xml">
<!ENTITY rfc2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml">
<!ENTITY rfc3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY rfc4966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4966.xml">
<!ENTITY rfc4074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4074.xml">
<!ENTITY rfc5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY I-D.natarajan-http-over-sctp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.natarajan-http-over-sctp.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-ietf-v6ops-happy-eyeballs-00" ipr="trust200902">
<front>
<title abbrev="Happy Eyeballs Dual Stack">Happy Eyeballs:
Trending Towards Success with Dual-Stack Hosts</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>De Kleetlaan, 7</street>
<city>San Jose</city>
<region>Diegem</region>
<code>B-1831</code>
<country>Belgium</country>
</postal>
<email>ayourtch@cisco.com</email>
</address>
</author>
<date year="2011" />
<workgroup>v6ops</workgroup>
<abstract>
<t>This document describes how a dual-stack client can determine the
functioning path to a dual-stack server. This provides a seamless
user experience during initial deployment of dual-stack networks and
during outages of IPv4 or outages of IPv6.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In order to use HTTP successfully over IPv6, it is necessary
that the user enjoys nearly identical performance as compared to
IPv4. A combination of today's applications, IPv6 tunneling and
IPv6 service providers, and some of today's content providers
all cause the user experience to suffer
(<xref target="problem_statement"></xref>). For IPv6, a content
provider may ensure a positive user experience by using a DNS white list of
IPv6 service providers who peer directly with
them, e.g. <xref target="whitelist"></xref>. However, this is not
scalable to all service providers worldwide, nor is it scalable
for other content providers to operate their own DNS white
list.</t>
<t>Instead, this document suggests a mechanism for applications
to quickly determine if IPv6 or IPv4 is the most optimal to
connect to a server. The suggestions in this document provide a
user experience which is superior to connecting to ordered IP
addresses which is helpful during the IPv6/IPv4 transition with
dual stack hosts.</t>
<t>This problem is described also in <xref target="RFC1671"></xref>:
"The dual-stack code may get two addresses back from DNS; which does
it use? During the many years of transition the Internet will
contain black holes. For example, somewhere on the way from IPng host
A to IPng host B there will sometimes (unpredictably) be IPv4-only
routers which discard IPng packets. Also, the state of the DNS does
not necessarily correspond to reality. A host for which DNS claims to
know an IPng address may in fact not be running IPng at a particular
moment; thus an IPng packet to that host will be discarded on
delivery. Knowing that a host has both IPv4 and IPng addresses gives
no information about black holes. A solution to this must be proposed
and it must not depend on manually maintained information. (If this
is not solved, the dual stack approach is no better than the packet
translation approach.)"</t>
<t>Following the procedures in this document, once a certain address
family is successful, the application trends towards preferring that address
family. Thus, repeated use of the application DOES NOT cause repeated
probes over both address families.</t>
<t>While the application recommendations in this document are
described in the context of HTTP clients ("web browsers"), it is also
useful and applicable to other interactive applications.</t>
<t>Code which implements some of the ideas described in this document
has been made available <xref target="Perreault"/>
<xref target="Andrews"/>.</t>
</section>
<section title="Notational Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="problem_statement" title="Problem Statement">
<t>As discussed in more detail in <xref target="problem_uris"></xref>,
it is important that the same URI and hostname be used for IPv4 and IPv6.
Using separate namespaces causes namespace fragmentation
and reduces the ability for users to share URIs and hostnames, and
complicates printed material that includes the URI or hostname.</t>
<t>As discussed in more detail
in <xref target="problem_ipv6"></xref>, IPv6 connectivity is
sometimes broken entirely or slower than native IPv4
connectivity.</t>
<section anchor="problem_uris" title="URIs and hostnames">
<t>URIs are often used between users to exchange pointers to
content -- such as on social networks, email, instant messaging, or
other systems. Thus, production URIs and production hostnames
containing references to IPv4 or IPv6 will only function if
the other party is also using an application, OS, and a network that
can access the URI or the hostname.</t>
</section>
<section anchor="problem_ipv6" title="IPv6 connectivity">
<t>When IPv6 connectivity is impaired, today's IPv6-capable
web browsers incur many seconds of delay before falling back
to IPv4. This harms the user's experience with IPv6, which
will slow the acceptance of IPv6, because IPv6 is frequently
disabled in its entirety on the end systems to improve the
user experience.</t>
<t>Reasons for such failure include no connection to the IPv6
Internet, broken 6to4 or Teredo tunnels, and broken IPv6
peering.</t>
<figure anchor="diagram_message_flow"
title="Existing behavior message flow">
<artwork align="center"><![CDATA[
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:dba::1----------->| |
5. | | |
6. | |--TCP SYN, IPv6--->X |
7. | |--TCP SYN, IPv6--->X |
8. | |--TCP SYN, IPv6--->X |
9. | | |
10. | |--TCP SYN, IPv4------->|
11. | |<-TCP SYN+ACK, IPv4----|
12. | |--TCP ACK, IPv4------->|
]]></artwork>
</figure>
<t>The client obtains the IPv4 and IPv6 records for the server (1-4).
The client attempts to connect using IPv6 to the server, but the IPv6
path is broken (6-8), which consumes several seconds of time.
Eventually, the client attempts to connect using IPv4 (10) which
succeeds.</t>
</section>
</section>
<section title="Client Recommendations">
<t>To provide fast connections for users, clients should make
connections quickly over various technologies, automatically tune itself
to avoid flooding the network with unnecessary connections (i.e., for
technologies that have not made successful connections), and
occasionally flush its self-tuning.</t>
<section anchor="client_v6" title="Dualstack behavior">
<t>If a TCP client supports IPv6 and IPv4 and is connected
to IPv4 and IPv6 networks, it can perform the procedures described
in this section.</t>
<figure anchor="diagram_message_flow_happy_1"
title="Happy Eyeballs flow 1, IPv6 broken">
<artwork align="center"><![CDATA[
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:dba::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |--TCP SYN, IPv4------->|
8. | |<-TCP SYN+ACK, IPv4----|
9. | |--TCP ACK, IPv4------->|
10. | |==TCP SYN, IPv6===>X |
]]></artwork>
</figure>
<t>In the diagram above, the client sends two TCP SYNs at the same time
over IPv6 (6) and IPv4 (7). In the diagram, the IPv6 path is broken
but has little impact to the user because there is no long delay
before using IPv4. The IPv6 path is retried until the application
gives up (10).</t>
<figure anchor="diagram_message_flow_happy_2"
title="Happy Eyeballs flow 2, IPv6 working">
<artwork align="center"><![CDATA[
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:dba::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6=======>|
7. | |--TCP SYN, IPv4------->|
8. | |<=TCP SYN+ACK, IPv6====|
9. | |<-TCP SYN+ACK, IPv4----|
10. | |==TCP ACK, IPv6=======>|
11. | |--TCP ACK, IPv4------->|
12. | |--TCP RST, IPv4------->|
]]></artwork>
</figure>
<t>The diagram above shows a case where both IPv6 and IPv4 are
working, and IPv4 is abandoned (12).</t>
</section>
<section anchor="client_v6_details" title="Implementation details">
<t>This section details how to provide robust dual stack service for
both IPv6 and IPv4, so that the user perceives very fast application
response.</t>
<t>The TCP client application is configured with one
application-wide value of P. A positive value indicates a preference for IPv6 and a
negative value indicates a preference for IPv4. A value of 0
indicates equal weight, which means the A and AAAA queries and
associated connection attempts will be sent as quickly as
possible. The absolute value of P is the measure of a delay
before initiating a DNS lookup and a connection attempt on the other address
family. There are two P values maintained: one is
application-wide and the other is specific per each
destination (hostname and port).</t>
<t>The algorithm attempts to delay the DNS query until it expects that
address family will be necessary; that is, if the preference is
towards IPv6, then AAAA will be queried immediately and the A query
will be delayed.</t>
<t>The TCP client application starts two concurrent execution flows (they will be referred
to as "threads" but this reference does not imply the implementation detail of using
the threading library, merely the property of mutual concurrency) in order to
minimize the user-noticeable delay ("dead time") during the
connection attempts:<list style="hanging">
<t hangText="thread 1: (IPv6)"><list style="symbols">
<t>If P<0, wait for absolute value of p*10 milliseconds</t>
<t>send DNS query for AAAA</t>
<t>wait until DNS response is received</t>
<t>Attempt to connect over IPv6 using TCP</t>
</list></t>
<t hangText="thread 2: (IPv4)"><list style="symbols">
<t>if P>0, wait for p*10 milliseconds</t>
<t>send DNS query for A</t>
<t>wait until DNS response is received</t>
<t>Attempt to connect over IPv4 using TCP</t>
</list></t>
</list></t>
<t>The first thread that succeeds returns the completed connection to
the parent code and aborts the other thread (<xref
target="abandon"></xref>).</t>
<t>After a connection is successful, we want to adjust the
application-wide preference and the per-destination preference. The
value of P is incremented (decremented) each time an IPv6 (IPv4)
connection wins the race.. When a connection using the
less-preferred address family is successful, it indicates the wrong
address family was used and the value of P is halved:<list style="symbols">
<t>If P>0 (indicating IPv6 is preferred over IPv4) and the
first thread to finish was the IPv6 thread it indicates the IPv6
preference is correct and we need to re-enforce this by increasing
the application-wide P value by 1. However, if the first thread to
finish was the IPv4 thread it indicates an IPv6 connection problem
occurred and we need to aggressively prefer IPv4 more by halving P
and rounding towards 0.</t>
<t>If P<0 (indicating IPv4 is preferred over IPv6) and the
first thread to finish was the IPv4 thread it indicates the
preference is correct and we need to re-enforce this gently by
decreasing the application-wide P value by 1. However, if the
first thread to finish was the IPv6 thread it indicates an IPv4
connection problem and we need to aggressively avoid IPv4 by
halving P and rounding towards 0.</t>
<t>If P=0 (indicating equal preference), P is incremented by one if the
first thread to complete was the IPv6 thread, or decremented by one if
the first thread to complete was the IPv4 thread.</t>
</list>After adjusting P, the resulting delay should never be larger than 4 seconds
-- which is similar to the value used by many IPv6-capable TCP
client applications to switch to an alternate A or AAAA record.</t>
<t><list style="empty">
<t>Editor's Note 01: Proof of concept tests on fast networks show that even
smaller value (around 0.5 seconds) may be practical. More extensive
testing would be useful to find the best upper boundary that still
ensures a good user experience.</t>
<t>Editor's Note 02: A strict implementation of the above steps results in
"P" being adjusted if there are no AAAA records or are
no A records. This is undesirable. Thus, a future version
of this specification is expected to recommend that "P"
only be adjusted if there was both an A and AAAA record.
</t>
</list></t>
<!--
<t>An implementation of the IPv6/IPv4 Happy Eyeballs algorithm in the
Links web browser <xref target="links"></xref> is available at <xref
target="64-impl"></xref>.</t>
-->
</section>
<section title="Additional Considerations">
<t>This section discusses considerations and requirements that are
common to new technology deployment.</t>
<section title="Additional Network and Host Traffic">
<t>Additional network traffic and additional server load is
created due to these recommendations and mitigated by
application-wide and per-destination timer adjustments. The
procedures described in this document retain a quality user
experience while transitioning from IPv4-only to dual stack.
The quality user experience benefits the user but to the
detriment of the network and server that are serving the
user.</t>
</section>
<section anchor="abandon" title="Abandon Non-Winning Connections">
<t>It is RECOMMENDED that the non-winning connections be abandoned,
even though they could be used to download content. This is because
some web sites provide HTTP clients with cookies (after logging in)
that incorporate the client's IP address, or use IP addresses to
identify users. If some connections from the same HTTP client are
arriving from different IP addresses, such HTTP applications will
break. It's also important to abandon connections to avoid
consuming server or middlebox (e.g., NAT) resources (file descriptors, memory, TCP control
blocks) and avoid sending TCP or application-level keepalives on
otherwise unused connections.</t>
<!--
<t><list style="empty"><t>[[Editor's Note 04: The "race to success" stops
when the first successful connection is made. However, it may be
prudent to keep the non-winning connection open for the scenario where
the application can detect a problem, such as Path MTU Discovery
blackholes <xref target="RFC2923"></xref>. The algorithm then can
take care by the application-level issues by reusing the second
connection in case the requests are idempotent (e.g., GET requests).
This needs more analysis.]]</t>
</list></t>
-->
</section>
<section title="Flush or Expire Cache">
<t>Because every network has different characteristics (e.g.,
working or broken IPv6 connectivity) the IPv6/IPv4 preference
value (P) SHOULD be reset to its default whenever the host is
connected to a new network
(<xref target="cx-osx"></xref>, <xref target="cx-win"></xref>).
However, in some instances the application and the host are
unaware the network connectivity has changed so it is
RECOMMENDED that per-destination values expire after 10
minutes of inactivity.</t>
</section>
<section title="Determining Address Type">
<t>For some transitional technologies such as a dual-stack host, it is
easy for the application to recognize the native IPv6 address (learned
via a AAAA query) and the native IPv4 address (learned via an A
query). For other transitional technologies <xref
target="RFC2766"></xref> it is impossible for the host to
differentiate a transitional technology IPv6 address from a native
IPv6 address (see Section 4.1 of <xref target="RFC4966"></xref>).
Replacement transitional technologies are attempting to bridge this
gap. It is necessary for applications to distinguish between native
and transitional addresses in order to provide the most seamless user
experience.</t>
<t>Application awareness of transitional technologies, if implemented,
SHOULD provide a facility to give the preference only to native IPv6 addresses.
</t>
</section>
<section title="Debugging and Troubleshooting">
<t>This mechanism is aimed at ensuring a reliable user experience
regardless of connectivity problems affecting any single transport.
However, this naturally means that applications employing these
techniques are by default less useful for diagnosing issues with any
particular transport. To
assist in that regard, the applications implementing the proposal in this
document SHOULD also provide a mechanism to revert the behavior
to that of a default provided by the operating system - the <xref
target="RFC3484"></xref>.</t>
<t><list style="empty">
<t>[[[ To be discussed. </t>
<t>Some sites may wish to be informed when the the hosts adjust their "P" value,
in order to troubleshoot the underlying cause. To help these sites,
a strawman proposal is to send a syslog message or other notification
to an address that may be configured
by a site administrator in a centralized fashion.
(The exact method TBD - DHCP option, domain name, etc.)
This syslog message should be sent only first N times that the host
expects to prefer IPv6 but has to use IPv4. I.e. the first N times it decreases
the value of P. N - TBD.</t>
<t>]]]</t>
</list></t>
</section>
<section anchor="dns_behavior" title="DNS Behavior">
<t>Unique to DNS AAAA queries are the problems described in <xref
target="RFC4074"></xref> which, if they still persist, require
applications to perform an A query before the AAAA query. <list>
<t>[[Editor's Note 03: It is believed these defective DNS servers
have long since been upgraded. If so, we can remove this
section.]]</t>
</list></t>
</section>
<section title="Middlebox Issues">
<t>Some devices are known to exhibit what amounts to a bug, when the A
and AAAA requests are sent back-to-back over the same 4-tuple, and
drop one of the requests or replies <xref
target="DNS-middlebox"></xref>. However, in some cases fixing this
behaviour may not be possible either due to the architectural
limitations or due to the administrative constraints (location of the
faulty device is unknown to the end hosts or not controlled by the end
hosts). The algorithm described in this draft, in the case of this
erroneous behaviour will eventually pace the queries such that this
issue is will be avoided. The algorithm described in this draft also
avoids calling the operating system's getaddrinfo() with "any", which
should prevent the operating system from sending the A and AAAA
queries on the same port.</t>
<t>For the large part, these issues are believed to be fixed,
in which case the getaddrinfo() with AF_UNSPEC as the address family
in its hints.</t>
</section>
<section title="Multiple Interfaces">
<t>Interaction of the suggestions in this document with
multiple interfaces, and interaction with the MIF working
group, is for further study.</t>
</section>
</section>
<section title="Content Provider Recommendations">
<t>Content providers SHOULD provide both AAAA and A records for servers
using the same DNS name for both IPv4 and IPv6.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>[[Placeholder.]]</t>
<t>See <xref target="abandon"></xref>.</t>
</section>
<section title="Acknowledgements">
<t>The mechanism described in this paper was inspired by Stuart
Cheshire's discussion at the IAB Plenary at IETF72, the author's
understanding of Safari's operation with SRV records, Interactive
Connectivity Establishment (<xref
target="RFC5245">ICE</xref>), and the current IPv4/IPv6
behavior of SMTP mail transfer agents.</t>
<t>Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and
Iljitsch van Beijnum for fostering the creation of this
document.</t>
<t>Thanks to Scott Brim, Rick Jones, Stig Venaas, Erik Kline, Bjoern Zeeb for
providing feedback on the document.</t>
<t>Thanks to Javier Ubillos, Simon Perreault and Mark Andrews for
the active feedback and the experimental work on the
independent practical implementations that they created.</t>
<t>Also the authors would like to thank the following individuals who
participated in various email discussions on this topic:
Mohacsi Janos, Pekka Savola, Ted Lemon, Carlos Martinez-Cagnazzo,
Simon Perreault, Jack Bates, Jeroen Massar, Fred Baker, Javier Ubillos,
Teemu Savolainen,
Scott Brim, Erik Kline, Cameron Byrne, Daniel Roesen, Guillaume Leclanche,
Cameron Byrne, Mark Smith, Gert Doering, Martin Millnert, Tim Durack.
</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3484;
</references>
<references title="Informational References">
&rfc1671;
&rfc2766;
&rfc4966;
&rfc4074;
&rfc5245;
<reference anchor="whitelist"
target="http://www.google.com/intl/en/ipv6">
<front>
<title>Google IPv6 DNS Whitelist</title>
<author fullname="Google" surname="Google">
<organization></organization>
</author>
<date month="January" year="2009" />
</front>
</reference>
<reference anchor="DNS-middlebox"
target="https://bugzilla.redhat.com/show_bug.cgi?id=505105">
<front>
<title>DNS middlebox behavior with multiple queries over same source
port</title>
<author fullname="Various" surname="Various">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
</reference>
<reference anchor="cx-osx"
target="https://bugzilla.redhat.com/show_bug.cgi?id=505105">
<front>
<title>AIHostReachabilityMonitor</title>
<author fullname="Adium" surname="Adium">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
</reference>
<reference anchor="cx-win"
target="http://msdn.microsoft.com/en-us/library/system.net.networkinformation.networkchange.networkavailabilitychanged.aspx">
<front>
<title>NetworkChange.NetworkAvailabilityChanged Event</title>
<author fullname="Microsoft" surname="Microsoft">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
</reference>
<reference anchor="Perreault"
target="http://www.viagenie.ca/news/index.html#happy_eyeballs_erlang">
<front>
<title>Happy Eyeballs in Erlang</title>
<author fullname="Simon Perreault"
surname="Perreault" initials="S">
<organization>Viagenie</organization>
</author>
<date month="February" year="2011" />
</front>
</reference>
<reference anchor="Andrews" target="http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-h
omed-server-over-tcp">
<front>
<title>How to connect to a multi-homed server over TCP</title>
<author fullname="Mark Andrews"
surname="Andrews" initials="M">
<organization>ISC</organization>
</author>
<date month="January" year="2011" />
</front>
</reference>
<!--
<reference anchor="64-impl"
target="http://www.employees.org/~andin/happy-eyeballs">
<front>
<title>Implementation of Happy Eyeballs Algorithm in Links</title>
<author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
<organization></organization>
</author>
<date month="July" year="2009" />
</front>
</reference>
<reference anchor="links"
target="http://links.sourceforge.net/">
<front>
<title>Links. The WWW Text Browser</title>
<author fullname="Sourceforge" surname="Sourceforge">
<organization></organization>
</author>
<date month="July" year="2009" />
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:02:15 |