Internet Engineering Task Force (IETF) D. Schinazi
Request for Comments: 8305 T. Pauly
Obsoletes: 6555 Apple Inc.
Category: Standards Track December 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Schinazi
Request for Comments: 8305 T. Pauly
Obsoletes: 6555 Apple Inc.
Category: Standards Track December 2017
ISSN: 2070-1721
Happy Eyeballs Version 2: Better Connectivity Using Concurrency
Happy Eyeballs版本2：使用并发实现更好的连接性
Abstract
摘要
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.
在现代互联网上运行的许多通信协议都使用主机名。这些通常解析为多个IP地址，每个IP地址可能具有不同的性能和连接特性。由于特定地址或地址族（IPv4或IPv6）可能在网络上被阻止、中断或次优，因此尝试并行多个连接的客户端有机会更快地建立连接。本文件规定了减少用户可见延迟的算法要求，并提供了一个称为“快乐眼球”的示例算法。本文件废弃了RFC 6555中的原始算法描述。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8305.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8305.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4
3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 5
4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 6
5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 7
6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 8
7. Supporting IPv6-Only Networks with NAT64 and DNS64 . . . . . 8
7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8
7.2. Hostnames with Broken AAAA Records . . . . . . . . . . . 9
7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 10
8. Summary of Configurable Values . . . . . . . . . . . . . . . 10
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 11
9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11
9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Differences from RFC 6555 . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Hostname Resolution Query Handling . . . . . . . . . . . . . 4
3.1. Handling Multiple DNS Server Addresses . . . . . . . . . 5
4. Sorting Addresses . . . . . . . . . . . . . . . . . . . . . . 6
5. Connection Attempts . . . . . . . . . . . . . . . . . . . . . 7
6. DNS Answer Changes during Happy Eyeballs Connection Setup . . 8
7. Supporting IPv6-Only Networks with NAT64 and DNS64 . . . . . 8
7.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 8
7.2. Hostnames with Broken AAAA Records . . . . . . . . . . . 9
7.3. Virtual Private Networks . . . . . . . . . . . . . . . . 10
8. Summary of Configurable Values . . . . . . . . . . . . . . . 10
9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Path Maximum Transmission Unit Discovery . . . . . . . . 11
9.2. Application Layer . . . . . . . . . . . . . . . . . . . . 11
9.3. Hiding Operational Issues . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Differences from RFC 6555 . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm.
在现代互联网上运行的许多通信协议都使用主机名。这些通常解析为多个IP地址，每个IP地址可能具有不同的性能和连接特性。由于特定地址或地址族（IPv4或IPv6）可能在网络上被阻止、中断或次优，因此尝试并行多个连接的客户端有机会更快地建立连接。本文件规定了减少用户可见延迟的算法要求，并提供了一个示例算法。
This document defines the algorithm for "Happy Eyeballs", a technique for reducing user-visible delays on dual-stack hosts. This definition obsoletes the original description in [RFC6555]. Now that this approach has been deployed at scale and measured for several years, the algorithm specification can be refined to improve its reliability and general applicability.
本文档定义了“快乐眼球”算法，这是一种减少双堆栈主机上用户可见延迟的技术。此定义废弃了[RFC6555]中的原始描述。现在，这种方法已经大规模部署并测量了几年，可以对算法规范进行改进，以提高其可靠性和普遍适用性。
The Happy Eyeballs algorithm of racing connections to resolved addresses has several stages to avoid delays to the user whenever possible, while preferring the use of IPv6. This document discusses how to handle DNS queries when starting a connection on a dual-stack client, how to create an ordered list of destination addresses to which to attempt connections, and how to race the connection attempts.
“快乐眼球”（Happy Eyeballs）算法将连接竞速到解析地址，该算法分为几个阶段，以尽可能避免用户延迟，同时更喜欢使用IPv6。本文档讨论在双堆栈客户端上启动连接时如何处理DNS查询，如何创建要尝试连接的目标地址的有序列表，以及如何竞争连接尝试。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（且仅在此处显示）应按照[RFC2119][RFC8174]所述进行解释。
This document defines a method of connection establishment, named the "Happy Eyeballs Connection Setup". This approach has several distinct phases:
本文档定义了一种建立连接的方法，称为“快乐眼球连接设置”。这种方法有几个不同的阶段：
1. Initiation of asynchronous DNS queries [Section 3]
1. 启动异步DNS查询[第3节]
2. Sorting of resolved destination addresses [Section 4]
2. 解析目的地址的排序[第4节]
3. Initiation of asynchronous connection attempts [Section 5]
3. 异步连接尝试的启动[第5节]
4. Establishment of one connection, which cancels all other attempts [Section 5]
4. 建立一个连接，取消所有其他尝试[第5节]
Note that this document assumes that the preference policy for the host destination address favors IPv6 over IPv4. IPv6 has many desirable properties designed to be improvements over IPv4 [RFC8200]. If the host is configured to have a different preference, the recommendations in this document can be easily adapted.
请注意，本文档假定主机目标地址的首选策略优先于IPv4。IPv6具有许多理想的特性，旨在改进IPv4[RFC8200]。如果主机配置为具有不同的首选项，则可以轻松调整本文档中的建议。
When a client has both IPv4 and IPv6 connectivity and is trying to establish a connection with a named host, it needs to send out both AAAA and A DNS queries. Both queries SHOULD be made as soon after one another as possible, with the AAAA query made first and immediately followed by the A query.
当客户端同时具有IPv4和IPv6连接并试图与命名主机建立连接时，它需要同时发送AAAA和DNS查询。这两个查询应该尽可能快地一个接一个地进行，首先进行AAAA查询，然后紧接着进行A查询。
Implementations SHOULD NOT wait for both families of answers to return before attempting connection establishment. If one query fails to return or takes significantly longer to return, waiting for the second address family can significantly delay the connection establishment of the first one. Therefore, the client SHOULD treat DNS resolution as asynchronous. Note that if the platform does not offer an asynchronous DNS API, this behavior can be simulated by making two separate synchronous queries on different threads, one per address family.
在尝试建立连接之前，实现不应该等待两个答案族返回。如果一个查询无法返回或返回所需的时间显著延长，等待第二个地址族可能会显著延迟第一个地址族的连接建立。因此，客户端应将DNS解析视为异步解析。请注意，如果平台不提供异步DNS API，则可以通过在不同线程上进行两个单独的同步查询（每个地址系列一个）来模拟此行为。
The algorithm proceeds as follows: if a positive AAAA response (a response with at least one valid AAAA record) is received first, the first IPv6 connection attempt is immediately started. If a positive A response is received first due to reordering, the client SHOULD wait a short time for the AAAA response to ensure that preference is given to IPv6 (it is common for the AAAA response to follow the A response by a few milliseconds). This delay will be referred to as the "Resolution Delay". The recommended value for the Resolution Delay is 50 milliseconds. If a positive AAAA response is received
该算法如下进行：如果首先收到肯定的AAAA响应（至少有一条有效AAAA记录的响应），则第一次IPv6连接尝试立即开始。如果由于重新排序而首先收到肯定的a响应，则客户端应等待AAAA响应一小段时间，以确保优先选择IPv6（AAAA响应通常在a响应之后几毫秒）。该延迟将被称为“解决延迟”。分辨率延迟的建议值为50毫秒。如果收到积极的AAAA响应
within the Resolution Delay period, the client immediately starts the IPv6 connection attempt. If a negative AAAA response (no error, no data) is received within the Resolution Delay period or the AAAA response has not been received by the end of the Resolution Delay period, the client SHOULD proceed to sorting addresses (see Section 4) and staggered connection attempts (see Section 5) using any IPv4 addresses returned so far. If the AAAA response arrives while these connection attempts are in progress but before any connection has been established, then the newly received IPv6 addresses are incorporated into the list of available candidate addresses (see Section 6) and the process of connection attempts will continue with the IPv6 addresses added, until one connection is established.
在解决延迟期内，客户端立即启动IPv6连接尝试。如果在解决延迟期内收到否定的AAAA响应（无错误，无数据），或者在解决延迟期结束时尚未收到AAAA响应，则客户端应使用迄今为止返回的任何IPv4地址继续对地址进行排序（参见第4节）和交错连接尝试（参见第5节）。如果AAAA响应在这些连接尝试进行中但在建立任何连接之前到达，则新收到的IPv6地址将并入可用候选地址列表（参见第6节），并且连接尝试过程将继续添加IPv6地址，直到建立了一个连接。
If multiple DNS server addresses are configured for the current network, the client may have the option of sending its DNS queries over IPv4 or IPv6. In keeping with the Happy Eyeballs approach, queries SHOULD be sent over IPv6 first (note that this is not referring to the sending of AAAA or A queries, but rather the address of the DNS server itself and IP version used to transport DNS messages). If DNS queries sent to the IPv6 address do not receive responses, that address may be marked as penalized and queries can be sent to other DNS server addresses.
如果为当前网络配置了多个DNS服务器地址，则客户端可以选择通过IPv4或IPv6发送其DNS查询。为了与“快乐眼球”方法保持一致，应首先通过IPv6发送查询（请注意，这不是指发送AAAA或A查询，而是指DNS服务器本身的地址和用于传输DNS消息的IP版本）。如果发送到IPv6地址的DNS查询未收到响应，则该地址可能会被标记为惩罚，并且可以将查询发送到其他DNS服务器地址。
As native IPv6 deployments become more prevalent and IPv4 addresses are exhausted, it is expected that IPv6 connectivity will have preferential treatment within networks. If a DNS server is configured to be accessible over IPv6, IPv6 should be assumed to be the preferred address family.
随着本机IPv6部署变得越来越普遍，IPv4地址耗尽，预计IPv6连接将在网络中得到优先处理。如果DNS服务器配置为可通过IPv6访问，则应假定IPv6是首选地址系列。
Client systems SHOULD NOT have an explicit limit to the number of DNS servers that can be configured, either manually or by the network. If such a limit is required by hardware limitations, the client SHOULD use at least one address from each address family from the available list.
客户端系统不应明确限制可以手动或通过网络配置的DNS服务器的数量。如果硬件限制要求这样的限制，则客户端应使用可用列表中每个地址系列中的至少一个地址。
Before attempting to connect to any of the resolved destination addresses, the client should define the order in which to start the attempts. Once the order has been defined, the client can use a simple algorithm for racing each option after a short delay (see Section 5). It is important that the ordered list involve all addresses from both families that have been received by this point, as this allows the client to get the racing effect of Happy Eyeballs for the entire list, not just the first IPv4 and first IPv6 addresses.
在尝试连接到任何已解析的目标地址之前，客户端应定义开始尝试的顺序。定义订单后，客户可以使用一个简单的算法在短时间延迟后对每个选项进行竞速（见第5节）。重要的是，有序列表包含到目前为止已收到的两个系列的所有地址，因为这允许客户端获得整个列表的快乐眼球的竞速效果，而不仅仅是第一个IPv4和第一个IPv6地址。
First, the client MUST sort the addresses received up to this point using Destination Address Selection ([RFC6724], Section 6).
首先，客户机必须使用目标地址选择（[RFC6724]，第6节）对目前为止接收到的地址进行排序。
If the client is stateful and has a history of expected round-trip times (RTTs) for the routes to access each address, it SHOULD add a Destination Address Selection rule between rules 8 and 9 that prefers addresses with lower RTTs. If the client keeps track of which addresses it used in the past, it SHOULD add another Destination Address Selection rule between the RTT rule and rule 9, which prefers used addresses over unused ones. This helps servers that use the client's IP address during authentication, as is the case for TCP Fast Open [RFC7413] and some Hypertext Transport Protocol (HTTP) cookies. This historical data MUST NOT be used across different network interfaces and SHOULD be flushed whenever a device changes the network to which it is attached.
如果客户端是有状态的，并且具有访问每个地址的路由的预期往返时间（RTT）的历史记录，那么它应该在规则8和9之间添加一个目标地址选择规则，该规则优先选择RTT较低的地址。如果客户机跟踪它过去使用的地址，它应该在RTT规则和规则9之间添加另一个目标地址选择规则，该规则优先使用已使用的地址而不是未使用的地址。这有助于服务器在身份验证期间使用客户端的IP地址，TCP Fast Open[RFC7413]和一些超文本传输协议（HTTP）cookies就是这样。此历史数据不得跨不同的网络接口使用，并且应在设备更改其所连接的网络时刷新。
Next, the client SHOULD modify the ordered list to interleave address families. Whichever address family is first in the list should be followed by an address of the other address family; that is, if the first address in the sorted list is IPv6, then the first IPv4 address should be moved up in the list to be second in the list. An implementation MAY want to favor one address family more by allowing multiple addresses of that family to be attempted before trying the other family. The number of contiguous addresses of the first address family will be referred to as the "First Address Family Count" and can be a configurable value. This is performed to avoid waiting through a long list of addresses from a given address family if connectivity over that address family is impaired.
接下来，客户机应该修改有序列表以交错地址族。列表中的第一个地址系列应紧跟另一个地址系列的地址；也就是说，如果排序列表中的第一个地址是IPv6，则列表中的第一个IPv4地址应上移到列表中的第二个。一个实现可能希望在尝试另一个地址族之前，允许尝试该地址族的多个地址，从而更偏向于该地址族。第一地址族的连续地址数将被称为“第一地址族计数”，并且可以是可配置的值。执行此操作是为了避免在给定地址族上的连接受损时等待该地址族的一长串地址。
Note that the address selection described in this section only applies to destination addresses; Source Address Selection ([RFC6724], Section 5) is performed once per destination address and is out of scope of this document.
注意，本节中描述的地址选择仅适用于目的地地址；源地址选择（[RFC6724]，第5节）针对每个目标地址执行一次，不在本文档范围内。
Once the list of addresses received up to this point has been constructed, the client will attempt to make connections. In order to avoid unreasonable network load, connection attempts SHOULD NOT be made simultaneously. Instead, one connection attempt to a single address is started first, followed by the others in the list, one at a time. Starting a new connection attempt does not affect previous attempts, as multiple connection attempts may occur in parallel. Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. Any address that was not yet attempted as a connection SHOULD be ignored. At that time, the asynchronous DNS query MAY be canceled as new addresses will not be used for this connection. However, the DNS client resolver SHOULD still process DNS replies from the network for a short period of time (recommended to be 1 second), as they will populate the DNS cache and can be used for subsequent connections.
一旦构建到目前为止接收到的地址列表，客户端将尝试建立连接。为了避免不合理的网络负载，不应同时尝试连接。相反，首先启动一个到单个地址的连接尝试，然后是列表中的其他地址，一次一个。启动新的连接尝试不会影响以前的尝试，因为多个连接尝试可能并行进行。一旦其中一次连接尝试成功（通常在TCP握手完成时），则应取消所有尚未成功的其他连接尝试。应忽略尚未尝试作为连接的任何地址。此时，异步DNS查询可能会被取消，因为新地址将不用于此连接。但是，DNS客户端解析程序仍应在短时间内（建议为1秒）处理来自网络的DNS答复，因为它们将填充DNS缓存并可用于后续连接。
A simple implementation can have a fixed delay for how long to wait before starting the next connection attempt. This delay is referred to as the "Connection Attempt Delay". One recommended value for a default delay is 250 milliseconds. A more nuanced implementation's delay should correspond to the time when the previous attempt is sending its second TCP SYN, based on the TCP's retransmission timer [RFC6298]. If the client has historical RTT data gathered from other connections to the same host or prefix, it can use this information to influence its delay. Note that this algorithm should only try to approximate the time of the first SYN retransmission, and not any further retransmissions that may be influenced by exponential timer back off.
一个简单的实现可以在开始下一次连接尝试之前有一个固定的延迟。此延迟称为“连接尝试延迟”。默认延迟的一个建议值是250毫秒。根据TCP的重传计时器[RFC6298]，更细微的实现延迟应与上一次尝试发送其第二个TCP SYN的时间相对应。如果客户端具有从其他连接到同一主机或前缀的历史RTT数据，则它可以使用此信息影响其延迟。请注意，此算法应仅尝试近似第一次SYN重传的时间，而不是可能受指数计时器后退影响的任何进一步重传。
The Connection Attempt Delay MUST have a lower bound, especially if it is computed using historical data. More specifically, a subsequent connection MUST NOT be started within 10 milliseconds of the previous attempt. The recommended minimum value is 100 milliseconds, which is referred to as the "Minimum Connection Attempt Delay". This minimum value is required to avoid congestion collapse in the presence of high packet-loss rates. The Connection Attempt Delay SHOULD have an upper bound, referred to as the "Maximum Connection Attempt Delay". The current recommended value is 2 seconds.
连接尝试延迟必须有一个下限，特别是如果它是使用历史数据计算的。更具体地说，在上一次尝试后的10毫秒内不得启动后续连接。建议的最小值为100毫秒，称为“最小连接尝试延迟”。这个最小值是为了避免在高丢包率的情况下拥塞崩溃所必需的。连接尝试延迟应有一个上限，称为“最大连接尝试延迟”。当前建议值为2秒。
If, during the course of connection establishment, the DNS answers change by either adding resolved addresses (for example due to DNS push notifications [DNS-PUSH]) or removing previously resolved addresses (for example, due to expiry of the TTL on that DNS record), the client should react based on its current progress.
如果在连接建立过程中，DNS应答通过添加解析地址（例如，由于DNS推送通知[DNS-push]）或删除以前解析的地址（例如，由于该DNS记录上的TTL过期）而改变，则客户端应根据其当前进度作出反应。
If an address is removed from the list that already had a connection attempt started, the connection attempt SHOULD NOT be canceled, but rather be allowed to continue. If the removed address had not yet had a connection attempt started, it SHOULD be removed from the list of addresses to try.
如果从已开始连接尝试的列表中删除了地址，则不应取消连接尝试，而应允许继续。如果删除的地址尚未启动连接尝试，则应将其从要尝试的地址列表中删除。
If an address is added to the list, it should be sorted into the list of addresses not yet attempted according to the rules above (see Section 4).
如果将地址添加到列表中，则应根据上述规则将其排序到尚未尝试的地址列表中（参见第4节）。
While many IPv6 transition protocols have been standardized and deployed, most are transparent to client devices. The combined use of NAT64 [RFC6146] and DNS64 [RFC6147] is a popular solution that is being deployed and requires changes in client devices. One possible way to handle these networks is for the client device networking stack to implement 464XLAT [RFC6877]. 464XLAT has the advantage of not requiring changes to user space software; however, it requires per-packet translation if the application is using IPv4 literals and does not encourage client application software to support native IPv6. On platforms that do not support 464XLAT, the Happy Eyeballs engine SHOULD follow the recommendations in this section to properly support IPv6-only networks with NAT64 and DNS64.
虽然许多IPv6转换协议已经标准化和部署，但大多数协议对客户端设备是透明的。NAT64[RFC6146]和DNS64[RFC6147]的组合使用是一种正在部署的流行解决方案，需要对客户端设备进行更改。处理这些网络的一种可能方法是，客户机设备网络堆栈实现464XLAT[RFC6877]。464XLAT的优点是不需要更改用户空间软件；但是，如果应用程序使用IPv4文本，并且不鼓励客户端应用程序软件支持本机IPv6，则需要逐包转换。在不支持464XLAT的平台上，Happy Eyeballs引擎应遵循本节中的建议，以正确支持仅限IPv6的NAT64和DNS64网络。
The features described in this section SHOULD only be enabled when the host detects one of these networks. A simple heuristic to achieve that is to check if the network offers routable IPv6 addressing, does not offer routable IPv4 addressing, and offers a DNS resolver address.
只有当主机检测到其中一个网络时，才应启用本节中描述的功能。一个简单的启发式方法是检查网络是否提供可路由的IPv6地址、是否不提供可路由的IPv4地址以及是否提供DNS解析程序地址。
If client applications or users wish to connect to IPv4 address literals, the Happy Eyeballs engine will need to perform NAT64 address synthesis for them. The solution is similar to "Bump-in-the-Host" [RFC6535] but is implemented inside the Happy Eyeballs library.
如果客户端应用程序或用户希望连接到IPv4地址文本，Happy Eyeballs引擎将需要为他们执行NAT64地址合成。该解决方案类似于“主机中的Bump”[RFC6535]，但在Happy Eyeballs库中实现。
When an IPv4 address is passed into the library instead of a hostname, the device queries the network for the NAT64 prefix using "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050] and then synthesizes an appropriate IPv6 address (or several) using the encoding described in "IPv6 Addressing of IPv4/ IPv6 Translators" [RFC6052]. The synthesized addresses are then inserted into the list of addresses as if they were results from DNS queries; connection attempts follow the algorithm described above (see Section 5).
当IPv4地址被传递到库中而不是主机名时，设备使用“发现用于IPv6地址合成的IPv6前缀”[RFC7050]来查询网络中的NAT64前缀，然后使用“IPv4/IPv6转换器的IPv6寻址”[RFC6052]中描述的编码来合成适当的IPv6地址（或多个地址）. 然后将合成的地址插入地址列表中，就像它们是DNS查询的结果一样；连接尝试遵循上述算法（参见第5节）。
At the time of writing, there exist a small but non-negligible number of hostnames that resolve to valid A records and broken AAAA records, which we define as AAAA records that contain seemingly valid IPv6 addresses but those addresses never reply when contacted on the usual ports. These can be, for example, caused by:
在撰写本文时，存在少量但不可忽略的主机名，这些主机名解析为有效的a记录和损坏的AAAA记录，我们将其定义为AAAA记录，其中包含看似有效的IPv6地址，但这些地址在通常的端口上联系时从不回复。例如，这些可能是由以下原因引起的：
o Mistyping of the IPv6 address in the DNS zone configuration
o DNS区域配置中的IPv6地址键入错误
o Routing black holes
o 路由黑洞
o Service outages
o 服务中断
While an algorithm complying with the other sections of this document would correctly handle such hostnames on a dual-stack network, they will not necessarily function correctly on IPv6-only networks with NAT64 and DNS64. Since DNS64 recursive resolvers rely on the authoritative name servers sending negative ("no error no answer") responses for AAAA records in order to synthesize, they will not synthesize records for these particular hostnames and will instead pass through the broken AAAA record.
虽然符合本文档其他部分要求的算法可以在双栈网络上正确处理此类主机名，但它们不一定能够在具有NAT64和DNS64的仅IPv6网络上正确运行。由于DNS64递归解析程序依靠权威名称服务器发送AAAA记录的否定（“无错误-无答案”）响应来进行合成，因此它们不会合成这些特定主机名的记录，而是通过损坏的AAAA记录。
In order to support these scenarios, the client device needs to query the DNS for the A record and then perform local synthesis. Since these types of hostnames are rare and, in order to minimize load on DNS servers, this A query should only be performed when the client has given up on the AAAA records it initially received. This can be achieved by using a longer timeout, referred to as the "Last Resort Local Synthesis Delay"; the delay is recommended to be 2 seconds. The timer is started when the last connection attempt is fired. If no connection attempt has succeeded when this timer fires, the device queries the DNS for the IPv4 address and, on reception of a valid A record, treats it as if it were provided by the application (see Section 7.1).
为了支持这些场景，客户端设备需要在DNS中查询A记录，然后执行本地合成。由于这些类型的主机名很少，并且为了最小化DNS服务器上的负载，只有当客户端放弃最初收到的AAAA记录时，才应执行此查询。这可以通过使用更长的超时来实现，称为“最后的本地合成延迟”；建议延迟为2秒。当最后一次连接尝试触发时，计时器启动。如果此计时器触发时连接尝试未成功，则设备会向DNS查询IPv4地址，并在接收到有效的a记录时，将其视为由应用程序提供（请参阅第7.1节）。
Some Virtual Private Networks (VPNs) may be configured to handle DNS queries from the device. The configuration could encompass all queries or a subset such as "*.internal.example.com". These VPNs can also be configured to only route part of the IPv4 address space, such as 192.0.2.0/24. However, if an internal hostname resolves to an external IPv4 address, these can cause issues if the underlying network is IPv6-only. As an example, let's assume that "www.internal.example.com" has exactly one A record, 198.51.100.42, and no AAAA records. The client will send the DNS query to the company's recursive resolver and that resolver will reply with these records. The device now only has an IPv4 address to connect to and no route to that address. Since the company's resolver does not know the NAT64 prefix of the underlying network, it cannot synthesize the address. Similarly, the underlying network's DNS64 recursive resolver does not know the company's internal addresses, so it cannot resolve the hostname. Because of this, the client device needs to resolve the A record using the company's resolver and then locally synthesize an IPv6 address, as if the resolved IPv4 address were provided by the application (Section 7.1).
一些虚拟专用网络（VPN）可以配置为处理来自设备的DNS查询。配置可以包含所有查询或子集，如“*.internal.example.com”。这些VPN还可以配置为仅路由IPv4地址空间的一部分，例如192.0.2.0/24。但是，如果内部主机名解析为外部IPv4地址，则如果基础网络仅为IPv6，则可能会导致问题。例如，假设“www.internal.example.com”有一条A记录198.51.100.42，而没有AAAA记录。客户端将向公司的递归解析程序发送DNS查询，该解析程序将使用这些记录进行回复。该设备现在只有一个IPv4地址可连接，没有到该地址的路由。由于该公司的解析器不知道底层网络的NAT64前缀，因此无法合成地址。类似地，底层网络的DNS64递归解析器不知道公司的内部地址，因此无法解析主机名。因此，客户端设备需要使用公司的解析器解析A记录，然后在本地合成IPv6地址，就像解析的IPv4地址是由应用程序提供的一样（第7.1节）。
The values that may be configured as defaults on a client for use in Happy Eyeballs are as follows:
可在客户端上配置为默认值以用于Happy Eyeballs的值如下所示：
o Resolution Delay (Section 3): The time to wait for a AAAA response after receiving an A response. Recommended to be 50 milliseconds.
o 解析延迟（第3节）：收到响应后等待AAAA响应的时间。建议为50毫秒。
o First Address Family Count (Section 4): The number of addresses belonging to the first address family (such as IPv6) that should be attempted before attempting another address family. Recommended to be 1; 2 may be used to more aggressively favor a particular address family.
o 第一个地址族计数（第4节）：在尝试另一个地址族之前，应尝试的属于第一个地址族（如IPv6）的地址数。建议为1；2可用于更积极地支持特定地址族。
o Connection Attempt Delay (Section 5): The time to wait between connection attempts in the absence of RTT data. Recommended to be 250 milliseconds.
o 连接尝试延迟（第5节）：在没有RTT数据的情况下，连接尝试之间的等待时间。建议为250毫秒。
o Minimum Connection Attempt Delay (Section 5): The minimum time to wait between connection attempts. Recommended to be 100 milliseconds. MUST NOT be less than 10 milliseconds.
o 最小连接尝试延迟（第5节）：连接尝试之间的最小等待时间。建议为100毫秒。不得小于10毫秒。
o Maximum Connection Attempt Delay (Section 5): The maximum time to wait between connection attempts. Recommended to be 2 seconds.
o 最大连接尝试延迟（第5节）：连接尝试之间的最大等待时间。建议为2秒。
o Last Resort Local Synthesis Delay (Section 7.2): The time to wait after starting the last IPv6 attempt and before sending the A query. Recommended to be 2 seconds.
o 最后的本地合成延迟（第7.2节）：在开始最后一次IPv6尝试之后和发送查询之前等待的时间。建议为2秒。
The delay values described in this section were determined empirically by measuring the timing of connections on a very wide set of production devices. They were picked to reduce wait times noticed by users while minimizing load on the network. As time passes, it is expected that the properties of networks will evolve. For that reason, it is expected that these values will change over time. Implementors should feel welcome to use different values without changing this specification. Since IPv6 issues are expected to be less common, the delays SHOULD be increased with time as client software is updated.
本节中所述的延迟值是通过测量一组非常广泛的生产设备上的连接时间经验确定的。选择它们是为了减少用户注意到的等待时间，同时最小化网络负载。随着时间的推移，预计网络的特性将发生变化。因此，预计这些值将随时间变化。应该欢迎实现者使用不同的值，而不必更改此规范。由于IPv6问题预计不太常见，因此随着客户端软件的更新，延迟应随着时间的推移而增加。
Happy Eyeballs will handle initial connection failures at the TCP/IP layer; however, other failures or performance issues may still affect the chosen connection.
Happy Eyeballs将处理TCP/IP层的初始连接故障；但是，其他故障或性能问题仍可能影响所选连接。
Since Happy Eyeballs is only active during the initial handshake and TCP does not pass the initial handshake, issues related to MTU can be masked and go unnoticed during Happy Eyeballs. Solving this issue is out of scope of this document. One solution is to use "Packetization Layer Path MTU Discovery" [RFC4821].
由于快乐眼球仅在初始握手期间活动，TCP不会通过初始握手，因此与MTU相关的问题可能会在快乐眼球期间被掩盖和忽略。解决此问题超出了本文档的范围。一种解决方案是使用“打包层路径MTU发现”[RFC4821]。
If the DNS returns multiple addresses for different application servers, the application itself may not be operational and functional on all of them. Common examples include Transport Layer Security (TLS) and HTTP.
如果DNS为不同的应用程序服务器返回多个地址，则应用程序本身可能无法在所有服务器上运行。常见的例子包括传输层安全（TLS）和HTTP。
It has been observed in practice that Happy Eyeballs can hide issues in networks. For example, if a misconfiguration causes IPv6 to consistently fail on a given network while IPv4 is still functional, Happy Eyeballs may impair the operator's ability to notice the issue. It is recommended that network operators deploy external means of monitoring to ensure functionality of all address families.
人们在实践中观察到，快乐的眼球可以隐藏网络中的问题。例如，如果错误配置导致IPv6在给定网络上持续失败，而IPv4仍在运行，则高兴的眼球可能会损害运营商注意问题的能力。建议网络运营商部署外部监控手段，以确保所有地址系列的功能。
Note that applications should not rely upon a stable hostname-to-address mapping to ensure any security properties, since DNS results may change between queries. Happy Eyeballs may make it more likely that subsequent connections to a single hostname use different IP addresses.
请注意，应用程序不应依赖稳定的主机名到地址映射来确保任何安全属性，因为DNS结果可能在查询之间发生变化。令人高兴的眼球可能会使到单个主机名的后续连接更可能使用不同的IP地址。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 4821，DOI 10.17487/RFC4821，2007年3月<https://www.rfc-editor.org/info/rfc4821>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052，DOI 10.17487/RFC6052，2010年10月<https://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 6147，DOI 10.17487/RFC6147，2011年4月<https://www.rfc-editor.org/info/rfc6147>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 6298，DOI 10.17487/RFC62982011年6月<https://www.rfc-editor.org/info/rfc6298>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <https://www.rfc-editor.org/info/rfc6535>.
[RFC6535]Huang，B.，Deng，H.，和T.Savolainen，“使用“主机中的凹凸”（BIH）的双堆栈主机”，RFC 6535，DOI 10.17487/RFC65352012年2月<https://www.rfc-editor.org/info/rfc6535>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，DOI 10.17487/RFC65552012年4月<https://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<https://www.rfc-editor.org/info/rfc6724>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，RFC 7050，DOI 10.17487/RFC7050，2013年11月<https://www.rfc-editor.org/info/rfc7050>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[DNS-PUSH] Pusateri, T. and S. Cheshire, "DNS Push Notifications", Work in Progress, draft-ietf-dnssd-push-13, October 2017.
[DNS-PUSH]Pusateri，T.和S.Cheshire，“DNS推送通知”，正在进行中，草稿-ietf-dnssd-PUSH-132017年10月。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，DOI 10.17487/RFC6877，2013年4月<https://www.rfc-editor.org/info/rfc6877>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<https://www.rfc-editor.org/info/rfc7413>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
"Happy Eyeballs: Success with Dual-Stack Hosts" [RFC6555] mostly concentrates on how to stagger connections to a hostname that has a AAAA and an A record. This document additionally discusses:
“快乐眼球：双堆栈主机的成功”[RFC6555]主要关注如何交错连接到具有AAAA和a记录的主机名。本文件还讨论了：
o how to perform DNS queries to obtain these addresses
o 如何执行DNS查询以获取这些地址
o how to handle multiple addresses from each address family
o 如何处理每个地址族中的多个地址
o how to handle DNS updates while connections are being raced
o 如何在连接处于竞争状态时处理DNS更新
o how to leverage historical information
o 如何利用历史信息
o how to support IPv6-only networks with NAT64 and DNS64
o 如何使用NAT64和DNS64支持仅限IPv6的网络
Note that a simple implementation of the algorithm described in this document is still compliant with the previous specification [RFC6555]. Implementations should take the new considerations into account when applicable to optimize their behavior.
请注意，本文中描述的算法的简单实现仍然符合先前的规范[RFC6555]。在适用于优化其行为时，实现应考虑新的考虑因素。
Acknowledgments
致谢
The authors thank Dan Wing, Andrew Yourtchenko, and everyone else who worked on the original Happy Eyeballs design [RFC6555], Josh Graessley, Stuart Cheshire, and the rest of team at Apple that helped implement and instrument this algorithm, and Jason Fesler and Paul Saab who helped measure and refine this algorithm. The authors would also like to thank Fred Baker, Nick Chettle, Lorenzo Colitti, Igor Gashinsky, Geoff Huston, Jen Linkova, Paul Hoffman, Philip Homburg, Warren Kumari, Erik Nygren, Jordi Palet Martinez, Rui Paulo, Stephen Strowes, Jinmei Tatuya, Dave Thaler, Joe Touch, and James Woodyatt for their input and contributions.
作者感谢Dan Wing、Andrew Yourtchenko和其他所有参与原始快乐眼球设计[RFC6555]的人、Josh Graessley、Stuart Cheshire以及帮助实现和安装该算法的苹果团队的其他成员，以及帮助测量和完善该算法的Jason Fesler和Paul Saab。作者还要感谢弗雷德·贝克、尼克·切特尔、洛伦佐·科利蒂、伊戈尔·加辛斯基、杰夫·休斯顿、詹·林科娃、保罗·霍夫曼、菲利普·霍姆伯格、沃伦·库马里、埃里克·尼格伦、乔迪·帕莱·马丁内斯、鲁伊·保罗、斯蒂芬·斯特罗维斯、金美·塔图亚、戴夫·泰勒、乔·图奇和詹姆斯·伍迪亚特的投入和贡献。
Authors' Addresses
作者地址
David Schinazi Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States of America
美国加利福尼亚州库珀蒂诺市无限环路1号苹果公司，邮编95014
Email: dschinazi@apple.com
Email: dschinazi@apple.com
Tommy Pauly Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States of America
汤米·保利苹果公司，加利福尼亚州库珀蒂诺无限环路1号，美国95014
Email: tpauly@apple.com
Email: tpauly@apple.com