Network Working Group J. Rosenberg
Request for Comments: 5389 Cisco
Obsoletes: 3489 R. Mahy
Category: Standards Track P. Matthews
Unaffiliated
D. Wing
Cisco
October 2008
Network Working Group J. Rosenberg
Request for Comments: 5389 Cisco
Obsoletes: 3489 R. Mahy
Category: Standards Track P. Matthews
Unaffiliated
D. Wing
Cisco
October 2008
Session Traversal Utilities for NAT (STUN)
NAT的会话遍历实用程序（STUN）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
Session Traversal Utilities for NAT (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. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
NAT会话遍历实用程序（STUN）是一种协议，可作为其他协议处理网络地址转换器（NAT）遍历的工具。端点可以使用它来确定NAT分配给它的IP地址和端口。它还可以用于检查两个端点之间的连接，并作为保持活动的协议来维护NAT绑定。STUN与许多现有NAT一起工作，不需要它们有任何特殊行为。
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.
STUN本身不是NAT遍历解决方案。相反，它是在NAT遍历解决方案的上下文中使用的工具。这是对本规范先前版本（RFC 3489）的重要更改，该版本将STUN作为一个完整的解决方案。
This document obsoletes RFC 3489.
本文件淘汰RFC 3489。
Table of Contents
目录
1. Introduction ....................................................4
2. Evolution from RFC 3489 .........................................4
3. Overview of Operation ...........................................5
4. Terminology .....................................................8
5. Definitions .....................................................8
6. STUN Message Structure .........................................10
7. Base Protocol Procedures .......................................12
7.1. Forming a Request or an Indication ........................12
7.2. Sending the Request or Indication .........................13
1. Introduction ....................................................4
2. Evolution from RFC 3489 .........................................4
3. Overview of Operation ...........................................5
4. Terminology .....................................................8
5. Definitions .....................................................8
6. STUN Message Structure .........................................10
7. Base Protocol Procedures .......................................12
7.1. Forming a Request or an Indication ........................12
7.2. Sending the Request or Indication .........................13
7.2.1. Sending over UDP ...................................13
7.2.2. Sending over TCP or TLS-over-TCP ...................14
7.3. Receiving a STUN Message ..................................16
7.3.1. Processing a Request ...............................17
7.3.1.1. Forming a Success or Error Response .......18
7.3.1.2. Sending the Success or Error Response .....19
7.3.2. Processing an Indication ...........................19
7.3.3. Processing a Success Response ......................19
7.3.4. Processing an Error Response .......................20
8. FINGERPRINT Mechanism ..........................................20
9. DNS Discovery of a Server ......................................21
10. Authentication and Message-Integrity Mechanisms ...............22
10.1. Short-Term Credential Mechanism ..........................22
10.1.1. Forming a Request or Indication ...................23
10.1.2. Receiving a Request or Indication .................23
10.1.3. Receiving a Response ..............................24
10.2. Long-Term Credential Mechanism ...........................24
10.2.1. Forming a Request .................................25
10.2.1.1. First Request ............................25
10.2.1.2. Subsequent Requests ......................26
10.2.2. Receiving a Request ...............................26
10.2.3. Receiving a Response ..............................27
11. ALTERNATE-SERVER Mechanism ....................................28
12. Backwards Compatibility with RFC 3489 .........................28
12.1. Changes to Client Processing .............................29
12.2. Changes to Server Processing .............................29
13. Basic Server Behavior .........................................30
14. STUN Usages ...................................................30
15. STUN Attributes ...............................................31
15.1. MAPPED-ADDRESS ...........................................32
15.2. XOR-MAPPED-ADDRESS .......................................33
15.3. USERNAME .................................................34
15.4. MESSAGE-INTEGRITY ........................................34
15.5. FINGERPRINT ..............................................36
15.6. ERROR-CODE ...............................................36
15.7. REALM ....................................................38
15.8. NONCE ....................................................38
15.9. UNKNOWN-ATTRIBUTES .......................................38
15.10. SOFTWARE ................................................39
15.11. ALTERNATE-SERVER ........................................39
16. Security Considerations .......................................39
16.1. Attacks against the Protocol .............................39
16.1.1. Outside Attacks ...................................39
16.1.2. Inside Attacks ....................................40
16.2. Attacks Affecting the Usage ..............................40
16.2.1. Attack I: Distributed DoS (DDoS) against a
Target ............................................41
16.2.2. Attack II: Silencing a Client .....................41
7.2.1. Sending over UDP ...................................13
7.2.2. Sending over TCP or TLS-over-TCP ...................14
7.3. Receiving a STUN Message ..................................16
7.3.1. Processing a Request ...............................17
7.3.1.1. Forming a Success or Error Response .......18
7.3.1.2. Sending the Success or Error Response .....19
7.3.2. Processing an Indication ...........................19
7.3.3. Processing a Success Response ......................19
7.3.4. Processing an Error Response .......................20
8. FINGERPRINT Mechanism ..........................................20
9. DNS Discovery of a Server ......................................21
10. Authentication and Message-Integrity Mechanisms ...............22
10.1. Short-Term Credential Mechanism ..........................22
10.1.1. Forming a Request or Indication ...................23
10.1.2. Receiving a Request or Indication .................23
10.1.3. Receiving a Response ..............................24
10.2. Long-Term Credential Mechanism ...........................24
10.2.1. Forming a Request .................................25
10.2.1.1. First Request ............................25
10.2.1.2. Subsequent Requests ......................26
10.2.2. Receiving a Request ...............................26
10.2.3. Receiving a Response ..............................27
11. ALTERNATE-SERVER Mechanism ....................................28
12. Backwards Compatibility with RFC 3489 .........................28
12.1. Changes to Client Processing .............................29
12.2. Changes to Server Processing .............................29
13. Basic Server Behavior .........................................30
14. STUN Usages ...................................................30
15. STUN Attributes ...............................................31
15.1. MAPPED-ADDRESS ...........................................32
15.2. XOR-MAPPED-ADDRESS .......................................33
15.3. USERNAME .................................................34
15.4. MESSAGE-INTEGRITY ........................................34
15.5. FINGERPRINT ..............................................36
15.6. ERROR-CODE ...............................................36
15.7. REALM ....................................................38
15.8. NONCE ....................................................38
15.9. UNKNOWN-ATTRIBUTES .......................................38
15.10. SOFTWARE ................................................39
15.11. ALTERNATE-SERVER ........................................39
16. Security Considerations .......................................39
16.1. Attacks against the Protocol .............................39
16.1.1. Outside Attacks ...................................39
16.1.2. Inside Attacks ....................................40
16.2. Attacks Affecting the Usage ..............................40
16.2.1. Attack I: Distributed DoS (DDoS) against a
Target ............................................41
16.2.2. Attack II: Silencing a Client .....................41
16.2.3. Attack III: Assuming the Identity of a Client .....42
16.2.4. Attack IV: Eavesdropping ..........................42
16.3. Hash Agility Plan ........................................42
17. IAB Considerations ............................................42
18. IANA Considerations ...........................................43
18.1. STUN Methods Registry ....................................43
18.2. STUN Attribute Registry ..................................43
18.3. STUN Error Code Registry .................................44
18.4. STUN UDP and TCP Port Numbers ............................45
19. Changes since RFC 3489 ........................................45
20. Contributors ..................................................47
21. Acknowledgements ..............................................47
22. References ....................................................47
22.1. Normative References .....................................47
22.2. Informative References ...................................48
Appendix A. C Snippet to Determine STUN Message Types .............50
16.2.3. Attack III: Assuming the Identity of a Client .....42
16.2.4. Attack IV: Eavesdropping ..........................42
16.3. Hash Agility Plan ........................................42
17. IAB Considerations ............................................42
18. IANA Considerations ...........................................43
18.1. STUN Methods Registry ....................................43
18.2. STUN Attribute Registry ..................................43
18.3. STUN Error Code Registry .................................44
18.4. STUN UDP and TCP Port Numbers ............................45
19. Changes since RFC 3489 ........................................45
20. Contributors ..................................................47
21. Acknowledgements ..............................................47
22. References ....................................................47
22.1. Normative References .....................................47
22.2. Informative References ...................................48
Appendix A. C Snippet to Determine STUN Message Types .............50
The protocol defined in this specification, Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive. With some extensions, the protocol can be used to do connectivity checks between two endpoints [MMUSIC-ICE], or to relay packets between two endpoints [BEHAVE-TURN].
本规范中定义的协议，NAT会话遍历实用程序，提供了处理NAT的工具。它为端点提供了一种方法来确定NAT分配的IP地址和端口，该NAT对应于其私有IP地址和端口。它还为端点提供了一种保持NAT绑定活动的方法。通过一些扩展，该协议可用于在两个端点之间进行连接检查[MMUSIC-ICE]，或在两个端点之间中继数据包[BEFORM-TURN]。
In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication.
根据其工具性质，本规范定义了一种可扩展的数据包格式，定义了多个传输协议上的操作，并提供了两种形式的身份验证。
STUN is intended to be used in context of one or more NAT traversal solutions. These solutions are known as STUN usages. Each usage describes how STUN is utilized to achieve the NAT traversal solution. Typically, a usage indicates when STUN messages get sent, which optional attributes to include, what server is used, and what authentication mechanism is to be used. Interactive Connectivity Establishment (ICE) [MMUSIC-ICE] is one usage of STUN. SIP Outbound [SIP-OUTBOUND] is another usage of STUN. In some cases, a usage will require extensions to STUN. A STUN extension can be in the form of new methods, attributes, or error response codes. More information on STUN usages can be found in Section 14.
STUN旨在用于一个或多个NAT穿越解决方案的上下文中。这些解决方案称为眩晕用法。每个用法都描述了如何利用STUN实现NAT遍历解决方案。通常，用法指示何时发送STUN消息、包括哪些可选属性、使用什么服务器以及使用什么身份验证机制。交互式连接建立（ICE）[MMUSIC-ICE]是STUN的一种用法。SIP Outbound[SIP-Outbound]是STUN的另一种用法。在某些情况下，一个用法需要对STUN进行扩展。STUN扩展可以采用新方法、属性或错误响应代码的形式。关于眩晕用法的更多信息，请参见第14节。
STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, determine its NAT type, discover its IP address and port on the public side of the outermost NAT, and then utilize that IP address and port within the body of protocols, such as the Session Initiation Protocol (SIP) [RFC3261]. However, experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution. The address and port learned through classic STUN are sometimes usable for communications with a peer, and sometimes not. Classic STUN provided no way to discover whether it would, in fact, work or not, and it provided no remedy in cases where it did not. Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
STUN最初在RFC 3489[RFC3489]中定义。该规范有时被称为“经典STUN”，它将自己描述为NAT遍历问题的完整解决方案。在该解决方案中，客户机将发现它是否在NAT后面，确定其NAT类型，在最外层NAT的公共侧发现其IP地址和端口，然后在协议体中利用该IP地址和端口，例如会话发起协议（SIP）[RFC3261]。然而，自RFC 3489发布以来的经验发现，经典STUN根本无法很好地作为可部署解决方案。通过经典STUN学习的地址和端口有时可用于与对等方的通信，有时则不可用。经典的晕眩并没有提供任何方法来发现它是否真的能起作用，而且在它不能起作用的情况下，它也并没有提供任何补救措施。此外，经典的STUN的NAT类型分类算法被发现是错误的，因为许多NAT不能完全适合那里定义的类型。
Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain topologies and constraints, and this was fundamentally not solvable through any cryptographic means. Though this problem remains with this specification, those attacks are now mitigated through the use of more complete solutions that make use of STUN.
Classic STUN还存在一个安全漏洞——攻击者可以在某些拓扑和约束条件下向客户端提供不正确的映射地址，这根本无法通过任何加密手段解决。尽管这个问题仍然存在于本规范中，但现在通过使用更完整的解决方案（利用STUN）减轻了这些攻击。
For these reasons, this specification obsoletes RFC 3489, and instead describes STUN as a tool that is utilized as part of a complete NAT traversal solution. ICE [MMUSIC-ICE] is a complete NAT traversal solution for protocols based on the offer/answer [RFC3264] methodology, such as SIP. SIP Outbound [SIP-OUTBOUND] is a complete solution for traversal of SIP signaling, and it uses STUN in a very different way. Though it is possible that a protocol may be able to use STUN by itself (classic STUN) as a traversal solution, such usage is not described here and is strongly discouraged for the reasons described above.
由于这些原因，本规范淘汰了RFC 3489，而是将STUN描述为作为完整NAT穿越解决方案一部分使用的工具。ICE[MMUSIC-ICE]是一个完整的NAT穿越解决方案，用于基于提供/应答[RFC3264]方法的协议，如SIP。SIP Outbound[SIP-Outbound]是一个完整的SIP信令遍历解决方案，它以一种非常不同的方式使用STUN。尽管协议可能能够单独使用STUN（经典STUN）作为遍历解决方案，但由于上述原因，这里不介绍这种用法，因此强烈建议不要使用。
The on-the-wire protocol described here is changed only slightly from classic STUN. The protocol now runs over TCP in addition to UDP. Extensibility was added to the protocol in a more structured way. A magic cookie mechanism for demultiplexing STUN with application protocols was added by stealing 32 bits from the 128-bit transaction ID defined in RFC 3489, allowing the change to be backwards compatible. Mapped addresses are encoded using a new exclusive-or format. There are other, more minor changes. See Section 19 for a more complete listing.
这里描述的在线协议与经典的STUN相比只有轻微的变化。该协议现在除了UDP之外还通过TCP运行。扩展性以更结构化的方式添加到协议中。通过从RFC 3489中定义的128位事务ID中窃取32位，添加了一种用于使用应用程序协议解复用STUN的神奇cookie机制，允许更改向后兼容。映射地址使用新的异或格式进行编码。还有其他更细微的变化。有关更完整的列表，请参见第19节。
Due to the change in scope, STUN has also been renamed from "Simple Traversal of UDP through NAT" to "Session Traversal Utilities for NAT". The acronym remains STUN, which is all anyone ever remembers anyway.
由于范围的变化，STUN也从“通过NAT简单遍历UDP”重命名为“NAT会话遍历实用程序”。这个首字母缩略词仍然是STUN，这是所有人都记得的。
This section is descriptive only.
本节仅作说明。
/-----\
// STUN \\
| Server |
\\ //
\-----/
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
Figure 1: One Possible STUN Configuration
图1：一种可能的眩晕配置
One possible STUN configuration is shown in Figure 1. In this configuration, there are two entities (called STUN agents) that implement the STUN protocol. The lower agent in the figure is the client, and is connected to private network 1. This network connects to private network 2 through NAT 1. Private network 2 connects to the public Internet through NAT 2. The upper agent in the figure is the server, and resides on the public Internet.
图1显示了一种可能的STUN配置。在此配置中，有两个实体（称为STUN代理）实现STUN协议。图中较低的代理是客户端，连接到专用网络1。该网络通过NAT 1连接到专用网络2。专用网络2通过NAT 2连接到公共互联网。图中的上层代理是服务器，驻留在公共Internet上。
STUN is a client-server protocol. It supports two types of transactions. One is a request/response transaction in which a client sends a request to a server, and the server returns a response. The second is an indication transaction in which either agent -- client or server -- sends an indication that generates no response. Both types of transactions include a transaction ID, which is a randomly selected 96-bit number. For request/response
STUN是一种客户机-服务器协议。它支持两种类型的事务。一种是请求/响应事务，其中客户端向服务器发送请求，服务器返回响应。第二种是指示事务，在该事务中，代理（客户机或服务器）发送的指示不生成响应。这两种类型的事务都包括一个事务ID，它是一个随机选择的96位数字。请求/答复
transactions, this transaction ID allows the client to associate the response with the request that generated it; for indications, the transaction ID serves as a debugging aid.
事务，此事务ID允许客户端将响应与生成响应的请求相关联；对于指示，事务ID用作调试辅助工具。
All STUN messages start with a fixed header that includes a method, a class, and the transaction ID. The method indicates which of the various requests or indications this is; this specification defines just one method, Binding, but other methods are expected to be defined in other documents. The class indicates whether this is a request, a success response, an error response, or an indication. Following the fixed header comes zero or more attributes, which are Type-Length-Value extensions that convey additional information for the specific message.
所有STUN消息都以一个固定的头开始，该头包括一个方法、一个类和事务ID。该方法指示这是各种请求或指示中的哪一个；本规范仅定义了一种方法，即绑定，但其他方法预计将在其他文档中定义。该类指示这是请求、成功响应、错误响应还是指示。固定头之后是零个或多个属性，这些属性是类型长度值扩展，用于传递特定消息的附加信息。
This document defines a single method called Binding. The Binding method can be used either in request/response transactions or in indication transactions. When used in request/response transactions, the Binding method can be used to determine the particular "binding" a NAT has allocated to a STUN client. When used in either request/ response or in indication transactions, the Binding method can also be used to keep these "bindings" alive.
本文档定义了一个名为Binding的方法。绑定方法可以在请求/响应事务或指示事务中使用。在请求/响应事务中使用时，绑定方法可用于确定NAT分配给STUN客户端的特定“绑定”。当在请求/响应或指示事务中使用时，绑定方法也可用于保持这些“绑定”处于活动状态。
In the Binding request/response transaction, a Binding request is sent from a STUN client to a STUN server. When the Binding request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server (in Figure 1, there were two such NATs). As the Binding request message passes through a NAT, the NAT will modify the source transport address (that is, the source IP address and the source port) of the packet. As a result, the source transport address of the request received by the server will be the public IP address and port created by the NAT closest to the server. This is called a reflexive transport address. The STUN server copies that source transport address into an XOR-MAPPED-ADDRESS attribute in the STUN Binding response and sends the Binding response back to the STUN client. As this packet passes back through a NAT, the NAT will modify the destination transport address in the IP header, but the transport address in the XOR-MAPPED-ADDRESS attribute within the body of the STUN response will remain untouched. In this way, the client can learn its reflexive transport address allocated by the outermost NAT with respect to the STUN server.
在绑定请求/响应事务中，绑定请求从STUN客户端发送到STUN服务器。当绑定请求到达STUN服务器时，它可能已经通过了STUN客户端和STUN服务器之间的一个或多个nat（在图1中，有两个这样的nat）。当绑定请求消息通过NAT时，NAT将修改数据包的源传输地址（即，源IP地址和源端口）。因此，服务器接收到的请求的源传输地址将是公共IP地址和最靠近服务器的NAT创建的端口。这称为自反传输地址。STUN服务器将该源传输地址复制到STUN绑定响应中的XOR映射地址属性中，并将绑定响应发送回STUN客户端。当该数据包通过NAT传回时，NAT将修改IP报头中的目标传输地址，但STUN响应主体内XOR-MAPPED-address属性中的传输地址将保持不变。通过这种方式，客户端可以了解最外层NAT相对于STUN服务器分配的自反传输地址。
In some usages, STUN must be multiplexed with other protocols (e.g., [MMUSIC-ICE], [SIP-OUTBOUND]). In these usages, there must be a way to inspect a packet and determine if it is a STUN packet or not. STUN provides three fields in the STUN header with fixed values that can be used for this purpose. If this is not sufficient, then STUN packets can also contain a FINGERPRINT value, which can further be used to distinguish the packets.
在某些用途中，STUN必须与其他协议（例如，[MMUSIC-ICE]、[SIP-OUTBOUND]）复用。在这些用法中，必须有一种方法来检查数据包并确定它是否是STUN数据包。STUN在STUN标题中提供了三个字段，其中包含可用于此目的的固定值。如果这还不够，那么STUN数据包还可以包含指纹值，指纹值还可以用于区分数据包。
STUN defines a set of optional procedures that a usage can decide to use, called mechanisms. These mechanisms include DNS discovery, a redirection technique to an alternate server, a fingerprint attribute for demultiplexing, and two authentication and message-integrity exchanges. The authentication mechanisms revolve around the use of a username, password, and message-integrity value. Two authentication mechanisms, the long-term credential mechanism and the short-term credential mechanism, are defined in this specification. Each usage specifies the mechanisms allowed with that usage.
STUN定义了一组用户可以决定使用的可选过程，称为机制。这些机制包括DNS发现、到备用服务器的重定向技术、用于解复用的指纹属性以及两个身份验证和消息完整性交换。身份验证机制围绕用户名、密码和消息完整性值的使用展开。本规范中定义了两种身份验证机制，长期凭证机制和短期凭证机制。每个用法指定了该用法允许的机制。
In the long-term credential mechanism, the client and server share a pre-provisioned username and password and perform a digest challenge/ response exchange inspired by (but differing in details) to the one defined for HTTP [RFC2617]. In the short-term credential mechanism, the client and the server exchange a username and password through some out-of-band method prior to the STUN exchange. For example, in the ICE usage [MMUSIC-ICE] the two endpoints use out-of-band signaling to exchange a username and password. These are used to integrity protect and authenticate the request and response. There is no challenge or nonce used.
在长期凭证机制中，客户端和服务器共享预先设置的用户名和密码，并执行摘要质询/响应交换，其灵感来自（但细节不同）为HTTP定义的摘要质询/响应交换[RFC2617]。在短期凭证机制中，客户机和服务器在STUN交换之前通过一些带外方法交换用户名和密码。例如，在ICE用法[MMUSIC-ICE]中，两个端点使用带外信令来交换用户名和密码。它们用于完整性保护和验证请求和响应。没有使用质询或临时命令。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant STUN implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的描述进行解释，并指出符合标准的STUN实施的要求级别。
STUN Agent: A STUN agent is an entity that implements the STUN protocol. The entity can be either a STUN client or a STUN server.
眩晕代理：眩晕代理是实现眩晕协议的实体。实体可以是STUN客户端或STUN服务器。
STUN Client: A STUN client is an entity that sends STUN requests and receives STUN responses. A STUN client can also send indications. In this specification, the terms STUN client and client are synonymous.
STUN客户端：STUN客户端是发送STUN请求并接收STUN响应的实体。STUN客户端也可以发送指示。在本规范中，术语STUN client和client是同义词。
STUN Server: A STUN server is an entity that receives STUN requests and sends STUN responses. A STUN server can also send indications. In this specification, the terms STUN server and server are synonymous.
STUN服务器：STUN服务器是接收STUN请求并发送STUN响应的实体。STUN服务器也可以发送指示。在本规范中，术语STUN server和server是同义词。
Transport Address: The combination of an IP address and port number (such as a UDP or TCP port number).
传输地址：IP地址和端口号（如UDP或TCP端口号）的组合。
Reflexive Transport Address: A transport address learned by a client that identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the mapped address allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) in STUN responses.
自反传输地址：客户端学习的一个传输地址，它将该客户端标识为IP网络上的另一个主机（通常是STUN服务器）看到的客户端。当客户端和另一主机之间存在中间NAT时，自反传输地址表示在NAT的公共侧分配给客户端的映射地址。自反传输地址从STUN响应中的映射地址属性（mapped-address或XOR-mapped-address）中学习。
Mapped Address: Same meaning as reflexive address. This term is retained only for historic reasons and due to the naming of the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes.
映射地址：与反射地址的含义相同。此术语仅因历史原因以及MAPPED-ADDRESS和XOR-MAPPED-ADDRESS属性的命名而保留。
Long-Term Credential: A username and associated password that represent a shared secret between client and server. Long-term credentials are generally granted to the client when a subscriber enrolls in a service and persist until the subscriber leaves the service or explicitly changes the credential.
长期凭证：代表客户端和服务器之间共享秘密的用户名和相关密码。长期凭据通常在订阅者注册服务时授予客户端，并持续到订阅者离开服务或显式更改凭据为止。
Long-Term Password: The password from a long-term credential.
长期密码：来自长期凭据的密码。
Short-Term Credential: A temporary username and associated password that represent a shared secret between client and server. Short-term credentials are obtained through some kind of protocol mechanism between the client and server, preceding the STUN exchange. A short-term credential has an explicit temporal scope, which may be based on a specific amount of time (such as 5 minutes) or on an event (such as termination of a SIP dialog). The specific scope of a short-term credential is defined by the application usage.
短期凭证：代表客户端和服务器之间共享秘密的临时用户名和相关密码。短期凭证是在STUN交换之前，通过客户端和服务器之间的某种协议机制获得的。短期凭证具有明确的时间范围，其可以基于特定的时间量（例如5分钟）或事件（例如SIP对话的终止）。短期凭证的特定范围由应用程序使用情况定义。
Short-Term Password: The password component of a short-term credential.
短期密码：短期凭证的密码组件。
STUN Indication: A STUN message that does not receive a response.
晕眩指示：未收到响应的晕眩信息。
Attribute: The STUN term for a Type-Length-Value (TLV) object that can be added to a STUN message. Attributes are divided into two types: comprehension-required and comprehension-optional. STUN agents can safely ignore comprehension-optional attributes they don't understand, but cannot successfully process a message if it contains comprehension-required attributes that are not understood.
属性：类型长度值（TLV）对象的眩晕术语，可添加到眩晕消息中。属性分为两种类型：需要理解和可选理解。STUN代理可以安全地忽略他们不理解的理解可选属性，但如果消息包含未理解的理解必需属性，则无法成功处理该消息。
RTO: Retransmission TimeOut, which defines the initial period of time between transmission of a request and the first retransmit of that request.
RTO：重新传输超时，它定义传输请求和第一次重新传输该请求之间的初始时间段。
STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big-endian). The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10).
STUN消息使用面向网络的格式（最高有效字节或八位字节优先，也称为big-endian）进行二进制编码。RFC 791[RFC0791]的附录B详细描述了传输顺序。除非另有说明，否则数值常量为十进制（以10为基数）。
All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. The STUN header contains a STUN message type, magic cookie, transaction ID, and message length.
所有STUN消息必须以20字节的头开头，后跟零个或多个属性。STUN头包含STUN消息类型、魔法cookie、事务ID和消息长度。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of STUN Message Header
图2:STUN消息头的格式
The most significant 2 bits of every STUN message MUST be zeroes. This can be used to differentiate STUN packets from other protocols when STUN is multiplexed with other protocols on the same port.
每个STUN消息的最高有效2位必须为零。当STUN与同一端口上的其他协议多路复用时，这可用于区分STUN数据包与其他协议。
The message type defines the message class (request, success response, failure response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only two types of transactions in STUN: request/response transactions (which consist of a request message and a response message) and indication transactions (which consist of a single indication message). Response classes are split into error and success responses to aid in quickly processing the STUN message.
消息类型定义了STUN消息的消息类（请求、成功响应、失败响应或指示）和消息方法（主要功能）。尽管有四个消息类，但STUN中只有两种类型的事务：请求/响应事务（由请求消息和响应消息组成）和指示事务（由单个指示消息组成）。响应类分为错误响应和成功响应，以帮助快速处理眩晕消息。
The message type field is decomposed further into the following structure:
消息类型字段进一步分解为以下结构：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of STUN Message Type Field
图3:STUN消息类型字段的格式
Here the bits in the message type field are shown as most significant (M11) through least significant (M0). M11 through M0 represent a 12- bit encoding of the method. C1 and C0 represent a 2-bit encoding of the class. A class of 0b00 is a request, a class of 0b01 is an indication, a class of 0b10 is a success response, and a class of 0b11 is an error response. This specification defines a single method, Binding. The method and class are orthogonal, so that for each method, a request, success response, error response, and indication are possible for that method. Extensions defining new methods MUST indicate which classes are permitted for that method.
此处，消息类型字段中的位显示为最高有效（M11）至最低有效（M0）。M11到M0表示该方法的12位编码。C1和C0表示类的2位编码。0b00类是请求，0b01类是指示，0b10类是成功响应，0b11类是错误响应。本规范定义了一个方法，即绑定。方法和类是正交的，因此对于每个方法，该方法都可能有请求、成功响应、错误响应和指示。定义新方法的扩展必须指明该方法允许哪些类。
For example, a Binding request has class=0b00 (request) and method=0b000000000001 (Binding) and is encoded into the first 16 bits as 0x0001. A Binding response has class=0b10 (success response) and method=0b000000000001, and is encoded into the first 16 bits as 0x0101.
例如，绑定请求具有class=0b00（请求）和method=0b000000000001（绑定），并将其编码为0x0001的前16位。绑定响应具有类=0b10（成功响应）和方法=0b000000000001，并被编码到前16位作为0x0101。
Note: This unfortunate encoding is due to assignment of values in [RFC3489] that did not consider encoding Indications, Success, and Errors using bit fields.
注意：这个不幸的编码是由于[fc3399]中没有使用比特字段考虑编码指示、成功和错误的值的赋值。
The magic cookie field MUST contain the fixed value 0x2112A442 in network byte order. In RFC 3489 [RFC3489], this field was part of the transaction ID; placing the magic cookie in this location allows a server to detect if the client will understand certain attributes that were added in this revised specification. In addition, it aids in distinguishing STUN packets from packets of other protocols when STUN is multiplexed with those other protocols on the same port.
magic cookie字段必须按网络字节顺序包含固定值0x2112A442。在RFC 3489[RFC3489]中，此字段是事务ID的一部分；将magic cookie放置在此位置允许服务器检测客户端是否理解此修订规范中添加的某些属性。此外，当STUN与同一端口上的其他协议多路复用时，它有助于区分STUN数据包与其他协议的数据包。
The transaction ID is a 96-bit identifier, used to uniquely identify STUN transactions. For request/response transactions, the transaction ID is chosen by the STUN client for the request and echoed by the server in the response. For indications, it is chosen by the agent sending the indication. It primarily serves to correlate requests with responses, though it also plays a small role
事务ID是一个96位标识符，用于唯一标识STUN事务。对于请求/响应事务，事务ID由STUN客户端为请求选择，并由服务器在响应中回显。对于指示，由发送指示的代理选择。它主要用于将请求与响应关联起来，但也起到了很小的作用
in helping to prevent certain types of attacks. The server also uses the transaction ID as a key to identify each transaction uniquely across all clients. As such, the transaction ID MUST be uniformly and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be cryptographically random. Resends of the same request reuse the same transaction ID, but the client MUST choose a new transaction ID for new transactions unless the new request is bit-wise identical to the previous request and sent from the same transport address to the same IP address. Success and error responses MUST carry the same transaction ID as their corresponding request. When an agent is acting as a STUN server and STUN client on the same port, the transaction IDs in requests sent by the agent have no relationship to the transaction IDs in requests received by the agent.
帮助防止某些类型的攻击。服务器还使用事务ID作为密钥，在所有客户端上唯一地标识每个事务。因此，必须从间隔0中统一随机地选择事务ID。。2**96-1，并且应该是加密随机的。同一请求的重新发送将重用同一事务ID，但客户端必须为新事务选择一个新事务ID，除非新请求在位上与前一个请求相同，并从同一传输地址发送到同一IP地址。成功和错误响应必须携带与其相应请求相同的事务ID。当代理在同一端口上充当STUN服务器和STUN客户端时，代理发送的请求中的事务ID与代理接收的请求中的事务ID没有关系。
The message length MUST contain the size, in bytes, of the message not including the 20-byte STUN header. Since all STUN attributes are padded to a multiple of 4 bytes, the last 2 bits of this field are always zero. This provides another way to distinguish STUN packets from packets of other protocols.
消息长度必须包含不包括20字节STUN头的消息的大小（以字节为单位）。由于所有眩晕属性都填充为4字节的倍数，因此该字段的最后2位始终为零。这提供了另一种区分STUN数据包和其他协议数据包的方法。
Following the STUN fixed portion of the header are zero or more attributes. Each attribute is TLV (Type-Length-Value) encoded. The details of the encoding, and of the attributes themselves are given in Section 15.
标题的眩晕固定部分后面是零个或多个属性。每个属性都是TLV（类型长度值）编码的。第15节给出了编码和属性本身的详细信息。
This section defines the base procedures of the STUN protocol. It describes how messages are formed, how they are sent, and how they are processed when they are received. It also defines the detailed processing of the Binding method. Other sections in this document describe optional procedures that a usage may elect to use in certain situations. Other documents may define other extensions to STUN, by adding new methods, new attributes, or new error response codes.
本节定义了STUN协议的基本程序。它描述了消息的形成方式、发送方式以及接收时的处理方式。它还定义了绑定方法的详细处理。本文件中的其他章节描述了在某些情况下，使用者可能选择使用的可选程序。其他文档可以通过添加新方法、新属性或新错误响应代码来定义STUN的其他扩展。
When formulating a request or indication message, the agent MUST follow the rules in Section 6 when creating the header. In addition, the message class MUST be either "Request" or "Indication" (as appropriate), and the method must be either Binding or some method defined in another document.
制定请求或指示消息时，代理在创建标头时必须遵循第6节中的规则。此外，消息类必须是“请求”或“指示”（视情况而定），并且方法必须是绑定的或在另一个文档中定义的某个方法。
The agent then adds any attributes specified by the method or the usage. For example, some usages may specify that the agent use an authentication method (Section 10) or the FINGERPRINT attribute (Section 8).
然后，代理添加由方法或用法指定的任何属性。例如，一些用法可以指定代理使用认证方法（第10节）或指纹属性（第8节）。
If the agent is sending a request, it SHOULD add a SOFTWARE attribute to the request. Agents MAY include a SOFTWARE attribute in indications, depending on the method. Extensions to STUN should discuss whether SOFTWARE is useful in new indications.
如果代理正在发送请求，则应向请求添加软件属性。代理可能包括指示中的软件属性，具体取决于方法。STUN的扩展应讨论软件在新适应症中是否有用。
For the Binding method with no authentication, no attributes are required unless the usage specifies otherwise.
对于没有身份验证的绑定方法，除非用法另有规定，否则不需要属性。
All STUN messages sent over UDP SHOULD be less than the path MTU, if known. If the path MTU is unknown, messages SHOULD be the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. This value corresponds to the overall size of the IP packet. Consequently, for IPv4, the actual STUN message would need to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte UDP header, assuming no IP options are used). STUN provides no ability to handle the case where the request is under the MTU but the response would be larger than the MTU. It is not envisioned that this limitation will be an issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [BEHAVE-NAT]. Outside of this or similar applications, the MTU constraint MUST be followed.
通过UDP发送的所有STUN消息应小于路径MTU（如果已知）。如果路径MTU未知，则消息应为576字节和第一跳MTU（IPv4[RFC1122]），以及1280字节（IPv6[RFC2460]）中的较小者。该值对应于IP数据包的总大小。因此，对于IPv4，实际的STUN消息需要小于548字节（576减去20字节的IP头，减去8字节的UDP头，假设没有使用IP选项）。STUN无法处理请求在MTU下但响应将大于MTU的情况。这是不可想象的，这一限制将是一个问题的眩晕。MTU限制是应该的，而不是必须的，以说明STUN本身被用于探测MTU特征的情况[BEFORM-NAT]。在该应用程序或类似应用程序之外，必须遵循MTU约束。
The agent then sends the request or indication. This document specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP; other transport protocols may be added in the future. The STUN usage must specify which transport protocol is used, and how the agent determines the IP address and port of the recipient. Section 9 describes a DNS-based method of determining the IP address and port of a server that a usage may elect to use. STUN may be used with anycast addresses, but only with UDP and in usages where authentication is not used.
然后，代理发送请求或指示。本文档指定如何通过UDP、TCP或TLS通过TCP发送STUN消息；将来可能会添加其他传输协议。STUN使用必须指定使用哪种传输协议，以及代理如何确定收件人的IP地址和端口。第9节描述了一种基于DNS的方法，用于确定用户可能选择使用的服务器的IP地址和端口。STUN可与选播地址一起使用，但仅用于UDP和不使用身份验证的情况。
At any time, a client MAY have multiple outstanding STUN requests with the same STUN server (that is, multiple transactions in progress, with different transaction IDs). Absent other limits to the rate of new transactions (such as those specified by ICE for connectivity checks or when STUN is run over TCP), a client SHOULD space new transactions to a server by RTO and SHOULD limit itself to ten outstanding transactions to the same server.
在任何时候，一个客户机都可能在同一个STUN服务器上有多个未完成的STUN请求（即，多个正在进行的事务，具有不同的事务ID）。如果没有对新事务速率的其他限制（如ICE为连接检查或通过TCP运行STUN而指定的限制），客户端应通过RTO将新事务分配给服务器，并应将自身限制为同一服务器的十个未完成事务。
When running STUN over UDP, it is possible that the STUN message might be dropped by the network. Reliability of STUN request/ response transactions is accomplished through retransmissions of the
通过UDP运行STUN时，网络可能会丢弃STUN消息。STUN请求/响应事务的可靠性是通过重新传输
request message by the client application itself. STUN indications are not retransmitted; thus, indication transactions over UDP are not reliable.
客户端应用程序本身发出的请求消息。眩晕指示不会被重新传输；因此，UDP上的指示事务不可靠。
A client SHOULD retransmit a STUN request message starting with an interval of RTO ("Retransmission TimeOut"), doubling after each retransmission. The RTO is an estimate of the round-trip time (RTT), and is computed as described in RFC 2988 [RFC2988], with two exceptions. First, the initial value for RTO SHOULD be configurable (rather than the 3 s recommended in RFC 2988) and SHOULD be greater than 500 ms. The exception cases for this "SHOULD" are when other mechanisms are used to derive congestion thresholds (such as the ones defined in ICE for fixed rate streams), or when STUN is used in non-Internet environments with known network capacities. In fixed-line access links, a value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms accuracy SHOULD be maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means that RTT estimates SHOULD NOT be computed from STUN transactions that result in the retransmission of a request.
客户端应以RTO（“重新传输超时”）的间隔开始重新传输STUN请求消息，每次重新传输后加倍。RTO是对往返时间（RTT）的估计，按照RFC 2988[RFC2988]中的描述计算，但有两个例外。首先，RTO的初始值应该是可配置的（而不是RFC 2988中建议的3 s），并且应该大于500 ms。这种“应该”的例外情况是，当使用其他机制来推导拥塞阈值时（如ICE中为固定速率流定义的机制），或者在已知网络容量的非互联网环境中使用STUN。在固定线路接入链路中，建议使用500 ms的值。其次，RTO的值不应四舍五入到最接近的秒。相反，应保持1 ms的精度。与TCP一样，建议使用Karn算法[KARN87]。当应用于STUN时，这意味着RTT估计值不应根据导致请求重新传输的STUN事务计算。
The value for RTO SHOULD be cached by a client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded after 10 minutes.
RTO的值应在事务完成后由客户端缓存，并用作同一服务器的下一个事务的RTO起始值（基于IP地址相等）。该值应视为过时，并在10分钟后丢弃。
Retransmissions continue until a response is received, or until a total of Rc requests have been sent. Rc SHOULD be configurable and SHOULD have a default of 7. If, after the last request, a duration equal to Rm times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), the client SHOULD consider the transaction to have failed. Rm SHOULD be configurable and SHOULD have a default of 16. A STUN transaction over UDP is also considered failed if there has been a hard ICMP error [RFC1122]. For example, assuming an RTO of 500 ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out.
重新传输将继续进行，直到收到响应，或者直到发送了全部Rc请求。Rc应该是可配置的，默认值为7。如果在最后请求之后，等于RM的持续时间，RTO已经没有响应（提供足够的时间来获得响应，如果只有这个最终请求实际上成功），则客户端应该考虑事务失败。Rm应该是可配置的，默认值为16。如果出现硬ICMP错误[RFC1122]，UDP上的STUN事务也被视为失败。例如，假设500毫秒的RTO，将在0毫秒、500毫秒、1500毫秒、3500毫秒、7500毫秒、15500毫秒和31500毫秒发送请求。如果客户端在39500毫秒之后没有收到响应，则客户端将考虑事务超时。
For TCP and TLS-over-TCP, the client opens a TCP connection to the server.
对于TCP和TCP上的TLS，客户端打开到服务器的TCP连接。
In some usages of STUN, STUN is sent as the only protocol over the TCP connection. In this case, it can be sent without the aid of any additional framing or demultiplexing. In other usages, or with other extensions, it may be multiplexed with other data over a TCP connection. In that case, STUN MUST be run on top of some kind of framing protocol, specified by the usage or extension, which allows for the agent to extract complete STUN messages and complete application layer messages. The STUN service running on the well-known port or ports discovered through the DNS procedures in Section 9 is for STUN alone, and not for STUN multiplexed with other data. Consequently, no framing protocols are used in connections to those servers. When additional framing is utilized, the usage will specify how the client knows to apply it and what port to connect to. For example, in the case of ICE connectivity checks, this information is learned through out-of-band negotiation between client and server.
在STUN的某些用法中，STUN作为TCP连接上的唯一协议发送。在这种情况下，它可以在没有任何额外帧或解复用帮助的情况下发送。在其他用途中，或与其他扩展一起，它可以通过TCP连接与其他数据多路复用。在这种情况下，STUN必须在某种帧协议上运行，该协议由用法或扩展指定，允许代理提取完整的STUN消息和完整的应用层消息。在第9节中通过DNS程序发现的一个或多个已知端口上运行的STUN服务仅适用于STUN，而不适用于与其他数据多路复用的STUN。因此，在与这些服务器的连接中不使用帧协议。当使用额外的帧时，用法将指定客户端如何知道应用它以及连接到哪个端口。例如，在ICE连接检查的情况下，通过客户机和服务器之间的带外协商了解此信息。
When STUN is run by itself over TLS-over-TCP, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a minimum. Implementations MAY also support any other ciphersuite. When it receives the TLS Certificate message, the client SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid or revoked, or if it does not identify the appropriate party, the client MUST NOT send the STUN message or otherwise proceed with the STUN transaction. The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [RFC2818]. Those procedures assume the client is dereferencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 8.1 as the host portion of the URI that has been dereferenced. Alternatively, a client MAY be configured with a set of domains or IP addresses that are trusted; if a certificate is received that identifies one of those domains or IP addresses, the client considers the identity of the server to be verified.
当STUN通过TCP上的TLS自行运行时，必须至少实现TLS_RSA_和_AES_128_CBC_SHA密码套件。实现还可以支持任何其他密码套件。当收到TLS证书消息时，客户端应验证证书并检查证书标识的站点。如果证书无效或已吊销，或者证书未标识适当的一方，则客户端不得发送STUN消息或以其他方式继续进行STUN事务。客户端必须验证服务器的标识。为此，应遵循RFC 2818[RFC2818]第3.1节中规定的识别程序。这些过程假定客户端正在取消对URI的引用。为了与本规范一起使用，客户机将第8.1节中使用的域名或IP地址视为已取消引用的URI的主机部分。或者，客户机可以配置有一组受信任的域或IP地址；如果接收到标识其中一个域或IP地址的证书，则客户端将考虑验证服务器的标识。
When STUN is run multiplexed with other protocols over a TLS-over-TCP connection, the mandatory ciphersuites and TLS handling procedures operate as defined by those protocols.
当STUN通过TLS over TCP连接与其他协议多路传输时，强制密码套件和TLS处理过程按照这些协议的定义运行。
Reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and there are no retransmissions at the STUN protocol level. However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5s. This value has been chosen to equalize the TCP and UDP timeouts for the default initial RTO.
STUN over TCP和TLS over TCP的可靠性由TCP本身处理，并且在STUN协议级别没有重传。但是，对于请求/响应事务，如果客户端在发送SYN以建立连接后的Ti秒内未收到响应，则认为该事务已超时。Ti应该是可配置的，默认值为39.5s。已选择此值以均衡默认初始RTO的TCP和UDP超时。
In addition, if the client is unable to establish the TCP connection, or the TCP connection is reset or fails before a response is received, any request/response transaction in progress is considered to have failed.
此外，如果客户端无法建立TCP连接，或者TCP连接在收到响应之前重置或失败，则任何正在进行的请求/响应事务都被视为失败。
The client MAY send multiple transactions over a single TCP (or TLS-over-TCP) connection, and it MAY send another request before receiving a response to the previous. The client SHOULD keep the connection open until it:
客户端可以通过单个TCP（或TCP上的TLS）连接发送多个事务，并且可以在接收到对前一个事务的响应之前发送另一个请求。客户端应保持连接打开，直到：
o has no further STUN requests or indications to send over that connection, and
o 没有通过该连接发送的进一步电击请求或指示，以及
o has no plans to use any resources (such as a mapped address (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address [BEHAVE-TURN]) that were learned though STUN requests sent over that connection, and
o 没有计划使用通过该连接发送的STUN请求获取的任何资源（如映射地址（mapped-address或XOR-mapped-address）或中继地址[BEHAVE-TURN]），以及
o if multiplexing other application protocols over that port, has finished using that other application, and
o 如果通过该端口复用其他应用程序协议，则已完成使用该其他应用程序，以及
o if using that learned port with a remote peer, has established communications with that remote peer, as is required by some TCP NAT traversal techniques (e.g., [MMUSIC-ICE-TCP]).
o 如果与远程对等方使用该学习端口，则已与该远程对等方建立通信，这是某些TCP NAT穿越技术（例如，[MMUSIC-ICE-TCP]）所要求的。
At the server end, the server SHOULD keep the connection open, and let the client close it, unless the server has determined that the connection has timed out (for example, due to the client disconnecting from the network). Bindings learned by the client will remain valid in intervening NATs only while the connection remains open. Only the client knows how long it needs the binding. The server SHOULD NOT close a connection if a request was received over that connection for which a response was not sent. A server MUST NOT ever open a connection back towards the client in order to send a response. Servers SHOULD follow best practices regarding connection management in cases of overload.
在服务器端，服务器应保持连接打开，并让客户端将其关闭，除非服务器已确定连接已超时（例如，由于客户端与网络断开连接）。只有在连接保持打开的情况下，客户端学习到的绑定才能在干预NAT中保持有效。只有客户机知道它需要绑定多长时间。如果通过未发送响应的连接接收到请求，则服务器不应关闭该连接。服务器决不能为了发送响应而打开回客户端的连接。服务器应遵循过载情况下连接管理的最佳实践。
This section specifies the processing of a STUN message. The processing specified here is for STUN messages as defined in this specification; additional rules for backwards compatibility are defined in Section 12. Those additional procedures are optional, and usages can elect to utilize them. First, a set of processing operations is applied that is independent of the class. This is followed by class-specific processing, described in the subsections that follow.
本节规定了STUN消息的处理。此处规定的处理适用于本规范中定义的STUN消息；第12节定义了向后兼容性的其他规则。这些附加程序是可选的，用户可以选择使用它们。首先，应用一组独立于类的处理操作。接下来是特定于类的处理，在后面的小节中进行了描述。
When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 6. It checks that the first two bits are 0, that the magic cookie field has the correct value, that the message length is sensible, and that the method value is a supported method. It checks that the message class is allowed for the particular method. If the message class is "Success Response" or "Error Response", the agent checks that the transaction ID matches a transaction that is still in progress. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any errors are detected, the message is silently discarded. In the case when STUN is being multiplexed with another protocol, an error may indicate that this is not really a STUN message; in this case, the agent should try to parse the message as a different protocol.
当眩晕代理收到眩晕消息时，它首先检查消息是否符合第6节的规则。它检查前两位是否为0，magic cookie字段是否具有正确的值，消息长度是否合理，以及方法值是否是受支持的方法。它检查消息类是否允许用于特定方法。如果消息类为“成功响应”或“错误响应”，则代理将检查事务ID是否与仍在进行的事务匹配。如果正在使用指纹扩展名，代理将检查指纹属性是否存在并包含正确的值。如果检测到任何错误，则会自动丢弃该消息。在STUN与另一协议多路传输的情况下，错误可能表明这不是真正的STUN消息；在这种情况下，代理应该尝试将消息解析为不同的协议。
The STUN agent then does any checks that are required by a authentication mechanism that the usage has specified (see Section 10).
然后，STUN代理执行该用法指定的身份验证机制所需的任何检查（参见第10节）。
Once the authentication checks are done, the STUN agent checks for unknown attributes and known-but-unexpected attributes in the message. Unknown comprehension-optional attributes MUST be ignored by the agent. Known-but-unexpected attributes SHOULD be ignored by the agent. Unknown comprehension-required attributes cause processing that depends on the message class and is described below.
身份验证检查完成后，STUN代理将检查消息中的未知属性和已知但意外的属性。代理必须忽略未知的可选属性。代理应忽略已知但意外的属性。未知的理解要求属性会导致依赖于消息类的处理，如下所述。
At this point, further processing depends on the message class of the request.
此时，进一步的处理取决于请求的消息类。
If the request contains one or more unknown comprehension-required attributes, the server replies with an error response with an error code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES attribute in the response that lists the unknown comprehension-required attributes.
如果请求包含一个或多个未知的理解必需属性，则服务器将以错误代码420（未知属性）的错误响应进行响应，并在响应中包含列出未知理解必需属性的unknown-attributes属性。
The server then does any additional checking that the method or the specific usage requires. If all the checks succeed, the server formulates a success response as described below.
然后，服务器执行该方法或特定用法所需的任何附加检查。如果所有检查都成功，服务器将按照如下所述制定成功响应。
When run over UDP, a request received by the server could be the first request of a transaction, or a retransmission. The server MUST respond to retransmissions such that the following property is preserved: if the client receives the response to the retransmission and not the response that was sent to the original request, the overall state on the client and server is identical to the case where only the response to the original retransmission is received, or
在UDP上运行时，服务器接收到的请求可能是事务的第一个请求，也可能是重新传输。服务器必须对重传做出响应，以便保留以下属性：如果客户端接收到对重传的响应而不是发送到原始请求的响应，则客户端和服务器上的总体状态与仅接收到对原始重传的响应的情况相同，或者
where both responses are received (in which case the client will use the first). The easiest way to meet this requirement is for the server to remember all transaction IDs received over UDP and their corresponding responses in the last 40 seconds. However, this requires the server to hold state, and will be inappropriate for any requests which are not authenticated. Another way is to reprocess the request and recompute the response. The latter technique MUST only be applied to requests that are idempotent (a request is considered idempotent when the same request can be safely repeated without impacting the overall state of the system) and result in the same success response for the same request. The Binding method is considered to be idempotent. Note that there are certain rare network events that could cause the reflexive transport address value to change, resulting in a different mapped address in different success responses. Extensions to STUN MUST discuss the implications of request retransmissions on servers that do not store transaction state.
接收到两个响应（在这种情况下，客户端将使用第一个响应）。满足此要求的最简单方法是服务器记住通过UDP接收的所有事务ID及其在过去40秒内的相应响应。但是，这需要服务器保持状态，对于任何未经身份验证的请求都是不合适的。另一种方法是重新处理请求并重新计算响应。后一种技术必须仅应用于幂等请求（当同一请求可以安全地重复而不影响系统的整体状态时，该请求被视为幂等请求），并对同一请求产生相同的成功响应。绑定方法被认为是幂等的。请注意，某些罕见的网络事件可能会导致自反传输地址值发生更改，从而在不同的成功响应中产生不同的映射地址。STUN的扩展必须讨论在不存储事务状态的服务器上重新传输请求的含义。
When forming the response (success or error), the server follows the rules of Section 6. The method of the response is the same as that of the request, and the message class is either "Success Response" or "Error Response".
当形成响应（成功或错误）时，服务器遵循第6节的规则。响应的方法与请求的方法相同，消息类为“成功响应”或“错误响应”。
For an error response, the server MUST add an ERROR-CODE attribute containing the error code specified in the processing above. The reason phrase is not fixed, but SHOULD be something suitable for the error code. For certain errors, additional attributes are added to the message. These attributes are spelled out in the description where the error code is specified. For example, for an error code of 420 (Unknown Attribute), the server MUST include an UNKNOWN-ATTRIBUTES attribute. Certain authentication errors also cause attributes to be added (see Section 10). Extensions may define other errors and/or additional attributes to add in error cases.
对于错误响应，服务器必须添加一个错误代码属性，该属性包含在上述处理中指定的错误代码。原因短语不是固定的，但应该适合于错误代码。对于某些错误，会向消息中添加其他属性。这些属性在指定错误代码的描述中详细说明。例如，对于错误代码420（未知属性），服务器必须包含未知属性。某些身份验证错误也会导致添加属性（参见第10节）。扩展可以定义其他错误和/或附加属性以添加到错误案例中。
If the server authenticated the request using an authentication mechanism, then the server SHOULD add the appropriate authentication attributes to the response (see Section 10).
如果服务器使用身份验证机制对请求进行了身份验证，则服务器应向响应中添加适当的身份验证属性（请参阅第10节）。
The server also adds any attributes required by the specific method or usage. In addition, the server SHOULD add a SOFTWARE attribute to the message.
服务器还添加特定方法或用法所需的任何属性。此外，服务器应向消息添加软件属性。
For the Binding method, no additional checking is required unless the usage specifies otherwise. When forming the success response, the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the contents of the attribute are the source transport address of the
对于绑定方法，除非用法另有规定，否则不需要额外的检查。在形成成功响应时，服务器向响应添加一个XOR-MAPPED-ADDRESS属性，其中该属性的内容是响应的源传输地址
request message. For UDP, this is the source IP address and source UDP port of the request message. For TCP and TLS-over-TCP, this is the source IP address and source TCP port of the TCP connection as seen by the server.
请求消息。对于UDP，这是请求消息的源IP地址和源UDP端口。对于TCP和TCP上的TLS，这是服务器看到的TCP连接的源IP地址和源TCP端口。
The response (success or error) is sent over the same transport as the request was received on. If the request was received over UDP, the destination IP address and port of the response are the source IP address and port of the received request message, and the source IP address and port of the response are equal to the destination IP address and port of the received request message. If the request was received over TCP or TLS-over-TCP, the response is sent back on the same TCP connection as the request was received on.
响应（成功或错误）通过与上接收的请求相同的传输发送。如果通过UDP接收请求，则响应的目标IP地址和端口是接收到的请求消息的源IP地址和端口，响应的源IP地址和端口等于接收到的请求消息的目标IP地址和端口。如果通过TCP或TLS通过TCP接收到请求，则响应将在上接收到请求的TCP连接上发回。
If the indication contains unknown comprehension-required attributes, the indication is discarded and processing ceases.
如果该指示包含未知的理解要求属性，则该指示将被丢弃并停止处理。
The agent then does any additional checking that the method or the specific usage requires. If all the checks succeed, the agent then processes the indication. No response is generated for an indication.
然后，代理执行该方法或特定用法所需的任何附加检查。如果所有检查都成功，则代理将处理该指示。没有针对指示生成响应。
For the Binding method, no additional checking or processing is required, unless the usage specifies otherwise. The mere receipt of the message by the agent has refreshed the "bindings" in the intervening NATs.
对于绑定方法，不需要额外的检查或处理，除非用法另有规定。代理仅仅收到消息就刷新了中间NAT中的“绑定”。
Since indications are not re-transmitted over UDP (unlike requests), there is no need to handle re-transmissions of indications at the sending agent.
由于指示不会通过UDP重新传输（与请求不同），因此无需在发送代理处处理指示的重新传输。
If the success response contains unknown comprehension-required attributes, the response is discarded and the transaction is considered to have failed.
如果成功响应包含未知的必需属性，则将放弃响应，并将事务视为失败。
The client then does any additional checking that the method or the specific usage requires. If all the checks succeed, the client then processes the success response.
然后，客户机执行方法或特定用法所需的任何附加检查。如果所有检查都成功，那么客户端将处理成功响应。
For the Binding method, the client checks that the XOR-MAPPED-ADDRESS attribute is present in the response. The client checks the address family specified. If it is an unsupported address family, the
对于绑定方法，客户机检查响应中是否存在XOR-MAPPED-ADDRESS属性。客户端检查指定的地址族。如果是不受支持的地址族，则
attribute SHOULD be ignored. If it is an unexpected but supported address family (for example, the Binding transaction was sent over IPv4, but the address family specified is IPv6), then the client MAY accept and use the value.
属性应该被忽略。如果它是意外但受支持的地址系列（例如，绑定事务是通过IPv4发送的，但指定的地址系列是IPv6），则客户端可以接受并使用该值。
If the error response contains unknown comprehension-required attributes, or if the error response does not contain an ERROR-CODE attribute, then the transaction is simply considered to have failed.
如果错误响应包含未知的理解所需属性，或者如果错误响应不包含错误代码属性，则事务仅被视为失败。
The client then does any processing specified by the authentication mechanism (see Section 10). This may result in a new transaction attempt.
然后，客户端执行身份验证机制指定的任何处理（参见第10节）。这可能会导致新的事务尝试。
The processing at this point depends on the error code, the method, and the usage; the following are the default rules:
此时的处理取决于错误代码、方法和用法；以下是默认规则：
o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension is being used. See Section 11.
o 如果错误代码是300到399，则客户端应该考虑事务失败，除非正在使用AddiTeaServer扩展。见第11节。
o If the error code is 400 through 499, the client declares the transaction failed; in the case of 420 (Unknown Attribute), the response should contain a UNKNOWN-ATTRIBUTES attribute that gives additional information.
o 如果错误代码为400到499，则客户端声明事务失败；在420（未知属性）的情况下，响应应包含提供附加信息的未知属性。
o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this.
o 如果错误代码为500到599，则客户端可以重新发送请求；这样做的客户端必须限制这样做的次数。
Any other error code causes the client to consider the transaction failed.
任何其他错误代码都会导致客户端认为事务失败。
This section describes an optional mechanism for STUN that aids in distinguishing STUN messages from packets of other protocols when the two are multiplexed on the same transport address. This mechanism is optional, and a STUN usage must describe if and when it is used. The FINGERPRINT mechanism is not backwards compatible with RFC 3489, and cannot be used in environments where such compatibility is required.
本节描述了STUN的可选机制，当两个协议的数据包在同一传输地址上多路传输时，该机制有助于将STUN消息与其他协议的数据包区分开来。此机制是可选的，并且必须说明是否以及何时使用眩晕。指纹机制与RFC 3489不向后兼容，并且不能在需要这种兼容性的环境中使用。
In some usages, STUN messages are multiplexed on the same transport address as other protocols, such as the Real Time Transport Protocol (RTP). In order to apply the processing described in Section 7, STUN messages must first be separated from the application packets.
在某些用途中，STUN消息与其他协议（如实时传输协议（RTP））在相同的传输地址上多路传输。为了应用第7节中描述的处理，必须首先将STUN消息与应用程序数据包分开。
Section 6 describes three fixed fields in the STUN header that can be used for this purpose. However, in some cases, these three fixed fields may not be sufficient.
第6节介绍了STUN标题中可用于此目的的三个固定字段。但是，在某些情况下，这三个固定字段可能不够。
When the FINGERPRINT extension is used, an agent includes the FINGERPRINT attribute in messages it sends to another agent. Section 15.5 describes the placement and value of this attribute. When the agent receives what it believes is a STUN message, then, in addition to other basic checks, the agent also checks that the message contains a FINGERPRINT attribute and that the attribute contains the correct value. Section 7.3 describes when in the overall processing of a STUN message the FINGERPRINT check is performed. This additional check helps the agent detect messages of other protocols that might otherwise seem to be STUN messages.
使用指纹扩展时，代理在发送给另一个代理的消息中包含指纹属性。第15.5节描述了该属性的位置和值。当代理接收到它认为是昏迷消息时，除了其他基本检查外，代理还检查消息是否包含指纹属性以及该属性是否包含正确的值。第7.3节描述了在STUN消息的整体处理中执行指纹检查的时间。此附加检查有助于代理检测其他协议的消息，否则这些消息可能看起来是STUN消息。
This section describes an optional procedure for STUN that allows a client to use DNS to determine the IP address and port of a server. A STUN usage must describe if and when this extension is used. To use this procedure, the client must know a server's domain name and a service name; the usage must also describe how the client obtains these. Hard-coding the domain name of the server into software is NOT RECOMMENDED in case the domain name is lost or needs to change for legal or other reasons.
本节介绍STUN的可选过程，该过程允许客户端使用DNS确定服务器的IP地址和端口。眩晕用法必须说明是否以及何时使用此扩展名。要使用此过程，客户端必须知道服务器的域名和服务名称；用法还必须描述客户如何获得这些信息。如果域名丢失或因法律或其他原因需要更改，则不建议将服务器的域名硬编码为软件。
When a client wishes to locate a STUN server in the public Internet that accepts Binding request/response transactions, the SRV service name is "stun". When it wishes to locate a STUN server that accepts Binding request/response transactions over a TLS session, the SRV service name is "stuns". STUN usages MAY define additional DNS SRV service names.
当客户端希望在公共Internet中找到接受绑定请求/响应事务的STUN服务器时，SRV服务名称为“STUN”。当它希望定位通过TLS会话接受绑定请求/响应事务的STUN服务器时，SRV服务名称为“stuns”。STUN使用可能会定义其他DNS SRV服务名称。
The domain name is resolved to a transport address using the SRV procedures specified in [RFC2782]. The DNS SRV service name is the service name provided as input to this procedure. The protocol in the SRV lookup is the transport protocol the client will run STUN over: "udp" for UDP and "tcp" for TCP. Note that only "tcp" is defined with "stuns" at this time.
使用[RFC2782]中规定的SRV程序将域名解析为传输地址。DNS SRV服务名称是作为此过程的输入提供的服务名称。SRV查找中的协议是客户端将通过STUN运行的传输协议：“udp”表示udp，“tcp”表示tcp。请注意，此时只有“tcp”定义为“眩晕”。
The procedures of RFC 2782 are followed to determine the server to contact. RFC 2782 spells out the details of how a set of SRV records is sorted and then tried. However, RFC 2782 only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. When following these procedures, if the STUN transaction times out without receipt of a response, the client SHOULD retry the request to
按照RFC 2782的程序确定要联系的服务器。RFC2782详细说明了如何对一组SRV记录进行排序，然后进行尝试。但是，RFC2782仅说明客户端应“尝试连接到（协议、地址、服务）”，而未提供任何有关发生故障时发生的情况的详细信息。在执行这些过程时，如果STUN事务超时而未收到响应，则客户端应重试请求以
the next server in the ordered defined by RFC 2782. Such a retry is only possible for request/response transmissions, since indication transactions generate no response or timeout.
RFC 2782定义的订单中的下一个服务器。由于指示事务不生成响应或超时，因此这种重试仅适用于请求/响应传输。
The default port for STUN requests is 3478, for both TCP and UDP.
对于TCP和UDP，STUN请求的默认端口为3478。
Administrators of STUN servers SHOULD use this port in their SRV records for UDP and TCP. In all cases, the port in DNS MUST reflect the one on which the server is listening. The default port for STUN over TLS is 5349. Servers can run STUN over TLS on the same port as STUN over TCP if the server software supports determining whether the initial message is a TLS or STUN message.
STUN服务器的管理员应在其UDP和TCP的SRV记录中使用此端口。在所有情况下，DNS中的端口都必须反映服务器正在侦听的端口。STUN over TLS的默认端口为5349。如果服务器软件支持确定初始消息是TLS消息还是STUN消息，则服务器可以在与STUN over TCP相同的端口上通过TLS运行STUN。
If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the default port using UDP or TCP, independent of the STUN usage. For usages that require TLS, the client connects to one of the IP addresses using the default STUN over TLS port.
如果未找到SRV记录，客户端将对域名执行A或AAAA记录查找。结果将是一个IP地址列表，每个IP地址都可以在默认端口使用UDP或TCP进行联系，与STUN使用情况无关。对于需要TLS的使用，客户端使用默认的STUN over TLS端口连接到其中一个IP地址。
This section defines two mechanisms for STUN that a client and server can use to provide authentication and message integrity; these two mechanisms are known as the short-term credential mechanism and the long-term credential mechanism. These two mechanisms are optional, and each usage must specify if and when these mechanisms are used. Consequently, both clients and servers will know which mechanism (if any) to follow based on knowledge of which usage applies. For example, a STUN server on the public Internet supporting ICE would have no authentication, whereas the STUN server functionality in an agent supporting connectivity checks would utilize short-term credentials. An overview of these two mechanisms is given in Section 3.
本节定义了客户机和服务器可用于提供身份验证和消息完整性的两种STUN机制；这两种机制称为短期凭证机制和长期凭证机制。这两种机制是可选的，每次使用都必须指定是否以及何时使用这些机制。因此，客户机和服务器都将根据应用哪种用法的知识知道应该遵循哪种机制（如果有的话）。例如，公共互联网上支持ICE的STUN服务器将没有身份验证，而支持连接检查的代理中的STUN服务器功能将使用短期凭据。第3节概述了这两种机制。
Each mechanism specifies the additional processing required to use that mechanism, extending the processing specified in Section 7. The additional processing occurs in three different places: when forming a message, when receiving a message immediately after the basic checks have been performed, and when doing the detailed processing of error responses.
每个机制都指定了使用该机制所需的附加处理，扩展了第7节中指定的处理。附加处理发生在三个不同的位置：形成消息时，在执行基本检查后立即接收消息时，以及在执行错误响应的详细处理时。
The short-term credential mechanism assumes that, prior to the STUN transaction, the client and server have used some other protocol to exchange a credential in the form of a username and password. This credential is time-limited. The time limit is defined by the usage.
短期凭证机制假设，在STUN事务之前，客户机和服务器已使用其他协议以用户名和密码的形式交换凭证。此凭证有时间限制。时间限制由用法定义。
As an example, in the ICE usage [MMUSIC-ICE], the two endpoints use out-of-band signaling to agree on a username and password, and this username and password are applicable for the duration of the media session.
例如，在ICE使用[MMUSIC-ICE]中，两个端点使用带外信令来商定用户名和密码，并且该用户名和密码适用于媒体会话的持续时间。
This credential is used to form a message-integrity check in each request and in many responses. There is no challenge and response as in the long-term mechanism; consequently, replay is prevented by virtue of the time-limited nature of the credential.
此凭证用于在每个请求和许多响应中形成消息完整性检查。没有像长期机制那样的挑战和反应；因此，由于凭证的时间限制性质，可以防止重播。
For a request or indication message, the agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in the message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as described in Section 15.4. Note that the password is never included in the request or indication.
对于请求或指示消息，代理必须在消息中包含用户名和消息完整性属性。消息完整性属性的HMAC计算如第15.4节所述。请注意，请求或指示中从不包含密码。
After the agent has done the basic processing of a message, the agent performs the checks listed below in order specified:
代理完成消息的基本处理后，代理将按照指定的顺序执行下列检查：
o If the message does not contain both a MESSAGE-INTEGRITY and a USERNAME attribute:
o 如果消息不同时包含消息完整性和用户名属性：
* If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 400 (Bad Request).
* 如果消息是请求，则服务器必须以错误响应拒绝该请求。此响应必须使用错误代码400（错误请求）。
* If the message is an indication, the agent MUST silently discard the indication.
* 如果消息是一个指示，则代理必须以静默方式放弃该指示。
o If the USERNAME does not contain a username value currently valid within the server:
o 如果用户名不包含服务器中当前有效的用户名值：
* If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized).
* 如果消息是请求，则服务器必须以错误响应拒绝该请求。此响应必须使用错误代码401（未经授权）。
* If the message is an indication, the agent MUST silently discard the indication.
* 如果消息是一个指示，则代理必须以静默方式放弃该指示。
o Using the password associated with the username, compute the value for the message integrity as described in Section 15.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute:
o 使用与用户名相关联的密码，计算第15.4节所述的消息完整性值。如果结果值与MESSAGE-INTEGRITY属性的内容不匹配：
* If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized).
* 如果消息是请求，则服务器必须以错误响应拒绝该请求。此响应必须使用错误代码401（未经授权）。
* If the message is an indication, the agent MUST silently discard the indication.
* 如果消息是一个指示，则代理必须以静默方式放弃该指示。
If these checks pass, the agent continues to process the request or indication. Any response generated by a server MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. The response MUST NOT contain the USERNAME attribute.
如果这些检查通过，代理将继续处理请求或指示。服务器生成的任何响应都必须包含MESSAGE-INTEGRITY属性，该属性使用用于验证请求的密码进行计算。响应不能包含USERNAME属性。
If any of the checks fail, a server MUST NOT include a MESSAGE-INTEGRITY or USERNAME attribute in the error response. This is because, in these failure cases, the server cannot determine the shared secret necessary to compute MESSAGE-INTEGRITY.
如果任何检查失败，服务器不得在错误响应中包含消息完整性或用户名属性。这是因为，在这些故障情况下，服务器无法确定计算消息完整性所需的共享机密。
The client looks for the MESSAGE-INTEGRITY attribute in the response. If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue.
客户端在响应中查找MESSAGE-INTEGRITY属性。如果存在，客户端将使用其用于请求的相同密码，按照第15.4节中的定义计算响应上的消息完整性。如果结果值与MESSAGE-INTEGRITY属性的内容匹配，则认为响应已通过身份验证。如果值不匹配，或者缺少消息完整性，则必须丢弃响应，就像从未收到响应一样。这意味着重新传输（如果适用）将继续。
The long-term credential mechanism relies on a long-term credential, in the form of a username and password that are shared between client and server. The credential is considered long-term since it is assumed that it is provisioned for a user, and remains in effect until the user is no longer a subscriber of the system, or is changed. This is basically a traditional "log-in" username and password given to users.
长期凭证机制依赖于客户端和服务器之间共享的用户名和密码形式的长期凭证。凭证被认为是长期的，因为它被认为是为用户提供的，并且一直有效，直到用户不再是系统的订户或被更改为止。这基本上是给用户的传统“登录”用户名和密码。
Because these usernames and passwords are expected to be valid for extended periods of time, replay prevention is provided in the form of a digest challenge. In this mechanism, the client initially sends a request, without offering any credentials or any integrity checks. The server rejects this request, providing the user a realm (used to guide the user or agent in selection of a username and password) and a nonce. The nonce provides the replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a
由于这些用户名和密码预期在较长时间内有效，因此以摘要质询的形式提供了重播预防。在这种机制中，客户端最初发送一个请求，而不提供任何凭据或任何完整性检查。服务器拒绝此请求，为用户提供一个领域（用于指导用户或代理选择用户名和密码）和一个nonce。nonce提供重播保护。它是一个cookie，由服务器选择，并以指示
duration of validity or client identity from which it is valid. The client retries the request, this time including its username and the realm, and echoing the nonce provided by the server. The client also includes a message-integrity, which provides an HMAC over the entire request, including the nonce. The server validates the nonce and checks the message integrity. If they match, the request is authenticated. If the nonce is no longer valid, it is considered "stale", and the server rejects the request, providing a new nonce.
有效期或其有效的客户身份。客户端重试请求，这次包括其用户名和域，并回显服务器提供的nonce。客户机还包括消息完整性，它在整个请求（包括nonce）上提供HMAC。服务器验证nonce并检查消息完整性。如果它们匹配，则对请求进行身份验证。如果nonce不再有效，它将被视为“过时”，服务器将拒绝该请求，并提供一个新的nonce。
In subsequent requests to the same server, the client reuses the nonce, username, realm, and password it used previously. In this way, subsequent requests are not rejected until the nonce becomes invalid by the server, in which case the rejection provides a new nonce to the client.
在对同一服务器的后续请求中，客户机重用以前使用的nonce、用户名、领域和密码。通过这种方式，后续请求不会被拒绝，直到nonce被服务器失效，在这种情况下，拒绝会向客户端提供一个新的nonce。
Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them.
请注意，长期凭证机制不能用于保护指示，因为指示不能被质疑。利用指示的使用必须使用短期凭证，或忽略其身份验证和消息完整性。
Since the long-term credential mechanism is susceptible to offline dictionary attacks, deployments SHOULD utilize passwords that are difficult to guess. In cases where the credentials are not entered by the user, but are rather placed on a client device during device provisioning, the password SHOULD have at least 128 bits of randomness. In cases where the credentials are entered by the user, they should follow best current practices around password structure.
由于长期凭证机制容易受到脱机字典攻击，因此部署应使用难以猜测的密码。如果凭据不是由用户输入的，而是在设备配置期间放置在客户端设备上，则密码应至少具有128位随机性。在用户输入凭据的情况下，他们应该遵循关于密码结构的当前最佳实践。
There are two cases when forming a request. In the first case, this is the first request from the client to the server (as identified by its IP address and port). In the second case, the client is submitting a subsequent request once a previous request/response transaction has completed successfully. Forming a request as a consequence of a 401 or 438 error response is covered in Section 10.2.3 and is not considered a "subsequent request" and thus does not utilize the rules described in Section 10.2.1.2.
形成请求时有两种情况。在第一种情况下，这是客户机向服务器发出的第一个请求（由其IP地址和端口标识）。在第二种情况下，一旦前一个请求/响应事务成功完成，客户端将提交后续请求。由于401或438错误响应而形成的请求包含在第10.2.3节中，不被视为“后续请求”，因此不使用第10.2.1.2节中描述的规则。
If the client has not completed a successful request/response transaction with the server (as identified by hostname, if the DNS procedures of Section 9 are used, else IP address if not), it SHOULD omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. In other words, the very first request is sent as if there were no authentication or message integrity applied.
如果客户端没有成功完成与服务器的请求/响应事务（由主机名标识，如果使用了第9节的DNS过程，否则为IP地址），则应省略用户名、消息完整性、领域和NONCE属性。换句话说，发送第一个请求时，就好像没有应用身份验证或消息完整性一样。
Once a request/response transaction has completed successfully, the client will have been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it SHOULD include the USERNAME, REALM, and NONCE attributes with these cached values. It SHOULD include a MESSAGE-INTEGRITY attribute, computed as described in Section 15.4 using the cached password.
一旦请求/响应事务成功完成，服务器将向客户端提供一个域和nonce，并选择一个用户名和密码进行身份验证。客户端应该缓存用户名、密码、领域和nonce，以便与服务器进行后续通信。当客户端发送后续请求时，它应该包括用户名、领域和NONCE属性以及这些缓存值。它应该包括一个消息完整性属性，按照第15.4节所述使用缓存密码进行计算。
After the server has done the basic processing of a request, it performs the checks listed below in the order specified:
服务器完成请求的基本处理后，将按照指定的顺序执行下面列出的检查：
o If the message does not contain a MESSAGE-INTEGRITY attribute, the server MUST generate an error response with an error code of 401 (Unauthorized). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, selected by the server. The response SHOULD NOT contain a USERNAME or MESSAGE-INTEGRITY attribute.
o 如果消息不包含消息完整性属性，则服务器必须生成错误代码为401（未经授权）的错误响应。此响应必须包含领域值。建议领域值为STUN服务器提供程序的域名。响应必须包括由服务器选择的NONCE。响应不应包含用户名或消息完整性属性。
o If the message contains a MESSAGE-INTEGRITY attribute, but is missing the USERNAME, REALM, or NONCE attribute, the server MUST generate an error response with an error code of 400 (Bad Request). This response SHOULD NOT include a USERNAME, NONCE, REALM, or MESSAGE-INTEGRITY attribute.
o 如果消息包含message-INTEGRITY属性，但缺少USERNAME、REALM或NONCE属性，则服务器必须生成错误代码为400的错误响应（错误请求）。此响应不应包括用户名、NONCE、领域或消息完整性属性。
o If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response MUST include NONCE and REALM attributes and SHOULD NOT include the USERNAME or MESSAGE-INTEGRITY attribute. Servers can invalidate nonces in order to provide additional security. See Section 4.3 of [RFC2617] for guidelines.
o 如果NONCE不再有效，服务器必须生成错误代码为438（Stale NONCE）的错误响应。此响应必须包括NONCE和REALM属性，而不应包括USERNAME或MESSAGE-INTEGRITY属性。服务器可以使nonce无效以提供额外的安全性。指南见[RFC2617]第4.3节。
o If the username in the USERNAME attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthorized). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, selected by the server. The response SHOULD NOT contain a USERNAME or MESSAGE-INTEGRITY attribute.
o 如果用户名属性中的用户名无效，服务器必须生成错误代码为401（未经授权）的错误响应。此响应必须包含领域值。建议领域值为STUN服务器提供程序的域名。响应必须包括由服务器选择的NONCE。响应不应包含用户名或消息完整性属性。
o Using the password associated with the username in the USERNAME attribute, compute the value for the message integrity as described in Section 15.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). It MUST include REALM and NONCE attributes and SHOULD NOT include the USERNAME or MESSAGE-INTEGRITY attribute.
o 使用用户名属性中与用户名相关联的密码，计算第15.4节所述的消息完整性值。如果生成的值与MESSAGE-INTEGRITY属性的内容不匹配，则服务器必须以错误响应拒绝该请求。此响应必须使用错误代码401（未经授权）。它必须包括REALM和NONCE属性，而不应包括USERNAME或MESSAGE-INTEGRITY属性。
If these checks pass, the server continues to process the request. Any response generated by the server (excepting the cases described above) MUST include the MESSAGE-INTEGRITY attribute, computed using the username and password utilized to authenticate the request. The REALM, NONCE, and USERNAME attributes SHOULD NOT be included.
如果这些检查通过，服务器将继续处理该请求。服务器生成的任何响应（上述情况除外）必须包含MESSAGE-INTEGRITY属性，该属性使用用于验证请求的用户名和密码计算。不应包括REALM、NONCE和USERNAME属性。
If the response is an error response with an error code of 401 (Unauthorized), the client SHOULD retry the request with a new transaction. This request MUST contain a USERNAME, determined by the client as the appropriate username for the REALM from the error response. The request MUST contain the REALM, copied from the error response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the MESSAGE-INTEGRITY attribute, computed using the password associated with the username in the USERNAME attribute. The client MUST NOT perform this retry if it is not changing the USERNAME or REALM or its associated password, from the previous attempt.
如果响应是错误代码为401（未经授权）的错误响应，则客户端应使用新事务重试请求。此请求必须包含一个用户名，该用户名由客户端根据错误响应确定为域的适当用户名。请求必须包含从错误响应复制的域。请求必须包含从错误响应复制的NONCE。请求必须包含MESSAGE-INTEGRITY属性，该属性使用与username属性中的用户名关联的密码计算。如果客户端未更改上次尝试的用户名或域或其关联密码，则客户端不得执行此重试。
If the response is an error response with an error code of 438 (Stale Nonce), the client MUST retry the request, using the new NONCE supplied in the 438 (Stale Nonce) response. This retry MUST also include the USERNAME, REALM, and MESSAGE-INTEGRITY.
如果响应是错误代码为438（过时Nonce）的错误响应，则客户端必须使用438（过时Nonce）响应中提供的新Nonce重试请求。此重试还必须包括用户名、域和消息完整性。
The client looks for the MESSAGE-INTEGRITY attribute in the response (either success or failure). If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue.
客户端在响应中查找MESSAGE-INTEGRITY属性（成功或失败）。如果存在，客户端将使用其用于请求的相同密码，按照第15.4节中的定义计算响应上的消息完整性。如果结果值与MESSAGE-INTEGRITY属性的内容匹配，则认为响应已通过身份验证。如果值不匹配，或者缺少消息完整性，则必须丢弃响应，就像从未收到响应一样。这意味着重新传输（如果适用）将继续。
This section describes a mechanism in STUN that allows a server to redirect a client to another server. This extension is optional, and a usage must define if and when this extension is used.
本节介绍STUN中的一种机制，该机制允许服务器将客户端重定向到另一台服务器。此扩展是可选的，用法必须定义是否以及何时使用此扩展。
A server using this extension redirects a client to another server by replying to a request message with an error response message with an error code of 300 (Try Alternate). The server MUST include an ALTERNATE-SERVER attribute in the error response. The error response message MAY be authenticated; however, there are uses cases for ALTERNATE-SERVER where authentication of the response is not possible or practical.
使用此扩展的服务器通过使用错误代码为300的错误响应消息回复请求消息，从而将客户端重定向到另一台服务器（请尝试备用）。服务器必须在错误响应中包含备用服务器属性。可以对错误响应消息进行认证；但是，对于ALTERNATE-SERVER，在某些情况下，响应的身份验证是不可能或不实用的。
A client using this extension handles a 300 (Try Alternate) error code as follows. The client looks for an ALTERNATE-SERVER attribute in the error response. If one is found, then the client considers the current transaction as failed, and reattempts the request with the server specified in the attribute, using the same transport protocol used for the previous request. That request, if authenticated, MUST utilize the same credentials that the client would have used in the request to the server that performed the redirection. If the client has been redirected to a server on which it has already tried this request within the last five minutes, it MUST ignore the redirection and consider the transaction to have failed. This prevents infinite ping-ponging between servers in case of redirection loops.
使用此扩展的客户端处理300（Try Alternate）错误代码，如下所示。客户端在错误响应中查找备用服务器属性。如果找到一个，则客户端会认为当前事务失败，并使用属性中指定的服务器重新尝试请求，使用与前一个请求相同的传输协议。该请求如果经过身份验证，则必须使用客户端在向执行重定向的服务器发出的请求中使用的相同凭据。如果客户端已经重定向到在过去五分钟内已经尝试过该请求的服务器，则它必须忽略重定向并考虑事务失败。这可以防止在重定向循环的情况下，服务器之间的无限乒乓。
This section defines procedures that allow a degree of backwards compatibility with the original protocol defined in RFC 3489 [RFC3489]. This mechanism is optional, meant to be utilized only in cases where a new client can connect to an old server, or vice versa. A usage must define if and when this procedure is used.
本节定义了允许与RFC 3489[RFC3489]中定义的原始协议向后兼容的程序。此机制是可选的，仅在新客户端可以连接到旧服务器的情况下使用，反之亦然。用法必须定义是否以及何时使用此过程。
Section 19 lists all the changes between this specification and RFC 3489 [RFC3489]. However, not all of these differences are important, because "classic STUN" was only used in a few specific ways. For the purposes of this extension, the important changes are the following. In RFC 3489:
第19节列出了本规范与RFC 3489[RFC3489]之间的所有变更。然而，并不是所有这些差异都是重要的，因为“经典眩晕”只是以几种特定的方式使用。就本扩展而言，重要的更改如下。在RFC 3489中：
o UDP was the only supported transport.
o UDP是唯一受支持的传输。
o The field that is now the magic cookie field was a part of the transaction ID field, and transaction IDs were 128 bits long.
o 现在的magic cookie字段是事务ID字段的一部分，事务ID的长度为128位。
o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding method used the MAPPED-ADDRESS attribute instead.
o XOR-MAPPED-ADDRESS属性不存在，绑定方法使用MAPPED-ADDRESS属性。
o There were three comprehension-required attributes, RESPONSE-ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESS, that have been removed from this specification.
o 从本规范中删除了三个需要理解的属性：RESPONSE-ADDRESS、CHANGE-REQUEST和CHANGE-ADDRESS。
* CHANGE-REQUEST and CHANGED-ADDRESS are now part of the NAT Behavior Discovery usage [BEHAVE-NAT], and the other is deprecated.
* CHANGE-REQUEST和CHANGED-ADDRESS现在是NAT行为发现用法[BEHAVE-NAT]的一部分，而另一个已被弃用。
A client that wants to interoperate with an [RFC3489] server SHOULD send a request message that uses the Binding method, contains no attributes, and uses UDP as the transport protocol to the server. If successful, the success response received from the server will contain a MAPPED-ADDRESS attribute rather than an XOR-MAPPED-ADDRESS attribute. A client seeking to interoperate with an older server MUST be prepared to receive either. Furthermore, the client MUST ignore any Reserved comprehension-required attributes that might appear in the response. Of the Reserved attributes in Section 18.2, 0x0002, 0x0004, 0x0005, and 0x000B may appear in Binding responses from a server compliant to RFC 3489. Other than this change, the processing of the response is identical to the procedures described above.
希望与[RFC3489]服务器进行互操作的客户端应向服务器发送使用绑定方法、不包含属性并使用UDP作为传输协议的请求消息。如果成功，则从服务器接收的成功响应将包含MAPPED-ADDRESS属性，而不是XOR-MAPPED-ADDRESS属性。寻求与旧服务器进行互操作的客户端必须准备好接收任何一个。此外，客户机必须忽略响应中可能出现的任何保留的必需属性。第18.2节中的保留属性中，0x0002、0x0004、0x0005和0x000B可能出现在符合RFC 3489的服务器的绑定响应中。除此更改外，响应的处理与上述过程相同。
A STUN server can detect when a given Binding request message was sent from an RFC 3489 [RFC3489] client by the absence of the correct value in the magic cookie field. When the server detects an RFC 3489 client, it SHOULD copy the value seen in the magic cookie field in the Binding request to the magic cookie field in the Binding response message, and insert a MAPPED-ADDRESS attribute instead of an XOR-MAPPED-ADDRESS attribute.
由于magic cookie字段中没有正确的值，STUN服务器可以检测何时从RFC 3489[RFC3489]客户端发送了给定的绑定请求消息。当服务器检测到RFC 3489客户端时，它应该将绑定请求中magic cookie字段中的值复制到绑定响应消息中的magic cookie字段中，并插入MAPPED-ADDRESS属性而不是XOR-MAPPED-ADDRESS属性。
The client might, in rare situations, include either the RESPONSE-ADDRESS or CHANGE-REQUEST attributes. In these situations, the server will view these as unknown comprehension-required attributes and reply with an error response. Since the mechanisms utilizing those attributes are no longer supported, this behavior is acceptable.
在极少数情况下，客户机可能包含响应地址或更改请求属性。在这些情况下，服务器将这些属性视为未知的必需属性，并以错误响应进行回复。由于不再支持使用这些属性的机制，因此这种行为是可以接受的。
The RFC 3489 version of STUN lacks both the magic cookie and the FINGERPRINT attribute that allows for a very high probability of correctly identifying STUN messages when multiplexed with other protocols. Therefore, STUN implementations that are backwards
RFC 3489版本的STUN既没有魔法cookie，也没有指纹属性，这使得在与其他协议多路传输时，很有可能正确识别STUN消息。因此，STUN的实现是向后的
compatible with RFC 3489 SHOULD NOT be used in cases where STUN will be multiplexed with another protocol. However, that should not be an issue as such multiplexing was not available in RFC 3489.
在STUN将与另一协议多路传输的情况下，不应使用与RFC 3489兼容的设备。然而，这不应该是一个问题，因为RFC 3489中没有这种多路复用。
This section defines the behavior of a basic, stand-alone STUN server. A basic STUN server provides clients with server reflexive transport addresses by receiving and replying to STUN Binding requests.
本节定义了基本的、独立的STUN服务器的行为。基本的STUN服务器通过接收和回复STUN绑定请求为客户端提供服务器自反传输地址。
The STUN server MUST support the Binding method. It SHOULD NOT utilize the short-term or long-term credential mechanism. This is because the work involved in authenticating the request is more than the work in simply processing it. It SHOULD NOT utilize the ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP and TCP. It MAY support STUN over TCP/TLS; however, TLS provides minimal security benefits in this basic mode of operation. It MAY utilize the FINGERPRINT mechanism but MUST NOT require it. Since the stand-alone server only runs STUN, FINGERPRINT provides no benefit. Requiring it would break compatibility with RFC 3489, and such compatibility is desirable in a stand-alone server. Stand-alone STUN servers SHOULD support backwards compatibility with [RFC3489] clients, as described in Section 12.
STUN服务器必须支持绑定方法。它不应该利用短期或长期的认证机制。这是因为验证请求所涉及的工作比简单地处理请求所涉及的工作要多。出于同样的原因，它不应该使用备用服务器机制。它必须支持UDP和TCP。它可以通过TCP/TLS支持STUN；但是，TLS在这种基本操作模式下提供的安全性好处微乎其微。它可以利用指纹机制，但不能要求它。因为独立服务器只运行STUN，所以指纹没有任何好处。要求它将破坏与RFC3489的兼容性，这种兼容性在独立服务器中是可取的。独立STUN服务器应支持与[RFC3489]客户端的向后兼容性，如第12节所述。
It is RECOMMENDED that administrators of STUN servers provide DNS entries for those servers as described in Section 9.
建议STUN服务器的管理员为这些服务器提供DNS条目，如第9节所述。
A basic STUN server is not a solution for NAT traversal by itself. However, it can be utilized as part of a solution through STUN usages. This is discussed further in Section 14.
基本的STUN服务器本身并不是NAT遍历的解决方案。但是，它可以通过STUN使用作为解决方案的一部分。这将在第14节中进一步讨论。
STUN by itself is not a solution to the NAT traversal problem. Rather, STUN defines a tool that can be used inside a larger solution. The term "STUN usage" is used for any solution that uses STUN as a component.
STUN本身并不是NAT遍历问题的解决方案。相反，STUN定义了一个可以在更大的解决方案中使用的工具。术语“STUN用法”用于任何将STUN用作组件的解决方案。
At the time of writing, three STUN usages are defined: Interactive Connectivity Establishment (ICE) [MMUSIC-ICE], Client-initiated connections for SIP [SIP-OUTBOUND], and NAT Behavior Discovery [BEHAVE-NAT]. Other STUN usages may be defined in the future.
在撰写本文时，定义了三种STUN用法：交互式连接建立（ICE）[MMUSIC-ICE]、SIP的客户端启动连接[SIP-OUTBOUND]和NAT行为发现[BEHAVE-NAT]。将来可能会定义其他眩晕用法。
A STUN usage defines how STUN is actually utilized -- when to send requests, what to do with the responses, and which optional procedures defined here (or in an extension to STUN) are to be used. A usage would also define:
STUN的使用定义了STUN的实际使用方式——何时发送请求，如何处理响应，以及使用此处（或在STUN的扩展中）定义的可选过程。用法还将定义：
o Which STUN methods are used.
o 使用了哪些眩晕方法。
o What authentication and message-integrity mechanisms are used.
o 使用了哪些身份验证和消息完整性机制。
o The considerations around manual vs. automatic key derivation for the integrity mechanism, as discussed in [RFC4107].
o 关于完整性机制的手动与自动密钥派生的注意事项，如[RFC4107]中所述。
o What mechanisms are used to distinguish STUN messages from other messages. When STUN is run over TCP, a framing mechanism may be required.
o 使用什么机制来区分昏迷消息和其他消息。当STUN通过TCP运行时，可能需要帧机制。
o How a STUN client determines the IP address and port of the STUN server.
o STUN客户端如何确定STUN服务器的IP地址和端口。
o Whether backwards compatibility to RFC 3489 is required.
o 是否需要向后兼容RFC 3489。
o What optional attributes defined here (such as FINGERPRINT and ALTERNATE-SERVER) or in other extensions are required.
o 此处（如指纹和备用服务器）或其他扩展中定义的可选属性是必需的。
In addition, any STUN usage must consider the security implications of using STUN in that usage. A number of attacks against STUN are known (see the Security Considerations section in this document), and any usage must consider how these attacks can be thwarted or mitigated.
此外，任何晕眩用法都必须考虑在使用中使用STUN的安全含义。许多针对STUN的攻击是已知的（参见本文档中的安全考虑部分），并且任何使用必须考虑这些攻击是如何被挫败或减轻的。
Finally, a usage must consider whether its usage of STUN is an example of the Unilateral Self-Address Fixing approach to NAT traversal, and if so, address the questions raised in RFC 3424 [RFC3424].
最后，使用必须考虑它是否使用STUN是单向NAT穿越的自地址固定方法的一个例子，如果是的话，请解决RFC 3424中提出的问题[RFC324]。
After the STUN header are zero or more attributes. Each attribute MUST be TLV encoded, with a 16-bit type, 16-bit length, and value. Each STUN attribute MUST end on a 32-bit boundary. As mentioned above, all fields in an attribute are transmitted most significant bit first.
晕眩头部之后是零个或多个属性。每个属性必须是TLV编码的，具有16位类型、16位长度和值。每个晕眩属性必须在32位边界上结束。如上所述，属性中的所有字段首先传输最高有效位。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes
图4:STUN属性的格式
The value in the length field MUST contain the length of the Value part of the attribute, prior to padding, measured in bytes. Since STUN aligns attributes on 32-bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of padding so that its value contains a multiple of 4 bytes. The padding bits are ignored, and may be any value.
长度字段中的值必须包含填充前属性值部分的长度（以字节为单位）。由于STUN在32位边界上对齐属性，因此内容不是4字节倍数的属性将使用1、2或3字节的填充进行填充，以便其值包含4字节的倍数。填充位被忽略，可以是任何值。
Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: only the first occurrence needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver.
任何属性类型都可能在昏迷消息中出现多次。除非另有规定，否则出现的顺序是重要的：只有第一次出现需要接收者处理，任何重复的都可能被接收者忽略。
To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into two ranges. Attributes with type values between 0x0000 and 0x7FFF are comprehension-required attributes, which means that the STUN agent cannot successfully process the message unless it understands the attribute. Attributes with type values between 0x8000 and 0xFFFF are comprehension-optional attributes, which means that those attributes can be ignored by the STUN agent if it does not understand them.
为了允许本规范的未来版本在需要时添加新属性，属性空间分为两个范围。类型值介于0x0000和0x7FFF之间的属性是需要理解的属性，这意味着STUN代理无法成功处理消息，除非它理解该属性。类型值介于0x8000和0xFFFF之间的属性是可选属性，这意味着如果STUN代理不理解这些属性，则可以忽略这些属性。
The set of STUN attribute types is maintained by IANA. The initial set defined by this specification is found in Section 18.2.
STUN属性类型集由IANA维护。本规范规定的初始集见第18.2节。
The rest of this section describes the format of the various attributes defined in this specification.
本节的其余部分描述了本规范中定义的各种属性的格式。
The MAPPED-ADDRESS attribute indicates a reflexive transport address of the client. It consists of an 8-bit address family and a 16-bit port, followed by a fixed-length value representing the IP address. If the address family is IPv4, the address MUST be 32 bits. If the address family is IPv6, the address MUST be 128 bits. All fields must be in network byte order.
MAPPED-ADDRESS属性表示客户端的自反传输地址。它由一个8位地址系列和一个16位端口组成，后跟一个表示IP地址的固定长度值。如果地址系列为IPv4，则地址必须为32位。如果地址族是IPv6，则地址必须为128位。所有字段必须按网络字节顺序排列。
The format of the MAPPED-ADDRESS attribute is:
映射地址属性的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address (32 bits or 128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address (32 bits or 128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of MAPPED-ADDRESS Attribute
图5：映射地址属性的格式
The address family can take on the following values:
地址族可以采用以下值：
0x01:IPv4 0x02:IPv6
0x01:IPv4 0x02:IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be ignored by receivers. These bits are present for aligning parameters on natural 32-bit boundaries.
映射地址的前8位必须设置为0，并且必须被接收器忽略。这些位用于对齐自然32位边界上的参数。
This attribute is used only by servers for achieving backwards compatibility with RFC 3489 [RFC3489] clients.
此属性仅由服务器用于实现与RFC 3489[RFC3489]客户端的向后兼容性。
The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS attribute, except that the reflexive transport address is obfuscated through the XOR function.
XOR-MAPPED-ADDRESS属性与MAPPED-ADDRESS属性相同，只是反射传输地址通过XOR函数进行模糊处理。
The format of the XOR-MAPPED-ADDRESS is:
XOR映射地址的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
图6:XOR-MAPPED-ADDRESS属性的格式
The Family represents the IP address family, and is encoded identically to the Family in MAPPED-ADDRESS.
该族表示IP地址族，其编码与映射的IP地址中的族相同。
X-Port is computed by taking the mapped port in host byte order, XOR'ing it with the most significant 16 bits of the magic cookie, and then the converting the result to network byte order. If the IP address family is IPv4, X-Address is computed by taking the mapped IP address in host byte order, XOR'ing it with the magic cookie, and converting the result to network byte order. If the IP address family is IPv6, X-Address is computed by taking the mapped IP address in host byte order, XOR'ing it with the concatenation of the magic cookie and the 96-bit transaction ID, and converting the result to network byte order.
X端口的计算方法是以主机字节顺序获取映射端口，将其与魔法cookie的最高有效16位异或，然后将结果转换为网络字节顺序。如果IP地址族是IPv4，则X-address的计算方法是按主机字节顺序获取映射的IP地址，用魔法cookie对其进行异或运算，然后将结果转换为网络字节顺序。如果IP地址族是IPv6，则X地址的计算方法是按主机字节顺序获取映射的IP地址，将其与magic cookie和96位事务ID的串联进行异或运算，然后将结果转换为网络字节顺序。
The rules for encoding and processing the first 8 bits of the attribute's value, the rules for handling multiple occurrences of the attribute, and the rules for processing address families are the same as for MAPPED-ADDRESS.
编码和处理属性值的前8位的规则、处理属性多次出现的规则以及处理地址族的规则与映射地址的规则相同。
Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding of the transport address. The former encodes the transport address by exclusive-or'ing it with the magic cookie. The latter encodes it directly in binary. RFC 3489 originally specified only MAPPED-ADDRESS. However, deployment experience found that some NATs rewrite the 32-bit binary payloads containing the NAT's public IP address, such as STUN's MAPPED-ADDRESS attribute, in the well-meaning but misguided attempt at providing a generic ALG function. Such behavior interferes with the operation of STUN and also causes failure of STUN's message-integrity checking.
注意：XOR-MAPPED-ADDRESS和MAPPED-ADDRESS仅在传输地址的编码上有所不同。前者通过使用魔法cookie对传输地址进行异或编码。后者直接用二进制编码。RFC 3489最初仅指定了映射地址。然而，部署经验发现，一些NAT重写了包含NAT公共IP地址的32位二进制有效负载，如STUN的MAPPED-address属性，这是一种善意但误导的尝试，试图提供通用ALG功能。这种行为会干扰STUN的操作，也会导致STUN的消息完整性检查失败。
The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check.
USERNAME属性用于消息完整性。它标识消息完整性检查中使用的用户名和密码组合。
The value of USERNAME is a variable-length value. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST have been processed using SASLprep [RFC4013].
用户名的值是一个可变长度的值。它必须包含少于513字节的UTF-8[RFC3629]编码序列，并且必须使用SASLprep[RFC4013]进行处理。
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY attribute can be present in any STUN message type. Since it uses the SHA1 hash, the HMAC will be 20 bytes. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY.
MESSAGE-INTEGRITY属性包含STUN消息的HMAC-SHA1[RFC2104]。MESSAGE-INTEGRITY属性可以出现在任何STUN消息类型中。由于它使用SHA1散列，HMAC将是20个字节。用作HMAC输入的文本是STUN消息，包括标题，最多包括message-INTEGRITY属性前面的属性。除了出现在消息完整性之后的指纹属性外，代理必须忽略消息完整性之后的所有其他属性。
The key for the HMAC depends on whether long-term or short-term credentials are in use. For long-term credentials, the key is 16 bytes:
HMAC的关键取决于使用的是长期凭证还是短期凭证。对于长期凭据，密钥为16字节：
key = MD5(username ":" realm ":" SASLprep(password))
key = MD5(username ":" realm ":" SASLprep(password))
That is, the 16-byte key is formed by taking the MD5 hash of the result of concatenating the following five fields: (1) the username, with any quotes and trailing nulls removed, as taken from the USERNAME attribute (in which case SASLprep has already been applied); (2) a single colon; (3) the realm, with any quotes and trailing nulls removed; (4) a single colon; and (5) the password, with any trailing nulls removed and after processing using SASLprep. For example, if the username was 'user', the realm was 'realm', and the password was 'pass', then the 16-byte HMAC key would be the result of performing an MD5 hash on the string 'user:realm:pass', the resulting hash being 0x8493fbc53ba582fb4c044c456bdc40eb.
也就是说，16字节的密钥是通过采用以下五个字段连接结果的MD5散列来形成的：（1）从username属性（在这种情况下，已经应用了SASLprep）中删除了任何引号和尾随空的username；（2） 单个结肠；（3） 领域，删除任何引号和尾随空；（4） 单个结肠；以及（5）密码，删除任何尾随的空值，并在使用SASLprep进行处理之后。例如，如果用户名为“user”，域为“realm”，密码为“pass”，则16字节的HMAC密钥将是对字符串“user:realm:pass”执行MD5哈希的结果，结果哈希为0x8493FBC53BA582FB4C04C456BDC40EB。
For short-term credentials:
短期证书：
key = SASLprep(password)
key=SASLprep（密码）
where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined in RFC 4013 [RFC4013].
其中，MD5在RFC 1321[RFC1321]中定义，SASLprep（）在RFC 4013[RFC4013]中定义。
The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP. Typically, SIP systems utilizing SIP's digest authentication mechanism do not actually store the password in the database. Rather, they store a value called H(A1), which is equal to the key defined above.
当与长期凭证一起使用时，密钥的结构有助于在同样使用SIP的系统中部署。通常，使用SIP摘要身份验证机制的SIP系统实际上不会将密码存储在数据库中。相反，它们存储一个名为H（A1）的值，该值等于上面定义的键。
Based on the rules above, the hash used to construct MESSAGE-INTEGRITY includes the length field from the STUN message header. Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content). The length MUST then be set to point to the length of the message up to, and including, the MESSAGE-INTEGRITY attribute itself, but excluding any attributes after it. Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the length in the STUN header can be set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY.
根据上述规则，用于构造消息完整性的哈希包含来自STUN消息头的长度字段。在执行哈希之前，必须将MESSAGE-INTEGRITY属性插入到消息中（使用虚拟内容）。然后，必须将长度设置为指向消息的长度，该长度不超过（包括）消息完整性属性本身，但不包括其后的任何属性。一旦执行了计算，就可以填写MESSAGE-INTEGRITY属性的值，并且可以将STUN头中的长度值设置为正确的值——整个消息的长度。类似地，在验证消息完整性时，在计算HMAC之前，应将长度字段调整为指向消息完整性属性的末尾。当属性（如指纹）出现在消息完整性之后时，这种调整是必要的。
The FINGERPRINT attribute MAY be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e (the XOR helps in cases where an application packet is also using CRC-32 in it). The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which has a generator polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. When present, the FINGERPRINT attribute MUST be the last attribute in the message, and thus will appear after MESSAGE-INTEGRITY.
指纹属性可能出现在所有昏迷消息中。属性值计算为STUN消息的CRC-32，最多（但不包括）指纹属性本身，与32位值0x5354554e异或（在应用程序数据包中也使用CRC-32的情况下，异或有帮助）。32位CRC是ITU V.42[ITU.V42.2002]中定义的CRC，其生成器多项式为x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1。当存在时，指纹属性必须是消息中的最后一个属性，因此将在消息完整性之后出现。
The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 8.
指纹属性可以帮助区分STUN数据包与其他协议的数据包。见第8节。
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute covers the length field from the STUN message header. Therefore, this value must be correct and include the CRC attribute as part of the message length, prior to computation of the CRC. When using the FINGERPRINT attribute in a message, the attribute is first placed into the message with a dummy value, then the CRC is computed, and then the value of the attribute is updated. If the MESSAGE-INTEGRITY attribute is also present, then it must be present with the correct message-integrity value before the CRC is computed, since the CRC is done over the value of the MESSAGE-INTEGRITY attribute as well.
与消息完整性一样，指纹属性中使用的CRC覆盖STUN消息头中的长度字段。因此，在计算CRC之前，该值必须是正确的，并且包含CRC属性作为消息长度的一部分。在消息中使用指纹属性时，首先将该属性与伪值一起放入消息中，然后计算CRC，然后更新该属性的值。如果消息完整性属性也存在，则在计算CRC之前，它必须具有正确的消息完整性值，因为CRC也是在消息完整性属性的值上进行的。
The ERROR-CODE attribute is used in error response messages. It contains a numeric error code value in the range of 300 to 699 plus a textual reason phrase encoded in UTF-8 [RFC3629], and is consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The reason phrase is meant for user consumption, and can be anything appropriate for the error code. Recommended reason phrases for the defined error codes are included in the IANA registry for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
错误代码属性用于错误响应消息中。它包含一个介于300到699之间的数字错误代码值，外加一个以UTF-8[RFC3629]编码的文本原因短语，其代码分配和语义与SIP[RFC3261]和HTTP[RFC2616]一致。原因短语用于用户消费，可以是任何适合错误代码的内容。已定义错误代码的推荐原因短语包含在IANA错误代码注册表中。原因短语必须是UTF-8[RFC3629]编码的序列，长度小于128个字符（可以长达763个字节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ERROR-CODE Attribute
图7：错误代码属性
To facilitate processing, the class of the error code (the hundreds digit) is encoded separately from the rest of the code, as shown in Figure 7.
为了便于处理，错误代码的类别（数百位）与代码的其余部分分开编码，如图7所示。
The Reserved bits SHOULD be 0, and are for alignment on 32-bit boundaries. Receivers MUST ignore these bits. The Class represents the hundreds digit of the error code. The value MUST be between 3 and 6. The Number represents the error code modulo 100, and its value MUST be between 0 and 99.
保留位应为0，用于在32位边界上对齐。接收器必须忽略这些位。该类表示错误代码的数百位数字。该值必须介于3和6之间。该数字表示模为100的错误代码，其值必须介于0和99之间。
The following error codes, along with their recommended reason phrases, are defined:
定义了以下错误代码及其建议的原因短语：
300 Try Alternate: The client should contact an alternate server for this request. This error response MUST only be sent if the request included a USERNAME attribute and a valid MESSAGE-INTEGRITY attribute; otherwise, it MUST NOT be sent and error code 400 (Bad Request) is suggested. This error response MUST be protected with the MESSAGE-INTEGRITY attribute, and receivers MUST validate the MESSAGE-INTEGRITY of this response before redirecting themselves to an alternate server.
300 Try Alternate：客户端应为此请求联系备用服务器。只有当请求包含用户名属性和有效的消息完整性属性时，才能发送此错误响应；否则，不得发送该请求，并建议发送错误代码400（错误请求）。必须使用MESSAGE-INTEGRITY属性保护此错误响应，并且接收方必须在将自己重定向到备用服务器之前验证此响应的MESSAGE-INTEGRITY。
Note: Failure to generate and validate message integrity for a 300 response allows an on-path attacker to falsify a 300 response thus causing subsequent STUN messages to be sent to a victim.
注意：如果无法生成和验证300响应的消息完整性，路径上的攻击者可以伪造300响应，从而导致后续的昏迷消息发送给受害者。
400 Bad Request: The request was malformed. The client SHOULD NOT retry the request without modification from the previous attempt. The server may not be able to generate a valid MESSAGE-INTEGRITY for this error, so the client MUST NOT expect a valid MESSAGE-INTEGRITY attribute on this response.
400错误请求：请求格式不正确。如果未对上一次尝试进行修改，客户端不应重试该请求。服务器可能无法为此错误生成有效的消息完整性，因此客户端不能期望此响应具有有效的消息完整性属性。
401 Unauthorized: The request did not contain the correct credentials to proceed. The client should retry the request with proper credentials.
401未授权：请求未包含正确的凭据以继续。客户端应使用正确的凭据重试请求。
420 Unknown Attribute: The server received a STUN packet containing a comprehension-required attribute that it did not understand. The server MUST put this unknown attribute in the UNKNOWN-ATTRIBUTE attribute of its error response.
420未知属性：服务器收到一个STUN数据包，其中包含一个它不理解的需要理解的属性。服务器必须将此未知属性放入其错误响应的unknown-attribute属性中。
438 Stale Nonce: The NONCE used by the client was no longer valid. The client should retry, using the NONCE provided in the response.
438 Stale Nonce:客户端使用的Nonce不再有效。客户端应使用响应中提供的NONCE重试。
500 Server Error: The server has suffered a temporary error. The client should try again.
500服务器错误：服务器遇到临时错误。客户端应重试。
The REALM attribute may be present in requests and responses. It contains text that meets the grammar for "realm-value" as described in RFC 3261 [RFC3261] but without the double quotes and their surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes), and MUST have been processed using SASLprep [RFC4013].
REALM属性可能存在于请求和响应中。它包含符合RFC 3261[RFC3261]中描述的“领域值”语法的文本，但没有双引号及其周围的空白。也就是说，它是一个不带引号的领域值（因此是一个qdtext序列或带引号的对）。它必须是少于128个字符的UTF-8[RFC3629]编码序列（长度可达763字节），并且必须使用SASLprep[RFC4013]进行处理。
Presence of the REALM attribute in a request indicates that long-term credentials are being used for authentication. Presence in certain error responses indicates that the server wishes the client to use a long-term credential for authentication.
请求中存在REALM属性表示正在使用长期凭据进行身份验证。出现某些错误响应表示服务器希望客户端使用长期凭据进行身份验证。
The NONCE attribute may be present in requests and responses. It contains a sequence of qdtext or quoted-pair, which are defined in RFC 3261 [RFC3261]. Note that this means that the NONCE attribute will not contain actual quote characters. See RFC 2617 [RFC2617], Section 4.3, for guidance on selection of nonce values in a server.
NONCE属性可能存在于请求和响应中。它包含RFC 3261[RFC3261]中定义的qdtext或quoted对序列。请注意，这意味着NONCE属性将不包含实际的引号字符。参见RFC 2617[RFC2617]，第4.3节，了解服务器中nonce值的选择指南。
It MUST be less than 128 characters (which can be as long as 763 bytes).
它必须少于128个字符（最长可达763字节）。
The UNKNOWN-ATTRIBUTES attribute is present only in an error response when the response code in the ERROR-CODE attribute is 420.
当错误代码属性中的响应代码为420时，未知属性仅出现在错误响应中。
The attribute contains a list of 16-bit values, each of which represents an attribute type that was not understood by the server.
该属性包含一个16位值的列表，每个值表示服务器无法理解的属性类型。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of UNKNOWN-ATTRIBUTES Attribute
图8：未知属性的格式
Note: In [RFC3489], this field was padded to 32 by duplicating the last attribute. In this version of the specification, the normal padding rules for attributes are used instead.
注意：在[RFC3489]中，通过复制最后一个属性将此字段填充为32。在此版本的规范中，使用了属性的常规填充规则。
The SOFTWARE attribute contains a textual description of the software being used by the agent sending the message. It is used by clients and servers. Its value SHOULD include manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
“软件”属性包含发送消息的代理正在使用的软件的文本描述。它由客户端和服务器使用。其值应包括制造商和版本号。该属性对协议的操作没有影响，仅用作诊断和调试工具。软件的价值是可变长度的。它必须是一个UTF-8[RFC3629]编码的序列，长度小于128个字符（可长达763字节）。
The alternate server represents an alternate transport address identifying a different STUN server that the STUN client should try.
备用服务器表示备用传输地址，该地址标识STUN客户端应尝试的其他STUN服务器。
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a single server by IP address. The IP address family MUST be identical to that of the source IP address of the request.
它的编码方式与映射地址相同，因此通过IP地址引用单个服务器。IP地址系列必须与请求的源IP地址系列相同。
An attacker can try to modify STUN messages in transit, in order to cause a failure in STUN operation. These attacks are detected for both requests and responses through the message-integrity mechanism, using either a short-term or long-term credential. Of course, once detected, the manipulated packets will be dropped, causing the STUN transaction to effectively fail. This attack is possible only by an on-path attacker.
攻击者可以尝试修改传输中的STUN消息，以导致STUN操作失败。通过消息完整性机制（使用短期或长期凭据）检测请求和响应的这些攻击。当然，一旦检测到，被操纵的数据包将被丢弃，从而导致STUN事务实际上失败。只有路径上的攻击者才能进行此攻击。
An attacker that can observe, but not modify, STUN messages in-transit (for example, an attacker present on a shared access medium, such as Wi-Fi), can see a STUN request, and then immediately send a STUN response, typically an error response, in order to disrupt STUN processing. This attack is also prevented for messages that utilize MESSAGE-INTEGRITY. However, some error responses, those related to authentication in particular, cannot be protected by MESSAGE-INTEGRITY. When STUN itself is run over a secure transport protocol (e.g., TLS), these attacks are completely mitigated.
能够观察但不能修改传输中的STUN消息的攻击者（例如，共享访问介质（如Wi-Fi）上的攻击者）可以看到STUN请求，然后立即发送STUN响应，通常是错误响应，以中断STUN处理。对于利用消息完整性的消息，也可以防止此攻击。但是，某些错误响应，特别是与身份验证相关的错误响应，不能受到消息完整性的保护。当STUN本身通过安全传输协议（如TLS）运行时，这些攻击会得到完全缓解。
Depending on the STUN usage, these attacks may be of minimal consequence and thus do not require message integrity to mitigate. For example, when STUN is used to a basic STUN server to discover a server reflexive candidate for usage with ICE, authentication and message integrity are not required since these attacks are detected during the connectivity check phase. The connectivity checks themselves, however, require protection for proper operation of ICE overall. As described in Section 14, STUN usages describe when authentication and message integrity are needed.
根据STUN的使用情况，这些攻击的后果可能最小，因此不需要消息完整性来缓解。例如，当将STUN用于基本STUN服务器以发现服务器自反候选以用于ICE时，不需要身份验证和消息完整性，因为这些攻击是在连接检查阶段检测到的。然而，连接检查本身需要保护，以确保ICE的正常运行。如第14节所述，STUN用法描述了何时需要身份验证和消息完整性。
Since STUN uses the HMAC of a shared secret for authentication and integrity protection, it is subject to offline dictionary attacks. When authentication is utilized, it SHOULD be with a strong password that is not readily subject to offline dictionary attacks. Protection of the channel itself, using TLS, mitigates these attacks. However, STUN is most often run over UDP and in those cases, strong passwords are the only way to protect against these attacks.
由于STUN使用共享秘密的HMAC进行身份验证和完整性保护，因此它会受到脱机字典攻击。使用身份验证时，应使用不易受到脱机字典攻击的强密码。使用TLS保护通道本身可以减轻这些攻击。但是，STUN通常通过UDP运行，在这些情况下，强密码是防止这些攻击的唯一方法。
A rogue client may try to launch a DoS attack against a server by sending it a large number of STUN requests. Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch.
恶意客户端可能会通过向服务器发送大量STUN请求，试图对其发起DoS攻击。幸运的是，服务器可以无状态处理STUN请求，这使得此类攻击很难启动。
A rogue client may use a STUN server as a reflector, sending it requests with a falsified source IP address and port. In such a case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. This attack is mitigated by ingress source address filtering.
流氓客户端可能使用STUN服务器作为反射器，使用伪造的源IP地址和端口向其发送请求。在这种情况下，响应将传递到该源IP和端口。这种攻击不会增加数据包的数量（STUN服务器为客户端发送的每个数据包发送一个数据包），尽管数据量略有增加，因为STUN响应通常大于请求。此攻击通过入口源地址过滤得到缓解。
Revealing the specific software version of the agent through the SOFTWARE attribute might allow them to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option.
通过“软件”属性显示代理的特定软件版本可能会使它们更容易受到针对已知包含安全漏洞的软件的攻击。实现者应该将软件属性的使用作为一个可配置的选项。
This section lists attacks that might be launched against a usage of STUN. Each STUN usage must consider whether these attacks are applicable to it, and if so, discuss counter-measures.
本节列出了可能针对使用眩晕而发起的攻击。每个STUN使用必须考虑这些攻击是否适用于它，如果是的话，讨论对抗措施。
Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by a STUN client through a
本节中的大多数攻击都是围绕攻击者修改STUN客户端通过
Binding request/response transaction. Since the usage of the reflexive address is a function of the usage, the applicability and remediation of these attacks are usage-specific. In common situations, modification of the reflexive address by an on-path attacker is easy to do. Consider, for example, the common situation where STUN is run directly over UDP. In this case, an on-path attacker can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client, and send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can direct it back towards the client. Protecting against this attack by using a message-integrity check is impossible, since a message-integrity value cannot cover the source IP address, since the intervening NAT must be able to modify this value. Instead, one solution to preventing the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [MMUSIC-ICE]. Other usages may use other means to prevent these attacks.
绑定请求/响应事务。由于自反地址的使用是使用的函数，因此这些攻击的适用性和修复是特定于使用的。在常见情况下，路径上攻击者很容易修改自反地址。例如，考虑STUN直接在UDP上运行的常见情况。在这种情况下，路径上攻击者可以在绑定请求到达STUN服务器之前修改其源IP地址。然后，STUN服务器将XOR-MAPPED-address属性中的该IP地址返回给客户端，并将响应发送回该（伪造的）IP地址和端口。如果攻击者也可以拦截此响应，则可以将其定向回客户端。由于消息完整性值不能覆盖源IP地址，因为介入NAT必须能够修改此值，因此不可能通过使用消息完整性检查来防止此攻击。相反，防止下面列出的攻击的一个解决方案是让客户端验证所学到的自反地址，就像在ICE[MMUSIC-ICE]中所做的那样。其他用途可能使用其他方法来防止这些攻击。
In this attack, the attacker provides one or more clients with the same faked reflexive address that points to the intended target. This will trick the STUN clients into thinking that their reflexive addresses are equal to that of the target. If the clients hand out that reflexive address in order to receive traffic on it (for example, in SIP messages), the traffic will instead be sent to the target. This attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications. However, it can only be launched against targets for which packets from the STUN server to the target pass through the attacker, limiting the cases in which it is possible.
在此攻击中，攻击者向一个或多个客户端提供指向目标的伪造反射地址。这将诱使昏迷客户认为他们的自反地址等于目标地址。如果客户机发送该自反地址以接收其上的流量（例如，在SIP消息中），则该流量将被发送到目标。此攻击可提供大量放大，尤其是与使用STUN启用多媒体应用程序的客户端一起使用时。但是，它只能针对从STUN服务器发送到目标的数据包通过攻击者的目标启动，从而限制了可能的情况。
In this attack, the attacker provides a STUN client with a faked reflexive address. The reflexive address it provides is a transport address that routes to nowhere. As a result, the client won't receive any of the packets it expects to receive when it hands out the reflexive address. This exploitation is not very interesting for the attacker. It impacts a single client, which is frequently not the desired target. Moreover, any attacker that can mount the attack could also deny service to the client by other means, such as preventing the client from receiving any response from the STUN server, or even a DHCP server. As with the attack in Section 16.2.1, this attack is only possible when the attacker is on path for packets sent from the STUN server towards this unused IP address.
在此攻击中，攻击者向Stunk客户端提供伪造的反射地址。它提供的自反地址是一个无处路由的传输地址。因此，当客户端发出自反地址时，它将不会接收到它期望接收的任何数据包。攻击者对此攻击不感兴趣。它影响单个客户机，而这通常不是期望的目标。此外，任何能够发起攻击的攻击者也可以通过其他方式拒绝向客户端提供服务，例如阻止客户端接收来自STUN服务器甚至DHCP服务器的任何响应。与第16.2.1节中的攻击一样，只有当攻击者处于从STUN服务器向该未使用IP地址发送数据包的路径上时，才可能进行此攻击。
This attack is similar to attack II. However, the faked reflexive address points to the attacker itself. This allows the attacker to receive traffic that was destined for the client.
此攻击类似于攻击II。但是，伪造的自反地址指向攻击者本身。这使攻击者能够接收发送给客户端的通信量。
In this attack, the attacker forces the client to use a reflexive address that routes to itself. It then forwards any packets it receives to the client. This attack would allow the attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, as a result, only useful for observing traffic by attackers on the path from the client to the STUN server, but not generally on the path of packets being routed towards the client.
在此攻击中，攻击者强制客户端使用路由到自身的自反地址。然后，它将接收到的任何数据包转发给客户端。此攻击将允许攻击者观察发送到客户端的所有数据包。但是，为了发起攻击，攻击者必须已经能够观察到从客户端到STUN服务器的数据包。在大多数情况下（例如从访问网络发起攻击），这意味着攻击者可能已经观察到发送到客户端的数据包。因此，这种攻击只在攻击者观察从客户端到STUN服务器的路径上的流量时有用，但通常不在路由到客户端的数据包路径上有用。
This specification uses HMAC-SHA-1 for computation of the message integrity. If, at a later time, HMAC-SHA-1 is found to be compromised, the following is the remedy that will be applied.
本规范使用HMAC-SHA-1计算消息完整性。如果以后发现HMAC-SHA-1受损，将采取以下补救措施。
We will define a STUN extension that introduces a new message-integrity attribute, computed using a new hash. Clients would be required to include both the new and old message-integrity attributes in their requests or indications. A new server will utilize the new message-integrity attribute, and an old one, the old. After a transition period where mixed implementations are in deployment, the old message-integrity attribute will be deprecated by another specification, and clients will cease including it in requests.
我们将定义一个STUN扩展，它引入了一个新的消息完整性属性，该属性使用新的散列计算。客户机需要在其请求或指示中同时包含新的和旧的消息完整性属性。新服务器将使用新的消息完整性属性，旧服务器将使用旧的消息完整性属性。在部署混合实现的过渡期之后，旧的消息完整性属性将被另一个规范弃用，客户端将停止在请求中包含它。
It is also important to note that the HMAC is done using a key that is itself computed using an MD5 of the user's password. The choice of the MD5 hash was made because of the existence of legacy databases that store passwords in that form. If future work finds that an HMAC of an MD5 input is not secure, and a different hash is needed, it can also be changed using this plan. However, this would require administrators to repopulate their databases.
还需要注意的是，HMAC是使用一个密钥完成的，该密钥本身是使用用户密码的MD5计算的。之所以选择MD5哈希，是因为存在以这种形式存储密码的遗留数据库。如果将来的工作发现MD5输入的HMAC不安全，并且需要不同的哈希，也可以使用此计划更改它。但是，这需要管理员重新填充其数据库。
The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT
IAB研究了单边自地址固定（UNSAF）问题，这是客户端试图在NAT另一端的另一个域中确定其地址的一般过程
through a collaborative protocol reflection mechanism (RFC3424 [RFC3424]). STUN can be used to perform this function using a Binding request/response transaction if one agent is behind a NAT and the other is on the public side of the NAT.
通过协作协议反射机制（RFC3424[RFC3424]）。如果一个代理位于NAT后面，另一个位于NAT的公共端，则可以使用绑定请求/响应事务来执行此功能。
The IAB has mandated that protocols developed for this purpose document a specific set of considerations. Because some STUN usages provide UNSAF functions (such as ICE [MMUSIC-ICE] ), and others do not (such as SIP Outbound [SIP-OUTBOUND]), answers to these considerations need to be addressed by the usages themselves.
IAB已授权为此目的制定的协议记录一组特定的注意事项。由于一些STUN用法提供UNSAF功能（如ICE[MMUSIC-ICE]），而其他用法则不提供（如SIP出站[SIP-Outbound]），因此这些注意事项的答案需要由用法本身解决。
IANA has created three new registries: a "STUN Methods Registry", a "STUN Attributes Registry", and a "STUN Error Codes Registry". IANA has also changed the name of the assigned IANA port for STUN from "nat-stun-port" to "stun".
IANA创建了三个新的注册表：一个“STUN方法注册表”、“STUN属性注册表”和一个“STUN错误代码注册表”。IANA还将为STUN分配的IANA端口的名称从“nat STUN端口”更改为“STUN”。
A STUN method is a hex number in the range 0x000 - 0xFFF. The encoding of STUN method into a STUN message is described in Section 6.
STUN方法是0x000-0xFFF范围内的十六进制数。第6节描述了将STUN方法编码为STUN消息的过程。
The initial STUN methods are:
最初的眩晕方法是：
0x000: (Reserved) 0x001: Binding 0x002: (Reserved; was SharedSecret)
0x000：（保留）0x001:绑定0x002:（保留；是共享机密）
STUN methods in the range 0x000 - 0x7FF are assigned by IETF Review [RFC5226]. STUN methods in the range 0x800 - 0xFFF are assigned by Designated Expert [RFC5226]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
0x000-0x7FF范围内的STUN方法由IETF评审[RFC5226]分配。0x800-0xFFF范围内的STUN方法由指定专家指定[RFC5226]。专家的责任是验证所选的代码点是否未被使用，以及请求的代码点数量是否异常多。延期本身的技术审查不属于指定专家的责任范围。
A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF. STUN attribute types in the range 0x0000 - 0x7FFF are considered comprehension-required; STUN attribute types in the range 0x8000 - 0xFFFF are considered comprehension-optional. A STUN agent handles unknown comprehension-required and comprehension-optional attributes differently.
眩晕属性类型是0x0000-0xFFFF范围内的十六进制数。0x0000-0x7FFF范围内的眩晕属性类型被认为是必需的；0x8000-0xFFFF范围内的眩晕属性类型视为可选。STUN代理以不同的方式处理未知的“必需理解”和“可选理解”属性。
The initial STUN Attributes types are:
初始眩晕属性类型为：
Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved)
0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-ADDRESS)
0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME
0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM
0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS
Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved)
0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-ADDRESS)
0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME
0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM
0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT
理解可选范围（0x8000-0xFFFF）0x8022:软件0x8023:备用服务器0x8028:指纹
STUN Attribute types in the first half of the comprehension-required range (0x0000 - 0x3FFF) and in the first half of the comprehension-optional range (0x8000 - 0xBFFF) are assigned by IETF Review [RFC5226]. STUN Attribute types in the second half of the comprehension-required range (0x4000 - 0x7FFF) and in the second half of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by Designated Expert [RFC5226]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use, and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
IETF Review[RFC5226]分配理解要求范围（0x0000-0x3FFF）前半部分和理解可选范围（0x8000-0xBFFF）前半部分的眩晕属性类型。指定专家[RFC5226]指定理解要求范围（0x4000-0x7FFF）后半部分和理解可选范围（0xC000-0xFFFF）后半部分的眩晕属性类型。专家的责任是验证所选的代码点未在使用中，并且请求的代码点数量不是异常多。延期本身的技术审查不属于指定专家的责任范围。
A STUN error code is a number in the range 0 - 699. STUN error codes are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is intended only for human consumption and can be anything appropriate; this document proposes only suggested values.
眩晕错误代码是一个范围在0-699之间的数字。STUN错误代码在UTF-8[RFC3629]中附有一个文本原因短语，该短语仅用于人类消费，可以是任何合适的词语；本文件仅提出建议值。
STUN error codes are consistent in codepoint assignments and semantics with SIP [RFC3261] and HTTP [RFC2616].
STUN错误代码在代码点分配和语义上与SIP[RFC3261]和HTTP[RFC2616]一致。
The initial values in this registry are given in Section 15.6.
第15.6节给出了该注册表中的初始值。
New STUN error codes are assigned based on IETF Review [RFC5226]. The specification must carefully consider how clients that do not understand this error code will process it before granting the request. See the rules in Section 7.3.4.
根据IETF审查[RFC5226]分配新的STUN错误代码。规范必须仔细考虑不理解此错误代码的客户端在授予请求之前将如何处理该错误代码。参见第7.3.4节中的规则。
IANA has previously assigned port 3478 for STUN. This port appears in the IANA registry under the moniker "nat-stun-port". In order to align the DNS SRV procedures with the registered protocol service, IANA is requested to change the name of protocol assigned to port 3478 from "nat-stun-port" to "stun", and the textual name from "Simple Traversal of UDP Through NAT (STUN)" to "Session Traversal Utilities for NAT", so that the IANA port registry would read:
IANA之前为STUN分配了3478端口。此端口出现在IANA注册表中的名字“nat stun端口”下。为了使DNS SRV过程与注册的协议服务保持一致，请求IANA将分配给端口3478的协议名称从“nat stun port”更改为“stun”，并将文本名称从“通过nat简单遍历UDP（stun）”更改为“nat会话遍历实用程序”，以便IANA端口注册表将显示：
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
用于NAT（stun）端口的stun 3478/tcp会话遍历实用程序用于NAT（stun）端口的stun 3478/udp会话遍历实用程序
In addition, IANA has assigned port number 5349 for the "stuns" service, defined over TCP and UDP. The UDP port is not currently defined; however, it is reserved for future use.
此外，IANA还为通过TCP和UDP定义的“stuns”服务分配了端口号5349。UDP端口当前未定义；但是，它是为将来使用而保留的。
This specification obsoletes RFC 3489 [RFC3489]. This specification differs from RFC 3489 in the following ways:
本规范淘汰了RFC 3489[RFC3489]。本规范与RFC 3489的不同之处如下：
o Removed the notion that STUN is a complete NAT traversal solution. STUN is now a tool that can be used to produce a NAT traversal solution. As a consequence, changed the name of the protocol to Session Traversal Utilities for NAT.
o 删除了STUN是一个完整的NAT遍历解决方案的概念。STUN现在是一个工具，可用于生成NAT遍历解决方案。因此，将协议的名称更改为NAT的会话遍历实用程序。
o Introduced the concept of STUN usages, and described what a usage of STUN must document.
o 介绍了STUN用法的概念，并描述了STUN的用法必须记录的内容。
o Removed the usage of STUN for NAT type detection and binding lifetime discovery. These techniques have proven overly brittle due to wider variations in the types of NAT devices than described in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST, SOURCE-ADDRESS, and REFLECTED-FROM attributes.
o 删除了STUN用于NAT类型检测和绑定生存期发现的用法。这些技术已被证明过于脆弱，因为NAT设备类型的变化比本文中描述的更大。删除了RESPONSE-ADDRESS、CHANGE-ADDRESS、CHANGE-REQUEST、SOURCE-ADDRESS和REFLECTED-FROM属性。
o Added a fixed 32-bit magic cookie and reduced length of transaction ID by 32 bits. The magic cookie begins at the same offset as the original transaction ID.
o 添加了一个固定的32位魔法cookie，并将事务ID的长度减少了32位。魔法cookie从与原始事务ID相同的偏移量开始。
o Added the XOR-MAPPED-ADDRESS attribute, which is included in Binding responses if the magic cookie is present in the request. Otherwise, the RFC 3489 behavior is retained (that is, Binding response includes MAPPED-ADDRESS). See discussion in XOR-MAPPED-ADDRESS regarding this change.
o 添加了XOR-MAPPED-ADDRESS属性，如果请求中存在魔法cookie，则该属性将包含在绑定响应中。否则，RFC3489行为将被保留（即，绑定响应包括MAPPED-ADDRESS）。请参阅XOR-MAPPED-ADDRESS中有关此更改的讨论。
o Introduced formal structure into the message type header field, with an explicit pair of bits for indication of request, response, error response, or indication. Consequently, the message type field is split into the class (one of the previous four) and method.
o 在消息类型头字段中引入正式结构，带有一对显式位，用于指示请求、响应、错误响应或指示。因此，消息类型字段被分为类（前四个类之一）和方法。
o Explicitly point out that the most significant 2 bits of STUN are 0b00, allowing easy differentiation with RTP packets when used with ICE.
o 明确指出，STUN的最高有效2位是0b00，当与ICE一起使用时，可以轻松区分RTP数据包。
o Added the FINGERPRINT attribute to provide a method of definitely detecting the difference between STUN and another protocol when the two protocols are multiplexed together.
o 添加了指纹属性，以提供一种方法，当两个协议复用在一起时，可以明确检测STUN和另一个协议之间的差异。
o Added support for IPv6. Made it clear that an IPv4 client could get a v6 mapped address, and vice versa.
o 增加了对IPv6的支持。明确了IPv4客户端可以获得v6映射地址，反之亦然。
o Added long-term-credential-based authentication.
o 添加了基于凭据的长期身份验证。
o Added the SOFTWARE, REALM, NONCE, and ALTERNATE-SERVER attributes.
o 添加了软件、领域、NONCE和备用服务器属性。
o Removed the SharedSecret method, and thus the PASSWORD attribute. This method was almost never implemented and is not needed with current usages.
o 删除了SharedSecret方法，从而删除了PASSWORD属性。这种方法几乎从未实现过，在当前的使用中也不需要。
o Removed recommendation to continue listening for STUN responses for 10 seconds in an attempt to recognize an attack.
o 删除了继续聆听昏迷反应10秒以试图识别攻击的建议。
o Changed transaction timers to be more TCP friendly.
o 将事务计时器更改为更加TCP友好。
o Removed the STUN example that centered around the separation of the control and media planes. Instead, provided more information on using STUN with protocols.
o 删除了以控制平面和媒体平面分离为中心的晕眩示例。相反，提供了更多关于将STUN与协议一起使用的信息。
o Defined a generic padding mechanism that changes the interpretation of the length attribute. This would, in theory, break backwards compatibility. However, the mechanism in RFC 3489 never worked for the few attributes that weren't aligned naturally on 32-bit boundaries.
o 定义了更改“长度”属性解释的通用填充机制。从理论上讲，这将破坏向后兼容性。然而，RFC 3489中的机制从未适用于在32位边界上不自然对齐的少数属性。
o REALM, SERVER, reason phrases, and NONCE limited to 127 characters. USERNAME to 513 bytes.
o 领域、服务器、原因短语和NONCE限制为127个字符。用户名为513字节。
o Changed the DNS SRV procedures for TCP and TLS. UDP remains the same as before.
o 更改了TCP和TLS的DNS SRV过程。UDP与以前一样。
Christian Huitema and Joel Weinberger were original co-authors of RFC 3489.
Christian Huitema和Joel Weinberger是RFC 3489的最初合著者。
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for their comments, and Baruch Sterman and Alan Hawrylyshen for initial implementations. Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input on this work.
作者要感谢塞德里克·奥恩、皮特·科德尔、卡伦·詹宁斯、鲍勃·彭菲尔德、泽维尔·马约、马格纳斯·韦斯特隆德、米格尔·加西亚、布鲁斯·洛坎普和克里斯·沙利文的评论，以及巴鲁克·斯特曼和艾伦·霍利森的初步实施。感谢Leslie Daigle、Allison Mankin、Eric Rescorla和Henning Schulzrinne对这项工作的IESG和IAB投入。
[ITU.V42.2002] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, March 2002.
[ITU.V42.2002]国际电信联盟，“使用异步到同步转换的DCE纠错程序”，ITU-T建议V.42，2002年3月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[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月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[BEHAVE-NAT] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using STUN", Work in Progress, July 2008.
[BEHAVE-NAT]MacDonald，D.和B.Lowekamp，“使用STUN进行NAT行为发现”，正在进行的工作，2008年7月。
[BEHAVE-TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008.
[BEHAVE-TURN]Rosenberg，J.，Mahy，R.，和P.Matthews，“使用NAT周围的中继进行遍历（TURN）：NAT会话遍历实用程序的中继扩展（STUN）”，正在进行的工作，2008年7月。
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 1987, August 1987.
[KARN87]Karn，P.和C.Partridge，“改进可靠传输协议中的往返时间估计”，SIGCOMM 1987，1987年8月。
[MMUSIC-ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[MMUSIC-ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，正在进行的工作，2007年10月。
[MMUSIC-ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2008.
[MMUSIC-ICE-TCP]Rosenberg，J.，“具有交互式连接建立（ICE）的TCP候选者”，正在进行的工作，2008年7月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[SIP-OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, June 2008.
[SIP-OUTBOUND]Jennings，C.和R.Mahy，“在会话启动协议（SIP）中管理客户端启动的连接”，正在进行的工作，2008年6月。
Given a 16-bit STUN message type value in host byte order in msg_type parameter, below are C macros to determine the STUN message types:
在msg_type参数中，给定主机字节顺序的16位STUN消息类型值，下面是确定STUN消息类型的C宏：
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Edison, NJ US
Jonathan Rosenberg Cisco Edison，美国新泽西州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rohan Mahy Unaffiliated
Rohan Mahy非附属公司
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Philip Matthews Unaffiliated
菲利普·马修斯无关联
EMail: philip_matthews@magma.ca
EMail: philip_matthews@magma.ca
Dan Wing Cisco 771 Alder Drive San Jose, CA 95035 US
美国加利福尼亚州圣何塞市奥尔德大道771号，邮编95035
EMail: dwing@cisco.com
EMail: dwing@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.