Internet Engineering Task Force (IETF) D. Wing
Request for Comments: 6555 A. Yourtchenko
Category: Standards Track Cisco
ISSN: 2070-1721 April 2012
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.
当服务器的IPv4路径和协议正常工作，但服务器的IPv6路径和协议不正常工作时，与仅IPv4的客户端相比，双堆栈客户端应用程序会经历显著的连接延迟。这是不可取的，因为它会导致双堆栈客户端的用户体验更差。本文件规定了减少用户可见延迟的算法要求，并提供了一种算法。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.
为了在IPv6上使用应用程序，用户必须享受与IPv4几乎相同的性能。当今的应用程序、IPv6隧道、IPv6服务提供商和一些内容提供商的组合都会影响用户体验（第3节）。对于IPv6，内容提供商可通过使用直接与其对等的IPv6服务提供商的DNS白名单（例如，[白名单]）来确保积极的用户体验。但是，这并不能很好地扩展（与全球DNS服务器的数量或全球内容提供商的数量相比），并且会对间歇性网络路径中断做出反应。
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]).
相反，应用程序通过更积极地在IPv6和IPv4上建立连接来减少连接设置延迟。可以设想有多种算法。本文件规定了任何此类算法的要求，其目标是在IPv6和IPv4上流量简单翻倍时不会对网络和服务器造成过度损害，并遵守主机的地址首选项（例如[RFC3484]）。
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.
由于本文档中的建议，会产生额外的网络流量和额外的服务器负载，尤其是当与首选地址系列（通常为IPv6）的连接未快速完成时。
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.
本文档中描述的过程在从仅IPv4过渡到双栈的过程中保留了高质量的用户体验，同时仍然使IPv6略优于IPv4（以消除IPv4网络的负载，最重要的是减少IPv4网络地址转换器的负载）。用户体验得到了改善，但对网络、DNS服务器和为用户服务的服务器造成了轻微损害。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The basis of the IPv6/IPv4 selection problem was first described in 1994 in [RFC1671]:
IPv6/IPv4选择问题的基础于1994年在[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.)
双堆栈代码可以从DNS返回两个地址；它用哪一种？在多年的过渡期间，互联网将包含黑洞。例如，在从IPng主机A到IPng主机B的途中，有时（不可预测地）会有丢弃IPng数据包的仅IPv4路由器。此外，DNS的状态不一定符合实际情况。DNS声称知道IPng地址的主机在特定时刻实际上可能没有运行IPng；因此，发送到该主机的IPng数据包在交付时将被丢弃。知道主机同时具有IPv4和IPng地址不会提供有关黑洞的信息。必须提出解决方案，且不得依赖手动维护的信息。（如果不解决这个问题，双堆栈方法并不比数据包转换方法好。）
As discussed in more detail in Section 3.1, it is important that the same hostname be used for IPv4 and IPv6.
如第3.1节所述，IPv4和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.
如第3.2节中更详细讨论的，IPv6连接断开到特定前缀或特定主机，或者比本机IPv4连接慢。
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]).
本文档中描述的机制直接适用于面向连接的传输（例如TCP、SCTP），这是本文档的范围。对于无连接传输协议（例如UDP），如果应用程序具有请求/响应语义（例如，通过交互式连接建立（ICE）选择工作IPv6或IPv4媒体路径[RFC6157]），则可以使用类似的机制。
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.
主机名通常在用户之间用于交换指向内容的指针，例如在社交网络、电子邮件、即时消息或其他系统上。使用单独的名称空间（例如“ipv6.example.com”），这些名称空间只能通过某些客户端技术（例如ipv6客户端）和依赖项（例如工作的ipv6路径）访问，这会导致名称空间碎片，并降低用户共享主机名的能力。它还使包含主机名的打印材料复杂化。
The algorithm described in this document allows production hostnames to avoid these problematic references to IPv4 or IPv6.
本文档中描述的算法允许生产主机名避免对IPv4或IPv6的这些有问题的引用。
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.
当IPv6连接受损时，今天支持IPv6的应用程序（例如，web浏览器、电子邮件客户端、即时消息客户端）在返回IPv4之前会延迟数秒。这会延迟整个应用程序的运行，包括损害用户对IPv6的体验，这将减缓IPv6的接受，因为IPv6经常在终端系统上被完全禁用，以改善用户体验。
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.
此类故障的原因包括未连接到IPv6 Internet、6to4或Teredo隧道中断以及IPv6对等中断。下图显示了此行为。
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------->|
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
图1：现有行为消息流
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.
客户端获取服务器（1-4）的IPv4和IPv6记录。客户端尝试使用IPv6连接到服务器，但IPv6路径断开（6-8），这需要几秒钟的时间。最终，客户端尝试使用IPv4（10）进行连接，成功。
Delays experienced by users of various browser and operating system combinations have been studied [Experiences].
研究了不同浏览器和操作系统组合的用户所经历的延迟[经验]。
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.
1. 通过快速尝试使用IPv6连接和（如果该连接尝试未快速成功）使用IPv4连接，为用户提供快速连接。
2. Avoids thrashing the network, by not (always) making simultaneous connection attempts on both IPv6 and IPv4.
2. 通过不（总是）在IPv6和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 |
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
图2：快乐眼球流1，IPv6断开
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).
在上图中，客户端同时通过IPv6（6）和IPv4（7）发送两个TCP SYN。在图中，IPv6路径已断开，但对用户几乎没有影响，因为在使用IPv4之前没有长时间延迟。将重试IPv6路径，直到应用程序放弃（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.
执行上述过程后，客户端将了解到与主机的IPv6或IPv4地址的连接是否成功。客户端必须缓存有关每次连接尝试结果的信息，并使用该信息避免后续尝试对网络造成冲击。在上面的示例中，缓存指示IPv6连接尝试失败，因此系统将首选IPv4。当缓存项的期限超过系统定义的最大期限（约10分钟）时，应刷新缓存项。
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------->|
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
图3：快乐眼球流2，IPv6工作
The diagram above shows a case where both IPv6 and IPv4 are working, and IPv4 is abandoned (12).
上图显示了IPv6和IPv4都在工作，而IPv4被放弃的情况（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.
只要客户机主机是双重堆叠的，任何快乐眼球算法都会在产品中持续存在，只要互联网上只有IPv4服务器——即所谓的“长尾”，这种算法就会持续存在。随着时间的推移，由于大多数内容可通过IPv6获得，IPv4通信量将减少。这意味着，随着时间的推移，IPv4基础设施的大小将能够适应减少的（和减少的）通信量。重要的是，快乐眼球算法不会在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.
向IPv6的过渡可能会在子网中产生不同主机的混合—仅IPv4主机、仅IPv6主机（例如传感器）和双堆栈主机。这种主机组合既存在于管理域内（单个家庭、企业、酒店或咖啡店），也存在于管理域之间。例如，一个单独的家庭可能在一个房间里有一台只支持IPv4的电视，而在另一个房间里有一台双栈电视。另一个例子是，另一个订阅者可能拥有能够进行双堆栈操作的主机。
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:
由于IPv4耗尽，订阅者的主机（仅IPv4主机和双堆栈主机）可能与其他订阅者共享IPv4地址。双栈主机有一个优势：它们可以利用IPv6或IPv4，这意味着它们可以利用本文档中描述的技术。仅IPv4主机有一个缺点：
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.
他们只能使用IPv4。如果所有主机（仅限双栈和IPv4）都在使用IPv4，则会存在对共享IPv4地址的额外争用。只有IPv4的主机无法避免这种争用（因为它们只能使用IPv4），而双堆栈主机可以通过使用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).
随着双栈主机的激增和内容通过IPv6变得可用，IPv4流量将相应减少。这一点尤其适用于未实现愉快眼球的双栈主机，因为这些双栈主机非常倾向于使用IPv6（在尝试使用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.
在部署IPv6时，内容提供商和互联网服务提供商（提供IPv4地址共享机制，如运营商级NAT（CGN））都希望减少对IPv4设备（负载平衡器、对等链路和地址共享设备）的投资。如果Happy Eyeballs实现通过连接到速度最快的地址系列来平等对待IPv6和IPv4，那么它将有助于增加IPv4上的负载。此负载影响仅IPv4的设备（通过增加IPv4地址共享的争用和增加IPv4负载平衡器上的负载）。因此，ISP和内容提供商将发现不可能减少对IPv4设备的投资。这意味着迁移到IPv6的成本增加，因为IPv4的投资无法减少。此外，仅使用衡量连接速度的指标忽略了IPv6与IPv4地址共享相比所带来的好处，例如改进的地理位置[RFC6269]，以及由于穿越大型转换器而缺乏命运共享。
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.
因此，为了避免损害仅IPv4主机，除非实现第4.2节中描述的有状态算法，否则实现必须首选主机地址首选策略返回的第一个IP地址族。这通常意味着优先选择IPv6而不是IPv4，尽管用户配置或网络配置[ADDR-SELECT]可以覆盖该优先选择。如果主机的策略未知或无法实现，则实现必须首选IPv6而不是IPv4。
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.
一些令人高兴的眼球算法是有状态的——也就是说，该算法将记住IPv6总是失败，或者某些前缀的IPv6总是失败，等等。本节介绍此类算法。无状态算法不记得以前连接的成功/失败，本节不讨论这些算法。
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.
在对首选地址系列（如IPv6）进行连接尝试后，在特定时间段内未能建立连接（见第5.5节），Happy Eyeballs实现将决定使用同一地址系列或其他地址系列启动第二次连接尝试。
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).
这样的实现可以在成功的地址系列（例如，IPv4）上进行后续连接尝试（到同一主机或到其他主机）。只要主机正在尝试新的连接，这种实现就必须偶尔使用主机的首选地址族进行连接尝试，因为它可能已经重新开始工作，并且应该每10分钟进行一次。重试失败的地址系列之前的10分钟延迟避免了IPv6和IPv4上连接尝试的简单加倍。实现说明：这可以通过每10分钟刷新一次Happy Eyeballs状态来实现，这不会显著影响应用程序后续的连接设置时间。如果使用首选地址系列的连接再次成功，则应将首选地址系列用于后续连接。由于此实现是有状态的，因此它可以基于IPv6或IPv4前缀跟踪连接成功（或失败）（例如，与分配给接口的相同前缀的连接成功，而与其他前缀的连接失败）。
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]).
因为每个网络都有不同的特征（例如，工作或中断的IPv6或IPv4连接），所以当接口连接到新网络时，快乐眼球算法应该重新初始化。接口可以通过多种机制确定网络（重新）初始化（例如，检测IPv4（DNAv4）[RFC4436]，DNAv6[RFC6059]中的网络连接）。
If the client application is a web browser, see also Section 5.6.
如果客户端应用程序是web浏览器，请参见第5.6节。
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.
理由：这减少了服务器（文件描述符、TCP控制块）和有状态中间盒（NAT和防火墙）上的负载。此外，如果放弃的连接是IPv4，这将减少IPv4地址共享争用。
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
HTTP：由于HTTP cookie包含客户端的IP地址，并且要求所有连接都来自同一IP地址，因此某些站点的设计可能会中断。如果有一些连接来自
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).
同一个客户端来自不同的IP地址（或者更糟糕的是，不同的IP地址系列），这样的应用程序将中断。此外，对于HTTP，使用非获胜连接可能会干扰浏览器的同源策略（请参阅第5.6节）。
This section discusses considerations related to Happy Eyeballs.
本节讨论与快乐眼球相关的注意事项。
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.
对于某些过渡技术（如双栈主机），应用程序很容易识别本机IPv6地址（通过AAAA查询了解）和本机IPv4地址（通过a查询了解）。虽然IPv6/IPv4转换很困难，但IPv6/IPv4转换器不需要部署在具有双堆栈客户端的网络上，因为双堆栈客户端可以使用其本机IP地址系列。
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).
该机制旨在确保可靠的用户体验，而不考虑影响任何单一传输的连接问题。然而，这自然意味着，默认情况下，采用这些技术的应用程序在诊断具有特定地址族的问题时不太有用。为了在这方面提供帮助，这些实现还可以提供一种机制，通过用户设置来禁用它们的快乐眼球行为，并提供对调试有用的数据（例如，日志或查看当前偏好的方式）。
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.
双栈主机通常有两个逻辑接口：IPv6接口和IPv4接口。但是，由于VPN（其中第三个接口是隧道地址，通常由远程公司网络分配）、多个物理接口（如有线和无线以太网）、主机属于多个VLAN或其他原因，双堆栈主机可能具有两个以上的逻辑接口。快乐眼球与两个以上逻辑接口的交互作用有待进一步研究。
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
a或AAAA资源记录的DNS查询可能会返回多个a或AAAA地址。出现这种情况时，建议Happy Eyeballs实现按照主机的地址首选项策略对响应进行排序，然后尝试第一种方法
address. If that fails after a certain time (see Section 5.5), the next address SHOULD be the IPv4 address.
住址如果在一段时间后失败（参见第5.5节），则下一个地址应为IPv4地址。
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.
如果在一段时间后连接失败（参见第5.5节），Happy Eyeballs实现应尝试返回的其他地址；这些连接尝试的顺序并不重要。
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.
在今天的互联网上，服务器通常有多个A记录，以在其服务器之间提供负载平衡。同样的技术也适用于AAAA记录。但是，如果将多个AAAA记录返回到未使用快乐眼球且已断开IPv6连接的客户端，则会进一步增加返回IPv4的延迟。因此，具有本机IPv6连接的网站运营商不应提供多个AAAA记录。如果“快乐眼球”在未来得到广泛应用，那么这一建议可能会被重新考虑。
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.
Happy Eyeballs的主要目的是减少完成双堆栈连接的等待时间，特别是当IPv6路径中断且首选IPv6时。主动超时（大约几十毫秒）实现了这一目标，但以网络流量为代价。这种网络流量可能在某些网络上计费，将在某些中间盒（例如防火墙、入侵检测系统、NAT）上创建状态，并且如果共享IPv4地址，则将使用端口。出于这些原因，建议对连接尝试进行调整，以使连接有机会完成。建议连接尝试间隔150-250毫秒，以平衡人为因素和网络负载。由于有状态算法保持对预期连接完成时间的估计，因此有状态算法预计会更具攻击性（即，使连接尝试更加紧密）。
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.
Web浏览器实施同一源策略[RFC6454]，该策略会导致到同一主机名的后续连接转到与先前成功连接相同的IPv4（或IPv6）地址。这样做是为了防止某些类型的攻击。
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.
如果新连接失败（例如，由于路由器故障或负载平衡器故障等瞬态事件），同源策略会损害用户可见的响应能力。虽然使用快乐眼球来保持响应性很有诱惑力，但web浏览器不能因为快乐眼球而更改其同源策略，因为这会造成额外的安全风险。
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.
实现快乐眼球的最简单场所是应用程序本身。本文档中指定的算法实现起来相对简单，除了提供传输服务的常用API之外，不需要操作系统的特定支持。还可以通过特定的Happy Eyeballs API将其添加到应用程序中，以替换或增强传输服务API。
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.
为了改进遗留应用程序的IPv6连接体验（例如，仅仅依赖于操作系统的地址偏好顺序的应用），操作系统可以考虑更复杂的方法。这些可能包括根据从网络接收到的配置更改默认地址选择排序[RFC3484]，或观察到IPv6和IPV4目标的连接故障。
What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.
下面是在Google Chrome和Mozilla Firefox中实现的算法。
1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
1. 调用getaddinfo（），它返回按主机的地址首选项策略排序的IP地址列表。
2. Initiate a connection attempt with the first address in that list (e.g., IPv6).
2. 使用该列表中的第一个地址（例如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).
3. 如果该连接未在短时间内完成（Firefox和Chrome使用300毫秒），请使用属于其他地址系列（例如IPv4）的第一个地址启动连接尝试。
4. The first connection that is established is used. The other connection is discarded.
4. 使用建立的第一个连接。另一个连接被丢弃。
If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.
如果算法要缓存连接成功/失败，则缓存将在步骤4确定哪个连接成功后发生。
Other example algorithms include [Perreault] and [Andrews].
其他示例算法包括[Perreault]和[Andrews]。
See Sections 4.4 and 5.6.
见第4.4节和第5.6节。
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.
本文中描述的机制受到Stuart Cheshire在IETF 72 IAB全体会议上的讨论、作者对Safari使用SRV记录的操作的理解、ICE[RFC5245]、SMTP邮件传输代理的当前IPv4/IPv6行为以及Google Chrome和Mozilla Firefox中快乐眼球的实现的启发。
Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van Beijnum for fostering the creation of this document.
感谢弗雷德·贝克（Fred Baker）、杰夫·金兹利（Jeff Kinzli）、克里斯蒂安·库茨（Christian Kuhtz）和伊尔吉奇·范·贝伊纳姆（Iljitsch van Beijnum）促成了本文件的创作。
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.
感谢Scott Brim、Rick Jones、Stig Venaas、Erik Kline、Bjoern Zeeb、Matt Miller、Dave Thaler、Dmitry Anipko、Brian Carpenter和David Crocker的反馈。
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.
感谢Javier Ubillos、Simon Perreault和Mark Andrews在他们创建的独立实践实现上的积极反馈和实验工作。
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.
此外，作者还想感谢以下参与有关此主题的各种电子邮件讨论的个人：莫哈西·雅诺斯、佩卡·萨沃拉、特德·莱蒙、卡洛斯·马丁内斯·卡格纳佐、西蒙·佩雷尔特、杰克·贝茨、杰罗恩·马萨、弗雷德·贝克、哈维尔·乌比略斯、蒂姆·萨沃莱宁、斯科特·布里姆、埃里克·克莱恩、卡梅隆·伯恩、丹尼尔·罗森、，纪尧姆·勒克兰奇、马克·史密斯、格特·多林、马丁·米尔纳特、蒂姆·杜拉克和马修·帕尔默。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[ADDR-SELECT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, February 2012.
[ADDR-SELECT]Matsumoto，A.，Fujisaki，T.，Kato，J.，和T.Chown，“使用DHCPv6分发地址选择策略”，正在进行的工作，2012年2月。
[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>.
[Andrews]Andrews，M.，“如何通过TCP连接到多主机服务器”，2011年1月<http://www.isc.org/community/ blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp>。
[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>.
[经验]Savolainen，T.，Miettinen，N.，Veikkolainen，S.，Chown，T.，和J.Morse，“破坏IPv6网络中主机行为的经验”，2011年3月<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>.
[Perreault]Perreault，S.，“二郎的快乐眼球”，2011年2月<http://www.viagenie.ca/news/ index.html#happy_眼球_erlang>。
[RFC1671] Carpenter, B., "IPng White Paper on Transition and Other Considerations", RFC 1671, August 1994.
[RFC1671]Carpenter，B.，“IPng关于过渡和其他考虑的白皮书”，RFC 16711994年8月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 60592010年11月。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157]Camarillo，G.，El Malki，K.，和V.Gurbani，“会话启动协议（SIP）中的IPv6转换”，RFC 6157，2011年4月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月。
[WHITELIST] Google, "Google over IPv6", <http://www.google.com/intl/en/ipv6>.
[白名单]谷歌，“IPv6上的谷歌”<http://www.google.com/intl/en/ipv6>.
Authors' Addresses
作者地址
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Andrew Yourtchenko Cisco Systems, Inc. De Kleetlaan, 7 Diegem B-1831 Belgium
Andrew Yourtchenko Cisco Systems，Inc.De Kleetlaan，7 Diegem B-1831比利时
EMail: ayourtch@cisco.com
EMail: ayourtch@cisco.com