One document matched: draft-ietf-v6ops-happy-eyeballs-05.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-05"
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 the IPv4 server and path is working but the IPv6 server or IPv6
path is down, 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
delay, and provides an example 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 can improve the user experience 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>
<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 URI and hostname be used for IPv4 and
IPv6. Using separate namespaces (e.g., "ipv6.example.com") 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 broken to specific prefixes or specific hosts, 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. The
following diagram shows this behavior.</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 if
connections to the host's IPv6 or IPv4 address were successful. The
client MUST cache that information to avoid thrashing the network with
excessive subsequent connection attempts. For example, in the diagram
above, the client has noticed that IPv6 to that address failed, and it
should provide a greater preference to using IPv4 instead.</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>In the near future, there will be a mix of different hosts at
individual subscribers homes -- hosts that are IPv4-only, hosts that
are IPv6-only (e.g., sensors), and dual-stack. This mix of hosts will
exist both within a single home and between subscribers. For example
an IPv4-only television or video streaming device purchased last year
and moved from the living room to a bedroom. 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. 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 less and 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 preferring 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). Such an implementation MUST occasionally make connection
attempts using the host's preferred address family, as it may have
become functional again, and is RECOMMENDED to do so every 10 minutes.
Implementation note: this can be achieved by attempting to connect to
both address families at the same time every 10 minutes, which does
not significantly harm the application's 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 host is connected to a new network.
Hosts can determine network (re-)initialization by a variety of
mechanisms (e.g., <xref target="RFC4436">DNAv4</xref>, <xref
target="RFC6059">DNAv6</xref>).</t>
<!--
<t><list style="empty">
<t>Justification: This provides the best chance that IPv6 will be
attempted over the new interface.</t>
</list></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="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 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, fortunately
IPv6/IPv4 translators are not deployed on networks with dual stack
clients.</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.</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 might have more than two interfaces
because of a VPN (where a third interface is the tunnel address, often
assigned by the remote corporate network), 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 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>
</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. 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="I-D.ietf-websec-origin"></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="Happy Eyeballs in an Operating System">
<t>Applications would have to change in order to use the mechanism
described in this document, by either implementing the mechanism
directly, or by calling APIs made available to them. 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 address sorting 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 (e.g., 200-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>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, and Brian
Carpenter 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.3363'?>
<?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.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>
<?rfc include='reference.I-D.ietf-websec-origin'?>
<!--
<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">
<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:57:52 |