Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 5928 Unaffiliated
Category: Standards Track August 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 5928 Unaffiliated
Category: Standards Track August 2010
ISSN: 2070-1721
Traversal Using Relays around NAT (TURN) Resolution Mechanism
使用NAT（TURN）解析机制周围的中继进行遍历
Abstract
摘要
This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation.
本文档定义了一种解析机制，用于生成服务器传输地址列表，可以尝试使用NAT（TURN）分配周围的中继创建遍历。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5928.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5928.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 6
4.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Compatibility with TURN . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. RELAY Application Service Tag Registration . . . . . . . . 9
6.2. turn.udp Application Protocol Tag Registration . . . . . . 9
6.3. turn.tcp Application Protocol Tag Registration . . . . . . 9
6.4. turn.tls Application Protocol Tag Registration . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 6
4.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Compatibility with TURN . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. RELAY Application Service Tag Registration . . . . . . . . 9
6.2. turn.udp Application Protocol Tag Registration . . . . . . 9
6.3. turn.tcp Application Protocol Tag Registration . . . . . . 9
6.4. turn.tls Application Protocol Tag Registration . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
The Traversal Using Relays around NAT (TURN) specification [RFC5766] defines a process for a TURN client to find TURN servers by using DNS SRV resource records, but this process does not let the TURN server administrators provision the preferred TURN transport protocol between the client and the server and does not allow the TURN client to discover this preference. This document defines an S-NAPTR application [RFC3958] for this purpose. This application defines "RELAY" as an application service tag and "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags.
NAT（TURN）规范[RFC5766]中使用中继的遍历定义了TURN客户端使用DNS SRV资源记录查找TURN服务器的过程，但此过程不允许TURN服务器管理员在客户端和服务器之间设置首选TURN传输协议，也不允许TURN客户端发现此首选项。本文件为此目的定义了S-NAPTR应用程序[RFC3958]。此应用程序将“中继”定义为应用程序服务标记，“turn.udp”、“turn.tcp”和“turn.tls”定义为应用程序协议标记。
Another usage of the resolution mechanism described in this document would be Remote Hosting as described in [RFC3958], Section 4.4. For example, a Voice over IP (VoIP) provider who does not want to deploy TURN servers could use the servers deployed by another company but could still want to provide configuration parameters to its customers without explicitly showing this relationship. The mechanism permits one to implement this indirection, without preventing the company hosting the TURN servers from managing them as it sees fit.
本文件中描述的解析机制的另一个用途是远程托管，如[RFC3958]第4.4节所述。例如，不希望部署TURN服务器的IP语音（VoIP）提供商可以使用另一家公司部署的服务器，但仍然希望在不明确显示此关系的情况下向其客户提供配置参数。该机制允许实现这种间接寻址，而不会阻止托管TURN服务器的公司按照其认为合适的方式管理它们。
[TURN-URI] can be used as a convenient way of carrying the four components (see Section 3) needed by the resolution mechanism described in this document. A reference implementation is available [REF-IMPL].
[TURN-URI]可以作为携带本文档中描述的解析机制所需的四个组件（见第3节）的方便方式。参考实现可用[REF-IMPL]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The resolution mechanism is used only to create an allocation. All other transactions use the IP address, transport, and port used for a successful allocation creation. The resolution mechanism only selects the transport used between the TURN client and the TURN server. The transport used by the allocation itself is selected by the REQUESTED-TRANSPORT attribute as described in Section 6.1 of [RFC5766].
解析机制仅用于创建分配。所有其他事务使用用于成功创建分配的IP地址、传输和端口。解析机制仅选择TURN客户端和TURN服务器之间使用的传输。分配本身使用的传输由[RFC5766]第6.1节所述的请求传输属性选择。
The resolution algorithm uses a boolean flag, <secure>; an IP address or domain name, <host>; a port number that can be empty, <port>; and a transport name that can be "udp", "tcp", or empty, <transport> as input. These four parameters are part of the user configuration of the TURN client. The resolution mechanism also uses as input a list, ordered by preference of supported TURN transports (UDP, TCP, Transport Layer Security (TLS)), that is provided by the application using the TURN client. This list reflects the capabilities and preferences of the application code that is using the S-NAPTR resolver and TURN client, as opposed to the configuration parameters that reflect the preferences of the user of the application. The output of the algorithm is a list of {IP address, transport, port} tuples that a TURN client can try in order to create an allocation on a TURN server.
解析算法使用布尔标志，<secure>；IP地址或域名，<host>；可以为空的端口号，<port>；以及可以是“udp”、“tcp”或空的传输名称，<transport>作为输入。这四个参数是TURN客户端用户配置的一部分。解析机制还使用一个列表作为输入，该列表按支持的TURN传输（UDP、TCP、传输层安全性（TLS））的首选项排序，该列表由使用TURN客户端的应用程序提供。此列表反映使用S-NAPTR解析器和TURN客户端的应用程序代码的功能和首选项，而不是反映应用程序用户首选项的配置参数。该算法的输出是一个{IP地址、传输、端口}元组列表，TURN客户端可以尝试该元组，以便在TURN服务器上创建分配。
An Allocate error response as specified in Section 6.4 of [RFC5766] is processed as a failure, as specified by [RFC3958], Section 2.2.4. The resolution stops when a TURN client gets a successful Allocate response from a TURN server. After an allocation succeeds or all the allocations fail, the resolution context MUST be discarded, and the resolution algorithm MUST be restarted from the beginning for any subsequent allocation. Servers temporarily blacklisted as described in Section 6.4 of [RFC5766], specifically because of a 437, 486, or 508 error code, MUST NOT be used for the specified duration, even if returned by a subsequent resolution.
[RFC5766]第6.4节规定的分配错误响应按照[RFC3958]第2.2.4节的规定作为故障处理。当TURN客户端从TURN服务器获得成功的分配响应时，解析停止。分配成功或所有分配失败后，必须放弃解析上下文，并且必须从头开始重新启动解析算法以进行后续分配。如[RFC5766]第6.4节所述，特别是由于437、486或508错误代码而被临时列入黑名单的服务器，即使通过后续解决方案返回，也不得在指定的持续时间内使用。
First, the resolution algorithm checks that the parameters can be resolved with the list of TURN transports supported by the application:
首先，解析算法检查是否可以使用应用程序支持的转弯传输列表解析参数：
o If <secure> is false and <transport> is defined as "udp" but the list of TURN transports supported by the application does not contain UDP, then the resolution MUST stop with an error.
o 如果<secure>为false且<transport>定义为“udp”，但应用程序支持的TURN传输列表不包含udp，则解析必须以错误停止。
o If <secure> is false and <transport> is defined as "tcp" but the list of TURN transports supported by the application does not contain TCP, then the resolution MUST stop with an error.
o 如果<secure>为false且<transport>定义为“tcp”，但应用程序支持的TURN传输列表不包含tcp，则解析必须以错误停止。
o If <secure> is true and <transport> is defined as "udp", then the resolution MUST stop with an error.
o 如果<secure>为true且<transport>定义为“udp”，则解析必须停止并出现错误。
o If <secure> is true and <transport> is defined as "tcp" but the list of TURN transports supported by the application does not contain TLS, then the resolution MUST stop with an error.
o 如果<secure>为true且<transport>定义为“tcp”，但应用程序支持的TURN传输列表不包含TLS，则解析必须以错误停止。
o If <secure> is true and <transport> is not defined but the list of TURN transports supported by the application does not contain TLS, then the resolution MUST stop with an error.
o 如果<secure>为true且未定义<transport>，但应用程序支持的转弯传输列表不包含TLS，则解析必须以错误停止。
o If <transport> is defined but unknown, then the resolution MUST stop with an error.
o 如果定义了<transport>，但未知，则解析必须停止并出现错误。
After verifying the validity of the parameters, the algorithm filters the list of TURN transports supported by the application by removing the UDP and TCP TURN transport if <secure> is true. If the list of TURN transports is empty after this filtering, the resolution MUST stop with an error.
验证参数的有效性后，如果<secure>为true，则该算法通过删除UDP和TCP TURN传输来过滤应用程序支持的TURN传输列表。如果此筛选后回合传输列表为空，则解析必须停止并出现错误。
After filtering the list of TURN transports supported by the application, the algorithm applies the steps described below. Note that in some steps, <secure> and <transport> have to be converted to a TURN transport. If <secure> is false and <transport> is defined as "udp", then the TURN UDP transport is used. If <secure> is false and <transport> is defined as "tcp", then the TURN TCP transport is used. If <secure> is true and <transport> is defined as "tcp", then the TURN TLS transport is used. This is summarized in Table 1.
过滤应用程序支持的转弯传输列表后，该算法应用以下步骤。请注意，在某些步骤中，<secure>和<transport>必须转换为转弯运输。如果<secure>为false且<transport>定义为“udp”，则使用TURN udp传输。如果<secure>为false且<transport>定义为“tcp”，则使用TURN tcp传输。如果<secure>为true且<transport>定义为“tcp”，则使用TURN TLS传输。表1对此进行了总结。
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| false | "udp" | UDP |
| false | "tcp" | TCP |
| true | "tcp" | TLS |
+----------+-------------+----------------+
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| false | "udp" | UDP |
| false | "tcp" | TCP |
| true | "tcp" | TLS |
+----------+-------------+----------------+
Table 1
表1
1. If <host> is an IP address, then it indicates the specific IP address to be used. If <port> is not defined, then either the default port declared in [RFC5766] for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true, MUST be used for contacting the TURN server. If <transport> is defined, then <secure> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried by preference order. If the TURN client cannot contact a TURN server with this IP address and port on any of the transports supported by the application, then the resolution MUST stop with an error.
1. 如果<host>是一个IP地址，则表示要使用的特定IP地址。如果未定义<port>，则必须使用[RFC5766]中为“turn”SRV服务名称声明的默认端口（如果<secure>为false）或“turns”SRV服务名称（如果<secure>为true）来联系turn服务器。如果定义了<transport>，则<secure>和<transport>将转换为表1中规定的转弯运输。如果未定义<transport>，则将按优先顺序尝试应用程序支持的过滤转弯运输。如果TURN客户端无法使用此IP地址和应用程序支持的任何传输上的端口联系TURN服务器，则解析必须停止并出现错误。
2. If <host> is a domain name and <port> is defined, then <host> is resolved to a list of IP addresses via DNS A and AAAA queries. If <transport> is defined, then <secure> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried in preference order. The TURN client can choose the order to contact the resolved IP addresses in any implementation-specific way. If the TURN client cannot contact a TURN server with this port, the transport or list of transports, and the resolved IP addresses, then the resolution MUST stop with an error.
2. 如果<host>是一个域名并且定义了<port>，那么<host>将通过DNS a和AAAA查询解析为IP地址列表。如果定义了<transport>，则<secure>和<transport>将转换为表1中规定的转弯运输。如果未定义<transport>，则将按首选顺序尝试应用程序支持的过滤转弯运输。TURN客户端可以选择以任何特定于实现的方式联系解析的IP地址的顺序。如果TURN客户端无法使用此端口、传输或传输列表以及解析的IP地址联系TURN服务器，则解析必须停止并出现错误。
3. If <host> is a domain name and <port> is not defined but <transport> is defined, then the SRV algorithm defined in [RFC2782] is used to generate a list of IP address and port tuples. <host> is used as Name, a value of false for <secure> as "turn" for Service, a value of true for <secure> as "turns" for Service, and <transport> as Protocol (Proto) in the SRV algorithm. <secure> and <transport> are converted to a TURN transport as specified in Table 1, and this transport is used with each tuple for contacting the TURN server. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case, the default port declared in [RFC5766] for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true, MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm with the transport converted from <secure> and <transport>, then the resolution MUST stop with an error.
3. 如果<host>是一个域名，并且未定义<port>，但定义了<transport>，则使用[RFC2782]中定义的SRV算法生成IP地址和端口元组列表<主机>用作名称，<secure>的值为false，服务的值为“turn”；服务的值为true，服务的值为“turns”；SRV算法中的<transport>协议（Proto）<secure>和<transport>转换为表1中指定的TURN传输，该传输与每个元组一起用于联系TURN服务器。如果SRV查询返回错误或没有SRV RR，SRV算法建议执行A查询；在这种情况下，[RFC5766]中为“turn”SRV服务名称声明的默认端口（如果<secure>为false）或“turns”SRV服务名称（如果<secure>为true）必须用于联系turn服务器。同样在这种情况下，本规范通过推荐A和AAAA查询来修改SRV算法。如果TURN客户端无法通过从<secure>和<transport>转换的传输与SRV算法返回的任何IP地址和端口元组联系TURN服务器，则解析必须停止并出现错误。
4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port, and transport tuples via the Straightforward Naming Authority Pointer (S-NAPTR) algorithm defined in [RFC3958] by using <host> as the initial target domain name and "RELAY" as the application service tag. The filtered list of TURN transports supported by the application are converted in application protocol tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP, and "turn.tls" if the TURN transport is TLS. The order to try the application protocol tags is provided by the ranking of the first set of NAPTR records. If multiple application protocol tags have the same ranking, the preferred order set by the application is used. If the first NAPTR query fails, the processing continues in step 5. If the TURN client cannot contact a TURN server with any of the IP address, port, and transport tuples returned by the S-NAPTR algorithm, then the resolution MUST stop with an error.
4. 如果<host>是域名且未定义<port>和<transport>，则<host>将通过[RFC3958]中定义的直接命名机构指针（S-NAPTR）算法转换为IP地址、端口和传输元组的有序列表，使用<host>作为初始目标域名，“中继”作为应用程序服务标签。如果TURN传输为udp，则使用“TURN.udp”，如果TURN传输为tcp，则使用“TURN.tcp”，如果TURN传输为tls，则使用“TURN.tls”，在应用程序协议标记中转换应用程序支持的TURN传输的筛选列表。尝试应用程序协议标记的顺序由第一组NAPTR记录的排序提供。如果多个应用程序协议标记具有相同的排名，则使用应用程序设置的首选顺序。如果第一个NAPTR查询失败，则在步骤5中继续处理。如果TURN客户端无法使用S-NAPTR算法返回的任何IP地址、端口和传输元组联系TURN服务器，则解析必须停止并出现错误。
5. If the first NAPTR query in the previous step does not return any result, then the SRV algorithm defined in [RFC2782] is used to generate a list of IP address and port tuples. The SRV algorithm is applied by using each transport in the filtered list of TURN transports supported by the application for the Protocol (Proto), <host> for the Name, "turn" for the Service if <secure> is false, or "turns" for the Service if <secure> is true. The same transport that was used to generate a list of tuples is used with each of these tuples for contacting the TURN server. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case, the default port declared in [RFC5766] for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true, MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm with the transports from the filtered list, then the resolution MUST stop with an error.
5. 如果上一步中的第一个NAPTR查询未返回任何结果，则使用[RFC2782]中定义的SRV算法生成IP地址和端口元组列表。SRV算法是通过使用协议（Proto）应用程序支持的TURN传输的过滤列表中的每个传输来应用的，<host>作为名称，“TURN”作为服务（如果<secure>为false），或“turns”作为服务（如果<secure>为true）。用于生成元组列表的传输与用于联系TURN服务器的每个元组使用的传输相同。如果SRV查询返回错误或没有SRV RR，SRV算法建议执行A查询；在这种情况下，[RFC5766]中为“turn”SRV服务名称声明的默认端口（如果<secure>为false）或“turns”SRV服务名称（如果<secure>为true）必须用于联系turn服务器。同样在这种情况下，本规范通过推荐A和AAAA查询来修改SRV算法。如果TURN客户端无法通过SRV算法返回的IP地址和端口元组中的任何一个与TURN服务器联系，以及来自筛选列表的传输，则解析必须以错误停止。
With the DNS RRs in Figure 1 and an ordered TURN transport list of {TLS, TCP, UDP}, the resolution algorithm will convert the parameters (<secure>=false, <host>="example.net", <port>=empty, <transport>=empty) to the list of IP address, port, and protocol tuples in Table 2.
使用图1中的DNS RRs和{TLS，TCP，UDP}的顺序转换传输列表，解析算法将参数（<secure>=false，<host>=“example.net”，<port>=empty，<transport>=empty）转换为表2中的IP地址、端口和协议元组列表。
example.net. IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.
例如.net。在NAPTR 100 10“中继中：turn.udp”数据报.example.net。在NAPTR 200 10“中继：turn.tcp:turn.tls”stream.example.net中。
datagram.example.net. IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
datagram.example.net。在NAPTR 100 10 S中继中：turn.udp”“\u turn.\u udp.example.net。
stream.example.net. IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net.
stream.example.net。在NAPTR 100 10 S中继中：turn.tcp”“\u turn.\u tcp.example.net。在NAPTR 200 10中，继电器：turn.tls“”A.example.net。
_turn._udp.example.net. IN SRV 0 0 3478 a.example.net.
_turn._udp.example.net。在SRV 0 3478 a.example.net中。
_turn._tcp.example.net. IN SRV 0 0 5000 a.example.net.
_turn.\u tcp.example.net。在SRV 0 0 5000 a.example.net中。
a.example.net. IN A 192.0.2.1
a、 例如.net。在192.0.2.1中
Figure 1
图1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
| 2 | TLS | 192.0.2.1 | 5349 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
| 2 | TLS | 192.0.2.1 | 5349 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
Table 2
表2
In the example in Figure 2, a VoIP provider (example.com) is using the TURN servers managed by the administrators of the example.net domain (defined in Figure 1). The resolution algorithm using the ordered TURN transport list of {TLS, TCP, UDP} would convert the same parameters as in the previous example but with the <host> parameter equal to "example.com" to the list of IP address, port, and protocol tuples in Table 2.
在图2中的示例中，VoIP提供商（example.com）正在使用由example.net域（图1中定义）的管理员管理的TURN服务器。使用{TLS，TCP，UDP}的有序TURN传输列表的解析算法将转换与前一示例中相同的参数，但<host>参数等于“example.com”，转换为表2中的IP地址、端口和协议元组列表。
example.com. IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net.
example.com。在NAPTR 100 10“中继：turn.udp:turn.tcp:turn.tls”example.net中。
Figure 2
图2
In deployments where it is not possible to guarantee that all TURN clients will support the resolution mechanism described in this document, the DNS configuration should be done in a way that works with both this resolution mechanism and the mechanism described in [RFC5766]. The DNS RRs in Figure 3 can be used in conjunction with the DNS RRs in Figures 1 and 2 for this purpose.
在无法保证所有TURN客户端都支持本文档中描述的解析机制的部署中，DNS配置应以与此解析机制和[RFC5766]中描述的机制一起工作的方式进行。为此，图3中的DNS RRs可与图1和2中的DNS RRs结合使用。
_turn._udp.example.com. IN SRV 0 0 3478 a.example.net.
_转身。_udp.example.com。在SRV 0 3478 a.example.net中。
_turn._tcp.example.com. IN SRV 0 0 5000 a.example.net.
_转身。_tcp.example.com。在SRV 0 0 5000 a.example.net中。
_turns._tcp.example.com. IN SRV 0 0 5349 a.example.net.
_转身。_tcp.example.com。在SRV05349a.example.net中。
Figure 3
图3
Security considerations for TURN are discussed in [RFC5766].
[RFC5766]中讨论了TURN的安全注意事项。
The application service tag and application protocol tags defined in this document do not introduce any specific security issues beyond the security considerations discussed in [RFC3958]. [RFC3958] requests that an S-NAPTR application define some form of end-to-end authentication to ensure that the correct destination has been reached. This is achieved by the Long-Term Credential Mechanism defined in [RFC5389], which is mandatory for [RFC5766].
本文档中定义的应用程序服务标签和应用程序协议标签不会引入[RFC3958]中讨论的安全注意事项以外的任何特定安全问题。[RFC3958]请求S-NAPTR应用程序定义某种形式的端到端身份验证，以确保到达正确的目的地。这是通过[RFC5389]中定义的长期凭证机制实现的，这是[RFC5766]所必需的。
Additionally, the usage of TLS [RFC5246] has the capability to address the requirement. In this case, the client MUST verify the identity of the server by following the identification procedure in Section 7.2.2 of [RFC5389] and by using the value of the <host> parameter as the identity of the server to be verified.
此外，TLS[RFC5246]的使用能够满足要求。在这种情况下，客户机必须按照[RFC5389]第7.2.2节中的识别程序，并使用<host>参数的值作为待验证服务器的标识来验证服务器的标识。
An implication of this is that the server's certificate could need to be changed when SRV or NAPTR records are added. For example, a client using just A/AAAA records, and configured with "turnserver.example.net", expects to find the name "turnserver.example.net" in the certificate. If a second client uses SRV records and is configured with <host> parameter "example.com", it expects to find "example.com" in the certificate, even if the SRV record at _turns._tcp.example.com points to turnserver.example.net.
这意味着在添加SRV或NAPTR记录时，可能需要更改服务器的证书。例如，仅使用a/AAAA记录并配置为“turnserver.example.net”的客户端希望在证书中找到名称“turnserver.example.net”。如果第二个客户端使用SRV记录并配置了<host>参数“example.com”，则它希望在证书中找到“example.com”，即使位于\u的SRV记录指向turnserver.example.net。
This section contains the registration information for one S-NAPTR application service tag and three S-NAPTR application protocol tags (in accordance with [RFC3958]).
本节包含一个S-NAPTR应用服务标签和三个S-NAPTR应用协议标签的注册信息（根据[RFC3958]）。
Application Protocol Tag: RELAY
应用协议标签：中继
Intended usage: See Section 3.
预期用途：见第3节。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 5.
安全注意事项：见第5节。
Relevant publications: RFC 5928
相关出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
作者/变更控制员：IESG
Application Protocol Tag: turn.udp
应用程序协议标记：turn.udp
Intended usage: See Section 3.
预期用途：见第3节。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 5.
安全注意事项：见第5节。
Relevant publications: RFC 5928
相关出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
作者/变更控制员：IESG
Application Protocol Tag: turn.tcp
应用程序协议标记：turn.tcp
Intended usage: See Section 3.
预期用途：见第3节。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 5.
安全注意事项：见第5节。
Relevant publications: RFC 5928
相关出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
作者/变更控制员：IESG
Application Protocol Tag: turn.tls
应用程序协议标记：turn.tls
Intended usage: See Section 3.
预期用途：见第3节。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 5.
安全注意事项：见第5节。
Relevant publications: RFC 5928
相关出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
作者/变更控制员：IESG
Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer Dawkins, Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for their comments, suggestions, and questions that helped to improve this document.
感谢Cullen Jennings、Alexey Melnikov、Scott Bradner、Spencer Dawkins、Pasi Eronen、Margaret Wasserman、Magnus Westerlund、Juergen Schoenwaeld、Sean Turner、Ted Hardie、Dave Thaler、Alfred E.Heggestad、Eilon Yardeni、Dan Wing、Alfred Hones和Jim Kleck的评论、建议和问题，这些都有助于改进本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[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, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[TURN-URI] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Work in Progress, January 2010.
[TURN-URI]Petit Huguenin，M.“围绕NAT（TURN）统一资源标识符使用中继进行遍历”，正在进行的工作，2010年1月。
[REF-IMPL] Petit-Huguenin, M., "Reference Implementation of TURN resolver and TURN URI parser", January 2010, <http:// debian.implementers.org/stable/source/turnuri.tar.gz>.
[REF-IMPL]Petit Huguenin，M.，“TURN解析器和TURN URI解析器的参考实现”，2010年1月，<http://debian.implementers.org/stable/source/turnuri.tar.gz>。
Author's Address
作者地址
Marc Petit-Huguenin Unaffiliated
Marc Petit Huguenin非附属公司
EMail: petithug@acm.org
EMail: petithug@acm.org