Internet Engineering Task Force (IETF) S. Nandakumar
Request for Comments: 7064 G. Salgueiro
Category: Standards Track P. Jones
ISSN: 2070-1721 Cisco Systems
M. Petit-Huguenin
Impedance Mismatch
November 2013
Internet Engineering Task Force (IETF) S. Nandakumar
Request for Comments: 7064 G. Salgueiro
Category: Standards Track P. Jones
ISSN: 2070-1721 Cisco Systems
M. Petit-Huguenin
Impedance Mismatch
November 2013
URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol
NAT（STUN）协议会话遍历实用程序的URI方案
Abstract
摘要
This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.
本文档为NAT（STUN）协议的会话遍历实用程序指定了统一资源标识符（URI）方案的语法和语义。
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/rfc7064.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7064.
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. Definition of the "stun" or "stuns" URI . . . . . . . . . . . 3
3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 3
3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. "stun" URI Registration . . . . . . . . . . . . . . . . . 5
5.2. "stuns" 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. Definition of the "stun" or "stuns" URI . . . . . . . . . . . 3
3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 3
3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. "stun" URI Registration . . . . . . . . . . . . . . . . . 5
5.2. "stuns" 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 Session Traversal Utilities for NAT (STUN) protocol.
本文档为NAT（STUN）协议的会话遍历实用程序指定了统一资源标识符（URI）方案的语法和语义。
STUN is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT, to perform connectivity checks between two endpoints, and as a keepalive protocol to maintain NAT bindings. RFC 5389 [RFC5389] defines the specifics of the STUN protocol.
STUN是一种协议，在处理网络地址转换器（NAT）遍历时用作其他协议的工具。端点可以使用它来确定NAT分配给它的IP地址和端口，在两个端点之间执行连接检查，并作为保持NAT绑定的keepalive协议。RFC 5389[RFC5389]定义了STUN协议的细节。
The "stun" and "stuns" URI schemes are used to designate a stand-alone STUN server or any Internet host performing the operations of a STUN server in the context of STUN usages (Section 14 of RFC 5389 [RFC5389]). 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 STUN server to carry out the STUN protocol. This implies that endpoints and/or applications must be provisioned with the appropriate configuration to identify the STUN server. Having an inconsistent syntax adds ambiguity and can result in non-interoperable solutions and implementation limitations. The "stun" and "stuns" URI schemes help alleviate most of these issues by providing a consistent way to describe, configure, and exchange the information identifying a STUN server.
“stun”和“stuns”URI方案用于指定独立stun服务器或在stun使用情况下执行stun服务器操作的任何互联网主机（RFC 5389[RFC5389]第14节）。随着WebRTC[WebRTC]等标准的出现，我们预计将有大量端点和web应用程序能够识别此类STUN服务器并与之通信，以执行STUN协议。这意味着必须为端点和/或应用程序提供适当的配置，以识别STUN服务器。语法不一致会增加歧义，并可能导致不可互操作的解决方案和实现限制。“stun”和“stuns”URI方案提供了一种一致的方式来描述、配置和交换标识stun服务器的信息，从而有助于缓解大多数问题。
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关键词。
"stun" and "stuns" URIs have the following formal ABNF syntax [RFC5234]:
“stun”和“stuns”URI具有以下正式ABNF语法[RFC5234]：
stunURI = scheme ":" host [ ":" port ]
scheme = "stun" / "stuns"
stunURI = scheme ":" host [ ":" port ]
scheme = "stun" / "stuns"
<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 "stun" and "stuns" URI
[RFC3986]中指定了<host>和<port>。虽然这两个ABNF产品在[RFC3986]中定义为通用层次URI的组件，但这并不意味着“stun”和“stuns”URI
schemes are hierarchical URIs. Developers MUST NOT use a generic hierarchical URI parser to parse a "stun" or "stuns" URI.
方案是分层URI。开发人员不得使用通用层次URI解析器来解析“stun”或“stuns”URI。
The "stun" and "stuns" URI schemes are used to designate a stand-alone STUN server or any Internet host performing the operations of a STUN server in the context of STUN usages (Section 14 of RFC 5389 [RFC5389]). The STUN protocol supports sending messages over UDP, TCP, or TLS-over-TCP. The "stuns" URI scheme MUST be used when STUN is run over TLS-over-TCP (or in the future DTLS-over-UDP), and the "stun" scheme MUST be used otherwise.
“stun”和“stuns”URI方案用于指定独立stun服务器或在stun使用情况下执行stun服务器操作的任何互联网主机（RFC 5389[RFC5389]第14节）。STUN协议支持通过UDP、TCP或TLS通过TCP发送消息。当通过TCP通过TLS（或将来通过UDP通过DTLS）运行STUN时，必须使用“STUN”URI方案，否则必须使用“STUN”方案。
The required <host> part of the "stun" URI denotes the STUN server host.
“stun”URI所需的<host>部分表示stun服务器主机。
For the optional DNS discovery procedure mentioned in Section 9 of RFC 5389, the "stun" URI scheme implies UDP as the transport protocol for SRV lookup, and the "stuns" URI scheme indicates TCP as the transport protocol.
对于RFC 5389第9节中提到的可选DNS发现过程，“stun”URI方案暗示UDP作为SRV查找的传输协议，“stun”URI方案表示TCP作为传输协议。
As specified in [RFC5389], the <port> part, if present, denotes the port on which the STUN server is awaiting connection requests. If it is absent, the default port is 3478 for both UDP and TCP. The default port for STUN over TLS is 5349 as per Section 9 of [RFC5389].
如[RFC5389]中所述，<port>部分（如果存在）表示STUN服务器正在等待连接请求的端口。如果没有，UDP和TCP的默认端口都是3478。根据[RFC5389]第9节，TLS上的STUN默认端口为5349。
The "stun" and "stuns" URI schemes do not introduce any specific security issues beyond the security considerations discussed in [RFC3986]. These URI schemes are intended for use in specific environments that involve NAT traversal. Users of the scheme need to carefully consider the security properties of the context in which they are using them.
除了[RFC3986]中讨论的安全注意事项外，“stun”和“stuns”URI方案不会引入任何特定的安全问题。这些URI方案旨在用于涉及NAT遍历的特定环境中。该方案的用户需要仔细考虑使用它们的上下文的安全属性。
Although a "stun" or "stuns" URI does not itself include the username or password that will be used to authenticate the STUN 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 "stuns" 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 "stuns" URI. For this reason, a STUN client MUST ensure that the username, password, "stuns" URI, and any other security-relevant parameters are received with equivalent security before using the "stuns" URI. Receiving those parameters over another TLS session can provide the appropriate level of security if both TLS sessions are similarly parameterized, e.g., with commensurate strength ciphersuites.
尽管“stun”或“stuns”URI本身不包括用于验证stun客户端的用户名或密码，但在某些环境中，如WebRTC，用户名和密码几乎肯定会由外部代理在向该客户端发送“stuns”URI的同时远程提供。因此，在这种情况下，如果用户名和密码是以明文形式接收的，那么使用“stuns”URI几乎没有什么好处。因此，在使用“stuns”URI之前，STUN客户端必须确保用户名、密码、“stuns”URI和任何其他安全相关参数以同等的安全性收到。如果两个TLS会话都采用类似的参数化，例如使用相应强度的密码套件，则通过另一个TLS会话接收这些参数可以提供适当级别的安全性。
This section contains the registration information for the "stun" and "stuns" URI schemes (in accordance with [RFC4395]). Note that these URI schemes are intended for use in very specific NAT traversal environments and should not be used otherwise on the open Web or Internet.
本节包含“stun”和“stuns”URI方案的注册信息（根据[RFC4395]）。请注意，这些URI方案旨在用于非常特定的NAT遍历环境，不应在开放Web或Internet上使用。
URI scheme name: stun
URI方案名称：stun
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 "stun" URI scheme is intended to be used by applications with a need to identify a STUN server to be used for NAT traversal.
“stun”URI方案旨在供需要识别用于NAT遍历的stun服务器的应用程序使用。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 4
安全注意事项：见第4节
Contact: Suhas Nandakumar <snandaku@cisco.com>
Contact: Suhas Nandakumar <snandaku@cisco.com>
Author/Change controller: The IESG
作者/变更控制员：IESG
References: RFC 7064
参考文献：RFC 7064
URI scheme name: stuns
URI方案名称：stuns
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 "stuns" URI scheme is intended to be used by applications with a need to identify a STUN server to be used for NAT traversal over a secure connection.
“stuns”URI方案旨在供需要识别用于通过安全连接进行NAT遍历的STUN服务器的应用程序使用。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: See Section 4
安全注意事项：见第4节
Contact: Suhas Nandakumar <snandaku@cisco.com>
Contact: Suhas Nandakumar <snandaku@cisco.com>
Author/Change controller: The IESG
作者/变更控制员：IESG
References: RFC 7064
参考文献：RFC 7064
The authors would like to extend a very special thanks to Cullen Jennings for bringing to our attention to WebRTC's need for this document, as well as his detailed review and thoughtful comments on this document.
作者特别感谢Cullen Jennings提醒我们注意WebRTC对本文件的需求，以及他对本文件的详细审查和深思熟虑的评论。
This document has benefited from extensive discussion and review of many of the members of the RTCWEB and BEHAVE working groups. The authors would also like to acknowledge Ted Hardie, Bjoern Hoehrmann, Russ Housley, Subramanian Moonesamy, Hadriel Kaplan, Graham Klyne, Peter Saint-Andre, Ted Lemon, Barry Leiba, Pete Resnick, Spencer Dawkins, Stephen Farrell, and Harald Alvestrand for their invaluable input, reviews, feedback comments, and suggestions that helped to improve this document.
本文件得益于RTCWEB和BEHAVE工作组许多成员的广泛讨论和审查。作者还想感谢特德·哈迪、比约恩·霍尔曼、罗斯·霍斯利、苏布拉曼尼亚·穆内萨米、哈德里尔·卡普兰、格雷厄姆·克莱恩、彼得·圣安德烈、特德·莱蒙、巴里·莱巴、皮特·雷斯尼克、斯宾塞·道金斯、斯蒂芬·法雷尔和哈拉尔德·阿尔维斯特兰的宝贵投入、评论和反馈意见，以及有助于改进本文件的建议。
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
作者还要感谢Dan Wing在指导本文件方面提供的帮助。我们还要感谢Gonzalo Camarillo，实时应用程序和
Infrastructure Area Director, for sponsoring this document as well as his careful reviews.
基础设施领域总监，感谢他赞助本文件及其仔细审查。
[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月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[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月。
[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月。
[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 examples for the "stun" and "stuns" URI schemes. For all these examples, the <host> component is populated with "example.org".
表1显示了“stun”和“stuns”URI方案的示例。对于所有这些示例，<host>组件都填充了“example.org”。
+-----------------------+
| URI |
+-----------------------+
| stun:example.org |
| stuns:example.org |
| stun:example.org:8000 |
+-----------------------+
+-----------------------+
| URI |
+-----------------------+
| stun:example.org |
| stuns:example.org |
| stun:example.org:8000 |
+-----------------------+
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 need for ";proto=" for the STUN URI cannot be sufficiently explained, and supporting it would render an incomplete specification. This would also result in lost symmetry between the TURN and STUN URIs.
o 一个反复出现的注释是停止在URI方案上使用后缀“s”，并将安全选项移动到一个参数（例如，“proto=tls”）。我们决定反对这个想法，因为无法充分解释stunuri对“proto=”的需要，支持它将导致规范不完整。这也会导致转弯和眩晕URI之间失去对称性。
o Following the advice of Section 2.2 of [RFC4395], and because the STUN URI does not describe a hierarchical structure, the STUN URIs are opaque.
o 按照[RFC4395]第2.2节的建议，由于STUN URI没有描述层次结构，因此STUN URI是不透明的。
Authors' Addresses
作者地址
Suhas Nandakumar Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道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 USA
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com
Paul E. Jones Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
Paul E.Jones思科系统7025 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: paulej@packetizer.com
EMail: paulej@packetizer.com
Marc Petit-Huguenin Impedance Mismatch
Marc Petit Huguenin阻抗失配
EMail: petithug@acm.org
EMail: petithug@acm.org