One document matched: draft-ietf-v6ops-happy-eyeballs-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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-07"
ipr="trust200902">
<front>
<title abbrev="Happy Eyeballs Dual Stack">Happy Eyeballs: 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></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>When a server's IPv4 path and protocol is working but the
server's IPv6 path and protocol are not working, a dual-stack client
application experiences significant connection delay compared to
an IPv4-only client. This is undesirable because it causes the
dual-stack client to have a worse user experience. This
document specifies requirements for algorithms that reduce this
user-visible delay, and provides an algorithm.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In order to use applications over IPv6, it is necessary that users
enjoy nearly identical performance as compared to IPv4. A combination of
today's applications, IPv6 tunneling, 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 does not scale well (to the
number of DNS servers worldwide or the number of content providers
worldwide), and does not react to intermittent network path outages.</t>
<t>Instead, applications reduce connection setup delays themselves, by
more aggressively making connections on IPv6 and IPv4. There are a
variety of algorithms that can be envisioned. This document specifies
requirements for any such algorithm, with the goals that the network and
servers are not inordinately harmed with a simple doubling of traffic on
IPv6 and IPv4, and the host's address preference is honored (e.g., <xref
target="RFC3484"></xref>).</t>
<!--
<t>Even after the transition, the procedure described in this document
allows applications to strongly prefer IPv6. Yet when an IPv6 outage
occurs the application will quickly start using IPv4 and continue using
IPv4. It will quietly continue trying to use IPv6 until IPv6 becomes
available again, and then trend again towards using IPv6.</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") and SRV clients (e.g.,
XMPP clients) the procedure is also useful and applicable to other
interactive applications.</t>
-->
<section title="Additional Network and Host Traffic">
<t>Additional network traffic and additional server load is created
due to the recommendations in this document, especially when
connections to the preferred address family (usually IPv6) are not
completing quickly.</t>
<t>The procedures described in this document retain a quality user
experience while transitioning from IPv4-only to dual stack, while
still giving IPv6 a slight preference over IPv4 (in order to remove
load from IPv4 networks, most importantly to reduce the load on IPv4
network address translators). The improvement in the user experience
benefits the user to only a small detriment of the network, DNS
server, and server that are serving the user.</t>
</section>
</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>The basis of the IPv6/IPv4 selection problem was first described in
1994 in <xref target="RFC1671"></xref>, <list style="empty">
<t>"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>
</list></t>
<t>As discussed in more detail in <xref target="problem_uris"></xref>,
it is important that the same hostname be used for IPv4 and
IPv6.</t>
<t>As discussed in more detail in <xref target="problem_ipv6"></xref>,
IPv6 connectivity is broken to specific prefixes or specific hosts, or
slower than native IPv4 connectivity.</t>
<t>The mechanism described in this document is directly
applicable to connection-oriented transports (e.g., TCP, SCTP),
which is the scope of this document. For connectionless
transport protocols (e.g., UDP), a similar mechanism can be used
if the application has request/response semantics (e.g., as done
by ICE to select a working IPv6 or IPv4 media
path <xref target="RFC6157"></xref>).</t>
<section anchor="problem_uris" title="Hostnames">
<t>Hostnames are often used between users to exchange pointers to
content -- such as on social networks, email, instant
messaging, or other systems. Using separate namespaces (e.g.,
"ipv6.example.com") which are only accessible with certain client
technology (e.g., an IPv6 client) and dependencies (e.g., a
working IPv6 path) causes
namespace fragmentation and reduces the ability for users to
share hostnames. It also complicates printed material
that includes the hostname.</t>
<t>The algorithm described in this document allows production
hostnames to avoid these problematic references to IPv4 or
IPv6.</t>
</section>
<section anchor="problem_ipv6" title="Delay When IPv6 is not Accessible">
<t>When IPv6 connectivity is impaired, today's IPv6-capable
applications (e.g., web browsers, email clients, instant
messaging clients) incur many seconds of delay before falling
back to IPv4. This delays overall application operation,
including harming 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. The
following diagram shows this behavior.</t>
<t>The algorithm described in this document allows clients
to connect to servers without significant delay, even if
a path or the server is slow or down.</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:db8::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>
<t>Delays experienced by users of various browser and operating system
combinations have been studied <xref target="Experiences"></xref>.</t>
</section>
</section>
<section title="Algorithm Requirements">
<t>A Happy Eyeballs algorithm has two primary goals:<list
style="numbers">
<t>Provides fast connection for users, by quickly attempting to
connect using IPv6 and (if that connection attempt is not quickly
successful) to connect using IPv4.</t>
<t>Avoids thrashing the network, by not (always) making simultaneous
connection attempts on both IPv6 and IPv4.</t>
</list></t>
<t>The basic idea is depicted in the following diagram:</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:db8::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>
<t>After performing the above procedure, the client learns whether
connections to the host's IPv6 or IPv4 address were successful.
The client MUST cache information regarding the outcome of each
connection attempt and uses that information to avoid thrashing the
network with subsequent attempts. For example, in the example
above, the cache indicates that the IPv6 connection attempt failed,
and therefore the system will prefer IPv4 instead. Cache entries
should be flushed when their age exceeds a system defined maximum
on the order of ten minutes.</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:db8::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>
<t>Any Happy Eyeballs algorithm will persist in products for as long as
the client host is dual-stacked, which will persist as long as there are
IPv4-only servers on the Internet -- the so-called "long tail". Over
time, as most content is available via IPv6, the amount of IPv4 traffic
will decrease. This means that the IPv4 infrastructure will, over time,
be sized to accommodate that decreased (and decreasing) amount of
traffic. It is critical that a Happy Eyeballs algorithm not cause a
surge of unnecessary traffic on that IPv4 infrastructure. To meet that
goal, compliant Happy Eyeballs algorithms must adhere to the
requirements in this section.</t>
<section title="Delay IPv4">
<t>The transition to IPv6 is likely to produce a mix of
different hosts within a subnetwork -- hosts that are IPv4-only, hosts
that are IPv6-only (e.g., sensors), and dual-stack. This mix of hosts
will exist both within an administrative domain (a single home,
enterprise, hotel, or coffee shop) and between administrative domains.
For example, a single home might have an IPv4-only television in one
room and a dual-stack television in another room. As another example,
another subscriber might have hosts that are all capable of dual-stack
operation.</t>
<t>Due to IPv4 exhaustion, it is likely that a subscriber's hosts
(both IPv4-only hosts and dual-stack hosts) will be sharing an IPv4
address with other subscribers. The dual-stack hosts have an
advantage: they can utilize IPv6 or IPv4, which means it can
utilize the technique described in this document. The IPv4-only hosts have a
disadvantage: they can only utilize IPv4. If all hosts (dual-stack and
IPv4-only) are using IPv4, there is additional contention for the
shared IPv4 address. The IPv4-only hosts cannot avoid that contention
(as they can only use IPv4) while the dual-stack hosts can avoid that
contention by using IPv6.</t>
<t>As dual-stack hosts proliferate and content becomes available over
IPv6, there will be proportionally less IPv4 traffic. This is true
especially for dual-stack hosts that do not implement Happy Eyeballs,
because those dual-stack hosts have a very strong preference to use
IPv6 (with timeouts in the tens of seconds before they will attempt to
use IPv4).</t>
<t>When deploying IPv6, both content providers and Internet Service
Providers (who supply IPv4 address sharing mechanisms such as Carrier
Grade NAT (CGN)) will want to reduce their investment in IPv4
equipment -- load balancers, peering links, and address sharing
devices. If a Happy Eyeballs implementation treats IPv6 and IPv4
equally by connecting to whichever address family is fastest, it will
contribute to load on IPv4. This load impacts IPv4-only devices (by
increasing contention of IPv4 address sharing and increasing load on
IPv4 load balancers). Because of this, ISPs and content providers will
find it impossible to reduce their investment in IPv4 equipment. This
means that costs to migrate to IPv6 are increased, because the
investment in IPv4 cannot be reduced. Furthermore, using only a metric
that measures connection speed ignores the value of IPv6 over IPv4
address sharing, such as shared penalty boxes and geo-location <xref
target="RFC6269"></xref>.</t>
<t>Thus, to avoid harming IPv4-only hosts which can only utilize IPv4,
implementations MUST prefer the first IP address family returned by
the host's address preference policy, unless implementing a stateful
algorithm described in <xref target="stateful"></xref>. This usually
means giving preference to IPv6 over IPv4, although that preference can
be over-ridden by user configuration or by network configuration <xref
target="I-D.ietf-6man-addr-select-opt"></xref>. If the host's policy
is unknown or not attainable, implementations MUST prefer IPv6 over
IPv4.</t>
<!--
<t><list style="empty">
<t>Justification: This helps the transition to IPv6 by
reducing the impact of dual-stack clients on IPv4-only clients.</t>
</list></t>
-->
</section>
<section anchor="stateful" title="Stateful Behavior when IPv6 Fails">
<t>Some Happy Eyeballs algorithms are stateful -- that is, the
algorithm will remember that IPv6 always fails, or that IPv6 to
certain prefixes always fails, and so on. This section describes such
algorithms. Stateless algorithms, which do not remember the
success/failure of previous connections, are not discussed in this
section.</t>
<t>After making a connection attempt on the preferred address family
(e.g., IPv6), and failing to establish a connection within a certain
time period (see <xref target="timeout"></xref>), a Happy Eyeballs
implementation will decide to initiate a second connection attempt
using the same address family or the other address family.</t>
<t>Such an implementation MAY make subsequent connection attempts (to
the same host or to other hosts) on the successful address family
(e.g., IPv4). So long as new connections are being attempted by
the host, such an implementation MUST occasionally make connection
attempts using the host's preferred address family, as it may have
become functional again, and it SHOULD do so every 10 minutes. The
10 minute delay before re-trying a failed address family avoids
the simple doubling of connection attempts on both IPv6 and IPv4.
Implementation note: this can be achieved by flushing Happy Eyeballs
state every every 10 minutes, which does
not significantly harm the application's subsequent connection setup time. If
connections using the preferred address family are again successful,
the preferred address family SHOULD be used for subsequent
connections. Because this implementation is stateful, it MAY track
connection success (or failure) based on IPv6 or IPv4 prefix (e.g.,
connections to the same prefix assigned to the interface are
successful whereas connections to other prefixes are failing).</t>
<!--
<t><list style="empty">
<t>Justification: Once the IPv6 path becomes usable again,
reducing IPv4 load is useful to help IPv4-only hosts, and
to reduce address sharing contention.</t>
</list></t>
-->
</section>
<section anchor="initialization"
title="Reset on Network (re-)Initialization">
<t>
Because every network has different characteristics (e.g., working or
broken IPv6 or IPv4 connectivity), a Happy Eyeballs algorithm
SHOULD re-initialize when the interface is connected to a new
network. Interfaces can determine network (re-)initialization by a
variety of mechanisms (e.g., <xref target="RFC4436">DNAv4</xref>, <xref
target="RFC6059">DNAv6</xref>).</t>
<t>If the client application is a web browser, see also <xref
target="section_sop"></xref>.</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 -- in some cases -- be put to reasonable
use.</t>
<t><list style="empty">
<t>Justification: This reduces the load on the server (file
descriptors, TCP control blocks), stateful middleboxes (NAT and
firewalls) and, if the abandoned connection is IPv4, reduces IPv4
address sharing contention.</t>
<t>HTTP: The design of some sites can break because of HTTP
cookies that incorporate the client's IP address and require all
connections be from the same IP address. If some connections from
the same client are arriving from different IP addresses (or
worse, different IP address families), such applications will
break. Additionally for HTTP, using the non-winning connection can
interfere with the browser's Same Origin Policy (see <xref
target="section_sop"></xref>).</t>
</list></t>
</section>
</section>
<section title="Additional Considerations">
<t>This section discusses considerations related to Happy Eyeballs.</t>
<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). While IPv6/IPv4 translation
makes that difficult, IPv6/IPv4 translators do not need to be
deployed on networks with dual stack clients, because dual
stack clients can use their native IP address family.</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 a particular address
family. To assist in that regard, the implementations MAY also
provide a mechanism to disable their Happy Eyeballs behavior
via a user setting, and to provide data useful for debugging
(e.g., a log or way to review current preferences).</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
middlebox issue is 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 from the same port.</t>
<t>For the large part, these issues with simultaneous DNS requests are
believed to be fixed.</t>
</section>
-->
<section title="Three or More Interfaces">
<t>A dual-stack host normally has two logical interfaces: an
IPv6 interface and an IPv4 interface. However, a dual-stack host
might have more than two logical interfaces because of a VPN (where a
third interface is the tunnel address, often assigned by the remote
corporate network) or because of multiple physical interfaces such as
wired and wireless Ethernet, because the host belongs to multiple
VLANs, or other reasons. The interaction of Happy Eyeballs with more
than two logical interfaces is for further study.</t>
</section>
<section title="A and AAAA Resource Records">
<t>It is possible that an DNS query for an A or AAAA resource record
will return more than one A or AAAA address. When this occurs, it is
RECOMMENDED that a Happy Eyeballs implementation order the responses
following the host's address preference policy and then try the first
address. If that fails after a certain time (see <xref
target="timeout"></xref>), the next address SHOULD be the IPv4
address.</t>
<t>If that fails to connect after a certain time (see <xref
target="timeout"></xref>), a Happy Eyeballs implementation SHOULD try
the other addresses returned; the order of these connection attempts
is not important.</t>
<t>On the Internet today, servers commonly have multiple A records to
provide load balancing across their servers. This same technique
would be useful for AAAA records, as well. However, if multiple AAAA
records are returned to a non-Happy Eyeballs client that has broken
IPv6 connectivity, it will further increase the delay to fall back to
IPv4. Thus, web site operators with native IPv6 connectivity SHOULD
NOT offer multiple AAAA records. If Happy Eyeballs is widely deployed
in the future, this recommendation might be revisited.</t>
</section>
<!--
<section title="A6 Resource Records">
<t>The A6 resource record SHOULD NOT be
queried <xref target="RFC3363"></xref>.</t>
</section>
-->
<section anchor="timeout" title="Connection time out">
<t>The primary purpose of Happy Eyeballs is to reduce the wait time
for a dual stack connection to complete, especially when the IPv6 path
is broken and IPv6 is preferred. Aggressive time outs (on the order of
tens of milliseconds) achieve this goal, but at the cost of network
traffic. This network traffic may be billable on certain networks,
will create state on some middleboxes (e.g., firewalls, IDS, NAT), and
will consume ports if IPv4 addresses are shared. For these reasons, it
is RECOMMENDED that connection attempts be paced to give connections a
chance to complete. It is RECOMMENDED that connections attempts be
paced 150-250ms apart, to balance human factors against network load. Stateful algorithms are expected to be more
aggressive (that is, make connection attempts closer together), as
stateful algorithms maintain an estimate of the expected connection
completion time.</t>
</section>
<section anchor="section_sop"
title="Interaction with Same Origin Policy">
<t>Web browsers implement a Same Origin Policy <xref
target="RFC6454"></xref> which causes subsequent
connections to the same hostname to go to the same IPv4 (or IPv6)
address as the previous successful connection. This is done to prevent
certain types of attacks.</t>
<t>The same-origin policy harms user-visible responsiveness if a new
connection fails (e.g., due to a transient event such as router
failure or load balancer failure). While it is tempting to use Happy
Eyeballs to maintain responsiveness, web browsers MUST NOT change
their Same Origin Policy because of Happy Eyeballs, as that would
create an additional security exposure. <!--
<list style="empty"><t>Note: most web browsers will bypass their
cached information (re-query DNS, re-fetch content) with a special
refresh sequence (e.g., Shift Refresh).</t></list>
--></t>
</section>
<section title="Implementation Strategies">
<t>The simplest venue for implementation of Happy Eyeballs is
within the application itself. The algorithm specified in
this document is relatively simple to implement, and would
require no specific support from the operating system beyond
the commonly-available APIs that provide transport service.
It could also be added to applications by way of a specific
Happy Eyeballs API, replacing or augmenting the transport
service APIs.</t>
<t>To improve IPv6 connectivity experience for legacy applications
(e.g., applications which simply rely on the operating
system's address preference order), operating systems may
consider more sophisticated approaches. These can include
changing default address selection sorting
(<xref target="RFC3484"></xref>) based on configuration
received from the network, or observing connection failures to
IPv6 and IPV4 destinations.</t>
</section>
</section>
<section title="Example Algorithm">
<t>What follows is the algorithm implemented in Google Chrome and
Mozilla Firefox.</t>
<t><list style="numbers">
<t>Call getaddinfo(), which returns a list of IP addresses sorted by
the host's address preference policy.</t>
<t>Initiate a connection attempt with the first address in that list
(e.g., IPv6).</t>
<t>If that connection does not complete within a short
period of time (Firefox and Chrome use 300ms),
initiate a connection attempt with the first address
belonging to the other address family (e.g., IPv4)</t>
<t>The first connection that is established is used. The other
connection is discarded.</t>
</list></t>
<t>If an algorithm were to cache connection success/failure, the
caching would occur after step 4 determined which connection was
successful.</t>
<t>Other example algorithms include <xref target="Perreault"></xref> and
<xref target="Andrews"></xref>.</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>See <xref target="abandon"></xref> and <xref
target="section_sop"></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>), the
current IPv4/IPv6 behavior of SMTP mail transfer agents, and the
implementation of Happy Eyeballs in Google Chrome and Mozilla
Firefox.</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, Matt Miller, Dave Thaler, Dmitry Anipko, Brian
Carpenter, and David Crocker for their feedback.</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, Mark Smith, Gert Doering, Martin Millnert, Tim Durack,
Matthew Palmer.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3484'?>
</references>
<references title="Informational References">
<?rfc include='reference.RFC.6157'?>
<?rfc include='reference.RFC.1671'?>
<?rfc include='reference.RFC.5245'?>
<?rfc include='reference.RFC.6059'?>
<?rfc include='reference.RFC.4436'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.RFC.6454'?>
<!--
<?rfc include='reference.I-D.chen-mif-happy-eyeballs-extension'?>
-->
<?rfc include='reference.I-D.ietf-6man-addr-select-opt'?>
<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" initials="S" surname="Perreault">
<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" initials="M" surname="Andrews">
<organization>ISC</organization>
</author>
<date month="January" year="2011" />
</front>
</reference>
<!--
<reference anchor="sop"
target="http://www.w3.org/Security/wiki/Same_Origin_Policy">
<front>
<title>Same Origin Policy</title>
<author fullname="W3C" surname="W3C">
<organization></organization>
</author>
<date month="January" year="2010" />
</front>
</reference>
-->
<reference anchor="Experiences"
target="http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf">
<front>
<title>Experiences of host behavior in broken IPv6 networks</title>
<author fullname="Teemu Savolainen" initials="T."
surname="Savolainen">
<organization></organization>
</author>
<author fullname="Natalia Miettinen" initials="N."
surname="Miettinen">
<organization></organization>
</author>
<author fullname="Simo Veikkolainen" initials="S."
surname="Veikkolainen">
<organization></organization>
</author>
<author fullname="Tim Chown" initials="T." surname="Chown">
<organization></organization>
</author>
<author fullname="James" initials="J." surname="Morse">
<organization></organization>
</author>
<date month="March" 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>
<section title="Changes">
<t>[RFC Editor: Please remove this section prior to publication
as an RFC.]</t>
<section title="changes from -06 to -07">
<t><list style="symbols">
<t>Changed "xmpp clients" to "instant messaging clients".</t>
<t>For debugging/troubleshooting, providing a log of activity or a way
to see current settings is useful.</t>
<t>tweaked abstract</t>
<t>"URIs and hostnames" -> "hostnames"</t>
<t>tweaked text on caching</t>
<t>interfaces (not hosts) notice when they are connected to a new network.</t>
<t>encourage implementations to provide log or other way to view Happy
Eyeballs settings.</t>
<t>detailed that implementation can be in OS or in application.</t>
<t>150-250ms is for human factors</t>
</list></t>
</section>
<section title="changes from -05 to -06">
<t><list style="symbols">
<t>Added paragraph describing current AAAA practice on the
Internet (one AAAA record) due to non-Happy Eyeballs
implementations, per opsdir review.</t>
<t>fixed "=" in Figure 1.</t>
<t>Removed text discussing A6. A6 is being deprecated in another
document, and querying A6 is not a significant operational problem
on the Internet.</t>
</list></t>
</section>
<section title="changes from -04 to -05">
<t><list style="symbols">
<t>Updated citations.</t>
</list></t>
</section>
<section title="changes from -03 to -04">
<t><list style="symbols">
<t>Make RFC3363 a non-normative reference.</t>
</list></t>
</section>
<section title="changes from -03 to -04">
<t><list style="symbols">
<t>Better explained why IPv6 needs to be preferred</t>
<t>Don't query A6.</t>
</list></t>
</section>
<section title="changes from -02 to -03">
<t><list style="symbols">
<t>Re-casted this specification as a list of requirements for a
compliant algorithm, rather than trying to dictate a One True
algorithm.</t>
</list></t>
</section>
<section title="changes from -01 to -02">
<t><list style="symbols">
<t>Now honors host's address preference (RFC3484 and friends)</t>
<t>No longer requires thread-safe DNS library. It uses
getaddrinfo()</t>
<t>No longer describes threading.</t>
<t>IPv6 is given a 200ms head start (Initial Headstart
variable).</t>
<t>If the IPv6 and IPv4 connection attempts were made at nearly
the same time, wait Tolerance Interval milliseconds for both to
complete before deciding which one wins.</t>
<t>Renamed "global P" to "Smoothed P", and better described how it
is calculated.</t>
<t>introduced the exception cache. This contains the set of
networks that only work with IPv4 (or only with IPv6), so that
subsequent connection attempts use that address family without
them causing serious affect to Smoothed P.</t>
<t>encourages that every 10 minutes the exception cache and
Smoothed P be reset. This allows IPv6 to be attempted again, so we
don't get 'stuck' on IPv4.</t>
<t>If we didn't get both A and AAAA, abandon all Happy Eyeballs
processing (thanks to Simon Perreault).</t>
<t>added discussion of Same Origin Policy</t>
<t>Removed discussion of NAT-PT and address learning; those are
only used with IPv6-only hosts whereas this document is about
dual-stack hosts contacting dual-stack servers.</t>
</list></t>
</section>
<section title="changes from -00 to -01">
<t><list style="symbols">
<t>added SRV section (thanks to Matt Miller)</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:59:45 |