Internet Engineering Task Force (IETF) P. Martinsen
Request for Comments: 8421 Cisco
BCP: 217 T. Reddy
Category: Best Current Practice McAfee, Inc.
ISSN: 2070-1721 P. Patil
Cisco
July 2018
Internet Engineering Task Force (IETF) P. Martinsen
Request for Comments: 8421 Cisco
BCP: 217 T. Reddy
Category: Best Current Practice McAfee, Inc.
ISSN: 2070-1721 P. Patil
Cisco
July 2018
Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE)
多址和IPv4/IPv6双栈交互式连接建立（ICE）指南
Abstract
摘要
This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).
本文档提供了有关如何在存在断开路径的多宿和IPv4/IPv6双栈场景中加快交互式连接建立（ICE）速度的指南。提供的指南与原始ICE规范向后兼容（见RFC 5245）。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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 BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc8421.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8421.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. ICE Multihomed Recommendations . . . . . . . . . . . . . . . 3
4. ICE Dual-Stack Recommendations . . . . . . . . . . . . . . . 4
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. ICE Multihomed Recommendations . . . . . . . . . . . . . . . 3
4. ICE Dual-Stack Recommendations . . . . . . . . . . . . . . . 4
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
In multihomed and IPv4/IPv6 dual-stack environments, ICE [RFC8445] would benefit by a fair distribution of its connectivity checks across available interfaces or IP address types. With a fair distribution of the connectivity checks, excessive delays are avoided if a particular network path is broken or slow. Arguably, it would be better to put the interfaces or address types known to the application last in the checklist. However, the main motivation by ICE is to make no assumptions regarding network topology; hence, a fair distribution of the connectivity checks is more appropriate. If an application operates in a well-known environment, it can safely override the recommendation given in this document.
在多址和IPv4/IPv6双栈环境中，ICE[RFC8445]将受益于跨可用接口或IP地址类型公平分配其连接检查。通过公平分配连接检查，可以避免在特定网络路径中断或速度较慢时出现过度延迟。可以说，最好将应用程序已知的接口或地址类型放在清单的最后。然而，ICE的主要动机是不对网络拓扑进行假设；因此，公平分配连接检查更合适。如果应用程序在众所周知的环境中运行，它可以安全地覆盖本文档中给出的建议。
Applications should take special care to deprioritize network interfaces known to provide unreliable connectivity when operating in a multihomed environment. For example, certain tunnel services might provide unreliable connectivity. Doing so will ensure a more fair distribution of the connectivity checks across available network interfaces on the device. The simple guidelines presented here describe how to deprioritize interfaces known by the application to provide unreliable connectivity.
应用程序应特别注意消除已知的网络接口优先级，这些接口在多址环境中运行时提供不可靠的连接。例如，某些隧道服务可能提供不可靠的连接。这样做将确保在设备上的可用网络接口之间更公平地分配连接检查。这里提供的简单指南描述了如何对应用程序已知的接口进行去优先级化，以提供不可靠的连接。
There is also a need to introduce better handling of connectivity checks for different IP address families in dual-stack IPv4/IPv6 ICE scenarios. Following the recommendations from RFC 6724 [RFC6724] will lead to prioritization of IPv6 over IPv4 for the same candidate type. Due to this, connectivity checks for candidates of the same type (host, reflexive, or relay) are sent such that an IP address family is completely depleted before checks from the other address family are started. This results in user-noticeable delays with setup if the path for the prioritized address family is broken.
在双栈IPv4/IPv6 ICE场景中，还需要更好地处理不同IP地址族的连接检查。按照RFC 6724[RFC6724]的建议，将导致同一候选类型的IPv6优先于IPv4。因此，发送相同类型（主机、自反或中继）的候选地址的连接性检查，以便在开始检查其他地址族之前，IP地址族完全耗尽。如果优先级地址族的路径被破坏，这将导致用户在设置时明显延迟。
To avoid user-noticeable delays when either the IPv6 or IPv4 path is broken or excessively slow, this specification encourages intermingling the different address families when connectivity checks are performed. This will lead to more sustained dual-stack IPv4/IPv6 deployment as users will no longer have an incentive to disable IPv6. The cost is a small penalty to the address type that otherwise would have been prioritized. Further, this document recommends keeping track of previous known connectivity problems and assigning a lower priority to those addresses. Specific mechanisms and rules for tracking connectivity issues are out of scope for this document.
为了避免在IPv6或IPv4路径中断或速度过慢时出现用户明显的延迟，本规范鼓励在执行连接检查时混合不同的地址族。这将导致更持久的双栈IPv4/IPv6部署，因为用户将不再有动机禁用IPv6。这样的代价对于地址类型来说是一个小小的损失，否则它将被优先考虑。此外，本文档建议跟踪以前已知的连接问题，并为这些地址分配较低的优先级。跟踪连接问题的特定机制和规则不在本文档的范围内。
This document describes what parameters an agent can safely alter to fairly order the checklist candidate pairs in multihomed and dual-stack environments, thus affecting the sending order of the connectivity checks. The actual values of those parameters are an implementation detail. Dependent on the nomination method in use, this might have an effect on what candidate pair ends up as the active one. Ultimately, it should be up to the agent to decide what candidate pair is best suited for transporting media.
本文档描述了代理可以安全地更改哪些参数，以便在多宿和双堆栈环境中公平地排列检查表候选对，从而影响连接检查的发送顺序。这些参数的实际值是实现细节。根据使用的提名方法，这可能会影响到哪一对候选人最终成为活跃候选人。最终，应由代理决定哪对候选对最适合传输媒体。
The guidelines outlined in this specification are backward compatible with the original ICE implementation. This specification only alters the values used to create the resulting checklists in such a way that the core mechanisms from the original ICE specification [RFC5245] and its replacement [RFC8445] are still in effect.
本规范中概述的指南与最初的ICE实施向后兼容。本规范仅更改用于创建结果检查表的值，从而使原始ICE规范[RFC5245]及其替代品[RFC8445]中的核心机构仍然有效。
This document uses terminology defined in [RFC8445].
本文件使用[RFC8445]中定义的术语。
A multihomed ICE agent can potentially send and receive connectivity checks on all available interfaces and IP addresses. It is possible for an interface to have several IP addresses associated with it. To avoid unnecessary delay when performing connectivity checks, it would be beneficial to prioritize interfaces and IP addresses known by the agent to provide stable connectivity.
多宿主ICE代理可以潜在地发送和接收所有可用接口和IP地址上的连接检查。一个接口可能有多个与之关联的IP地址。为了避免执行连接检查时出现不必要的延迟，最好对代理已知的接口和IP地址进行优先级排序，以提供稳定的连接。
The application knowledge regarding the reliability of an interface can also be based on simple metrics like previous connection success/ failure rates, or it can be a more static model based on interface types like wired, wireless, cellular, virtual, and tunneled in conjunction with other operational metrics. This would require the application to have the right permissions to obtain such operational metrics.
关于接口可靠性的应用程序知识也可以基于简单的指标，如以前的连接成功率/失败率，也可以是基于接口类型（如有线、无线、蜂窝、虚拟和隧道）的更静态的模型，并结合其他操作指标。这将要求应用程序具有获取此类操作度量的正确权限。
Candidates from an interface known to the application to provide unreliable connectivity should get a low candidate priority. When to consider connectivity as unreliable is implementation specific. Usage of ICE is not limited to Voice over IP (VoIP) applications. What an application sees as unreliability might be determined by a mix of how long lived the connection is, how often setup is required, and other, for now unknown, requirements. This is purely an optimization to speed up the ICE connectivity check phase.
来自应用程序已知的提供不可靠连接的接口的候选者应获得较低的候选者优先级。当考虑连接性不可靠时，是特定于实现的。ICE的使用不限于IP语音（VoIP）应用。应用程序所认为的不可靠性可能由连接的寿命、需要设置的频率以及其他（目前还未知）需求的组合来确定。这纯粹是为了加快ICE连接检查阶段的优化。
If the application is unable to get any interface information regarding type or is unable to store any relevant metrics, it should treat all interfaces as if they have reliable connectivity. This ensures that all interfaces get a fair chance to perform their connectivity checks.
如果应用程序无法获取有关类型的任何接口信息或无法存储任何相关度量，则应将所有接口视为具有可靠连接。这确保所有接口都有公平的机会执行其连接检查。
Candidates should be prioritized such that a sequence of candidates belonging to the same address family will be intermingled with candidates from an alternate IP family, for example, promote IPv4 candidates in the presence of many IPv6 candidates such that an IPv4 address candidate is always present after a small sequence of IPv6 candidates (i.e., reorder candidates such that both IPv6 and IPv4 candidates get a fair chance during the connectivity check phase). This makes ICE connectivity checks more responsive to broken-path failures of an address family.
候选地址应按优先级排列，以便属于同一地址系列的候选地址序列将与来自备用IP系列的候选地址相混合，例如，在存在多个IPv6候选地址的情况下提升IPv4候选地址，以便IPv4地址候选地址始终在一小段IPv6候选地址序列之后出现（即，对候选地址重新排序，以便IPv6和IPv4候选地址在连接检查阶段都有公平的机会）。这使得ICE连接检查对地址系列的断开路径故障更具响应性。
An ICE agent can select an algorithm or a technique of its choice to ensure that the resulting checklists have a fair intermingled mix of IPv4 and IPv6 address families. However, modifying the checklist directly can lead to uncoordinated local and remote checklists that result in ICE taking longer to complete or, in the worst case scenario, fail. The best approach is to set the appropriate value for local preference in the formula for calculating the candidate priority value as described in the "Recommended Formula" section (Section 5.1.2.1) of [RFC8445].
ICE代理可以选择其选择的算法或技术，以确保生成的检查表具有IPv4和IPv6地址族的公平混合。但是，直接修改检查表可能会导致本地和远程检查表不协调，导致ICE需要更长的时间才能完成，或者在最坏的情况下失败。最好的方法是按照[RFC8445]的“推荐公式”一节（第5.1.2.1节）中所述，在计算候选优先级值的公式中为本地偏好设置适当的值。
Implementations should prioritize IPv6 candidates by putting some of them first in the intermingled checklist. This increases the chance of IPv6 connectivity checks to complete first and be ready for nomination or usage. This enables implementations to follow the intent of "Happy Eyeballs: Success with Dual-Stack Hosts" [RFC8305]. It is worth noting that the timing recommendations in [RFC8305] will be overruled by how ICE paces out its connectivity checks.
实施应通过在混合清单中首先列出一些候选IPv6来确定其优先级。这增加了IPv6连接检查首先完成并准备好提名或使用的机会。这使实现能够遵循“快乐眼球：双堆栈主机成功”的意图[RFC8305]。值得注意的是，[RFC8305]中的定时建议将被ICE如何进行连接检查所推翻。
A simple formula to calculate how many IPv6 addresses to put before any IPv4 addresses could look like:
计算在任何IPv4地址之前放置多少IPv6地址的简单公式如下所示：
Hi = (N_4 + N_6) / N_4
Hi = (N_4 + N_6) / N_4
Where Hi = Head start before intermingling starts N_4 = Number of IPv4 addresses N_6 = Number of IPv6 addresses
其中Hi=混合开始前的起始N_4=IPv4地址数N_6=IPv6地址数
If a host has two IPv4 addresses and six IPv6 addresses, it will insert an IPv4 address after four IPv6 addresses by choosing the appropriate local preference values when calculating the pair priorities.
如果主机有两个IPv4地址和六个IPv6地址，则在计算对优先级时，它将通过选择适当的本地首选项值在四个IPv6地址之后插入一个IPv4地址。
The formula in Section 5.1.2 of [RFC8445] should be used to calculate the candidate priority. The formula is as follows:
应使用[RFC8445]第5.1.2节中的公式计算候选优先级。公式如下：
priority = (2^24)*(type preference) +
(2^8)*(local preference) +
(2^0)*(256 - component ID)
priority = (2^24)*(type preference) +
(2^8)*(local preference) +
(2^0)*(256 - component ID)
"Guidelines for Choosing Type and Local Preferences" (Section 5.1.2.2 of [RFC8445]) has guidelines for how the type preference and local preference value should be chosen. Instead of having a static local preference value for IPv4 and IPv6 addresses, it is possible to choose this value dynamically in such a way that IPv4 and IPv6 address candidate priorities end up intermingled within the same candidate type. It is also possible to assign lower priorities to IP addresses derived from unreliable interfaces using the local preference value.
“选择类型和本地首选项的指南”（[RFC8445]第5.1.2.2节）提供了如何选择类型首选项和本地首选项值的指南。与IPv4和IPv6地址具有静态本地首选项值不同，可以动态选择此值，以使IPv4和IPv6地址候选优先级最终在同一候选类型中混合。还可以使用本地首选项值为来自不可靠接口的IP地址分配较低的优先级。
It is worth mentioning that Section 5.1.2.1 of [RFC8445] states that "if there are multiple candidates for a particular component for a particular data stream that have the same type, the local preference MUST be unique for each one".
值得一提的是，[RFC8445]第5.1.2.1节规定，“如果特定数据流的特定组件有多个具有相同类型的候选组件，则每个组件的本地首选项必须是唯一的”。
The local type preference can be dynamically changed in such a way that IPv4 and IPv6 address candidates end up intermingled regardless of candidate type. This is useful if there are a lot of IPv6 host candidates effectively blocking connectivity checks for IPv4 server reflexive candidates.
本地类型首选项可以动态更改，从而使IPv4和IPv6地址候选项最终混合在一起，而不考虑候选类型。如果有大量IPv6主机候选有效地阻止IPv4服务器自反候选的连接检查，则此选项非常有用。
Candidates with IP addresses from an unreliable interface should be ordered at the end of the checklist, i.e., not intermingled as the dual-stack candidates.
具有来自不可靠接口的IP地址的候选者应在清单末尾订购，即，不要与双堆栈候选者混淆。
The list below shows a sorted local candidate list where the priority is calculated in such a way that the IPv4 and IPv6 candidates are intermingled (no multihomed candidates). To allow for earlier connectivity checks for the IPv4 server reflexive candidates, some of the IPv6 host candidates are demoted. This is just an example of how candidate priorities can be calculated to provide better fairness between IPv4 and IPv6 candidates without breaking any of the ICE connectivity checks.
下面的列表显示了已排序的本地候选列表，其中优先级的计算方式为IPv4和IPv6候选混合（无多址候选）。为了允许对IPv4服务器自反候选主机进行早期连接检查，某些IPv6候选主机被降级。这只是一个示例，说明如何计算候选优先级，以便在不破坏任何ICE连接检查的情况下，在IPv4和IPv6候选之间提供更好的公平性。
Candidate Address Component
Type Type ID Priority
-------------------------------------------
(1) HOST IPv6 (1) 2129289471
(2) HOST IPv6 (2) 2129289470
(3) HOST IPv4 (1) 2129033471
(4) HOST IPv4 (2) 2129033470
(5) HOST IPv6 (1) 2128777471
(6) HOST IPv6 (2) 2128777470
(7) HOST IPv4 (1) 2128521471
(8) HOST IPv4 (2) 2128521470
(9) HOST IPv6 (1) 2127753471
(10) HOST IPv6 (2) 2127753470
(11) SRFLX IPv6 (1) 1693081855
(12) SRFLX IPv6 (2) 1693081854
(13) SRFLX IPv4 (1) 1692825855
(14) SRFLX IPv4 (2) 1692825854
(15) HOST IPv6 (1) 1692057855
(16) HOST IPv6 (2) 1692057854
(17) RELAY IPv6 (1) 15360255
(18) RELAY IPv6 (2) 15360254
(19) RELAY IPv4 (1) 15104255
(20) RELAY IPv4 (2) 15104254
Candidate Address Component
Type Type ID Priority
-------------------------------------------
(1) HOST IPv6 (1) 2129289471
(2) HOST IPv6 (2) 2129289470
(3) HOST IPv4 (1) 2129033471
(4) HOST IPv4 (2) 2129033470
(5) HOST IPv6 (1) 2128777471
(6) HOST IPv6 (2) 2128777470
(7) HOST IPv4 (1) 2128521471
(8) HOST IPv4 (2) 2128521470
(9) HOST IPv6 (1) 2127753471
(10) HOST IPv6 (2) 2127753470
(11) SRFLX IPv6 (1) 1693081855
(12) SRFLX IPv6 (2) 1693081854
(13) SRFLX IPv4 (1) 1692825855
(14) SRFLX IPv4 (2) 1692825854
(15) HOST IPv6 (1) 1692057855
(16) HOST IPv6 (2) 1692057854
(17) RELAY IPv6 (1) 15360255
(18) RELAY IPv6 (2) 15360254
(19) RELAY IPv4 (1) 15104255
(20) RELAY IPv4 (2) 15104254
SRFLX = server reflexive
SRFLX = server reflexive
Note that the list does not alter the component ID part of the formula. This keeps the different components (RTP and the Real-time Transport Control Protocol (RTCP)) close in the list. What matters is the ordering of the candidates with component ID 1. Once the checklist is formed for a media stream, the candidate pair with component ID 1 will be tested first. If the ICE connectivity check is successful, then other candidate pairs with the same foundation will be unfrozen (see "Computing Candidate Pair States" in Section 6.1.2.6 of [RFC8445]).
请注意，该列表不会更改公式的组件ID部分。这使列表中的不同组件（RTP和实时传输控制协议（RTCP））保持关闭状态。重要的是组件ID为1的候选组件的顺序。一旦为媒体流形成检查表，将首先测试组件ID为1的候选对。如果ICE连通性检查成功，则具有相同基础的其他候选对将被解冻（参见[RCF8445 ]第6节1.62.6节中的“计算候选配对状态”）。
The local and remote agent can have different algorithms for choosing the local preference and type preference values without impacting the synchronization between the local and remote checklists.
本地和远程代理可以使用不同的算法来选择本地首选项和类型首选项值，而不会影响本地和远程检查列表之间的同步。
The checklist is made up of candidate pairs. A candidate pair is two candidates paired up and given a candidate pair priority as described in Section 6.1.2.3 of [RFC8445]. Using the pair priority formula:
检查表由候选对组成。候选对是指两个配对的候选对，并按照[RFC8445]第6.1.2.3节中的说明给予候选对优先级。使用配对优先级公式：
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G is the candidate priority provided by the controlling agent, and D is the candidate priority provided by the controlled agent. This ensures that the local and remote checklists are coordinated.
其中G是由控制代理提供的候选优先级，D是由控制代理提供的候选优先级。这确保了本地和远程检查表的协调。
Even if the two agents have different algorithms for choosing the candidate priority value to get an intermingled set of IPv4 and IPv6 candidates, the resulting checklist, that is a list sorted by the pair priority value, will be identical on the two agents.
即使两个代理具有不同的算法来选择候选优先级值以获得IPv4和IPv6候选的混合集，结果检查表（即按对优先级值排序的列表）在两个代理上也是相同的。
The agent that has promoted IPv4 cautiously, i.e., lower IPv4 candidate priority values compared to the other agent, will influence the checklist the most due to (2^32*MIN(G,D)) in the formula.
由于公式中的（2^32*MIN（G，D）），谨慎提升IPv4的代理（即，与其他代理相比，IPv4候选优先级值较低）对检查表的影响最大。
These recommendations are backward compatible with the original ICE implementation. The resulting local and remote checklist will still be synchronized.
这些建议与最初的ICE实现向后兼容。生成的本地和远程检查表仍将同步。
Dependent of the nomination method in use, the procedures described in this document might change what candidate pair ends up as the active one.
根据所使用的提名方法，本文件中所述的程序可能会改变最终成为活动候选对的候选对。
A test implementation of an example algorithm is available at [ICE_dualstack_imp].
示例算法的测试实现可在[ICE_dualstack_imp]上获得。
This document has no IANA actions.
本文档没有IANA操作。
The security considerations described in [RFC8445] are valid. It changes recommended values and describes how an agent could choose those values in a safe way. In Section 3, the agent can prioritize the network interface based on previous network knowledge. This can potentially be unwanted information leakage towards the remote agent.
[RFC8445]中描述的安全注意事项是有效的。它更改了建议的值，并描述了代理如何以安全的方式选择这些值。在第3节中，代理可以基于先前的网络知识对网络接口进行优先级排序。这可能是不必要的信息泄漏到远程代理。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<https://www.rfc-editor.org/info/rfc5245>.
[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>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305]Schinazi，D.和T.Pauly，“快乐眼球第2版：使用并发实现更好的连接”，RFC 8305，DOI 10.17487/RFC8305，2017年12月<https://www.rfc-editor.org/info/rfc8305>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]Keranen，A.，Holmberg，C.，和J.Rosenberg，“交互式连接建立（ICE）：网络地址转换器（NAT）遍历协议”，RFC 8445，DOI 10.17487/RFC84452018年7月<https://www.rfc-editor.org/info/rfc8445>.
[ICE_dualstack_imp] "ICE Happy Eyeball Test Algorithms", commit 45083fb, January 2014, <https://github.com/palerikm/ICE-DualStackFairness>.
[ICE_dualstack_imp]“ICE快乐眼球测试算法”，提交45083fb，2014年1月<https://github.com/palerikm/ICE-DualStackFairness>.
Acknowledgements
致谢
The authors would like to thank Dan Wing, Ari Keranen, Bernard Aboba, Martin Thomson, Jonathan Lennox, Balint Menyhart, Ole Troan, Simon Perreault, Ben Campbell, and Mirja Kuehlewind for their comments and review.
作者要感谢Dan Wing、Ari Keranen、Bernard Aboba、Martin Thomson、Jonathan Lennox、Balint Menyhart、Ole Troan、Simon Perreault、Ben Campbell和Mirja Kuehlewind的评论和评论。
Authors' Addresses
作者地址
Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens Vei 22 Lysaker, Akershus 1325 Norway
Paal Erik Martinsen思科系统有限公司Philip Pedersens Vei 22 Lysaker，挪威阿克苏
Email: palmarti@cisco.com
Email: palmarti@cisco.com
Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India
印度卡纳塔克邦班加罗尔大使馆高尔夫链接商务园Tirumaleswar Reddy McAfee，Inc.560071
Email: TirumaleswarReddy_Konda@McAfee.com
Email: TirumaleswarReddy_Konda@McAfee.com
Prashanth Patil Cisco Systems, Inc. Bangalore India
印度班加罗尔Prashanth Patil思科系统公司
Email: praspati@cisco.com
Email: praspati@cisco.com