Internet Engineering Task Force (IETF) P. Patil
Request for Comments: 8155 T. Reddy
Updates: 5766 Cisco
Category: Standards Track D. Wing
ISSN: 2070-1721 April 2017
Internet Engineering Task Force (IETF) P. Patil
Request for Comments: 8155 T. Reddy
Updates: 5766 Cisco
Category: Standards Track D. Wing
ISSN: 2070-1721 April 2017
Traversal Using Relays around NAT (TURN) Server Auto Discovery
使用NAT（TURN）服务器自动发现周围的中继进行遍历
Abstract
摘要
Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.
当前使用NAT（TURN）服务器发现机制周围的中继进行的遍历是相对静态的，并且仅限于显式配置。它们通常由应用程序或服务提供商管理控制，而不是由企业、ISP或客户端所在的网络控制。希望提供自己的TURN服务器的企业和ISP需要自动发现机制，TURN客户端只需很少或不需要配置即可使用这些机制。本文档描述了三种TURN服务器发现机制。
This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.
本文件更新了RFC 5766，以放宽某些情况下的相互认证要求。
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 http://www.rfc-editor.org/info/rfc8155.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8155.
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 (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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 4
4. Discovery Using Service Resolution . . . . . . . . . . . . . 5
4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. From Own Identity . . . . . . . . . . . . . . . . . . 6
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery Using Anycast . . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP Addresses . . . . . . . . . . . 8
7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
8.2. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 12
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 12
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 4
4. Discovery Using Service Resolution . . . . . . . . . . . . . 5
4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. From Own Identity . . . . . . . . . . . . . . . . . . 6
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery Using Anycast . . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP Addresses . . . . . . . . . . . 8
7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
8.2. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 12
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 12
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
TURN [RFC5766] is a protocol that is often used to improve the connectivity of Peer-to-Peer (P2P) applications (as defined in Section 2.7 of [RFC5128]). TURN allows a connection to be established when one or both sides are incapable of a direct P2P connection. It is an important building block for interactive, real-time communication using audio, video, collaboration, etc.
TURN[RFC5766]是一种协议，通常用于改善对等（P2P）应用程序的连接性（如[RFC5128]第2.7节所定义）。TURN允许在一方或双方无法建立直接P2P连接时建立连接。它是使用音频、视频、协作等进行交互式实时通信的重要构件。
While TURN services are extensively used today, the means to automatically discover TURN servers do not exist. TURN clients are usually explicitly configured with a well-known TURN server. To allow TURN applications to operate seamlessly across different types of networks and encourage the use of TURN without the need for manual configuration, it is important that there exist an auto-discovery mechanism for TURN services. Web Real-Time Communication (WebRTC) [WebRTC-Overview] usages and related extensions, which are mostly based on web applications, need TURN server discovery mechanisms.
尽管TURN服务如今被广泛使用，但自动发现TURN服务器的方法并不存在。TURN客户端通常使用知名的TURN服务器显式配置。为了允许TURN应用程序在不同类型的网络之间无缝运行，并鼓励使用TURN而无需手动配置，重要的是存在TURN服务的自动发现机制。Web实时通信（WebRTC）[WebRTC概述]主要基于Web应用程序的用法和相关扩展需要转向服务器发现机制。
This document describes three discovery mechanisms, so as to maximize the opportunity for discovery, based on the network in which the TURN client finds itself. The three discovery mechanisms are:
本文档描述了三种发现机制，以便根据TURN客户端发现自身的网络最大限度地增加发现机会。三种发现机制是：
o A resolution mechanism based on Straightforward-Naming Authority Pointer (S-NAPTR) resource records in the Domain Name System (DNS). [RFC5928] describes details on retrieving a list of server transport addresses from the DNS that can be used to create a TURN allocation.
o 基于域名系统（DNS）中直接命名机构指针（S-NAPTR）资源记录的解析机制。[RFC5928]描述了从DNS检索可用于创建回合分配的服务器传输地址列表的详细信息。
o DNS Service Discovery.
o DNS服务发现。
o A mechanism based on an anycast address for TURN.
o 基于TURN的选播地址的机制。
In general, if a client wishes to communicate using one of its interfaces using a specific IP address family, it SHOULD query the TURN server(s) that has been discovered for that specific interface and address family. How to select an interface and IP address family is out of the scope of this document.
通常，如果客户机希望使用特定IP地址系列使用其接口之一进行通信，则应查询已发现的该特定接口和地址系列的TURN服务器。如何选择接口和IP地址系列超出了本文档的范围。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
TURN clients, by default, discover TURN server(s) by means of local or manual TURN configuration (i.e., TURN servers configured at the system level). Configuration discovered from an application, e.g., a JavaScript-specified TURN server for Web Real-Time Communication (WebRTC) [WebRTC-Overview] usages and related extensions, is considered a local configuration. An implementation may give the user an opportunity (e.g., by means of configuration file options or menu items) to specify a TURN server for each address family. A client can choose auto-discovery in the absence of local configuration, if local configuration doesn't work or in addition to local configuration. This document does not offer a recommendation on server selection.
默认情况下，TURN客户端通过本地或手动TURN配置（即在系统级别配置的TURN服务器）发现TURN服务器。从应用程序中发现的配置，例如用于Web实时通信（WebRTC）[WebRTC概述]用法和相关扩展的JavaScript指定TURN服务器，被视为本地配置。实现可以给用户一个机会（例如，通过配置文件选项或菜单项）为每个地址族指定一个TURN服务器。如果本地配置不起作用，或者除了本地配置之外，客户端还可以在没有本地配置的情况下选择自动发现。本文档不提供有关服务器选择的建议。
A TURN client that implements the auto-discovery algorithm, to discover TURN servers in the attached network, uses the following mechanisms for discovery:
实现自动发现算法的TURN客户端用于发现连接网络中的TURN服务器，它使用以下发现机制：
o Service Resolution: The TURN client attempts to perform TURN service resolution using the host's DNS domain.
o 服务解析：TURN客户端尝试使用主机的DNS域执行TURN服务解析。
o DNS SD: DNS Service Discovery.
o DNS SD:DNS服务发现。
o Anycast: Send TURN Allocation request to the assigned TURN anycast request for each combination of interface and address family.
o 选播：为接口和地址系列的每个组合向指定的选播请求发送轮数分配请求。
Not all TURN servers may be discovered using NAPTR records or DNS SD. Similarly, not all TURN servers may support anycast. For best results, a client SHOULD implement all the discovery mechanisms described above.
并非所有TURN服务器都可以使用NAPTR记录或DNS SD发现。同样，并非所有TURN服务器都支持选播。为了获得最佳结果，客户机应该实现上述所有发现机制。
The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform all the above steps in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds.
该文件并未规定客户在发现时必须遵守的严格顺序。实现可以选择并行执行上述所有步骤以进行发现，或者选择遵循任何所需顺序并在机制成功时停止发现过程。
On hosts with more than one interface or address family (IPv4/v6), the TURN server discovery procedure has to be performed for each combination of interface and address family. A client MAY choose to perform the discovery procedure only for a desired interface/address combination if the client does not wish to discover a TURN server for all combinations of interface and address family.
在具有多个接口或地址系列（IPv4/v6）的主机上，必须对接口和地址系列的每个组合执行TURN服务器发现过程。如果客户端不希望为接口和地址系列的所有组合发现TURN服务器，则客户端可以选择仅对所需的接口/地址组合执行发现过程。
This mechanism is performed in two steps:
此机制分两步执行：
1. A DNS domain name is retrieved for each combination of interface and address family.
1. 为接口和地址系列的每个组合检索DNS域名。
2. Retrieved DNS domain names are then used for S-NAPTR lookups as per [RFC5928]. Further DNS lookups may be necessary to determine TURN server IP address(es).
2. 然后根据[RFC5928]将检索到的DNS域名用于S-NAPTR查找。可能需要进一步的DNS查找来确定TURN服务器IP地址。
A client has to determine the domain in which it is located. The following sections provide two possible mechanisms to learn the domain name, but other means of retrieving domain names may be used, which are outside the scope of this document, e.g., local configuration.
客户端必须确定其所在的域。以下各节提供了两种可能的机制来了解域名，但也可以使用其他检索域名的方法，这些方法不在本文档的范围内，例如本地配置。
Implementations may allow the user to specify a default name that is used if no specific name has been configured.
实现可能允许用户指定默认名称，如果未配置特定名称，则使用该名称。
DHCP can be used to determine the domain name related to an interface's point of network attachment. Network operators may provide the domain name to be used for service discovery within an access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define DHCP IPv4 and IPv6 access network domain name options, OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to identify a domain name that is suitable for service discovery within the access network.
DHCP可用于确定与接口的网络连接点相关的域名。网络运营商可以使用DHCP在接入网络内提供用于服务发现的域名。[RFC5986]的第3.2节和第3.3节分别定义了DHCP IPv4和IPv6访问网络域名选项、选项_V4_访问_域和选项_V6_访问_域，以确定适合访问网络内服务发现的域名。
For IPv4, the discovery procedure MUST request the access network domain name option in a Parameter Request List option, as described in [RFC2131]. [RFC2132] defines the DHCP IPv4 domain name option; while this option is less suitable, a client MAY request it if the access network domain name defined in [RFC5986] is not available.
对于IPv4，发现过程必须在参数请求列表选项中请求访问网络域名选项，如[RFC2131]中所述。[RFC2132]定义DHCP IPv4域名选项；虽然此选项不太合适，但如果[RFC5986]中定义的接入网络域名不可用，客户端可能会请求此选项。
For IPv6, the discovery procedure MUST request the access network domain name option in an Options Request Option (ORO) within an Information-request message, as described in [RFC3315].
对于IPv6，发现过程必须在信息请求消息中的选项请求选项（ORO）中请求访问网络域名选项，如[RFC3315]中所述。
If neither option can be retrieved, the procedure fails for this interface. If a result can be retrieved, it will be used as an input for S-NAPTR resolution.
如果两个选项都无法检索，则此接口的过程将失败。如果可以检索结果，则将其用作S-NAPTR分辨率的输入。
For a TURN client with an understanding of the protocol mechanics of calling applications, the client may wish to extract the domain name from its own identity, i.e, the canonical identifier used to reach the user.
对于理解调用应用程序的协议机制的TURN客户机，客户机可能希望从其自己的标识（即用于到达用户的规范标识符）中提取域名。
Example:
例子：
SIP : 'sip:alice@example.com'
Bare JID : 'alice@example.com'
email : 'alice@example.com'
SIP : 'sip:alice@example.com'
Bare JID : 'alice@example.com'
email : 'alice@example.com'
'example.com' is retrieved from the above examples.
从上述示例中检索“example.com”。
A client may support multiple users, potentially with different domains, or a single user utilizing different domains for different services. The means to choose and extract the domain name may be different based on the type of identifier, service being used, etc., which are outside the scope of this document.
客户机可能支持多个用户，可能具有不同的域，或者单个用户使用不同的域提供不同的服务。根据标识符类型、使用的服务等，选择和提取域名的方法可能会有所不同，这超出了本文档的范围。
Once the TURN discovery procedure has retrieved domain names, the resolution mechanism described in [RFC5928] is followed. An S-NAPTR lookup with the 'RELAY' application service and the desired protocol tag is made to obtain the information necessary to connect to the authoritative TURN server within the given domain.
一旦回合发现程序检索到域名，将遵循[RFC5928]中描述的解析机制。使用“中继”应用程序服务和所需的协议标签进行S-NAPTR查找，以获取连接到给定域内权威TURN服务器所需的信息。
If no TURN-specific S-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If more domain names are known, the discovery procedure may perform the corresponding S-NAPTR lookups immediately. However, before retrying a lookup that has failed, a client must wait a time period that is appropriate for the encountered error (NXDOMAIN, timeout, etc.).
如果无法检索特定于TURN的S-NAPTR记录，则该域名（以及相应的接口和IP协议版本）的发现过程将失败。如果已知更多域名，发现过程可能会立即执行相应的S-NAPTR查找。但是，在重试失败的查找之前，客户端必须等待一段适合遇到错误的时间（NXDOMAIN、超时等）。
DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS (mDNS) [RFC6762] provide generic solutions for discovering services available in a local network. DNS-SD/mDNS define a set of naming rules for certain DNS record types that they use for advertising and discovering services.
基于DNS的服务发现（DNS-SD）[RFC6763]和多播DNS（MDN）[RFC6762]为发现本地网络中可用的服务提供了通用解决方案。DNS-SD/MDN为用于广告和发现服务的特定DNS记录类型定义一组命名规则。
Section 4.1 of [RFC6763] specifies that a service instance name in DNS-SD has the following structure:
[RFC6763]第4.1节规定DNS-SD中的服务实例名称具有以下结构：
<Instance> . <Service> . <Domain>
<Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS sub-domain where the service instance is registered. It may be "local.", indicating the mDNS local domain, or it may be a conventional domain name such as "example.com.". The <Service> portion of the TURN service instance name MUST be "_turn._udp" or "_turn._tcp" or "_turns._udp" or "_turns._tcp", as introduced in [RFC5766].
<Domain>部分指定注册服务实例的DNS子域。它可以是“local.”，表示mDNS本地域，也可以是常规域名，如“example.com.”。TURN服务实例名称的<Service>部分必须是“\u TURN.\u udp”或“\u TURN.\u tcp”或“\u turns.\u udp”或“\u turns.\u tcp”，如[RFC5766]中所述。
A TURN client can proactively discover TURN servers being advertised in the site by multicasting a PTR query to one or all of the following:
TURN客户端可以通过将PTR查询多播到以下一个或全部内容，主动发现站点中正在播发的TURN服务器：
o "_turn._udp.local."
o “_turn._udp.local”
o "_turn._tcp.local"
o “_turn._tcp.local”
o "_turns._udp.local."
o “_turns._udp.local”
o "_turns._tcp.local"
o “_turns._tcp.local”
A TURN server can send out gratuitous multicast DNS answer packets whenever it starts up, wakes from sleep, or detects a change in network configuration. TURN clients receive these gratuitous packets and cache information contained in it.
TURN服务器可以在启动、从睡眠中唤醒或检测到网络配置发生变化时发送免费的多播DNS应答包。TURN客户端接收这些免费数据包并缓存其中包含的信息。
IP anycast can also be used for TURN service discovery. A packet sent to an anycast address is delivered to the "topologically nearest" network interface with the anycast address. Using the TURN anycast address, the only two things that need to be deployed in the network for discovery are the two things that actually use TURN.
IP选播也可用于TURN服务发现。发送到选播地址的数据包被发送到具有选播地址的“拓扑上最近的”网络接口。使用TURN选播地址，只需要在网络中部署两件事来进行发现，即实际使用TURN的两件事。
When a client requires TURN services, it sends a TURN Allocation request to the assigned anycast address. A TURN anycast server performs checks 1 through 7 discussed in Section 6.2 of [RFC5766]. If all checks pass, the TURN anycast server MUST respond with a 300 (Try Alternate) error as described in Section 2.9 of [RFC5766]; the response contains the TURN unicast address in the ALTERNATE-SERVER attribute. For subsequent communication with the TURN server, the client uses the responding server's unicast address. This has to be done because two packets addressed to an anycast address may reach
当客户端需要回合服务时，它会向指定的选播地址发送回合分配请求。TURN选播服务器执行[RFC5766]第6.2节中讨论的检查1到7。如果所有检查都通过，TURN选播服务器必须响应[RFC5766]第2.9节中所述的300（Try Alternate）错误；响应在ALTERNATE-SERVER属性中包含TURN单播地址。对于与TURN服务器的后续通信，客户端使用响应服务器的单播地址。必须这样做，因为寻址到选播地址的两个数据包可能到达
two different anycast servers. The client, thus, also needs to ensure that the initial request fits in a single packet. An implementation may choose to send out every new TURN Allocation request to the anycast address to discover the closest and the most optimal unicast address for the TURN server.
两个不同的选播服务器。因此，客户机还需要确保初始请求适合单个数据包。实现可以选择向选播地址发送每个新的回合分配请求，以发现回合服务器的最近和最佳单播地址。
A change of IP address on an interface may invalidate the result of the TURN server discovery procedure. For instance, if the IP address assigned to a mobile host changes due to host mobility, it may be required to re-run the TURN server discovery procedure without relying on earlier gained information. New requests should be made to the newly learned TURN servers that were learned after TURN the discovery was re-run. However, if an earlier learned TURN server is still accessible using the new IP address, procedures described for mobility using TURN defined in [RFC8016] can be used for ongoing streams.
接口上IP地址的更改可能会使TURN服务器发现过程的结果无效。例如，如果分配给移动主机的IP地址由于主机移动性而改变，则可能需要重新运行TURN服务器发现过程，而不依赖于先前获得的信息。重新运行发现后，应向新学习的回合服务器发出新请求。但是，如果使用新的IP地址仍然可以访问先前学习的TURN服务器，则[RFC8016]中定义的使用TURN的移动过程可用于正在进行的流。
WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms described in this specification as an enterprise/gateway or access network server, in accordance with Recursively Encapsulated TURN [RETURN].
WebRTC端点应根据递归封装的TURN[RETURN]，将通过本规范中描述的机制发现的任何TURN服务器视为企业/网关或访问网络服务器。
IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix and registered it in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890].
IANA已从192.0.0.0/24前缀分配了一个IPv4地址，并将其注册到“IANA IPv4专用地址注册表”[RFC6890]。
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.10/32 |
| Name | Traversal Using Relays around NAT Anycast |
| RFC | RFC 8155 |
| Allocation Date | 2017-02 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.10/32 |
| Name | Traversal Using Relays around NAT Anycast |
| RFC | RFC 8155 |
| Allocation Date | 2017-02 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
IANA has assigned a single IPv6 address from the 2001:0000::/23 prefix and registered it in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890].
IANA已从2001:0000:：/23前缀分配了一个IPv6地址，并将其注册到“IANA IPv6专用地址注册表”[RFC6890]。
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::2/128 |
| Name | Traversal Using Relays around NAT Anycast |
| RFC | RFC 8155 |
| Allocation Date | 2017-02 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::2/128 |
| Name | Traversal Using Relays around NAT Anycast |
| RFC | RFC 8155 |
| Allocation Date | 2017-02 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
Use of Session Traversal Utilities for NAT (STUN) [RFC5389] authentication is OPTIONAL for TURN servers provided by the local network or by the access network. A network-provided TURN server MAY be configured to accept Allocation requests without STUN authentication, and a TURN client MAY be configured to accept Allocation success responses without STUN authentication from a network-provided TURN server.
对于本地网络或接入网络提供的TURN服务器，使用NAT（STUN）[RFC5389]身份验证的会话遍历实用程序是可选的。网络提供的TURN服务器可配置为接受分配请求而无需STUN认证，TURN客户端可配置为接受来自网络提供的TURN服务器的分配成功响应而无需STUN认证。
Making STUN authentication optional is a downgrade of a MUST level requirement defined in [RFC5766]. The downgrade allows TURN servers provided by the local or access network to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication. The intention in such deployments is to provide TURN services to all users in the local or access network. However, this opens up a TURN server to a variety of attacks described in Section 17 of [RFC5766]. A TURN server in such cases must be configured to only process STUN requests from the trusted local network or subscribers of the access network. Operational measures must be taken in order to protect the TURN server; some of these measures include, but are not limited to, access control by means of access lists, firewalls, subscriber quota limits, ingress filtering, etc.
将STUN身份验证设置为可选是对[RFC5766]中定义的必须级别要求的降级。降级允许本地或接入网络提供的TURN服务器接受网络中新用户和/或来宾用户的分配请求，这些用户不一定拥有STUN身份验证的长期凭据。此类部署的目的是向本地或接入网络中的所有用户提供TURN服务。但是，这会使TURN服务器面临[RFC5766]第17节所述的各种攻击。在这种情况下，TURN服务器必须配置为仅处理来自受信任本地网络或接入网络订户的STUN请求。必须采取操作措施以保护TURN服务器；其中一些措施包括但不限于通过访问列表、防火墙、订户配额限制、入口过滤等方式进行访问控制。
A TURN client in the absence of the STUN long-term credential mechanism [RFC5389] or the STUN Extension for Third-Party Authorization [RFC7635] MUST use (D)TLS unless it trusts the network infrastructure to defend against attacks discussed in [RFC5766]. It is RECOMMENDED that the TURN client use one of the following techniques with (D)TLS to validate the TURN server:
在没有STUN长期凭证机制[RFC5389]或第三方授权的STUN扩展[RFC7635]的情况下，TURN客户端必须使用（D）TLS，除非它信任网络基础设施来防御[RFC5766]中讨论的攻击。建议TURN客户端对（D）TLS使用以下技术之一来验证TURN服务器：
o For certificate-based authentication, a pre-populated trust anchor store [RFC6024] allows a TURN client to perform path validation for the server certificate obtained during the (D)TLS handshake. If the client used a domain name to discover the TURN server, that domain name also provides a mechanism for validation of the TURN server. The client MUST use the rules and guidelines given in Section 6 of [RFC6125] to validate the TURN server identity.
o 对于基于证书的身份验证，预填充的信任锚存储[RFC6024]允许TURN客户端对在（D）TLS握手期间获得的服务器证书执行路径验证。如果客户端使用域名发现TURN服务器，则该域名还提供验证TURN服务器的机制。客户机必须使用[RFC6125]第6节中给出的规则和指南来验证TURN服务器标识。
o Certification authorities that issue TURN server certificates SHOULD support the CN-ID, DNS-ID, SRV-ID, and URI-ID identifier types. TURN service providers SHOULD prefer the use of DNS-ID, SRV-ID, and URI-ID over CN-ID identifier types in certificate requests (as described in Section 2.3 from [RFC6125]) and the wildcard character '*' SHOULD NOT be included in the presented identifier.
o 颁发TURN服务器证书的证书颁发机构应支持CN-ID、DNS-ID、SRV-ID和URI-ID标识符类型。TURN服务提供商在证书请求中应优先使用DNS-ID、SRV-ID和URI-ID，而不是CN-ID标识符类型（如[RFC6125]第2.3节所述），并且通配符“*”不应包含在提供的标识符中。
o For TURN servers that don't have a certificate trust chain (e.g., because they are on a home network or a corporate network), a configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public key is used for the same reasons HTTP pinning [RFC7469] uses the public key.
o 对于没有证书信任链的TURN服务器（例如，因为它们位于家庭网络或公司网络上），TURN服务器的配置列表可以包含TURN服务器的主题公钥信息（SPKI）指纹。使用公钥的原因与HTTP固定[RFC7469]使用公钥的原因相同。
o Raw public key-based authentication, as defined in [RFC7250], could also be used to authenticate a TURN server.
o [RFC7250]中定义的基于原始公钥的身份验证也可用于对TURN服务器进行身份验证。
An auto-discovered TURN server is considered to be only as trusted as the path between the client and the TURN server. In order to safely use auto-discovered TURN servers for sessions with 'strict privacy' requirements, the user needs to be able to define privacy criteria (e.g., a trusted list of servers, networks, or domains) that are considered acceptable for such traffic. Any discovered TURN server outside the criteria is considered untrusted and therefore MUST NOT be used for privacy-sensitive communication.
自动发现的TURN服务器仅被视为与客户端和TURN服务器之间的路径一样受信任。为了安全地将自动发现的TURN服务器用于具有“严格隐私”要求的会话，用户需要能够定义被认为可接受此类流量的隐私标准（例如，服务器、网络或域的可信列表）。任何发现的超出标准的TURN服务器都被视为不受信任，因此不得用于隐私敏感的通信。
In some auto-discovery scenarios, it might not be possible for the TURN client to use (D)TLS authentication to validate the TURN server. However, fallback to clear text in such cases could leave the TURN client open to on-path injection of spoofed TURN messages. A TURN client could fall back to encryption-only (D)TLS when (D)TLS authentication is not available but MUST NOT fall back without explicit administrator choice. Another reason to fall back to encryption-only is for privacy, which is analogous to SMTP opportunistic encryption [RFC7435] where one does not require privacy but one desires privacy when possible.
在某些自动发现场景中，TURN客户端可能无法使用（D）TLS身份验证来验证TURN服务器。但是，在这种情况下，回退到明文可能会使TURN客户端对路径上注入伪造的TURN消息保持开放。当（D）TLS身份验证不可用时，TURN客户端可以退回到仅加密（D）TLS，但如果没有明确的管理员选择，则不能退回。退而只使用加密的另一个原因是为了隐私，这类似于SMTP机会主义加密[RFC7435]，其中不需要隐私，但在可能的情况下需要隐私。
In order to allow the TURN client to fall back to (D)TLS as described above, a TURN server that does not require either STUN long-term authentication [RFC5389] or STUN Extension for Third Party Authorization [RFC7635] MUST support (D)TLS and, if the network infrastructure is capable of defending against attacks discussed in [RFC5766], then the TURN server MAY allow fallback to clear text.
为了允许TURN客户端退回到（D）TLS（如上所述），不需要STUN长期身份验证[RFC5389]或第三方授权的STUN扩展[RFC7635]的TURN服务器必须支持（D）TLS，并且如果网络基础设施能够抵御[RFC5766]中讨论的攻击，然后，TURN服务器可能允许回退以清除文本。
A TURN client could fall back to clear text if it does not support unauthenticated (D)TLS but MUST NOT fall back without explicit administrator choice. Fallback to clear text is NOT RECOMMENDED because it makes the client more susceptible to man-in-the-middle attacks and on-path packet injection.
如果TURN客户端不支持未经身份验证的（D）TLS，则它可以退回到明文，但如果没有明确的管理员选择，则不能退回。不建议回退到明文，因为它使客户端更容易受到中间人攻击和路径数据包注入。
The primary attack against the methods described in this document is one that would lead to impersonation of a TURN server. An attacker could attempt to compromise the S-NAPTR resolution. Security considerations described in [RFC5928] are applicable here as well.
针对本文档中描述的方法的主要攻击会导致模拟TURN服务器。攻击者可能试图破坏S-NAPTR解决方案。[RFC5928]中描述的安全注意事项也适用于此处。
In addition to considerations related to S-NAPTR, it is important to recognize that the output of this is entirely dependent on its input. An attacker who can control the domain name can also control the final result. Because more than one method can be used to determine the domain name, a host implementation needs to consider attacks against each of the methods that are used.
除了与S-NAPTR相关的考虑因素外，还必须认识到其输出完全取决于其输入。可以控制域名的攻击者也可以控制最终结果。因为可以使用多种方法来确定域名，所以主机实现需要考虑对所使用的每种方法的攻击。
If DHCP is used, the integrity of DHCP options is limited by the security of the channel over which they are provided. Physical security and separation of DHCP messages from other packets are commonplace methods that can reduce the possibility of attack within an access network; alternatively, DHCP authentication [RFC3188] can provide a degree of protection against modification. When using DHCP discovery, clients are encouraged to use unicast DHCP INFORM queries instead of broadcast queries, which are more easily spoofed in insecure networks.
如果使用DHCP，DHCP选项的完整性将受到提供这些选项的通道的安全性的限制。物理安全性和DHCP消息与其他数据包的分离是常见的方法，可以降低接入网络中的攻击可能性；或者，DHCP身份验证[RFC3188]可以提供一定程度的防修改保护。在使用DHCP发现时，鼓励客户端使用单播DHCP通知查询而不是广播查询，广播查询在不安全的网络中更容易被欺骗。
Since DNS-SD is just a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important. For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.
由于DNS-SD只是现有DNS系统中如何命名和使用记录的规范，因此除了已经应用于DNS查询和DNS更新的安全要求外，它没有其他特定的安全要求。对于DNS查询，如果信息的真实性很重要，则应使用DNS安全扩展（DNSSEC）[RFC4033]。对于DNS更新，通常应使用安全更新[RFC2136][RFC3007]来控制哪些客户端有权更新DNS记录。
For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers.
对于MDN，除了上述内容之外，主要的安全威胁是IP多播路由和在其上运行的任何应用程序固有的安全威胁。流氓系统可以公布它是回合服务器。如果TURN客户端能够对发现的TURN服务器进行身份验证和授权，则发现TURN服务器等恶意系统本身并不构成安全威胁。
In a network without any TURN server that is aware of the TURN anycast address, outgoing TURN requests could leak out onto the external Internet, possibly revealing information.
在没有任何知道TURN选播地址的TURN服务器的网络中，传出的TURN请求可能泄漏到外部Internet上，可能泄露信息。
Using an IANA-assigned well-known TURN anycast address enables border gateways to block such outgoing packets. In the default-free zone, routers should be configured to drop such packets. Such configuration can occur naturally via BGP messages advertising that no route exists to said address.
使用IANA分配的众所周知的TURN选播地址，使边界网关能够阻止此类传出数据包。在默认自由区中，路由器应配置为丢弃此类数据包。这样的配置可以通过BGP消息自然发生，该消息声明不存在到所述地址的路由。
Sensitive clients that do not wish to leak information about their presence can set an IP TTL on their TURN requests that limits how far they can travel into the public Internet.
不希望泄露其存在信息的敏感客户端可以在其轮换请求上设置IP TTL，以限制其进入公共互联网的距离。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<http://www.rfc-editor.org/info/rfc2132>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<http://www.rfc-editor.org/info/rfc2136>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <http://www.rfc-editor.org/info/rfc3007>.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，DOI 10.17487/RFC3007，2000年11月<http://www.rfc-editor.org/info/rfc3007>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, DOI 10.17487/RFC5928, August 2010, <http://www.rfc-editor.org/info/rfc5928>.
[RFC5928]Petit Huguenin，M.“使用NAT（转弯）解析机制周围的中继进行遍历”，RFC 5928，DOI 10.17487/RFC5928，2010年8月<http://www.rfc-editor.org/info/rfc5928>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, DOI 10.17487/RFC5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 5986，DOI 10.17487/RFC5986，2010年9月<http://www.rfc-editor.org/info/rfc5986>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <http://www.rfc-editor.org/info/rfc6024>.
[RFC6024]Reddy，R.和C.Wallace，“信托锚管理要求”，RFC 6024，DOI 10.17487/RFC60242010年10月<http://www.rfc-editor.org/info/rfc6024>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<http://www.rfc-editor.org/info/rfc6763>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 6890，DOI 10.17487/RFC6890，2013年4月<http://www.rfc-editor.org/info/rfc6890>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7250]Wouters，P.，Ed.，Tschofenig，H.，Ed.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年6月<http://www.rfc-editor.org/info/rfc7250>.
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <http://www.rfc-editor.org/info/rfc7635>.
[RFC7635]Reddy，T.，Patil，P.，Ravindranath，R.，和J.Uberti，“第三方授权NAT（STUN）扩展的会话遍历实用程序”，RFC 7635，DOI 10.17487/RFC7635，2015年8月<http://www.rfc-editor.org/info/rfc7635>.
[RETURN] Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC", Work in Progress, draft-ietf-rtcweb-return-02, March 2017.
[RETURN]Schwartz，B.和J.Uberti，“网络RTC中连接和隐私的递归封装TURN（RETURN）”，正在进行的工作，草稿-ietf-rtcweb-RETURN-022017年3月。
[RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC3188]Hakala，J.，“使用国家书目编号作为统一资源名称”，RFC 3188，DOI 10.17487/RFC3188，2001年10月<http://www.rfc-editor.org/info/rfc3188>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC5128]Srisuresh，P.，Ford，B.，和D.Kegel，“跨网络地址转换器（NAT）的对等（P2P）通信状态”，RFC 5128，DOI 10.17487/RFC5128，2008年3月<http://www.rfc-editor.org/info/rfc5128>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<http://www.rfc-editor.org/info/rfc7469>.
[RFC8016] Reddy, T., Wing, D., Patil, P., and P. Martinsen, "Mobility with Traversal Using Relays around NAT (TURN)", RFC 8016, DOI 10.17487/RFC8016, November 2016, <http://www.rfc-editor.org/info/rfc8016>.
[RFC8016]Reddy，T.，Wing，D.，Patil，P.，和P.Martinsen，“利用NAT（转弯）周围的中继进行穿越的机动性”，RFC 8016，DOI 10.17487/RFC8016，2016年11月<http://www.rfc-editor.org/info/rfc8016>.
[WebRTC-Overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-18, March 2017.
[WebRTC概述]Alvestrand，H.，“概述：基于浏览器的应用程序的实时协议”，正在进行的工作，草稿-ietf-rtcweb-Overview-18，2017年3月。
Acknowledgements
致谢
The authors would like to thank Simon Perrault, Paul Kyzivat, Troy Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl, Brian Weis, Ralph Dromes, Ben Campbell, Suresh Krishnan, and Brandon Williams for their review and valuable comments. Thanks to Adam Roach for his detailed review and suggesting DNS Service Discovery as an additional discovery mechanism.
作者要感谢Simon Perrault、Paul Kyzivat、Troy Shields、Eduardo Gueiros、Ted Hardie、Bernard Aboba、Karl Stahl、Brian Weis、Ralph Dromes、Ben Campbell、Suresh Krishnan和Brandon Williams的评论和宝贵意见。感谢Adam Roach的详细评论，并建议将DNS服务发现作为一种额外的发现机制。
Authors' Addresses
作者地址
Prashanth Patil Cisco Systems, Inc.
Prashanth Patil思科系统公司。
Email: praspati@cisco.com
Email: praspati@cisco.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Dan Wing United States America
丹荣美国
Email: dwing-ietf@fuggles.com
Email: dwing-ietf@fuggles.com