Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 7065 Impedance Mismatch
Category: Standards Track S. Nandakumar
ISSN: 2070-1721 G. Salgueiro
P. Jones
Cisco Systems
November 2013
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 7065 Impedance Mismatch
Category: Standards Track S. Nandakumar
ISSN: 2070-1721 G. Salgueiro
P. Jones
Cisco Systems
November 2013
Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers
使用NAT（TURN）统一资源标识符周围的中继进行遍历
Abstract
摘要
This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).
本文档指定了统一资源标识符（URI）方案的语法，用于使用NAT（TURN）协议周围的中继进行遍历。它定义了两个URI方案来提供回合解析机制（RFC 5928）。
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/rfc7065.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7065.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Definitions of the "turn" and "turns" URI . . . . . . . . . . 4
3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 4
3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. "turn" URI Registration . . . . . . . . . . . . . . . . . 5
5.2. "turns" URI Registration . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Design Notes . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions of the "turn" and "turns" URI . . . . . . . . . . 4
3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 4
3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. "turn" URI Registration . . . . . . . . . . . . . . . . . 5
5.2. "turns" URI Registration . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Design Notes . . . . . . . . . . . . . . . . . . . . 8
This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Traversal Using Relays around NAT (TURN) protocol.
本文档指定了统一资源标识符（URI）方案的语法和语义，用于使用NAT（TURN）协议周围的中继进行遍历。
The TURN protocol is a specification allowing hosts behind NAT to control the operation of a relay server. The relay server allows hosts to exchange packets with its peers. The peers themselves may also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the TURN protocol.
TURN协议是一种规范，允许NAT后面的主机控制中继服务器的操作。中继服务器允许主机与其对等方交换数据包。同龄人本身也可能支持NAT。RFC 5766[RFC5766]定义了TURN协议的细节。
The "turn" and "turns" URI schemes are used to designate a TURN server (also known as a relay) on Internet hosts accessible using the TURN protocol. With the advent of standards such as WebRTC [WEBRTC], we anticipate a plethora of endpoints and web applications to be able to identify and communicate with such a TURN server to carry out the TURN protocol. This implies that endpoints and/or applications must be provisioned with the appropriate configuration to identify the TURN server. Having an inconsistent syntax adds ambiguity and can result in non-interoperable solutions and implementation limitations. The "turn" and "turns" URI schemes help alleviate most of these issues by providing a consistent way to describe, configure, and exchange the information identifying a TURN server.
“turn”和“turns”URI方案用于在可使用turn协议访问的Internet主机上指定turn服务器（也称为中继）。随着WebRTC[WebRTC]等标准的出现，我们预计将有大量端点和web应用程序能够识别此类TURN服务器并与之通信，以执行TURN协议。这意味着必须为端点和/或应用程序提供适当的配置，以标识TURN服务器。语法不一致会增加歧义，并可能导致不可互操作的解决方案和实现限制。“turn”和“turns”URI方案通过提供一种一致的方式来描述、配置和交换标识turn服务器的信息，帮助缓解了大多数这些问题。
[RFC5928] defines a resolution mechanism to convert a secure flag, a host name or IP address, a potentially empty port, and a potentially empty transport to a list of IP address, port, and TURN transport tuples.
[RFC5928]定义了一种解析机制，用于将安全标志、主机名或IP地址、可能为空的端口和可能为空的传输转换为IP地址、端口和TURN传输元组列表。
To simplify the provisioning of TURN clients, this document defines the "turn" and "turns" URI schemes that can carry the four components needed for the resolution mechanism.
为了简化TURN客户端的配置，本文档定义了“TURN”和“turns”URI方案，它们可以承载解析机制所需的四个组件。
The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as RFC 2119 key words.
当本文件中的关键词“必须”、“不得”、“必需”、“可能”和“可选”出现在所有大写字母中时，应按照[RFC2119]中所述进行解释。当这些词不在所有大写字母中时（如“应该”或“应该”），它们具有其通常的英语含义，并且不能解释为RFC 2119关键词。
The "turn" and "turns" URIs have the following formal ABNF syntax [RFC5234]:
“turn”和“turns”URI具有以下形式ABNF语法[RFC5234]：
turnURI = scheme ":" host [ ":" port ]
[ "?transport=" transport ]
scheme = "turn" / "turns"
transport = "udp" / "tcp" / transport-ext
transport-ext = 1*unreserved
turnURI = scheme ":" host [ ":" port ]
[ "?transport=" transport ]
scheme = "turn" / "turns"
transport = "udp" / "tcp" / transport-ext
transport-ext = 1*unreserved
<host> and <port> are specified in [RFC3986]. While these two ABNF productions are defined in [RFC3986] as components of the generic hierarchical URI, this does not imply that the "turn" and "turns" schemes are hierarchical URIs. Developers MUST NOT use a generic hierarchical URI parser to parse a "turn" or "turns" URI.
[RFC3986]中指定了<host>和<port>。虽然[RFC3986]将这两个ABNF产品定义为通用层次URI的组件，但这并不意味着“turn”和“turns”方案是层次URI。开发人员不得使用通用层次URI解析器来解析“turn”或“turns”URI。
The <host>, <port>, and <transport> components are passed without modification to the [RFC5928] algorithm. <secure> is set to false if <scheme> is equal to "turn", and set to true if <scheme> is equal to "turns" and passed to the [RFC5928] algorithm with the other components.
<host>、<port>和<transport>组件在不修改[RFC5928]算法的情况下传递<如果<scheme>等于“turns”，则secure>设置为false；如果<scheme>等于“turns”，并与其他组件一起传递给[RFC5928]算法，则secure>设置为true。
The "turn" and "turns" URI schemes are used to designate a TURN server (also known as a relay) on Internet hosts accessible using the TURN protocol. The TURN protocol supports sending messages over UDP, TCP, or TLS-over-TCP. The "turns" URI scheme MUST be used when TURN is run over TLS-over-TCP (or, in the future, DTLS-over-UDP), and the "turn" scheme MUST be used otherwise.
“turn”和“turns”URI方案用于在可使用turn协议访问的Internet主机上指定turn服务器（也称为中继）。TURN协议支持通过UDP、TCP或TLS通过TCP发送消息。当通过TCP上的TLS（或者将来通过UDP上的DTLS）运行TURN时，必须使用“turns”URI方案，否则必须使用“TURN”方案。
The required <host> part of the "turn" URI denotes the TURN server host.
“turn”URI的必需<host>部分表示turn服务器主机。
As specified in [RFC5766] and [RFC5928], the <port> part, if present, denotes the port on which the TURN server is awaiting connection requests. If it is absent, the default port is 3478 for both UDP and TCP. The default port for TURN over TLS is 5349.
如[RFC5766]和[RFC5928]中所述，<port>部分（如果存在）表示转弯服务器正在等待连接请求的端口。如果没有，UDP和TCP的默认端口都是3478。移交TLS的默认端口为5349。
Security considerations for the resolution mechanism are discussed in Section 5 of [RFC5928]. Note that this section contains normative text defining authentication procedures to be followed by turn clients when TLS is used.
[RFC5928]第5节讨论了解决机制的安全注意事项。请注意，本节包含规范性文本，定义了使用TLS时turn客户端应遵循的身份验证过程。
The "turn" and "turns" URI schemes do not introduce any specific security issues beyond the security considerations discussed in [RFC3986].
“turn”和“turns”URI方案不会引入任何超出[RFC3986]中讨论的安全注意事项之外的特定安全问题。
Although a "turn" or "turns" URI does not itself include the username or password that will be used to authenticate the TURN client, in certain environments, such as WebRTC, the username and password will almost certainly be provisioned remotely by an external agent at the same time as a "turns" URI is sent to that client. Thus, in such situations, if the username and password were received in the clear, there would be little or no benefit to using a "turns" URI. For this reason, a TURN client MUST ensure that the username, password, "turns" URI, and any other security-relevant parameters are received with equivalent security before using the "turns" URI. Receiving those parameters over another TLS session can provide the appropriate level of security, if both TLS sessions are similarly parameterised, e.g., with commensurate strength ciphersuites.
尽管“turn”或“turns”URI本身不包括将用于验证turn客户端的用户名或密码，但在某些环境中，如WebRTC，用户名和密码几乎肯定会在“turns”URI发送到该客户端的同时由外部代理远程提供。因此，在这种情况下，如果用户名和密码是以明文形式接收的，那么使用“turns”URI几乎没有什么好处。因此，TURN客户端必须确保在使用“turns”URI之前，以同等的安全性接收用户名、密码、“turns”URI和任何其他安全相关参数。如果两个TLS会话的参数化程度相似（例如，使用同等强度的密码套件），则通过另一个TLS会话接收这些参数可以提供适当的安全级别。
This section contains the registration information for the "turn" and "turns" URI Schemes (in accordance with [RFC4395]).
本节包含“turn”和“turns”URI方案的注册信息（根据[RFC4395]）。
URI scheme name: turn
URI方案名称：turn
Status: permanent
地位：永久
URI scheme syntax: See Section 3.1.
URI方案语法：参见第3.1节。
URI scheme semantics: See Section 3.2.
URI方案语义：参见第3.2节。
Encoding considerations: There are no encoding considerations beyond those in [RFC3986].
编码注意事项：除了[RFC3986]中的编码注意事项外，没有其他编码注意事项。
Applications/protocols that use this URI scheme name:
使用此URI方案名称的应用程序/协议：
The "turn" URI scheme is intended to be used by applications with a need to identify a TURN server to be used for NAT traversal.
“turn”URI方案旨在由需要识别用于NAT遍历的turn服务器的应用程序使用。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 4.
安全注意事项：见第4节。
Contact: Marc Petit-Huguenin <petithug@acm.org>
Contact: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
作者/变更控制员：IESG
References: RFC 7065
参考文献：RFC 7065
URI scheme name: turns
URI方案名称：turns
Status: permanent
地位：永久
URI scheme syntax: See Section 3.1.
URI方案语法：参见第3.1节。
URI scheme semantics: See Section 3.2.
URI方案语义：参见第3.2节。
Encoding considerations: There are no encoding considerations beyond those in [RFC3986].
编码注意事项：除了[RFC3986]中的编码注意事项外，没有其他编码注意事项。
Applications/protocols that use this URI scheme name:
使用此URI方案名称的应用程序/协议：
The "turns" URI scheme is intended to be used by applications with a need to identify a TURN server to be used for NAT traversal over a secure connection.
“turns”URI方案旨在由需要识别用于通过安全连接进行NAT遍历的TURN服务器的应用程序使用。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 4.
安全注意事项：见第4节。
Contact: Marc Petit-Huguenin <petithug@acm.org>
Contact: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
作者/变更控制员：IESG
References: RFC 7065
参考文献：RFC 7065
Thanks to 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 the comments, suggestions, and questions that helped improve "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers" by M. Petit-Huguenin (October 2011).
感谢Margaret Wasserman、Magnus Westerlund、Juergen Schoenwaeld、Sean Turner、Ted Hardie、Dave Thaler、Alfred E.Heggestad、Eilon Yardeni、Dan Wing、Alfred Hoenes和Jim Kleck提出的意见、建议和问题，这些意见、建议和问题有助于改进M.Petit Hugunin提出的“使用NAT（TURN）统一资源标识符周围的中继进行穿越”（2011年10月）。
Many thanks to Cullen Jennings for his detailed review and thoughtful comments on "URI Scheme for Traversal Using Relays around NAT (TURN) Protocol" by S. Nandakumar, et al. (October 2011).
非常感谢Cullen Jennings对S.Nandakumar等人（2011年10月）关于“使用NAT（TURN）协议中继进行遍历的URI方案”的详细审查和深思熟虑的评论。
Thanks to Bjoern Hoehrmann, Dan Wing, Russ Housley, S. Moonesamy, Graham Klyne, Harald Alvestrand, Hadriel Kaplan, Tina Tsou, Spencer Dawkins, Ted Lemon, Barry Leiba, Pete Resnick, and Stephen Farrell for the comments, suggestions, and questions that helped improve this document.
感谢Bjoern Hoehrmann、Dan Wing、Russ Housley、S.Moonesamy、Graham Klyne、Harald Alvestrand、Hadriel Kaplan、Tina Tsou、Spencer Dawkins、Ted Lemon、Barry Leiba、Pete Resnick和Stephen Farrell的评论、建议和问题，帮助改进了本文件。
The authors would also like to express their gratitude to Dan Wing for his assistance in shepherding this document. We also want to thank Gonzalo Camarillo, the Real-time Applications and Infrastructure Area Director, for sponsoring this document as well as his careful reviews.
作者还要感谢Dan Wing在指导本文件方面提供的帮助。我们还要感谢实时应用和基础设施领域总监Gonzalo Camarillo，他赞助了本文档，并进行了认真的审查。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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月。
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, August 2010.
[RFC5928]Petit Huguenin，M.“使用NAT（转弯）解析机制周围的中继进行遍历”，RFC 59282010年8月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[WEBRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20120821, August 2012, <http://www.w3.org/TR/2012/WD-webrtc-20120821>.
[WEBRTC]Bergkvist，A.，Burnett，D.，Jennings，C.，和A.Narayanan，“WEBRTC 1.0：浏览器之间的实时通信”，万维网联盟WD WD-WEBRTC-2012082112012年8月<http://www.w3.org/TR/2012/WD-webrtc-20120821>.
Table 1 shows how the <secure>, <port>, and <transport> components are populated from various URIs. For all these examples, the <host> component is populated with "example.org".
表1显示了如何从各种URI填充<secure>、<port>和<transport>组件。对于所有这些示例，<host>组件都填充了“example.org”。
+---------------------------------+----------+--------+-------------+
| URI | <secure> | <port> | <transport> |
+---------------------------------+----------+--------+-------------+
| turn:example.org | false | | |
| turns:example.org | true | | |
| turn:example.org:8000 | false | 8000 | |
| turn:example.org?transport=udp | false | | UDP |
| turn:example.org?transport=tcp | false | | TCP |
| turns:example.org?transport=tcp | true | | TLS |
+---------------------------------+----------+--------+-------------+
+---------------------------------+----------+--------+-------------+
| URI | <secure> | <port> | <transport> |
+---------------------------------+----------+--------+-------------+
| turn:example.org | false | | |
| turns:example.org | true | | |
| turn:example.org:8000 | false | 8000 | |
| turn:example.org?transport=udp | false | | UDP |
| turn:example.org?transport=tcp | false | | TCP |
| turns:example.org?transport=tcp | true | | TLS |
+---------------------------------+----------+--------+-------------+
Table 1
表1
o One recurring comment was to stop using the suffix "s" on the URI scheme, and to move the secure option to a parameter (e.g. ";proto=tls"). We decided against this idea because the STUN URI does not have a ";proto=" parameter and we would have lost the symmetry between the TURN and STUN URIs.
o 一个反复出现的注释是停止在URI方案上使用后缀“s”，并将安全选项移动到一个参数（例如，“proto=tls”）。我们决定反对这个想法，因为眩晕URI没有“proto=”参数，我们会失去回合和眩晕URI之间的对称性。
o Following the advice of Section 2.2 of RFC 4395, and because the TURN URI does not describe a hierarchical structure, the TURN URIs are opaque URIs.
o 按照RFC 4395第2.2节的建议，由于TURN URI没有描述层次结构，所以TURN URI是不透明的URI。
o <password> is not used in the URIs because it is deprecated [RFC3986]. <username> and <auth> are not used in the URIs because they do not guide the resolution mechanism.
o <password>未在URI中使用，因为它已被弃用[RFC3986]<用户名>和<auth>未在URI中使用，因为它们不指导解析机制。
o As discussed at IETF 72 in Dublin, there are no generic parameters in the URI to prevent compatibility issues.
o 正如都柏林IETF72所讨论的，URI中没有防止兼容性问题的通用参数。
Authors' Addresses
作者地址
Marc Petit-Huguenin Impedance Mismatch
Marc Petit Huguenin阻抗失配
EMail: petithug@acm.org
EMail: petithug@acm.org
Suhas Nandakumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞西塔斯曼大道170号Suhas Nandakumar Cisco Systems，邮编95134
EMail: snandaku@cisco.com
EMail: snandaku@cisco.com
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
Gonzalo Salgueiro思科系统7200-12美国北卡罗来纳州Kit Creek Road研究三角公园，邮编27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com
Paul E. Jones Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 US
Paul E.Jones Cisco Systems 7025 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: paulej@packetizer.com
EMail: paulej@packetizer.com