doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6555.txt b/doc/rfc/rfc6555.txt
new file mode 100644
index 0000000..0e53ea1
--- /dev/null
+++ b/doc/rfc/rfc6555.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           D. Wing
+Request for Comments: 6555                                A. Yourtchenko
+Category: Standards Track                                          Cisco
+ISSN: 2070-1721                                               April 2012
+
+
+             Happy Eyeballs: Success with Dual-Stack Hosts
+
+Abstract
+
+   When a server's IPv4 path and protocol are 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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6555.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 1]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Additional Network and Host Traffic  . . . . . . . . . . .  3
+   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
+   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Hostnames  . . . . . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  Delay When IPv6 Is Not Accessible  . . . . . . . . . . . .  5
+   4.  Algorithm Requirements . . . . . . . . . . . . . . . . . . . .  6
+     4.1.  Delay IPv4 . . . . . . . . . . . . . . . . . . . . . . . .  7
+     4.2.  Stateful Behavior When IPv6 Fails  . . . . . . . . . . . .  8
+     4.3.  Reset on Network (Re-)Initialization . . . . . . . . . . .  9
+     4.4.  Abandon Non-Winning Connections  . . . . . . . . . . . . .  9
+   5.  Additional Considerations  . . . . . . . . . . . . . . . . . . 10
+     5.1.  Determining Address Type . . . . . . . . . . . . . . . . . 10
+     5.2.  Debugging and Troubleshooting  . . . . . . . . . . . . . . 10
+     5.3.  Three or More Interfaces . . . . . . . . . . . . . . . . . 10
+     5.4.  A and AAAA Resource Records  . . . . . . . . . . . . . . . 10
+     5.5.  Connection Timeout . . . . . . . . . . . . . . . . . . . . 11
+     5.6.  Interaction with Same-Origin Policy  . . . . . . . . . . . 11
+     5.7.  Implementation Strategies  . . . . . . . . . . . . . . . . 12
+   6.  Example Algorithm  . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 2]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+1.  Introduction
+
+   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 (Section 3).  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., [WHITELIST]).
+   However, this does not scale well (to the number of DNS servers
+   worldwide or the number of content providers worldwide) and does
+   react to intermittent network path outages.
+
+   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 not be inordinately harmed with a simple
+   doubling of traffic on IPv6 and IPv4 and the host's address
+   preference be honored (e.g., [RFC3484]).
+
+1.1.  Additional Network and Host Traffic
+
+   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.
+
+   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 and, most importantly, to reduce the load on
+   IPv4 network address translators).  The user experience is improved
+   to the slight detriment of the network, DNS server, and server that
+   are serving the user.
+
+2.  Notational Conventions
+
+   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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 3]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+3.  Problem Statement
+
+   The basis of the IPv6/IPv4 selection problem was first described in
+   1994 in [RFC1671]:
+
+      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.)
+
+   As discussed in more detail in Section 3.1, it is important that the
+   same hostname be used for IPv4 and IPv6.
+
+   As discussed in more detail in Section 3.2, IPv6 connectivity is
+   broken to specific prefixes or specific hosts or is slower than
+   native IPv4 connectivity.
+
+   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 Interactive Connectivity
+   Establishment (ICE) to select a working IPv6 or IPv4 media path
+   [RFC6157]).
+
+3.1.  Hostnames
+
+   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.
+
+   The algorithm described in this document allows production hostnames
+   to avoid these problematic references to IPv4 or IPv6.
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 4]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+3.2.  Delay When IPv6 Is Not Accessible
+
+   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.
+
+   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.
+
+   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.
+
+           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------->|
+
+                 Figure 1: Existing Behavior Message Flow
+
+   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.
+
+   Delays experienced by users of various browser and operating system
+   combinations have been studied [Experiences].
+
+
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 5]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+4.  Algorithm Requirements
+
+   A "Happy Eyeballs" algorithm has two primary goals:
+
+   1.  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.
+
+   2.  Avoids thrashing the network, by not (always) making simultaneous
+       connection attempts on both IPv6 and IPv4.
+
+   The basic idea is depicted in the following diagram:
+
+           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   |
+
+               Figure 2: Happy Eyeballs Flow 1, IPv6 Broken
+
+   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).
+
+   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 it uses that information to avoid thrashing
+   the network with subsequent attempts.  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 10 minutes.
+
+
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 6]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+           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------->|
+
+               Figure 3: Happy Eyeballs Flow 2, IPv6 Working
+
+   The diagram above shows a case where both IPv6 and IPv4 are working,
+   and IPv4 is abandoned (12).
+
+   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.
+
+4.1.  Delay IPv4
+
+   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 hosts.  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.
+
+   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 they can utilize the technique
+   described in this document.  The IPv4-only hosts have a disadvantage:
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 7]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+   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 it by using
+   IPv6.
+
+   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).
+
+   When deploying IPv6, both content providers and Internet Service
+   Providers (who supply mechanisms for IPv4 address sharing 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 the connection speed ignores the benefits that
+   IPv6 brings when compared with IPv4 address sharing, such as improved
+   geo-location [RFC6269] and the lack of fate-sharing due to traversing
+   a large translator.
+
+   Thus, to avoid harming IPv4-only hosts, implementations MUST prefer
+   the first IP address family returned by the host's address preference
+   policy, unless implementing a stateful algorithm described in
+   Section 4.2.  This usually means giving preference to IPv6 over IPv4,
+   although that preference can be overridden by user configuration or
+   by network configuration [ADDR-SELECT].  If the host's policy is
+   unknown or not attainable, implementations MUST prefer IPv6 over
+   IPv4.
+
+4.2.  Stateful Behavior When IPv6 Fails
+
+   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.
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 8]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+   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 Section 5.5), a Happy Eyeballs implementation will
+   decide to initiate a second connection attempt using the same address
+   family or the other address family.
+
+   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 retrying 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 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).
+
+4.3.  Reset on Network (Re-)Initialization
+
+   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., Detecting Network Attachment in IPv4 (DNAv4)
+   [RFC4436], DNAv6 [RFC6059]).
+
+   If the client application is a web browser, see also Section 5.6.
+
+4.4.  Abandon Non-Winning Connections
+
+   It is RECOMMENDED that the non-winning connections be abandoned, even
+   though they could -- in some cases -- be put to reasonable use.
+
+      Justification: This reduces the load on the server (file
+      descriptors, TCP control blocks) and stateful middleboxes (NAT and
+      firewalls).  Also, if the abandoned connection is IPv4, this
+      reduces IPv4 address sharing contention.
+
+      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
+
+
+
+Wing & Yourtchenko           Standards Track                    [Page 9]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+      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
+      Section 5.6).
+
+5.  Additional Considerations
+
+   This section discusses considerations related to Happy Eyeballs.
+
+5.1.  Determining Address Type
+
+   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.
+
+5.2.  Debugging and Troubleshooting
+
+   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).
+
+5.3.  Three or More Interfaces
+
+   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), 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.
+
+5.4.  A and AAAA Resource Records
+
+   It is possible that a 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
+
+
+
+Wing & Yourtchenko           Standards Track                   [Page 10]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+   address.  If that fails after a certain time (see Section 5.5), the
+   next address SHOULD be the IPv4 address.
+
+   If that fails to connect after a certain time (see Section 5.5), a
+   Happy Eyeballs implementation SHOULD try the other addresses
+   returned; the order of these connection attempts is not important.
+
+   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 client that is not using Happy Eyeballs and
+   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.
+
+5.5.  Connection Timeout
+
+   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 timeouts (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, intrusion
+   detection systems, NATs), 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 connection attempts be paced 150-250 ms 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.
+
+5.6.  Interaction with Same-Origin Policy
+
+   Web browsers implement a same-origin policy [RFC6454] that 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.
+
+   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.
+
+
+
+
+Wing & Yourtchenko           Standards Track                   [Page 11]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+5.7.  Implementation Strategies
+
+   The simplest venue for the 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.
+
+   To improve the IPv6 connectivity experience for legacy applications
+   (e.g., applications that 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 [RFC3484] based on configuration received from the
+   network, or observing connection failures to IPv6 and IPV4
+   destinations.
+
+6.  Example Algorithm
+
+   What follows is the algorithm implemented in Google Chrome and
+   Mozilla Firefox.
+
+   1.  Call getaddinfo(), which returns a list of IP addresses sorted by
+       the host's address preference policy.
+
+   2.  Initiate a connection attempt with the first address in that list
+       (e.g., IPv6).
+
+   3.  If that connection does not complete within a short period of
+       time (Firefox and Chrome use 300 ms), initiate a connection
+       attempt with the first address belonging to the other address
+       family (e.g., IPv4).
+
+   4.  The first connection that is established is used.  The other
+       connection is discarded.
+
+   If an algorithm were to cache connection success/failure, the caching
+   would occur after step 4 determined which connection was successful.
+
+   Other example algorithms include [Perreault] and [Andrews].
+
+7.  Security Considerations
+
+   See Sections 4.4 and 5.6.
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                   [Page 12]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+8.  Acknowledgements
+
+   The mechanism described in this paper was inspired by Stuart
+   Cheshire's discussion at the IAB Plenary at IETF 72, the author's
+   understanding of Safari's operation with SRV records, ICE [RFC5245],
+   the current IPv4/IPv6 behavior of SMTP mail transfer agents, and the
+   implementation of Happy Eyeballs in Google Chrome and Mozilla
+   Firefox.
+
+   Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van
+   Beijnum for fostering the creation of this document.
+
+   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.
+
+   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.
+
+   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, and Matthew Palmer.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3484]     Draves, R., "Default Address Selection for Internet
+                 Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+9.2.  Informative References
+
+   [ADDR-SELECT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
+                 "Distributing Address Selection Policy using DHCPv6",
+                 Work in Progress, February 2012.
+
+   [Andrews]     Andrews, M., "How to connect to a multi-homed server
+                 over TCP", January 2011, <http://www.isc.org/community/
+                 blog/201101/how-to-connect-to-a-multi-homed-server-
+                 over-tcp>.
+
+
+
+Wing & Yourtchenko           Standards Track                   [Page 13]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+   [Experiences] Savolainen, T., Miettinen, N., Veikkolainen, S., Chown,
+                 T., and J. Morse, "Experiences of host behavior in
+                 broken IPv6 networks", March 2011,
+                 <http://www.ietf.org/proceedings/80/slides/
+                 v6ops-12.pdf>.
+
+   [Perreault]   Perreault, S., "Happy Eyeballs in Erlang", February
+                 2011, <http://www.viagenie.ca/news/
+                 index.html#happy_eyeballs_erlang>.
+
+   [RFC1671]     Carpenter, B., "IPng White Paper on Transition and
+                 Other Considerations", RFC 1671, August 1994.
+
+   [RFC4436]     Aboba, B., Carlson, J., and S. Cheshire, "Detecting
+                 Network Attachment in IPv4 (DNAv4)", RFC 4436, March
+                 2006.
+
+   [RFC5245]     Rosenberg, J., "Interactive Connectivity Establishment
+                 (ICE): A Protocol for Network Address Translator (NAT)
+                 Traversal for Offer/Answer Protocols", RFC 5245, April
+                 2010.
+
+   [RFC6059]     Krishnan, S. and G. Daley, "Simple Procedures for
+                 Detecting Network Attachment in IPv6", RFC 6059,
+                 November 2010.
+
+   [RFC6157]     Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
+                 Transition in the Session Initiation Protocol (SIP)",
+                 RFC 6157, April 2011.
+
+   [RFC6269]     Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+                 Roberts, "Issues with IP Address Sharing", RFC 6269,
+                 June 2011.
+
+   [RFC6454]     Barth, A., "The Web Origin Concept", RFC 6454, December
+                 2011.
+
+   [WHITELIST]   Google, "Google over IPv6",
+                 <http://www.google.com/intl/en/ipv6>.
+
+
+
+
+
+
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                   [Page 14]
+
+RFC 6555                Happy Eyeballs Dual Stack             April 2012
+
+
+Authors' Addresses
+
+   Dan Wing
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: dwing@cisco.com
+
+
+   Andrew Yourtchenko
+   Cisco Systems, Inc.
+   De Kleetlaan, 7
+   Diegem  B-1831
+   Belgium
+
+   EMail: ayourtch@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wing & Yourtchenko           Standards Track                   [Page 15]
+