Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 8489 Impedance Mismatch
Obsoletes: 5389 G. Salgueiro
Category: Standards Track Cisco
ISSN: 2070-1721 J. Rosenberg
Five9
D. Wing
Citrix
R. Mahy
Unaffiliated
P. Matthews
Nokia
February 2020
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 8489 Impedance Mismatch
Obsoletes: 5389 G. Salgueiro
Category: Standards Track Cisco
ISSN: 2070-1721 J. Rosenberg
Five9
D. Wing
Citrix
R. Mahy
Unaffiliated
P. Matthews
Nokia
February 2020
Session Traversal Utilities for NAT (STUN)
NAT的会话遍历实用程序（STUN）
Abstract
摘要
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with 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.
STUN本身不是NAT遍历解决方案。相反，它是在NAT遍历解决方案的上下文中使用的工具。
This document obsoletes RFC 5389.
本文件废除RFC 5389。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8489.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8489.
Copyright Notice
版权公告
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2020 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Overview of Operation ...........................................5
3. Terminology .....................................................7
4. Definitions .....................................................7
5. STUN Message Structure ..........................................9
6. Base Protocol Procedures .......................................11
6.1. Forming a Request or an Indication ........................11
6.2. Sending the Request or Indication .........................12
6.2.1. Sending over UDP or DTLS-over-UDP ..................13
6.2.2. Sending over TCP or TLS-over-TCP ...................14
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP .........15
6.3. Receiving a STUN Message ..................................16
6.3.1. Processing a Request ...............................17
6.3.1.1. Forming a Success or Error Response .......17
6.3.1.2. Sending the Success or Error Response .....18
6.3.2. Processing an Indication ...........................18
6.3.3. Processing a Success Response ......................19
6.3.4. Processing an Error Response .......................19
7. FINGERPRINT Mechanism ..........................................20
8. DNS Discovery of a Server ......................................20
8.1. STUN URI Scheme Semantics .................................21
9. Authentication and Message-Integrity Mechanisms ................22
9.1. Short-Term Credential Mechanism ...........................23
9.1.1. HMAC Key ...........................................23
9.1.2. Forming a Request or Indication ....................23
9.1.3. Receiving a Request or Indication ..................23
9.1.4. Receiving a Response ...............................25
9.1.5. Sending Subsequent Requests ........................25
9.2. Long-Term Credential Mechanism ............................26
9.2.1. Bid-Down Attack Prevention .........................27
9.2.2. HMAC Key ...........................................27
1. Introduction ....................................................4
2. Overview of Operation ...........................................5
3. Terminology .....................................................7
4. Definitions .....................................................7
5. STUN Message Structure ..........................................9
6. Base Protocol Procedures .......................................11
6.1. Forming a Request or an Indication ........................11
6.2. Sending the Request or Indication .........................12
6.2.1. Sending over UDP or DTLS-over-UDP ..................13
6.2.2. Sending over TCP or TLS-over-TCP ...................14
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP .........15
6.3. Receiving a STUN Message ..................................16
6.3.1. Processing a Request ...............................17
6.3.1.1. Forming a Success or Error Response .......17
6.3.1.2. Sending the Success or Error Response .....18
6.3.2. Processing an Indication ...........................18
6.3.3. Processing a Success Response ......................19
6.3.4. Processing an Error Response .......................19
7. FINGERPRINT Mechanism ..........................................20
8. DNS Discovery of a Server ......................................20
8.1. STUN URI Scheme Semantics .................................21
9. Authentication and Message-Integrity Mechanisms ................22
9.1. Short-Term Credential Mechanism ...........................23
9.1.1. HMAC Key ...........................................23
9.1.2. Forming a Request or Indication ....................23
9.1.3. Receiving a Request or Indication ..................23
9.1.4. Receiving a Response ...............................25
9.1.5. Sending Subsequent Requests ........................25
9.2. Long-Term Credential Mechanism ............................26
9.2.1. Bid-Down Attack Prevention .........................27
9.2.2. HMAC Key ...........................................27
9.2.3. Forming a Request ..................................28
9.2.3.1. First Request .............................28
9.2.3.2. Subsequent Requests .......................29
9.2.4. Receiving a Request ................................29
9.2.5. Receiving a Response ...............................31
10. ALTERNATE-SERVER Mechanism ....................................33
11. Backwards Compatibility with RFC 3489 .........................34
12. Basic Server Behavior .........................................34
13. STUN Usages ...................................................35
14. STUN Attributes ...............................................36
14.1. MAPPED-ADDRESS ...........................................37
14.2. XOR-MAPPED-ADDRESS .......................................38
14.3. USERNAME .................................................39
14.4. USERHASH .................................................40
14.5. MESSAGE-INTEGRITY ........................................40
14.6. MESSAGE-INTEGRITY-SHA256 .................................41
14.7. FINGERPRINT ..............................................41
14.8. ERROR-CODE ...............................................42
14.9. REALM ....................................................44
14.10. NONCE ...................................................44
14.11. PASSWORD-ALGORITHMS .....................................44
14.12. PASSWORD-ALGORITHM ......................................45
14.13. UNKNOWN-ATTRIBUTES ......................................45
14.14. SOFTWARE ................................................46
14.15. ALTERNATE-SERVER ........................................46
14.16. ALTERNATE-DOMAIN ........................................46
15. Operational Considerations ....................................47
16. Security Considerations .......................................47
16.1. Attacks against the Protocol .............................47
16.1.1. Outside Attacks ...................................47
16.1.2. Inside Attacks ....................................48
16.1.3. Bid-Down Attacks ..................................48
16.2. Attacks Affecting the Usage ..............................50
16.2.1. Attack I: Distributed DoS (DDoS) against a
Target ............................................51
16.2.2. Attack II: Silencing a Client .....................51
16.2.3. Attack III: Assuming the Identity of a Client .....52
16.2.4. Attack IV: Eavesdropping ..........................52
16.3. Hash Agility Plan ........................................52
17. IAB Considerations ............................................53
18. IANA Considerations ...........................................53
18.1. STUN Security Features Registry ..........................53
18.2. STUN Methods Registry ....................................54
18.3. STUN Attributes Registry .................................54
18.3.1. Updated Attributes ................................55
18.3.2. New Attributes ....................................55
18.4. STUN Error Codes Registry ................................56
18.5. STUN Password Algorithms Registry ........................56
9.2.3. Forming a Request ..................................28
9.2.3.1. First Request .............................28
9.2.3.2. Subsequent Requests .......................29
9.2.4. Receiving a Request ................................29
9.2.5. Receiving a Response ...............................31
10. ALTERNATE-SERVER Mechanism ....................................33
11. Backwards Compatibility with RFC 3489 .........................34
12. Basic Server Behavior .........................................34
13. STUN Usages ...................................................35
14. STUN Attributes ...............................................36
14.1. MAPPED-ADDRESS ...........................................37
14.2. XOR-MAPPED-ADDRESS .......................................38
14.3. USERNAME .................................................39
14.4. USERHASH .................................................40
14.5. MESSAGE-INTEGRITY ........................................40
14.6. MESSAGE-INTEGRITY-SHA256 .................................41
14.7. FINGERPRINT ..............................................41
14.8. ERROR-CODE ...............................................42
14.9. REALM ....................................................44
14.10. NONCE ...................................................44
14.11. PASSWORD-ALGORITHMS .....................................44
14.12. PASSWORD-ALGORITHM ......................................45
14.13. UNKNOWN-ATTRIBUTES ......................................45
14.14. SOFTWARE ................................................46
14.15. ALTERNATE-SERVER ........................................46
14.16. ALTERNATE-DOMAIN ........................................46
15. Operational Considerations ....................................47
16. Security Considerations .......................................47
16.1. Attacks against the Protocol .............................47
16.1.1. Outside Attacks ...................................47
16.1.2. Inside Attacks ....................................48
16.1.3. Bid-Down Attacks ..................................48
16.2. Attacks Affecting the Usage ..............................50
16.2.1. Attack I: Distributed DoS (DDoS) against a
Target ............................................51
16.2.2. Attack II: Silencing a Client .....................51
16.2.3. Attack III: Assuming the Identity of a Client .....52
16.2.4. Attack IV: Eavesdropping ..........................52
16.3. Hash Agility Plan ........................................52
17. IAB Considerations ............................................53
18. IANA Considerations ...........................................53
18.1. STUN Security Features Registry ..........................53
18.2. STUN Methods Registry ....................................54
18.3. STUN Attributes Registry .................................54
18.3.1. Updated Attributes ................................55
18.3.2. New Attributes ....................................55
18.4. STUN Error Codes Registry ................................56
18.5. STUN Password Algorithms Registry ........................56
18.5.1. Password Algorithms ...............................57
18.5.1.1. MD5 ......................................57
18.5.1.2. SHA-256 ..................................57
18.6. STUN UDP and TCP Port Numbers ............................57
19. Changes since RFC 5389 ........................................57
20. References ....................................................58
20.1. Normative References .....................................58
20.2. Informative References ...................................61
Appendix A. C Snippet to Determine STUN Message Types ............64
Appendix B. Test Vectors .........................................64
B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH .....................65
Acknowledgements ..................................................66
Contributors ......................................................66
Authors' Addresses ................................................67
18.5.1. Password Algorithms ...............................57
18.5.1.1. MD5 ......................................57
18.5.1.2. SHA-256 ..................................57
18.6. STUN UDP and TCP Port Numbers ............................57
19. Changes since RFC 5389 ........................................57
20. References ....................................................58
20.1. Normative References .....................................58
20.2. Informative References ...................................61
Appendix A. C Snippet to Determine STUN Message Types ............64
Appendix B. Test Vectors .........................................64
B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH .....................65
Acknowledgements ..................................................66
Contributors ......................................................66
Authors' Addresses ................................................67
The protocol defined in this specification, Session Traversal Utilities for NAT (STUN), provides a tool for dealing with Network Address Translators (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 [RFC8445] or to relay packets between two endpoints [RFC5766].
本规范中定义的协议，NAT会话遍历实用程序（STUN），提供了处理网络地址转换器（NAT）的工具。它为端点提供了一种方法来确定NAT分配的IP地址和端口，该NAT对应于其私有IP地址和端口。它还为端点提供了一种保持NAT绑定活动的方法。通过一些扩展，该协议可用于在两个端点[RFC8445]之间进行连接检查，或在两个端点[RFC5766]之间中继数据包。
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 the 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) [RFC8445] is one usage of STUN. SIP Outbound [RFC5626] 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 13.
STUN旨在用于一个或多个NAT穿越解决方案的上下文中。这些解决方案被称为“眩晕用法”。每个用法都描述了如何利用STUN实现NAT遍历解决方案。通常，用法指示何时发送STUN消息、包括哪些可选属性、使用什么服务器以及使用什么身份验证机制。交互式连接建立（ICE）[RFC8445]是STUN的一种用法。SIP Outbound[RFC5626]是STUN的另一种用法。在某些情况下，一个用法需要对STUN进行扩展。STUN扩展可以采用新方法、属性或错误响应代码的形式。关于眩晕用法的更多信息，请参见第13节。
This section is descriptive only.
本节仅作说明。
/-----\
// STUN \\
| Server |
\\ //
\-----/
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private Network 2
................| NAT 1 |.......................
+--------------+
+--------------+ Private Network 2
................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private Network 1
\-----/
/-----\
// STUN \\
| Client |
\\ // Private Network 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, which 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, which 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
STUN是一种客户机-服务器协议。它支持两种类型的事务。一种是请求/响应事务，其中客户端向服务器发送请求，服务器返回响应。第二种是指示事务，在该事务中，代理（客户机或服务器）发送的指示不生成响应。这两种类型的事务都包含一个事务ID，该ID
is a randomly selected 96-bit number. For request/response 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.
是随机选择的96位数字。对于请求/响应事务，此事务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 are 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., [RFC8445] and [RFC5626]). 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
在某些用途中，STUN必须与其他协议（例如，[RFC8445]和[RFC5626]）多路复用。在这些用法中，必须有一种方法来检查数据包并确定它是否是STUN数据包。STUN在STUN标题中提供了三个字段，其中包含可以修改的固定值
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数据包还可以包含指纹值，指纹值还可以用于区分数据包。
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 the one defined for HTTP [RFC7616] but differing in details. 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 [RFC8445], 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[RFC7616]定义的质询/响应交换，但在细节上有所不同。在短期凭证机制中，客户机和服务器在STUN交换之前通过一些带外方法交换用户名和密码。例如，在ICE用法[RFC8445]中，两个端点使用带外信令来交换用户名和密码。它们用于完整性保护和验证请求和响应。没有使用质询或临时命令。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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 and STUN indications. A STUN client can also send indications. In this specification, the terms "STUN client" and "client" are synonymous.
眩晕客户端：眩晕客户端是发送眩晕请求并接收眩晕响应和眩晕指示的实体。STUN客户端也可以发送指示。在本规范中，“STUN客户端”和“客户端”是同义词。
STUN Server: A STUN server is an entity that receives STUN requests and STUN indications and that sends STUN responses. A STUN server can also send indications. In this specification, the terms "STUN server" and "server" are synonymous.
眩晕服务器：眩晕服务器是接收眩晕请求和眩晕指示并发送眩晕响应的实体。STUN服务器也可以发送指示。在本规范中，“STUN服务器”和“服务器”是同义词。
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 Session Initiation Protocol (SIP) [RFC3261] dialog). The specific scope of a short-term credential is defined by the application usage.
短期凭证：代表客户端和服务器之间共享秘密的临时用户名和相关密码。短期凭证是在STUN交换之前，通过客户端和服务器之间的某种协议机制获得的。短期凭证具有明确的时间范围，其可以基于特定的时间量（例如5分钟）或事件（例如会话发起协议（SIP）[rfc326]对话框的终止）。短期凭证的特定范围由应用程序使用情况定义。
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 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10).
STUN消息使用面向网络的格式（最高有效字节或八位字节优先，也称为big-endian）进行二进制编码。[RFC0791]的附录B详细描述了传输顺序。除非另有说明，否则数值常量为十进制（以10为基数）。
All STUN messages comprise a 20-byte header followed by zero or more attributes. The STUN header contains a STUN message type, message length, magic cookie, and transaction ID.
所有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, error 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 STUN Message Type field is decomposed further into the following structure:
STUN消息类型字段进一步分解为以下结构：
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|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of STUN Message Type Field
图3:STUN消息类型字段的格式
Here the bits in the STUN 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.
此处，STUN消息类型字段中的位显示为最高有效（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 indication messages, success responses, and errors responses using bit fields.
注意：这个不幸的编码是由于在[fcC3149]中没有考虑使用比特字段来编码编码指示消息、成功响应和错误响应的值。
The Magic Cookie field MUST contain the fixed value 0x2112A442 in network byte order. In [RFC3489], the 32 bits comprising the Magic Cookie field were 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 to STUN by [RFC5389]. 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。在[RFC3489]中，包含Magic Cookie字段的32位是事务ID的一部分；将magic cookie放置在此位置允许服务器检测客户端是否理解[RFC5389]添加到STUN的某些属性。此外，当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 MUST 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 of the message in bytes, 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. Details of the encoding and the attributes themselves are given in Section 14.
标题的眩晕固定部分后面是零个或多个属性。每个属性都是TLV（类型长度值）编码的。第14节给出了编码和属性本身的详细信息。
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 5 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.
制定请求或指示消息时，代理在创建标头时必须遵循第5节中的规则。此外，消息类必须是“请求”或“指示”（视情况而定），并且方法必须是绑定的或在另一个文档中定义的某个方法。
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 9) or the FINGERPRINT attribute (Section 7).
然后，代理添加由方法或用法指定的任何属性。例如，一些用法可以指定代理使用认证方法（第9节）或指纹属性（第7节）。
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. Note that the inclusion of a SOFTWARE attribute may have security implications; see Section 16.1.2 for details.
如果代理正在发送请求，则应向请求添加软件属性。代理可能包括指示中的软件属性，具体取决于方法。STUN的扩展应讨论软件在新适应症中是否有用。请注意，包含软件属性可能会带来安全隐患；详见第16.1.2节。
For the Binding method with no authentication, no attributes are required unless the usage specifies otherwise.
对于没有身份验证的绑定方法，除非用法另有规定，否则不需要属性。
All STUN messages sent over UDP or DTLS-over-UDP [RFC6347] SHOULD be less than the path MTU, if known.
通过UDP发送的所有STUN消息或通过UDP发送的DTLS[RFC6347]应小于路径MTU（如果已知）。
If the path MTU is unknown for UDP, messages SHOULD be the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC8200]. 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).
如果UDP的路径MTU未知，则消息应为576字节和第一跳MTU（IPv4[RFC1122]）中的较小者，以及1280字节（IPv6[RFC8200]）。该值对应于IP数据包的总大小。因此，对于IPv4，实际的STUN消息需要小于548字节（576减去20字节的IP头，减去8字节的UDP头，假设没有使用IP选项）。
If the path MTU is unknown for DTLS-over-UDP, the rules described in the previous paragraph need to be adjusted to take into account the size of the (13-byte) DTLS Record header, the Message Authentication Code (MAC) size, and the padding size.
如果UDP上的DTLS的路径MTU未知，则需要调整上一段中描述的规则，以考虑（13字节）DTLS记录头的大小、消息身份验证码（MAC）大小和填充大小。
STUN provides no ability to handle the case where the request is smaller than the MTU but the response is larger than the MTU. It is not envisioned that this limitation will be an issue for STUN. The MTU limitation is a SHOULD, not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [RFC5780]. See also [STUN-PMTUD] for a framework that uses STUN to add Path MTU Discovery to protocols that lack such a mechanism. Outside of this or similar applications, the MTU constraint MUST be followed.
STUN无法处理请求小于MTU但响应大于MTU的情况。这是不可想象的，这一限制将是一个问题的眩晕。MTU限制是一个应该，而不是必须的，以说明STUN本身被用于探测MTU特性的情况[RFC5780]。另请参见[STUN-PMTUD]，了解使用STUN向缺少这种机制的协议添加路径MTU发现的框架。在该应用程序或类似应用程序之外，必须遵循MTU约束。
The agent then sends the request or indication. This document specifies how to send STUN messages over UDP, TCP, TLS-over-TCP, or DTLS-over-UDP; 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 8 describes a DNS-based method of determining the IP address and port of a server that a usage may elect to use.
然后，代理发送请求或指示。本文档指定如何通过UDP、TCP、TCP上的TLS或UDP上的DTLS发送STUN消息；将来可能会添加其他传输协议。STUN使用必须指定使用哪种传输协议，以及代理如何确定收件人的IP地址和端口。第8节描述了一种基于DNS的方法，用于确定用户可能选择使用的服务器的IP地址和端口。
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
在任何时候，一个客户机都可能在同一个STUN服务器上有多个未完成的STUN请求（即，多个正在进行的事务，具有不同的事务ID）。没有其他限制
the rate of new transactions (such as those specified by ICE for connectivity checks or when STUN is run over TCP), a client SHOULD limit itself to ten outstanding transactions to the same server.
新事务的速率（如ICE为连接检查指定的事务或通过TCP运行STUN时指定的事务），客户端应将自身限制为同一服务器的十个未完成事务。
When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], 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 request message by the client application itself. STUN indications are not retransmitted; thus, indication transactions over UDP or DTLS-over-UDP are not reliable.
在UDP上运行STUN或UDP上运行DTLS上的STUN[RFC7350]时，网络可能会丢弃STUN消息。STUN请求/响应事务的可靠性是通过客户端应用程序本身重新传输请求消息来实现的。眩晕指示不会被重新传输；因此，UDP上的指示事务或UDP上的DTL不可靠。
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 [RFC6298], with two exceptions. First, the initial value for RTO SHOULD be greater than or equal to 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）的估计，计算方法如[RFC6298]所述，但有两个例外。首先，RTO的初始值应大于或等于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 if no transactions have occurred to the same server in the last 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 or DTLS-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事务或UDP上的DTLS事务也被视为失败。例如，假设500毫秒的RTO，将在0毫秒、500毫秒、1500毫秒、3500毫秒、7500毫秒、15500毫秒和31500毫秒发送请求。如果客户端在39500毫秒之后没有收到响应，则客户端将考虑事务超时。
For TCP and TLS-over-TCP [RFC8446], the client opens a TCP connection to the server.
对于TCP和TCP上的TLS[RFC8446]，客户端打开到服务器的TCP连接。
In some usages of STUN, STUN is 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 8 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消息和完整的应用层消息。在第8节中通过DNS程序发现的一个或多个已知端口上运行的STUN服务仅适用于STUN，而不适用于与其他数据多路复用的STUN。因此，在与这些服务器的连接中不使用帧协议。当使用额外的帧时，用法将指定客户端如何知道应用它以及连接到哪个端口。例如，在ICE连接检查的情况下，通过客户机和服务器之间的带外协商了解此信息。
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 request message, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5 s. 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协议级别没有重传。但是，对于请求/响应事务，如果客户端在发送请求消息后的Ti秒内没有收到响应，则它认为该事务已超时。Ti应该是可配置的，默认值为39.5秒。已选择此值以均衡默认初始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 request. 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,
o 没有进一步的眩晕请求或指示通过该连接发送，
o has no plans to use any resources (such as a mapped address (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address [RFC5766]) that were learned though STUN requests sent over that connection,
o 没有计划使用通过该连接发送的STUN请求获取的任何资源（如映射地址（mapped-address或XOR-mapped-address）或中继地址[RFC5766]），
o if multiplexing other application protocols over that port, has finished using those other protocols,
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., [RFC6544]).
o 如果与远程对等方使用该学习端口，则已与该远程对等方建立通信，这是某些TCP NAT遍历技术（例如，[RFC6544]）所要求的。
The details of an eventual keep-alive mechanism are left to each STUN Usage. In any case, if a transaction fails because an idle TCP connection doesn't work anymore, the client SHOULD send a RST and try to open a new TCP connection.
最终的“保持活力”机制的细节将留给每一次昏迷使用。在任何情况下，如果由于空闲TCP连接不再工作而导致事务失败，客户端应发送RST并尝试打开新的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中保持有效。只有客户机知道它需要绑定多长时间。如果通过未发送响应的连接接收到请求，则服务器不应关闭该连接。服务器决不能为了发送响应而打开回客户端的连接。服务器应遵循过载情况下连接管理的最佳实践。
When STUN is run by itself over TLS-over-TCP or DTLS-over-UDP, the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ciphersuites MUST be implemented (for compatibility with older versions of this protocol), except if deprecated by rules of a specific STUN usage. Other ciphersuites MAY be implemented. Note that STUN clients and servers that implement TLS version 1.3 [RFC8446] or subsequent versions are also required to implement mandatory ciphersuites from those specifications and SHOULD disable usage of deprecated ciphersuites when they detect support for those specifications. Perfect Forward Secrecy (PFS) ciphersuites MUST be preferred over non-PFS ciphersuites. Ciphersuites with known weaknesses, such as those based on (single) DES and RC4, MUST NOT be used. Implementations MUST disable TLS-level compression.
当STUN通过TCP上的TLS或UDP上的DTLS自行运行时，必须实现TLS_DHE_RSA_与_AES_128_GCM_SHA256和TLS_ECDHE_RSA_与_AES_128_GCM_SHA256密码套件（为了与此协议的旧版本兼容），除非特定STUN使用规则不推荐使用。可以实现其他密码套件。请注意，实现TLS版本1.3[RFC8446]或后续版本的STUN客户端和服务器也需要实现这些规范中的强制密码套件，并且当它们检测到对这些规范的支持时，应禁用不推荐使用的密码套件。完美前向保密（PFS）密码套件必须优先于非PFS密码套件。不得使用具有已知弱点的密码套件，例如基于（单一）DES和RC4的密码套件。实现必须禁用TLS级压缩。
These recommendations are just a part of the recommendations in [BCP195] that implementations and deployments of a STUN Usage using TLS or DTLS MUST follow.
这些建议只是[BCP195]中建议的一部分，使用TLS或DTL实现和部署STUN必须遵循这些建议。
When it receives the TLS Certificate message, the client MUST verify the certificate and inspect the site identified by the certificate. If the certificate is invalid or revoked, or if it does not identify
当收到TLS证书消息时，客户端必须验证证书并检查证书标识的站点。如果证书无效或已吊销，或者证书未标识
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 [RFC6125], with a certificate containing an identifier of type DNS-ID or CN-ID, optionally with a wildcard character as the leftmost label, but not of type SRV-ID or URI-ID.
作为适当的一方，客户不得发送STUN消息或以其他方式继续进行STUN交易。客户端必须验证服务器的标识。为此，它遵循[RFC6125]中定义的识别过程，证书包含类型为DNS-ID或CN-ID的标识符，可以选择使用通配符作为最左边的标签，但不是类型为SRV-ID或URI-ID。
When STUN is run multiplexed with other protocols over a TLS-over-TCP connection or a DTLS-over-UDP association, the mandatory ciphersuites and TLS handling procedures operate as defined by those protocols.
当STUN通过TLS over TCP连接或DTLS over UDP关联与其他协议多路传输时，强制密码套件和TLS处理过程按照这些协议的定义运行。
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 11. 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消息；第11节定义了向后兼容性的其他规则。这些附加程序是可选的，用户可以选择使用它们。首先，应用一组独立于类的处理操作。接下来是特定于类的处理，在后面的小节中进行了描述。
When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 5. 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.
当眩晕代理收到眩晕消息时，它首先检查消息是否符合第5节的规则。它检查前两位是否为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 9).
然后，STUN代理执行该用法指定的身份验证机制所需的任何检查（请参见第9节）。
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属性。
Otherwise, 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 or DTLS-over-UDP, a request received by the server could be the first request of a transaction or could be 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 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 or DTLS-over-UDP and their corresponding responses in the last 40 seconds. However, this requires the server to hold state and is inappropriate for any requests that 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运行或通过UDP运行DTLS时，服务器收到的请求可能是事务的第一个请求，也可能是重新传输。服务器必须对重传做出响应，以便保留以下属性：如果客户端接收到对重传的响应，而不是发送到原始请求的响应，客户端和服务器上的总体状态与仅接收到对原始重传的响应或同时接收到两个响应的情况相同（在这种情况下，客户端将使用第一个响应）。满足此要求的最简单方法是服务器记住通过UDP或通过UDP的DTL接收的所有事务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 9). Extensions may define other errors and/or additional attributes to add in error cases.
对于错误响应，服务器必须添加一个错误代码属性，该属性包含在上述处理中指定的错误代码。原因短语不是固定的，但应该适合于错误代码。对于某些错误，会向消息中添加其他属性。这些属性在指定错误代码的描述中详细说明。例如，对于错误代码420（未知属性），服务器必须包含未知属性。某些身份验证错误还会导致添加属性（请参见第9节）。扩展可以定义其他错误和/或附加属性以添加到错误案例中。
If the server authenticated the request using an authentication mechanism, then the server SHOULD add the appropriate authentication attributes to the response (see Section 9).
如果服务器使用身份验证机制对请求进行了身份验证，则服务器应向响应中添加适当的身份验证属性（请参见第9节）。
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 an XOR-MAPPED-ADDRESS attribute to the response; this attribute contains the source transport address of the request message. For UDP or DTLS-over-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.
对于绑定方法，除非用法另有规定，否则不需要额外的检查。在形成成功响应时，服务器向响应添加XOR-MAPPED-ADDRESS属性；此属性包含请求消息的源传输地址。对于UDP或UDP上的DTLS，这是请求消息的源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 or DTLS-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或通过UDP的DTLS接收请求，则响应的目标IP地址和端口是接收到的请求消息的源IP地址和端口，并且响应的源IP地址和端口等于接收到的请求消息的目标IP地址和端口。如果通过TCP或TLS通过TCP接收到请求，则响应将在上接收到请求的TCP连接上发回。
The server is allowed to send responses in a different order than it received the requests.
允许服务器以与接收请求不同的顺序发送响应。
If the indication contains unknown comprehension-required attributes, the indication is discarded and processing ceases.
如果该指示包含未知的理解要求属性，则该指示将被丢弃并停止处理。
Otherwise, 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 or DTLS-over-UDP (unlike requests), there is no need to handle re-transmissions of indications at the sending agent.
由于指示不会通过UDP或DTLS通过UDP重新传输（与请求不同），因此无需在发送代理处处理指示的重新传输。
If the success response contains unknown comprehension-required attributes, the response is discarded and the transaction is considered to have failed.
如果成功响应包含未知的必需属性，则将放弃响应，并将事务视为失败。
Otherwise, 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 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.
对于绑定方法，客户机检查响应中是否存在XOR-MAPPED-ADDRESS属性。客户端检查指定的地址族。如果它是不受支持的地址族，则应忽略该属性。如果它是意外但受支持的地址系列（例如，绑定事务是通过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.
如果错误响应包含未知的理解所需属性，或者如果错误响应不包含错误代码属性，则事务仅被视为失败。
Otherwise, the client then does any processing specified by the authentication mechanism (see Section 9). This may result in a new transaction attempt.
否则，客户端将执行身份验证机制指定的任何处理（请参见第9节）。这可能会导致新的事务尝试。
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 (Section 10) is being used.
o 如果错误代码是300到399，则客户端应该考虑事务失败，除非正在使用AutoTeleServer扩展（第10节）。
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. Unless a specific error code specifies a different value, the number of retransmissions SHOULD be limited to 4.
o 如果错误代码为500到599，则客户端可以重新发送请求；这样做的客户端必须限制这样做的次数。除非特定错误代码指定不同的值，否则重新传输的次数应限制为4次。
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 6, STUN messages must first be separated from the application packets.
在某些用途中，STUN消息与其他协议（如实时传输协议（RTP））在相同的传输地址上多路传输。为了应用第6节中描述的处理，必须首先将STUN消息与应用程序数据包分开。
Section 5 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.
第5节介绍了STUN标题中可用于此目的的三个固定字段。但是，在某些情况下，这三个固定字段可能不够。
When the FINGERPRINT extension is used, an agent includes the FINGERPRINT attribute in messages it sends to another agent. Section 14.7 describes the placement and value of this attribute.
使用指纹扩展时，代理在发送给另一个代理的消息中包含指纹属性。第14.7节描述了该属性的位置和值。
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 6.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.
当代理接收到它认为是昏迷消息时，除了其他基本检查外，代理还检查消息是否包含指纹属性以及该属性是否包含正确的值。第6.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
本节介绍STUN的可选过程，该过程允许客户端使用DNS确定服务器的IP地址和端口。眩晕用法必须说明是否以及何时使用此扩展名。到
use this procedure, the client must know a STUN URI [RFC7064]; the usage must also describe how the client obtains this URI. Hard-coding a STUN URI into software is NOT RECOMMENDED in case the domain name is lost or needs to change for legal or other reasons.
使用此过程时，客户端必须知道一个stunuri[RFC7064]；用法还必须描述客户端如何获取此URI。如果域名丢失或因法律或其他原因需要更改，则不建议将STUN URI硬编码到软件中。
When a client wishes to locate a STUN server on the public Internet that accepts Binding request/response transactions, the STUN URI scheme is "stun". When it wishes to locate a STUN server that accepts Binding request/response transactions over a TLS or DTLS session, the URI scheme is "stuns".
当客户端希望在公共Internet上找到接受绑定请求/响应事务的STUN服务器时，STUN URI方案为“STUN”。当它希望定位通过TLS或DTLS会话接受绑定请求/响应事务的STUN服务器时，URI方案为“stuns”。
The syntax of the "stun" and "stuns" URIs is defined in Section 3.1 of [RFC7064]. STUN Usages MAY define additional URI schemes.
[RFC7064]第3.1节定义了“stun”和“stuns”URI的语法。STUN使用可能会定义其他URI方案。
If the <host> part of a "stun" URI contains an IP address, then this IP address is used directly to contact the server. A "stuns" URI containing an IP address MUST be rejected. A future STUN extension or usage may relax this requirement, provided it demonstrates how to authenticate the STUN server and prevent man-in-the-middle attacks.
如果“stun”URI的<host>部分包含一个IP地址，那么该IP地址将直接用于联系服务器。必须拒绝包含IP地址的“stuns”URI。未来的STUN扩展或使用可能会放宽这一要求，前提是它演示了如何验证STUN服务器并防止中间人攻击。
If the URI does not contain an IP address, the domain name contained in the <host> part is resolved to a transport address using the SRV procedures specified in [RFC2782]. The DNS SRV service name is the content of the <scheme> part. The protocol in the SRV lookup is the transport protocol the client will run STUN over: "udp" for UDP and "tcp" for TCP.
如果URI不包含IP地址，则使用[RFC2782]中指定的SRV过程将<host>部分中包含的域名解析为传输地址。DNS SRV服务名称是<scheme>部分的内容。SRV查找中的协议是客户端将通过STUN运行的传输协议：“udp”表示udp，“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 the next server in the order defined by RFC 2782. Such a retry is only possible for request/response transmissions, since indication transactions generate no response or timeout.
按照RFC 2782的程序确定要联系的服务器。RFC2782详细说明了如何对一组SRV记录进行排序，然后进行尝试。但是，RFC2782仅说明客户端应“尝试连接到（协议、地址、服务）”，而未提供任何有关发生故障时发生的情况的详细信息。在执行这些过程时，如果STUN事务超时而未收到响应，则客户端应按照RFC 2782定义的顺序重试对下一台服务器的请求。由于指示事务不生成响应或超时，因此这种重试仅适用于请求/响应传输。
In addition, instead of querying either the A or the AAAA resource records for a domain name, a dual-stack IPv4/IPv6 client MUST query both and try the requests with all the IP addresses received, as specified in [RFC8305].
此外，如[RFC8305]中所述，双栈IPv4/IPv6客户端必须同时查询并使用接收到的所有IP地址尝试请求，而不是在A或AAAA资源记录中查询域名。
The default port for STUN requests is 3478, for both TCP and UDP. The default port for STUN over TLS and STUN over DTLS requests is 5349. Servers can run STUN over DTLS on the same port as STUN over
对于TCP和UDP，STUN请求的默认端口为3478。STUN over TLS和STUN over DTLS请求的默认端口为5349。服务器可以在与STUN over相同的端口上通过DTL运行STUN
UDP if the server software supports determining whether the initial message is a DTLS or STUN message. 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.
UDP，如果服务器软件支持确定初始消息是DTLS还是STUN消息。如果服务器软件支持确定初始消息是TLS消息还是STUN消息，则服务器可以在与STUN over TCP相同的端口上通过TLS运行STUN。
Administrators of STUN servers SHOULD use these ports 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.
STUN服务器的管理员应在其UDP和TCP的SRV记录中使用这些端口。在所有情况下，DNS中的端口都必须反映服务器正在侦听的端口。
If no SRV records are found, the client performs both an A and AAAA record lookup of the domain name, as described in [RFC8305]. The result will be a list of IP addresses, each of which can be simultaneously contacted at the default port using UDP or TCP, independent of the STUN Usage. For usages that require TLS, the client connects to the IP addresses using the default STUN over TLS port. For usages that require DTLS, the client connects to the IP addresses using the default STUN over DTLS port.
如果未找到SRV记录，客户端将对域名执行A和AAAA记录查找，如[RFC8305]中所述。结果将是一个IP地址列表，可以使用UDP或TCP在默认端口同时联系每个IP地址，与STUN的使用无关。对于需要TLS的使用，客户端使用默认的STUN over TLS端口连接到IP地址。对于需要DTLS的使用，客户端使用默认的STUN over DTLS端口连接到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 2.
本节定义了客户机和服务器可用于提供身份验证和消息完整性的两种STUN机制；这两种机制称为短期凭证机制和长期凭证机制。这两种机制是可选的，每次使用都必须指定是否以及何时使用这些机制。因此，客户机和服务器都将根据应用哪种用法的知识知道应该遵循哪种机制（如果有的话）。例如，公共互联网上支持ICE的STUN服务器将没有身份验证，而支持连接检查的代理中的STUN服务器功能将使用短期凭据。第2节概述了这两种机制。
Each mechanism specifies the additional processing required to use that mechanism, extending the processing specified in Section 6. 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.
每个机制指定了使用该机制所需的附加处理，扩展了第6节中指定的处理。附加处理发生在三个不同的位置：形成消息时，在执行基本检查后立即接收消息时，以及在执行错误响应的详细处理时。
Note that agents MUST ignore all attributes that follow MESSAGE-INTEGRITY, with the exception of the MESSAGE-INTEGRITY-SHA256 and FINGERPRINT attributes. Similarly, agents MUST ignore all attributes that follow the MESSAGE-INTEGRITY-SHA256 attribute if the MESSAGE-INTEGRITY attribute is not present, with the exception of the FINGERPRINT attribute.
请注意，代理必须忽略MESSAGE-INTEGRITY之后的所有属性，MESSAGE-INTEGRITY-SHA256和指纹属性除外。类似地，如果MESSAGE-INTEGRITY属性不存在，则代理必须忽略MESSAGE-INTEGRITY-SHA256属性后面的所有属性，指纹属性除外。
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. As an example, in the ICE usage [RFC8445], 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.
短期凭证机制假设，在STUN事务之前，客户机和服务器已使用其他协议以用户名和密码的形式交换凭证。此凭证有时间限制。时间限制由用法定义。例如，在ICE使用[RFC8445]中，两个端点使用带外信令来商定用户名和密码，并且该用户名和密码适用于媒体会话的持续时间。
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 limited by virtue of the time-limited nature of the credential.
此凭证用于在每个请求和许多响应中形成消息完整性检查。没有像长期机制那样的挑战和反应；因此，由于凭证的时间限制性质，重播受到限制。
For short-term credentials, the Hash-Based Message Authentication Code (HMAC) key is defined as follow:
对于短期凭证，基于哈希的消息身份验证码（HMAC）密钥定义如下：
key = OpaqueString(password)
key=OpaqueString（密码）
where the OpaqueString profile is defined in [RFC8265]. The encoding used is UTF-8 [RFC3629].
其中，[RFC8265]中定义了不透明字符串配置文件。使用的编码是UTF-8[RFC3629]。
For a request or indication message, the agent MUST include the USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes in the message unless the agent knows from an external mechanism which message integrity algorithm is supported by both agents. In this case, either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST be included in addition to USERNAME. The HMAC for the MESSAGE-INTEGRITY attribute is computed as described in Section 14.5, and the HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as described in Section 14.6. Note that the password is never included in the request or indication.
对于请求或指示消息，代理必须在消息中包含用户名、message-INTEGRITY-SHA256和message-INTEGRITY属性，除非代理通过外部机制知道两个代理都支持哪个消息完整性算法。在这种情况下，除了用户名外，还必须包括MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256。如第14.5节所述计算消息完整性属性的HMAC，如第14.6节所述计算消息完整性SHA256属性的HMAC。请注意，请求或指示中从不包含密码。
After the agent has done the basic processing of a message, the agent performs the checks listed below in the order specified:
代理完成消息的基本处理后，代理将按照指定的顺序执行下列检查：
o If the message does not contain 1) a MESSAGE-INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute and 2) a USERNAME attribute:
o 如果消息不包含1）消息完整性或消息完整性SHA256属性和2）用户名属性：
* 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 (Unauthenticated).
* 如果消息是请求，则服务器必须以错误响应拒绝该请求。此响应必须使用错误代码401（未经验证）。
* If the message is an indication, the agent MUST silently discard the indication.
* 如果消息是一个指示，则代理必须以静默方式放弃该指示。
o If the MESSAGE-INTEGRITY-SHA256 attribute is present, compute the value for the message integrity as described in Section 14.6, using the password associated with the username. If the MESSAGE-INTEGRITY-SHA256 attribute is not present, then use the same password to compute the value for the message integrity as described in Section 14.5. If the resulting value does not match the contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256 or MESSAGE-INTEGRITY):
o 如果存在MESSAGE-INTEGRITY-SHA256属性，请使用与用户名关联的密码，按照第14.6节所述计算消息完整性的值。如果MESSAGE-INTEGRITY-SHA256属性不存在，则使用相同的密码计算第14.5节所述的消息完整性值。如果结果值与相应属性（MESSAGE-INTEGRITY-SHA256或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 (Unauthenticated).
* 如果消息是请求，则服务器必须以错误响应拒绝该请求。此响应必须使用错误代码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 to a request that contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the MESSAGE-INTEGRITY-SHA256 attribute, computed using the password utilized to authenticate the request. Any response generated by a server to a request that contains only a MESSAGE-INTEGRITY attribute MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. This means that only one of these attributes can appear in a response. The response MUST NOT contain the USERNAME attribute.
如果这些检查通过，代理将继续处理请求或指示。服务器对包含MESSAGE-INTEGRITY-SHA256属性的请求生成的任何响应都必须包含MESSAGE-INTEGRITY-SHA256属性，该属性使用用于验证请求的密码计算。服务器对仅包含MESSAGE-INTEGRITY属性的请求生成的任何响应必须包含MESSAGE-INTEGRITY属性，该属性使用用于验证请求的密码计算。这意味着响应中只能出现这些属性中的一个。响应不能包含USERNAME属性。
If any of the checks fail, a server MUST NOT include a MESSAGE-INTEGRITY-SHA256, 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 the MESSAGE-INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes.
如果任何检查失败，服务器不得在错误响应中包含MESSAGE-INTEGRITY-SHA256、MESSAGE-INTEGRITY或USERNAME属性。这是因为，在这些故障情况下，服务器无法确定计算MESSAGE-INTEGRITY-SHA256或MESSAGE-INTEGRITY属性所需的共享机密。
The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY-SHA256 attribute in the response. If present and if the client only sent one of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes in the request (because of the external indication in Section 9.1.2 or because this is a subsequent request as defined in Section 9.1.5), the algorithm in the response has to match; otherwise, the response MUST be discarded.
客户端在响应中查找MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性。如果存在，且客户机在请求中仅发送了一个MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性（由于第9.1.2节中的外部指示或因为这是第9.1.5节中定义的后续请求），则响应中的算法必须匹配；否则，必须放弃响应。
The client then computes the message integrity over the response as defined in Section 14.5 for the MESSAGE-INTEGRITY attribute or Section 14.6 for the MESSAGE-INTEGRITY-SHA256 attribute, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, respectively, the response is considered authenticated. If the value does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 are absent, the processing depends on whether the request was sent over a reliable or an unreliable transport.
然后，客户机使用其用于请求的相同密码，根据第14.5节中针对message-integrity属性的定义或第14.6节中针对message-integrity-SHA256属性的定义，计算响应上的消息完整性。如果结果值分别与MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性的内容匹配，则认为响应已通过身份验证。如果该值不匹配，或者如果MESSAGE-INTEGRITY和MESSAGE-INTEGRITY-SHA256都不存在，则处理取决于请求是通过可靠传输还是不可靠传输发送的。
If the request was sent over an unreliable transport, the response MUST be discarded, as if it had never been received. This means that retransmits, if applicable, will continue. If all the responses received are discarded, then instead of signaling a timeout after ending the transaction, the layer MUST signal that the integrity protection was violated.
如果请求是通过不可靠的传输发送的，则必须丢弃响应，就像从未收到响应一样。这意味着重新传输（如果适用）将继续。如果接收到的所有响应都被丢弃，则层必须发出完整性保护被违反的信号，而不是在事务结束后发出超时信号。
If the request was sent over a reliable transport, the response MUST be discarded, and the layer MUST immediately end the transaction and signal that the integrity protection was violated.
如果请求是通过可靠传输发送的，则必须放弃响应，层必须立即结束事务并发出完整性保护被违反的信号。
A client sending subsequent requests to the same server MUST send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute that matches the attribute that was received in the response to the initial request. Here, "same server" means same IP address and port number, not just the same URI or SRV lookup result.
向同一服务器发送后续请求的客户端必须只发送MESSAGE-INTEGRITY-SHA256或MESSAGE-INTEGRITY属性，该属性与响应初始请求时接收到的属性相匹配。这里，“相同的服务器”意味着相同的IP地址和端口号，而不仅仅是相同的URI或SRV查找结果。
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 until it 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 a limited replay protection. It is a cookie, selected by the server and encoded in such a way as to indicate a duration of validity or client identity from which it is valid. Only the server needs to know about the internal structure of the cookie. 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 one of the message-integrity attributes defined in this document, 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提供有限的重播保护。它是一个cookie，由服务器选择，并以指示其有效期或客户端标识的方式进行编码。只有服务器需要知道cookie的内部结构。客户端重试请求，这次包括其用户名和域，并回显服务器提供的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.
请注意，长期凭证机制不能用于保护指示，因为指示不能被质疑。利用指示的使用必须使用短期凭证，或忽略其身份验证和消息完整性。
To indicate that it supports this specification, a server MUST prepend the NONCE attribute value with the character string composed of "obMatJos2" concatenated with the (4-character) base64 [RFC4648] encoding of the 24-bit STUN Security Features as defined in Section 18.1. The 24-bit Security Feature set is encoded as 3 bytes, with bit 0 as the most significant bit of the first byte and bit 23 as the least significant bit of the third byte. If no security features are used, then a byte array with all 24 bits set to zero
为了表明它支持此规范，服务器必须在NONCE属性值前加上由“obMatJos2”组成的字符串，该字符串与第18.1节中定义的24位STUN安全特性的（4个字符）base64[RFC4648]编码连接。24位安全功能集编码为3个字节，位0为第一个字节的最高有效位，位23为第三个字节的最低有效位。如果未使用任何安全功能，则将所有24位设置为零的字节数组
MUST be encoded instead. For the remainder of this document, the term "nonce cookie" will refer to the complete 13-character string prepended to the NONCE attribute value.
必须改为编码。对于本文档的其余部分，术语“nonce cookie”将指在nonce属性值前面的完整13个字符的字符串。
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位随机性。在用户输入凭据的情况下，他们应该遵循关于密码结构的当前最佳实践。
This document introduces two new security features that provide the ability to choose the algorithm used for password protection as well as the ability to use an anonymous username. Both of these capabilities are optional in order to remain backwards compatible with previous versions of the STUN protocol.
本文档介绍了两个新的安全功能，它们提供了选择用于密码保护的算法以及使用匿名用户名的功能。这两种功能都是可选的，以便与以前版本的STUN协议保持向后兼容。
These new capabilities are subject to bid-down attacks whereby an attacker in the message path can remove these capabilities and force weaker security properties. To prevent these kinds of attacks from going undetected, the nonce is enhanced with additional information.
这些新功能会受到向下出价攻击的影响，消息路径中的攻击者可以删除这些功能并强制较弱的安全属性。为了防止这些类型的攻击未被发现，使用附加信息增强了nonce。
The value of the "nonce cookie" will vary based on the specific STUN Security Feature bits selected. When this document makes reference to the "nonce cookie" in a section discussing a specific STUN Security Feature it is understood that the corresponding STUN Security Feature bit in the "nonce cookie" is set to 1.
“nonce cookie”的值将根据所选的特定STUN安全功能位而变化。当本文档在讨论特定STUN安全功能的章节中提及“nonce cookie”时，可以理解，“nonce cookie”中对应的STUN安全功能位设置为1。
For example, when the PASSWORD-ALGORITHMS security feature (defined in Section 9.2.4) is used, the corresponding "Password algorithms" bit (defined in Section 18.1) is set to 1 in the "nonce cookie".
例如，当使用密码-算法安全功能（在第9.2.4节中定义）时，相应的“密码算法”位（在第18.1节中定义）在“nonce cookie”中设置为1。
For long-term credentials that do not use a different algorithm, as specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes:
对于不使用不同算法的长期凭据，如PASSWORD-algorithm属性所指定，密钥为16字节：
key = MD5(username ":" OpaqueString(realm)
":" OpaqueString(password))
key = MD5(username ":" OpaqueString(realm)
":" OpaqueString(password))
Where MD5 is defined in [RFC1321] and [RFC6151], and the OpaqueString profile is defined in [RFC8265]. The encoding used is UTF-8 [RFC3629].
其中，MD5在[RFC1321]和[RFC6151]中定义，不透明字符串配置文件在[RFC8265]中定义。使用的编码是UTF-8[RFC3629]。
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 OpaqueString has already been applied); (2) a single colon; (3) the realm, with any quotes and trailing nulls removed and after processing using OpaqueString; (4) a single colon; and (5) the password, with any trailing nulls removed and after processing using OpaqueString. For example, if the username is 'user', the realm is 'realm', and the password is '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属性（在这种情况下，已经应用了OpaqueString）中删除了任何引号和尾随空的username；（2） 单个结肠；（3） 域，在使用OpaqueString进行处理后，删除任何引号和尾随null；（4） 单个结肠；和（5）密码，删除任何尾随空，并使用OpaqueString进行处理。例如，如果用户名为“user”，域为“realm”，密码为“pass”，则16字节的HMAC密钥将是对字符串“user:realm:pass”执行MD5哈希的结果，结果哈希为0x8493FBC53BA582FB4B4C04C456BDC40EB。
The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP [RFC3261]. 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. For example, this mechanism can be used with the authentication extensions defined in [RFC5090].
当与长期凭证一起使用时，密钥的结构有助于在同样使用SIP[RFC3261]的系统中部署。通常，使用SIP摘要身份验证机制的SIP系统实际上不会将密码存储在数据库中。相反，它们存储一个名为“H（A1）”的值，该值等于上面定义的键。例如，此机制可与[RFC5090]中定义的身份验证扩展一起使用。
When a PASSWORD-ALGORITHM is used, the key length and algorithm to use are described in Section 18.5.1.
当使用密码算法时，第18.5.1节描述了密钥长度和使用的算法。
The first request from the client to the server (as identified by hostname if the DNS procedures of Section 8 are used and by IP address if not) is handled according to the rules in Section 9.2.3.1. When the client initiates a subsequent request once a previous request/response transaction has completed successfully, it follows the rules in Section 9.2.3.2. Forming a request as a consequence of a 401 (Unauthenticated) or 438 (Stale Nonce) error response is covered in Section 9.2.5 and is not considered a "subsequent request" and thus does not utilize the rules described in Section 9.2.3.2. Each of these types of requests have a different mandatory attributes.
根据第9.2.3.1节中的规则处理从客户端到服务器的第一个请求（如果使用第8节中的DNS过程，则通过主机名标识，如果未使用，则通过IP地址标识）。当客户在前一请求/响应事务成功完成后发起后续请求时，它将遵循第9.2.3.2节中的规则。第9.2.5节介绍了由于401（未经验证）或438（过时的暂时）错误响应而形成的请求，不被视为“后续请求”，因此不使用第9.2.3.2节所述的规则。每种类型的请求都有不同的强制属性。
If the client has not completed a successful request/response transaction with the server, it MUST omit the USERNAME, USERHASH, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, REALM, NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM attributes. In other words, the first request is sent as if there were no authentication or message integrity applied.
如果客户端尚未与服务器成功完成请求/响应事务，则必须省略用户名、USERHASH、MESSAGE-INTEGRITY、MESSAGE-INTEGRITY-SHA256、REALM、NONCE、PASSWORD-ALGORITHMS和PASSWORD-ALGORITHM属性。换句话说，发送第一个请求时，就好像没有应用身份验证或消息完整性一样。
Once a request/response transaction has completed, 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 MUST include either the USERNAME or USERHASH, REALM, NONCE, and PASSWORD-ALGORITHM attributes with these cached values. It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY-SHA256 attribute, computed as described in Sections 14.5 and 14.6 using the cached password. The choice between the two attributes depends on the attribute received in the response to the first request.
一旦请求/响应事务完成，服务器将向客户端提供一个域和nonce，并选择一个用户名和密码进行身份验证。客户端应该缓存用户名、密码、领域和nonce，以便与服务器进行后续通信。当客户端发送后续请求时，它必须包含用户名或USERHASH、REALM、NONCE和密码算法属性以及这些缓存值。它必须包括一个MESSAGE-INTEGRITY属性或MESSAGE-INTEGRITY-SHA256属性，按照第14.5节和第14.6节所述使用缓存密码进行计算。这两个属性之间的选择取决于在响应第一个请求时接收到的属性。
After the server has done the basic processing of a request, it performs the checks listed below in the order specified. Note that it is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server:
服务器完成请求的基本处理后，将按照指定的顺序执行下面列出的检查。请注意，建议领域值为STUN服务器提供商的域名：
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, the server MUST generate an error response with an error code of 401 (Unauthenticated). This response MUST include a REALM value. The response MUST include a NONCE, selected by the server. The server MUST NOT choose the same NONCE for two requests unless they have the same source IP address and port. The server MAY support alternate password algorithms, in which case it can list them in preferential order in a PASSWORD-ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS attribute, it MUST set the STUN Security Feature "Password algorithms" bit to 1. The server MAY support anonymous username, in which case it MUST set the STUN Security Feature "Username anonymity" bit set to 1. The response SHOULD NOT contain a USERNAME, USERHASH, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 attribute.
o 如果消息不包含message-INTEGRITY或message-INTEGRITY-SHA256属性，则服务器必须生成错误代码为401（未经验证）的错误响应。此响应必须包含领域值。响应必须包括由服务器选择的NONCE。服务器不能为两个请求选择相同的NONCE，除非它们具有相同的源IP地址和端口。服务器可能支持备用密码算法，在这种情况下，它可以在password-algorithms属性中按优先顺序列出它们。如果服务器添加PASSWORD-ALGORITHMS属性，则必须将STUN安全功能“PASSWORD-ALGORITHMS”位设置为1。服务器可能支持匿名用户名，在这种情况下，它必须将STUN安全功能“用户名匿名”位设置为1。响应不应包含用户名、USERHASH、MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性。
Note: Reusing a NONCE for different source IP addresses or ports was not explicitly forbidden in [RFC5389].
注意：在[RFC5389]中没有明确禁止为不同的源IP地址或端口重用NONCE。
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute, but is missing either the USERNAME or USERHASH, 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, USERHASH, NONCE, or REALM
o 如果消息包含message-INTEGRITY或message-INTEGRITY-SHA256属性，但缺少USERNAME或USERHASH、REALM或NONCE属性，则服务器必须生成错误代码为400的错误响应（错误请求）。此响应不应包括用户名、USERHASH、NONCE或领域
attribute. The response cannot contain a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, as the attributes required to generate them are missing.
属性响应不能包含MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性，因为缺少生成它们所需的属性。
o If the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithms" bit set to 1, the server performs these checks in the order specified:
o 如果NONCE属性以“NONCE cookie”开头，且STUN安全功能“Password algorithms”位设置为1，则服务器将按照指定的顺序执行这些检查：
* If the request contains neither the PASSWORD-ALGORITHMS nor the PASSWORD-ALGORITHM algorithm, then the request is processed as though PASSWORD-ALGORITHM were MD5.
* 如果请求既不包含PASSWORD-ALGORITHMS，也不包含PASSWORD-ALGORITHM，则该请求的处理方式与PASSWORD-ALGORITHM是MD5一样。
* Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD-ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches the value sent in the response that sent this NONCE, and (3) PASSWORD-ALGORITHM matches one of the entries in PASSWORD-ALGORITHMS, the server MUST generate an error response with an error code of 400 (Bad Request).
* 否则，除非（1）PASSWORD-ALGORITHM和PASSWORD-ALGORITHMS都存在，（2）PASSWORD-ALGORITHMS与发送此NONCE的响应中发送的值匹配，（3）PASSWORD-ALGORITHM与PASSWORD-ALGORITHMS中的一个条目匹配，否则服务器必须生成错误代码为400的错误响应（错误请求）。
o If the value of the USERNAME or USERHASH attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthenticated). This response MUST include a REALM value. The response MUST include a NONCE, selected by the server. The response MUST include a PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a USERNAME or USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the previous key to calculate it.
o 如果USERNAME或USERHASH属性的值无效，服务器必须生成错误代码为401（未经验证）的错误响应。此响应必须包含领域值。响应必须包括由服务器选择的NONCE。响应必须包含密码-算法属性。响应不应包含用户名或USERHASH属性。响应可以包括MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性，使用前一个键来计算它。
o If the MESSAGE-INTEGRITY-SHA256 attribute is present, compute the value for the message integrity as described in Section 14.6, using the password associated with the username. Otherwise, using the same password, compute the value for the MESSAGE-INTEGRITY attribute as described in Section 14.5. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-INTEGRITY-SHA256 attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthenticated). It MUST include the REALM and NONCE attributes and SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 attribute.
o 如果存在MESSAGE-INTEGRITY-SHA256属性，请使用与用户名关联的密码，按照第14.6节所述计算消息完整性的值。否则，使用相同的密码，按照第14.5节所述计算消息完整性属性的值。如果结果值与MESSAGE-INTEGRITY属性或MESSAGE-INTEGRITY-SHA256属性的内容不匹配，则服务器必须以错误响应拒绝请求。此响应必须使用错误代码401（未经验证）。它必须包括REALM和NONCE属性，而不应包括USERNAME、USERHASH、MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性。
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, REALM, and PASSWORD-ALGORITHMS attributes and SHOULD NOT include the USERNAME and USERHASH attributes. The NONCE attribute value MUST be valid. The response MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the
o 如果NONCE不再有效，服务器必须生成错误代码为438（Stale NONCE）的错误响应。此响应必须包括NONCE、REALM和PASSWORD-ALGORITHMS属性，而不应包括USERNAME和USERHASH属性。NONCE属性值必须有效。响应可以包括MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性，使用
previous NONCE to calculate it. Servers can revoke nonces in order to provide additional security. See Section 5.4 of [RFC7616] for guidelines.
前一个NONCE来计算它。服务器可以撤销nonce以提供额外的安全性。有关指南，请参见[RFC7616]第5.4节。
If these checks pass, the server continues to process the request. Any response generated by the server MUST include the MESSAGE-INTEGRITY-SHA256 attribute, computed using the username and password utilized to authenticate the request, unless the request was processed as though PASSWORD-ALGORITHM was MD5 (because the request contained neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case, the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE-INTEGRITY-SHA256 attribute, and the REALM, NONCE, USERNAME, and USERHASH attributes SHOULD NOT be included.
如果这些检查通过，服务器将继续处理该请求。服务器生成的任何响应都必须包含MESSAGE-INTEGRITY-SHA256属性，该属性使用用于验证请求的用户名和密码计算，除非将请求当作password-ALGORITHM是MD5处理（因为请求既不包含password-ALGORITHMS，也不包含password-ALGORITHM）。在这种情况下，必须使用MESSAGE-INTEGRITY属性而不是MESSAGE-INTEGRITY-SHA256属性，并且不应包括REALM、NONCE、USERNAME和USERHASH属性。
If the response is an error response with an error code of 401 (Unauthenticated) or 438 (Stale Nonce), the client MUST test if the NONCE attribute value starts with the "nonce cookie". If so and the "nonce cookie" has the STUN Security Feature "Password algorithms" bit set to 1 but no PASSWORD-ALGORITHMS attribute is present, then the client MUST NOT retry the request with a new transaction.
如果响应是错误代码为401（未经验证）或438（过时的Nonce）的错误响应，则客户端必须测试Nonce属性值是否以“Nonce cookie”开头。如果是，并且“nonce cookie”的STUN安全功能“Password algorithms”位设置为1，但不存在Password-algorithms属性，则客户端不得使用新事务重试请求。
If the response is an error response with an error code of 401 (Unauthenticated), the client SHOULD retry the request with a new transaction. This request MUST contain a USERNAME or a USERHASH, determined by the client as the appropriate username for the REALM from the error response. If the "nonce cookie" is present and has the STUN Security Feature "Username anonymity" bit set to 1, then the USERHASH attribute MUST be used; else, the USERNAME attribute MUST be used. The request MUST contain the REALM, copied from the error response. The request MUST contain the NONCE, copied from the error response. If the response contains a PASSWORD-ALGORITHMS attribute, the request MUST contain the PASSWORD-ALGORITHMS attribute with the same content. If the response contains a PASSWORD-ALGORITHMS attribute, and this attribute contains at least one algorithm that is supported by the client, then the request MUST contain a PASSWORD-ALGORITHM attribute with the first algorithm supported on the list. If the response contains a PASSWORD-ALGORITHMS attribute, and this attribute does not contain any algorithm that is supported by the client, then the client MUST NOT retry the request with a new transaction. The client MUST NOT perform this retry if it is not changing the USERNAME, USERHASH, REALM, or its associated password from the previous attempt.
如果响应是错误代码为401（未经验证）的错误响应，则客户端应使用新事务重试请求。此请求必须包含用户名或USERHASH，由客户端根据错误响应确定为域的适当用户名。如果“nonce cookie”存在并且将STUN安全特性“Username匿名性”位设置为1，则必须使用USERHASH属性；否则，必须使用USERNAME属性。请求必须包含从错误响应复制的域。请求必须包含从错误响应复制的NONCE。如果响应包含PASSWORD-ALGORITHMS属性，则请求必须包含具有相同内容的PASSWORD-ALGORITHMS属性。如果响应包含PASSWORD-ALGORITHMS属性，并且该属性至少包含一个客户端支持的算法，则请求必须包含一个PASSWORD-algorithm属性，其中列表中支持的第一个算法。如果响应包含PASSWORD-ALGORITHMS属性，且该属性不包含客户端支持的任何算法，则客户端不得使用新事务重试请求。如果客户端未更改上次尝试的用户名、USERHASH、领域或其关联密码，则客户端不得执行此重试。
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 attribute supplied in the 438 (Stale Nonce) response. This retry MUST also include either the USERNAME or USERHASH, the REALM, and either the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
如果响应是错误代码为438（Stale Nonce）的错误响应，则客户端必须使用438（Stale Nonce）响应中提供的新Nonce属性重试请求。此重试还必须包括用户名或USERHASH、领域以及MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性。
For all other responses, if the NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithms" bit set to 1 but PASSWORD-ALGORITHMS is not present, the response MUST be ignored.
对于所有其他响应，如果NONCE属性以“NONCE cookie”开头，STUN安全功能“Password algorithms”位设置为1，但不存在Password-algorithms，则必须忽略响应。
If the response is an error response with an error code of 400 (Bad Request) and does not contain either the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, then the response MUST be discarded, as if it were never received. This means that retransmits, if applicable, will continue.
如果响应是错误代码为400（错误请求）的错误响应，并且不包含MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性，则必须丢弃响应，就像从未收到响应一样。这意味着重新传输（如果适用）将继续。
Note: In this case, the 400 response will never reach the application, resulting in a timeout.
注意：在这种情况下，400响应永远不会到达应用程序，从而导致超时。
The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute in the response (either success or failure). If present, the client computes the message integrity over the response as defined in Sections 14.5 or 14.6, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered authenticated. If the value does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 are absent, the processing depends on the request being sent over a reliable or an unreliable transport.
客户端在响应中查找MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性（成功或失败）。如果存在，客户端将使用用于请求的相同密码，按照第14.5节或第14.6节中的定义，计算响应上的消息完整性。如果结果值与MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性的内容匹配，则响应被视为已验证。如果该值不匹配，或者如果MESSAGE-INTEGRITY和MESSAGE-INTEGRITY-SHA256都不存在，则处理取决于通过可靠或不可靠传输发送的请求。
If the request was sent over an unreliable transport, the response MUST be discarded, as if it had never been received. This means that retransmits, if applicable, will continue. If all the responses received are discarded, then instead of signaling a timeout after ending the transaction, the layer MUST signal that the integrity protection was violated.
如果请求是通过不可靠的传输发送的，则必须丢弃响应，就像从未收到响应一样。这意味着重新传输（如果适用）将继续。如果接收到的所有响应都被丢弃，则层必须发出完整性保护被违反的信号，而不是在事务结束后发出超时信号。
If the request was sent over a reliable transport, the response MUST be discarded, and the layer MUST immediately end the transaction and signal that the integrity protection was violated.
如果请求是通过可靠传输发送的，则必须放弃响应，层必须立即结束事务并发出完整性保护被违反的信号。
If the response contains a PASSWORD-ALGORITHMS attribute, all the subsequent requests MUST be authenticated using MESSAGE-INTEGRITY-SHA256 only.
如果响应包含PASSWORD-ALGORITHMS属性，则必须仅使用MESSAGE-INTEGRITY-SHA256对所有后续请求进行身份验证。
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. The ALTERNATE-SERVER attribute carries an IP address.
本节介绍STUN中的一种机制，该机制允许服务器将客户端重定向到另一台服务器。此扩展是可选的，用法必须定义是否以及何时使用此扩展。备用服务器属性包含一个IP地址。
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 at least one ALTERNATE-SERVER attribute in the error response, which MUST contain an IP address of the same address family as the source IP address of the request message. The server SHOULD include an additional ALTERNATE-SERVER attribute, after the mandatory one, that contains an IP address of the address family other than the source IP address of the request message. The error response message MAY be authenticated; however, there are use cases for ALTERNATE-SERVER where authentication of the response is not possible or practical. If the transaction uses TLS or DTLS, if the transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute, and if the server wants to redirect to a server that uses a different certificate, then it MUST include an ALTERNATE-DOMAIN attribute containing the name inside the subjectAltName of that certificate. This series of conditions on the MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction is authenticated and that the client implements this specification and therefore can process the ALTERNATE-DOMAIN attribute.
使用此扩展的服务器通过使用错误代码为300的错误响应消息回复请求消息，从而将客户端重定向到另一台服务器（请尝试备用）。服务器必须在错误响应中至少包含一个备用服务器属性，该属性必须包含与请求消息的源IP地址相同的地址系列的IP地址。服务器应在强制属性之后包含一个附加的备用服务器属性，该属性包含除请求消息的源IP地址之外的地址系列的IP地址。可以对错误响应消息进行认证；然而，对于ALTERNATE-SERVER来说，在一些用例中，响应的身份验证是不可能或不实用的。如果事务使用TLS或DTL，如果事务通过MESSAGE-INTEGRITY-SHA256属性进行身份验证，并且如果服务器希望重定向到使用不同证书的服务器，则它必须包含一个备用域属性，该属性包含该证书的subjectAltName内的名称。MESSAGE-INTEGRITY-SHA256属性上的这一系列条件表示事务已通过身份验证，并且客户端实现了此规范，因此可以处理ALTERNATE-DOMAIN属性。
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 transport protocol uses TLS or DTLS, then the client looks for an ALTERNATE-DOMAIN attribute. If the attribute is found, the domain MUST be used to validate the certificate using the recommendations in [RFC6125]. The certificate MUST contain an identifier of type DNS-ID or CN-ID (eventually with wildcards) but not of type SRV-ID or URI-ID. If the attribute is not found, the same domain that was used for the original request MUST be used to validate the certificate. If the client has been redirected to a server to which it has already sent 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）错误代码，如下所示。客户端在错误响应中查找备用服务器属性。如果找到一个，则客户端会认为当前事务失败，并使用属性中指定的服务器重新尝试请求，使用与前一个请求相同的传输协议。该请求如果经过身份验证，则必须使用客户端在向执行重定向的服务器发出的请求中使用的相同凭据。如果传输协议使用TLS或DTL，则客户端将查找备用域属性。如果找到该属性，则必须使用域来使用[RFC6125]中的建议验证证书。证书必须包含类型为DNS-ID或CN-ID（最终为通配符）的标识符，但不包含类型为SRV-ID或URI-ID的标识符。如果未找到该属性，则必须使用用于原始请求的同一域来验证证书。如果客户端已被重定向到在最近五分钟内已经发送该请求的服务器，则必须忽略重定向并考虑事务失败。这可以防止在重定向循环的情况下，服务器之间的无限乒乓。
In addition to the backward compatibility already described in Section 12 of [RFC5389], DTLS MUST NOT be used with [RFC3489] (referred to as "classic STUN"). Any STUN request or indication without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST be considered invalid: all requests MUST generate a 500 (Server Error) error response, and indications MUST be ignored.
除了[RFC5389]第12节中已经描述的向后兼容性外，DTL不得与[RFC3489]（称为“经典STUN”）一起使用。DTLS上任何没有magic cookie（参见[RFC5389]第6节）的STUN请求或指示必须视为无效：所有请求必须生成500（服务器错误）错误响应，并且指示必须忽略。
This section defines the behavior of a basic, stand-alone STUN server.
本节定义了基本的、独立的STUN服务器的行为。
Historically, "classic STUN" [RFC3489] only defined the behavior of a server that was providing clients with server reflexive transport addresses by receiving and replying to STUN Binding requests. [RFC5389] redefined the protocol as an extensible framework, and the server functionality became the sole STUN Usage defined in that document. This STUN Usage is also known as "Basic STUN Server".
历史上，“classic STUN”[RFC3489]只定义了通过接收和回复STUN绑定请求向客户端提供服务器自反传输地址的服务器的行为。[RFC5389]将协议重新定义为可扩展框架，服务器功能成为该文档中定义的唯一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 or STUN over UDP/DTLS; however, DTLS and TLS provide minimal security benefits in this basic mode of operation. It does not require a keep-alive mechanism because a TCP or TLS-over-TCP connection is closed after the end of the Binding transaction. 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 clients using [RFC3489], as described in Section 11.
STUN服务器必须支持绑定方法。它不应该利用短期或长期的认证机制。这是因为验证请求所涉及的工作比简单地处理请求所涉及的工作要多。出于同样的原因，它不应该使用备用服务器机制。它必须支持UDP和TCP。它可以支持TCP/TLS上的STUN或UDP/DTLS上的STUN；然而，DTL和TLS在这种基本操作模式下提供的安全性好处最小。它不需要保持活动机制，因为TCP或TLS over TCP连接在绑定事务结束后关闭。它可以利用指纹机制，但不能要求它。因为独立服务器只运行STUN，所以指纹没有任何好处。要求它将破坏与RFC3489的兼容性，这种兼容性在独立服务器中是可取的。独立STUN服务器应支持使用[RFC3489]与客户端的向后兼容性，如第11节所述。
It is RECOMMENDED that administrators of STUN servers provide DNS entries for those servers as described in Section 8. If both A and AAAA resource records are returned, then the client can simultaneously send STUN Binding requests to the IPv4 and IPv6 addresses (as specified in [RFC8305]), as the Binding request is idempotent. Note that the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attributes that are returned will not necessarily match the address family of the server address used.
建议STUN服务器的管理员为这些服务器提供DNS条目，如第8节所述。如果同时返回A和AAAA资源记录，则客户端可以同时向IPv4和IPv6地址发送STUN绑定请求（如[RFC8305]中所述），因为绑定请求是幂等的。请注意，返回的MAPPED-ADDRESS或XOR-MAPPED-ADDRESS属性不一定与所用服务器地址的地址系列匹配。
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 13.
基本的STUN服务器本身并不是NAT遍历的解决方案。但是，它可以通过STUN使用作为解决方案的一部分。这将在第13节中进一步讨论。
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用作组件的解决方案。
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 also defines:
STUN的使用定义了STUN的实际使用方式——何时发送请求，如何处理响应，以及使用此处（或在STUN的扩展中）定义的可选过程。用法还定义了：
o Which STUN methods are used.
o 使用了哪些眩晕方法。
o What transports are used. If DTLS-over-UDP is used, then implementing the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] is mandatory.
o 使用什么运输工具。如果使用UDP上的DTLS，则必须实施[RFC6347]第4.2.1节所述的拒绝服务对策。
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 or TLS-over-TCP, a framing mechanism may be required.
o 使用什么机制来区分昏迷消息和其他消息。当通过TCP运行STUN或通过TCP运行TLS时，可能需要帧机制。
o How a STUN client determines the IP address and port of the STUN server.
o STUN客户端如何确定STUN服务器的IP地址和端口。
o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs [RFC8305]) works with non-idempotent transactions when both address families are found for the STUN server.
o 当为STUN服务器找到IPv4和IPv6地址族时，如何同时使用IPv4和IPv6地址（开心眼球[RFC8305]）处理非幂等事务。
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 此处（如指纹和备用服务器）或其他扩展中定义的可选属性是必需的。
o If MESSAGE-INTEGRITY-SHA256 truncation is permitted, and the limits permitted for truncation.
o 如果允许MESSAGE-INTEGRITY-SHA256截断，以及允许截断的限制。
o The keep-alive mechanism if STUN is run over TCP or TLS-over-TCP.
o 如果通过TCP运行STUN或通过TCP运行TLS，则保持活动机制。
o If anycast addresses can be used for the server in case 1) TCP or TLS-over-TCP or 2) authentication is used.
o 如果在1）TCP或TLS over TCP或2）使用身份验证的情况下，服务器可以使用选播地址。
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 MUST be set to zero on sending and MUST be ignored by the receiver.
长度字段中的值必须包含填充前属性值部分的长度（以字节为单位）。由于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
为了允许本规范的未来版本在需要时添加新属性，属性空间分为两个范围。类型值介于0x0000和0x7FFF之间的属性是
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.
理解必需属性，这意味着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.3.
STUN属性类型集由IANA维护。本规范规定的初始集见第18.3节。
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 [RFC3489] clients.
此属性仅由服务器用于实现与[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
图6:XOR-MAPPED-ADDRESS属性的格式
The Family field represents the IP address family and is encoded identically to the Family field in MAPPED-ADDRESS.
“族”字段表示IP地址族，其编码方式与映射地址中的“族”字段相同。
X-Port is computed by XOR'ing the mapped port with the most significant 16 bits of the magic cookie. If the IP address family is IPv4, X-Address is computed by XOR'ing the mapped IP address with the magic cookie. If the IP address family is IPv6, X-Address is computed by XOR'ing the mapped IP address with the concatenation of the magic cookie and the 96-bit transaction ID. In all cases, the XOR operation works on its inputs in network byte order (that is, the order they will be encoded in the message).
X-Port是通过将映射端口与magiccookie的最高有效16位异或来计算的。如果IP地址族是IPv4，则通过将映射的IP地址与魔法cookie异或来计算X地址。如果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 XOR'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 to provide a generic Application Layer Gateway (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 containing the authentication username. It MUST contain a UTF-8-encoded [RFC3629] sequence of fewer than 509 bytes and MUST have been processed using the OpaqueString profile [RFC8265]. A compliant implementation MUST be able to parse a UTF-8-encoded sequence of 763 or fewer octets to be compatible with [RFC5389].
USERNAME的值是包含身份验证用户名的可变长度值。它必须包含少于509字节的UTF-8编码[RFC3629]序列，并且必须使用OpaqueString配置文件[RFC8265]进行处理。兼容的实现必须能够解析763个或更少八位字节的UTF-8编码序列，以便与[RFC5389]兼容。
Note: [RFC5389] mistakenly referenced the definition of UTF-8 in [RFC2279]. [RFC2279] assumed up to 6 octets per characters encoded. [RFC2279] was replaced by [RFC3629], which allows only 4 octets per character encoded, consistent with changes made in Unicode 2.0 and ISO/IEC 10646.
注：[RFC5389]在[RFC2279]中错误引用了UTF-8的定义。[RFC2279]假设每个编码字符最多有6个八位字节。[RFC2279]被[RFC3629]所取代，它只允许每个字符编码4个八位字节，这与Unicode 2.0和ISO/IEC 10646中所做的更改一致。
Note: This specification uses the OpaqueString profile instead of the UsernameCasePreserved profile for username string processing in order to improve compatibility with deployed password stores. Many password databases used for HTTP and SIP Digest authentication store the MD5 hash of username:realm:password instead of storing a plain text password. In [RFC3489], STUN authentication was designed to be compatible with these existing databases to the extent possible, which like SIP and HTTP performed no pre-processing of usernames and passwords other than prohibiting non-space ASCII control characters. The next revision of the STUN specification, [RFC5389], used the SASLprep [RFC4013] stringprep [RFC3454] profile to pre-process usernames and passwords. SASLprep uses Unicode Normalization Form KC (Compatibility Decomposition, followed by Canonical Composition) [UAX15] and prohibits various control, space, and non-text, deprecated, or inappropriate codepoints. The PRECIS framework [RFC8264] obsoletes stringprep. PRECIS handling of usernames and passwords [RFC8265] uses Unicode Normalization Form C (Canonical Decomposition, followed by Canonical Composition). While there are specific cases where different username strings under HTTP Digest could be mapped to a single STUN username processed with OpaqueString, these cases are extremely unlikely and easy to detect and correct. With a UsernameCasePreserved profile, it would be more likely that valid usernames under HTTP Digest would not match their processed forms (specifically usernames containing bidirectional text and compatibility forms). Operators are free to further restrict the allowed codepoints in usernames to avoid problematic characters.
注意：本规范使用OpaqueString配置文件而不是usernamecaseperved配置文件来处理用户名字符串，以提高与已部署密码存储的兼容性。许多用于HTTP和SIP摘要身份验证的密码数据库存储username:realm:password的MD5哈希，而不是存储纯文本密码。在[RFC3489]中，STUN身份验证设计为尽可能与这些现有数据库兼容，这些数据库与SIP和HTTP一样，除了禁止非空格ASCII控制字符外，不执行用户名和密码的预处理。STUN规范的下一版本[RFC5389]使用SASLprep[RFC4013]stringprep[RFC3454]配置文件预处理用户名和密码。SASLprep使用Unicode规范化形式KC（兼容性分解，然后是规范组合）[UAX15]，并禁止各种控件、空格和非文本、不推荐或不适当的代码点。PRECIS框架[RFC8264]淘汰了stringprep。PRECIS对用户名和密码的处理[RFC8265]使用Unicode规范化形式C（规范分解，然后是规范组合）。虽然在某些特定情况下，HTTP摘要下的不同用户名字符串可以映射到使用OpaqueString处理的单个STUN用户名，但这些情况极不可能，也很容易检测和纠正。使用UsernameCasePreserved配置文件时，HTTP摘要下的有效用户名更有可能与其处理的表单（特别是包含双向文本和兼容性表单的用户名）不匹配。操作员可以进一步限制用户名中允许的代码点，以避免出现问题字符。
The USERHASH attribute is used as a replacement for the USERNAME attribute when username anonymity is supported.
当支持用户名匿名性时，USERHASH属性用作USERNAME属性的替换。
The value of USERHASH has a fixed length of 32 bytes. The username MUST have been processed using the OpaqueString profile [RFC8265], and the realm MUST have been processed using the OpaqueString profile [RFC8265] before hashing.
USERHASH的值具有32字节的固定长度。用户名必须使用OpaqueString配置文件[RFC8265]处理，域必须在散列之前使用OpaqueString配置文件[RFC8265]处理。
The following is the operation that the client will perform to hash the username:
以下是客户端将执行的哈希用户名操作：
userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm))
userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm))
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 SHA-1 hash, the HMAC will be 20 bytes.
MESSAGE-INTEGRITY属性包含STUN消息的HMAC-SHA1[RFC2104]。MESSAGE-INTEGRITY属性可以出现在任何STUN消息类型中。由于它使用SHA-1散列，HMAC将是20个字节。
The key for the HMAC depends on which credential mechanism is in use. Section 9.1.1 defines the key for the short-term credential mechanism, and Section 9.2.2 defines the key for the long-term credential mechanism. Other credential mechanisms MUST define the key that is used for the HMAC.
HMAC的密钥取决于正在使用的凭据机制。第9.1.1节定义了短期凭证机制的密钥，第9.2.2节定义了长期凭证机制的密钥。其他凭证机制必须定义用于HMAC的密钥。
The text used as input to HMAC is the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. The Length field of the STUN message header is adjusted to point to the end of the MESSAGE-INTEGRITY attribute. The value of the MESSAGE-INTEGRITY attribute is set to a dummy value.
用作HMAC输入的文本是STUN消息，最多包括message-INTEGRITY属性前面的属性。STUN消息头的长度字段被调整为指向message-INTEGRITY属性的末尾。MESSAGE-INTEGRITY属性的值设置为伪值。
Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute is filled in, and the value of the length in the STUN header is set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the Length field in the STUN header must be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC over the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. Such adjustment is necessary when attributes, such as FINGERPRINT and MESSAGE-INTEGRITY-SHA256, appear after MESSAGE-INTEGRITY. See also [RFC5769] for examples of such calculations.
执行计算后，将填充MESSAGE-INTEGRITY属性的值，并将STUN头中的长度值设置为其正确的值——整个消息的长度。类似地，在验证消息完整性时，在计算STUN消息上的HMAC之前，必须调整STUN头中的长度字段，使其指向消息完整性属性的末尾，直到并包括消息完整性属性之前的属性。当属性（如指纹和MESSAGE-INTEGRITY-SHA256）出现在MESSAGE-INTEGRITY之后时，这种调整是必要的。有关此类计算的示例，请参见[RFC5769]。
The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256 attribute can be present in any STUN message type. The MESSAGE-INTEGRITY-SHA256 attribute contains an initial portion of the HMAC-SHA-256 [RFC2104] of the STUN message. The value will be at most 32 bytes, but it MUST be at least 16 bytes and MUST be a multiple of 4 bytes. The value must be the full 32 bytes unless the STUN Usage explicitly specifies that truncation is allowed. STUN Usages may specify a minimum length longer than 16 bytes.
MESSAGE-INTEGRITY-SHA256属性包含STUN消息的HMAC-SHA256[RFC2104]。MESSAGE-INTEGRITY-SHA256属性可以出现在任何STUN消息类型中。MESSAGE-INTEGRITY-SHA256属性包含STUN消息的HMAC-SHA-256[RFC2104]的初始部分。该值最多为32字节，但必须至少为16字节，并且必须是4字节的倍数。除非STUN用法明确指定允许截断，否则该值必须为完整的32字节。STUN用法可以指定大于16字节的最小长度。
The key for the HMAC depends on which credential mechanism is in use. Section 9.1.1 defines the key for the short-term credential mechanism, and Section 9.2.2 defines the key for the long-term credential mechanism. Other credential mechanism MUST define the key that is used for the HMAC.
HMAC的密钥取决于正在使用的凭据机制。第9.1.1节定义了短期凭证机制的密钥，第9.2.2节定义了长期凭证机制的密钥。其他凭证机制必须定义用于HMAC的密钥。
The text used as input to HMAC is the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. The Length field of the STUN message header is adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256 attribute. The value of the MESSAGE-INTEGRITY-SHA256 attribute is set to a dummy value.
用作HMAC输入的文本是STUN消息，最多包含message-INTEGRITY-SHA256属性之前的属性。STUN消息头的长度字段调整为指向message-INTEGRITY-SHA256属性的末尾。MESSAGE-INTEGRITY-SHA256属性的值设置为伪值。
Once the computation is performed, the value of the MESSAGE-INTEGRITY-SHA256 attribute is filled in, and the value of the length in the STUN header is set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY-SHA256, the Length field in the STUN header must be adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256 attribute prior to calculating the HMAC over the STUN message, up to and including the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY-SHA256. See also Appendix B.1 for examples of such calculations.
执行计算后，将填充MESSAGE-INTEGRITY-SHA256属性的值，并将STUN头中的长度值设置为正确的值——整个消息的长度。类似地，在验证MESSAGE-INTEGRITY-SHA256时，在计算STUN消息上的HMAC之前，必须调整STUN头中的长度字段，使其指向MESSAGE-INTEGRITY-SHA256属性的末尾，直到并包括MESSAGE-INTEGRITY-SHA256属性之前的属性。当属性（如指纹）出现在MESSAGE-INTEGRITY-SHA256之后时，这种调整是必要的。有关此类计算的示例，请参见附录B.1。
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 operation ensures that the FINGERPRINT test will not report a false positive on a packet containing a CRC-32 generated by an application protocol.) The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which
属性值计算为STUN消息的CRC-32，最多（但不包括）指纹属性本身，与32位值0x5354554e异或。（异或操作确保指纹测试不会在包含应用协议生成的CRC-32的数据包上报告假阳性。）32位CRC是ITU V.42[ITU.V42.2002]中定义的CRC
has a generator polynomial of x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1. See the sample code for the CRC-32 in Section 8 of [RFC1952].
具有x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1的生成器多项式。参见[RFC1952]第8节中CRC-32的示例代码。
When present, the FINGERPRINT attribute MUST be the last attribute in the message and thus will appear after MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256.
当存在时，指纹属性必须是消息中的最后一个属性，因此将出现在message-INTEGRITY和message-INTEGRITY-SHA256之后。
The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 7.
指纹属性可以帮助区分STUN数据包与其他协议的数据包。见第7节。
As with MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, the CRC used in the FINGERPRINT attribute covers the Length field from the STUN message header. Therefore, prior to computation of the CRC, this value must be correct and include the CRC attribute as part of the message length. 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 the value of the attribute is updated. If the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 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 and MESSAGE-INTEGRITY-SHA256 attributes as well.
与MESSAGE-INTEGRITY和MESSAGE-INTEGRITY-SHA256一样，指纹属性中使用的CRC覆盖STUN消息头中的长度字段。因此，在计算CRC之前，该值必须是正确的，并且包含CRC属性作为消息长度的一部分。当在消息中使用指纹属性时，该属性首先以伪值放入消息中；然后，计算CRC，并更新属性值。如果MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性也存在，则在计算CRC之前，它必须具有正确的MESSAGE INTEGRITY值，因为CRC也是在MESSAGE-INTEGRITY和MESSAGE-INTEGRITY-SHA256属性的值上进行的。
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]; it is also consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC7231]. The reason phrase is meant for diagnostic purposes 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-encoded [RFC3629] sequence of fewer than 128 characters (which can be as long as 509 bytes when encoding them or 763 bytes when decoding them).
错误代码属性用于错误响应消息中。它包含一个介于300到699之间的数字错误代码值，外加一个以UTF-8[RFC3629]编码的文本原因短语；它的代码分配和语义也与SIP[RFC3261]和HTTP[RFC7231]一致。原因短语用于诊断目的，可以是适用于错误代码的任何内容。已定义错误代码的推荐原因短语包含在IANA错误代码注册表中。原因短语必须是少于128个字符的UTF-8编码[RFC3629]序列（编码时可以长到509字节，解码时可以长到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: Format of 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 binary encoding of 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 either a USERNAME or USERHASH attribute and a valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 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 or MESSAGE-INTEGRITY-SHA256 attribute, and receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 of this response before redirecting themselves to an alternate server.
300 Try Alternate：客户端应为此请求联系备用服务器。只有当请求包含用户名或USERHASH属性以及有效的MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性时，才能发送此错误响应；否则，不得发送该请求，并建议发送错误代码400（错误请求）。此错误响应必须使用MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性进行保护，并且接收方必须在将自己重定向到备用服务器之前验证此响应的MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256。
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 or MESSAGE-INTEGRITY-SHA256 for this error, so the client MUST NOT expect a valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute on this response.
400错误请求：请求格式不正确。如果未对上一次尝试进行修改，客户端不应重试该请求。服务器可能无法为此错误生成有效的MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256，因此客户端不能期望此响应具有有效的MESSAGE-INTEGRITY或MESSAGE-INTEGRITY-SHA256属性。
401 Unauthenticated: 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 [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-encoded [RFC3629] sequence of fewer than 128 characters (which can be as long as 509 bytes when encoding them and as long as 763 bytes when decoding them) and MUST have been processed using the OpaqueString profile [RFC8265].
REALM属性可能存在于请求和响应中。它包含符合[RFC3261]中描述的“领域值”语法的文本，但没有双引号及其周围的空白。也就是说，它是一个不带引号的领域值（因此是一个qdtext序列或带引号的对）。它必须是少于128个字符的UTF-8编码[RFC3629]序列（编码时可长达509字节，解码时可长达763字节），并且必须使用OpaqueString配置文件[RFC8265]进行处理。
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 in that realm 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 [RFC3261]. Note that this means that the NONCE attribute will not contain the actual surrounding quote characters. The NONCE attribute MUST be fewer than 128 characters (which can be as long as 509 bytes when encoding them and a long as 763 bytes when decoding them). See Section 5.4 of [RFC7616] for guidance on selection of nonce values in a server.
NONCE属性可能存在于请求和响应中。它包含[RFC3261]中定义的qdtext或quoted对序列。注意，这意味着NONCE属性将不包含实际的引号字符。NONCE属性必须少于128个字符（编码时可长达509字节，解码时可长达763字节）。有关在服务器中选择nonce值的指导，请参见[RFC7616]的第5.4节。
The PASSWORD-ALGORITHMS attribute may be present in requests and responses. It contains the list of algorithms that the server can use to derive the long-term password.
密码-算法属性可能出现在请求和响应中。它包含服务器可用于导出长期密码的算法列表。
The set of known algorithms is maintained by IANA. The initial set defined by this specification is found in Section 18.5.
已知算法集由IANA维护。本规范规定的初始集见第18.5节。
The attribute contains a list of algorithm numbers and variable length parameters. The algorithm number is a 16-bit value as defined in Section 18.5. The parameters start with the length (prior to padding) of the parameters as a 16-bit value, followed by the parameters that are specific to each algorithm. The parameters are padded to a 32-bit boundary, in the same manner as an attribute.
该属性包含算法编号和可变长度参数的列表。算法编号为第18.5节中定义的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 1 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 | Algorithm 2 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 Parameters (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 1 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 | Algorithm 2 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
Figure 8: Format of PASSWORD-ALGORITHMS Attribute
图8：密码-算法属性的格式
The PASSWORD-ALGORITHM attribute is present only in requests. It contains the algorithm that the server must use to derive a key from the long-term password.
密码-算法属性仅在请求中存在。它包含服务器从长期密码中派生密钥时必须使用的算法。
The set of known algorithms is maintained by IANA. The initial set defined by this specification is found in Section 18.5.
已知算法集由IANA维护。本规范规定的初始集见第18.5节。
The attribute contains an algorithm number and variable length parameters. The algorithm number is a 16-bit value as defined in Section 18.5. The parameters starts with the length (prior to padding) of the parameters as a 16-bit value, followed by the parameters that are specific to the algorithm. The parameters are padded to a 32-bit boundary, in the same manner as an attribute. Similarly, the padding bits MUST be set to zero on sending and MUST be ignored by the receiver.
该属性包含算法编号和可变长度参数。算法编号为第18.5节中定义的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Algorithm Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Parameters (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Algorithm Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of PASSWORD-ALGORITHM Attribute
图9：密码-算法属性的格式
The UNKNOWN-ATTRIBUTES attribute is present only in an error response when the response code in the ERROR-CODE attribute is 420 (Unknown Attribute).
当错误代码属性中的响应代码为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 10: Format of UNKNOWN-ATTRIBUTES Attribute
图10：未知属性的格式
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-encoded [RFC3629] sequence of fewer than 128 characters (which can be as long as 509 when encoding them and as long as 763 bytes when decoding them).
“软件”属性包含发送消息的代理正在使用的软件的文本描述。它由客户端和服务器使用。其值应包括制造商和版本号。该属性对协议的操作没有影响，仅用作诊断和调试工具。软件的价值是可变长度的。它必须是一个UTF-8编码的[RFC3629]序列，少于128个字符（编码时可长达509个字节，解码时可长达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.
它的编码方式与映射地址相同，因此通过IP地址引用单个服务器。
The alternate domain represents the domain name that is used to verify the IP address in the ALTERNATE-SERVER attribute when the transport protocol uses TLS or DTLS.
备用域表示当传输协议使用TLS或DTL时，用于验证备用服务器属性中的IP地址的域名。
The value of ALTERNATE-DOMAIN is variable length. It MUST be a valid DNS name [RFC1123] (including A-labels [RFC5890]) of 255 or fewer ASCII characters.
ALTERNATE-DOMAIN的值是可变长度的。它必须是255个或更少ASCII字符的有效DNS名称[RFC1123]（包括a标签[RFC5890]）。
STUN MAY be used with anycast addresses, but only with UDP and in STUN Usages where authentication is not used.
STUN可与选播地址一起使用，但仅用于UDP和不使用身份验证的STUN使用中。
Implementations and deployments of a STUN Usage using TLS or DTLS MUST follow the recommendations in [BCP195].
使用TLS或DTL实施和部署STUN必须遵循[BCP195]中的建议。
Implementations and deployments of a STUN Usage using the long-term credential mechanism (Section 9.2) MUST follow the recommendations in Section 5 of [RFC7616].
使用长期凭证机制（第9.2节）实施和部署STUN使用必须遵循[RFC7616]第5节中的建议。
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 13, STUN Usages describe when authentication and message integrity are needed.
根据STUN的使用情况，这些攻击的后果可能最小，因此不需要消息完整性来缓解。例如，当将STUN用于基本STUN服务器以发现服务器自反候选以用于ICE时，不需要身份验证和消息完整性，因为这些攻击是在连接检查阶段检测到的。然而，连接检查本身需要保护，以确保ICE的正常运行。如第13节所述，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 or DTLS, mitigates these attacks.
由于STUN使用共享秘密的HMAC进行身份验证和完整性保护，因此它会受到脱机字典攻击。使用身份验证时，应使用不易受到脱机字典攻击的强密码。使用TLS或DTL保护通道本身可以减轻这些攻击。
STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, which makes STUN subject to bid-down attacks by an on-path attacker. An attacker could strip the MESSAGE-INTEGRITY-SHA256 attribute, leaving only the MESSAGE-INTEGRITY attribute and thus exploiting a potential vulnerability. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. Timely removal of the support of MESSAGE-INTEGRITY in a future version of STUN is necessary.
STUN同时支持MESSAGE-INTEGRITY和MESSAGE-INTEGRITY-SHA256，这使得STUN容易受到路径上攻击者的下注攻击。攻击者可以剥离MESSAGE-INTEGRITY-SHA256属性，只留下MESSAGE-INTEGRITY属性，从而利用潜在漏洞进行攻击。使用TLS或DTL保护通道本身可以减轻这些攻击。在未来版本的STUN中，需要及时删除对消息完整性的支持。
Note: The use of SHA-256 for password hashing does not meet modern standards, which are aimed at slowing down exhaustive password searches by providing a relatively slow minimum time to compute the hash. Although better algorithms such as Argon2 [Argon2] are available, SHA-256 was chosen for consistency with [RFC7616].
注意：使用SHA-256进行密码散列不符合现代标准，现代标准旨在通过提供相对较慢的最短散列计算时间来减缓穷举密码搜索。尽管有更好的算法，如Argon2[Argon2]，但选择SHA-256是为了与[RFC7616]保持一致。
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 effectively.
恶意客户端可能会通过向服务器发送大量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 document adds the possibility of selecting different algorithms to protect the confidentiality of the passwords stored on the server side when using the long-term credential mechanism while still
本文档增加了选择不同算法的可能性，以保护服务器端存储的密码在使用长期凭证机制时的机密性，同时
ensuring compatibility with MD5, which was the algorithm used in [RFC5389]. This selection works by having the server send to the client the list of algorithms supported in a PASSWORD-ALGORITHMS attribute and having the client send back a PASSWORD-ALGORITHM attribute containing the algorithm selected.
确保与[RFC5389]中使用的算法MD5兼容。此选择通过让服务器向客户端发送PASSWORD-algorithms属性中支持的算法列表，并让客户端发回包含所选算法的PASSWORD-ALGORITHM属性来工作。
Because the PASSWORD-ALGORITHMS attribute has to be sent in an unauthenticated response, an on-path attacker wanting to exploit an eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS attribute from the unprotected response, thus making the server subsequently act as if the client was implementing the version of this protocol defined in [RFC5389].
由于PASSWORD-ALGORITHMS属性必须在未经验证的响应中发送，因此想要利用MD5中的最终漏洞进行攻击的路径上攻击者只需从未受保护的响应中删除PASSWORD-ALGORITHMS属性，因此，使服务器随后发挥作用，就好像客户机正在实现[RFC5389]中定义的该协议版本一样。
To protect against this attack and other similar bid-down attacks, the nonce is enriched with a set of security bits that indicates which security features are in use. In the case of the selection of the password algorithm, the matching bit is set in the nonce returned by the server in the same response that contains the PASSWORD-ALGORITHMS attribute. Because the nonce used in subsequent authenticated transactions is verified by the server to be identical to what was originally sent, it cannot be modified by an on-path attacker. Additionally, the client is mandated to copy the received PASSWORD-ALGORITHMS attribute in the next authenticated transaction to that server.
为了防止此攻击和其他类似的下标攻击，nonce中增加了一组安全位，用于指示正在使用的安全功能。在选择密码算法的情况下，匹配位在服务器在包含password-ALGORITHMS属性的相同响应中返回的nonce中设置。由于服务器验证后续经过身份验证的事务中使用的nonce与最初发送的相同，因此路径上的攻击者无法修改该nonce。此外，客户机必须在下一个经过身份验证的事务中将收到的PASSWORD-ALGORITHMS属性复制到该服务器。
An on-path attack that removes the PASSWORD-ALGORITHMS will be detected because the client will not be able to send it back to the server in the next authenticated transaction. The client will detect that attack because the security bit is set but the matching attribute is missing; this will end the session. A client using an older version of this protocol will not send the PASSWORD-ALGORITHMS back but can only use MD5 anyway, so the attack is inconsequential.
将检测到删除密码算法的路径攻击，因为客户端将无法在下一个经过身份验证的事务中将其发送回服务器。客户端将检测到该攻击，因为设置了安全位，但缺少匹配属性；这将结束会话。使用此协议的旧版本的客户端不会将密码算法发回，但无论如何只能使用MD5，因此攻击是无关紧要的。
The on-path attack may also try to remove the security bit together with the PASSWORD-ALGORITHMS attribute, but the server will discover that when the next authenticated transaction contains an invalid nonce.
路径攻击还可能试图删除安全位和PASSWORD-ALGORITHMS属性，但服务器将在下一个经过身份验证的事务包含无效nonce时发现。
An on-path attack that removes some algorithms from the PASSWORD-ALGORITHMS attribute will be equally defeated because that attribute will be different from the original one when the server verifies it in the subsequent authenticated transaction.
从PASSWORD-algorithms属性中删除某些算法的路径攻击将同样被击败，因为当服务器在随后的已验证事务中验证该属性时，该属性将与原始属性不同。
Note that the bid-down protection mechanism introduced in this document is inherently limited by the fact that it is not possible to detect an attack until the server receives the second request after the 401 (Unauthenticated) response.
请注意，本文档中引入的降价保护机制本质上受到以下事实的限制：在服务器收到401（未经验证）响应后的第二个请求之前，不可能检测到攻击。
SHA-256 was chosen as the new default for password hashing for its compatibility with [RFC7616], but because SHA-256 (like MD5) is a comparatively fast algorithm, it does little to deter brute-force attacks. Specifically, this means that if the user has a weak password, an attacker that captures a single exchange can use a brute-force attack to learn the user's password and then potentially impersonate the user to the server and to other servers where the same password was used. Note that such an attacker can impersonate the user to the server itself without any brute-force attack.
由于与[RFC7616]的兼容性，SHA-256被选为密码哈希的新默认值，但由于SHA-256（与MD5一样）是一种相对快速的算法，它对阻止暴力攻击几乎没有作用。具体而言，这意味着，如果用户的密码较弱，则捕获单个exchange的攻击者可以使用暴力攻击来了解用户的密码，然后向服务器和使用相同密码的其他服务器模拟用户。请注意，此类攻击者可以向服务器本身模拟用户，而无需任何暴力攻击。
A stronger (which is to say, slower) algorithm, like Argon2 [Argon2], would help both of these cases; however, in the first case, it would only help after the database entry for this user is updated to exclusively use that stronger mechanism.
一个更强（也就是说，更慢）的算法，比如Argon2[Argon2]，将有助于这两种情况；但是，在第一种情况下，只有在更新该用户的数据库条目以专门使用该更强大的机制之后，它才会有所帮助。
The bid-down defenses in this protocol prevent an attacker from forcing the client and server to complete a handshake using weaker algorithms than they jointly support, but only if the weakest joint algorithm is strong enough that it cannot be compromised by a brute-force attack. However, this does not defend against many attacks on those algorithms; specifically, an on-path attacker might perform a bid-down attack on a client that supports both Argon2 [Argon2] and SHA-256 for password hashing and use that to collect a MESSAGE-INTEGRITY-SHA256 value that it can then use for an offline brute-force attack. This would be detected when the server receives the second request, but that does not prevent the attacker from obtaining the MESSAGE-INTEGRITY-SHA256 value.
此协议中的出价下降防御可防止攻击者使用比他们共同支持的算法更弱的算法强迫客户端和服务器完成握手，但前提是最弱的联合算法足够强大，无法被暴力攻击破坏。然而，这并不能抵御对这些算法的许多攻击；具体而言，路径上的攻击者可能会对同时支持Argon2[Argon2]和SHA-256进行密码哈希的客户端执行向下出价攻击，并使用该攻击收集MESSAGE-INTEGRITY-SHA256值，然后使用该值进行脱机暴力攻击。这将在服务器收到第二个请求时检测到，但这不会阻止攻击者获取MESSAGE-INTEGRITY-SHA256值。
Similarly, an attack against the USERHASH mechanism will not succeed in establishing a session as the server will detect that the feature was discarded on path, but the client would still have been convinced to send its username in the clear in the USERNAME attribute, thus disclosing it to the attacker.
类似地，针对USERHASH机制的攻击也不会成功建立会话，因为服务器会检测到该功能在路径上被丢弃，但客户端仍会被说服在用户名属性中以明文形式发送其用户名，从而向攻击者披露。
Finally, when the bid-down protection mechanism is employed for a future upgrade of the HMAC algorithm used to protect messages, it will offer only a limited protection if the current HMAC algorithm is already compromised.
最后，当在用于保护消息的HMAC算法的未来升级中采用降价保护机制时，如果当前HMAC算法已经受损，它将只提供有限的保护。
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 countermeasures.
本节列出了可能针对使用眩晕而发起的攻击。每个STUN使用必须考虑这些攻击是否适用于它，如果是，则讨论对策。
Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by a STUN client through a Binding request/response transaction. Since the usage of the
本节中的大多数攻击都是围绕攻击者修改STUN客户端通过绑定请求/响应事务学习的自反地址展开的。自从使用
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 and the intervening NAT must be able to modify this value. Instead, one solution to prevent the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [RFC8445].
自反地址是用法的函数，这些攻击的适用性和修复是用法特定的。在常见情况下，路径上攻击者很容易修改自反地址。例如，考虑STUN直接在UDP上运行的常见情况。在这种情况下，路径上攻击者可以在绑定请求到达STUN服务器之前修改其源IP地址。然后，STUN服务器将XOR-MAPPED-address属性中的该IP地址返回给客户端，并将响应发送回该（伪造的）IP地址和端口。如果攻击者也可以拦截此响应，则可以将其定向回客户端。由于消息完整性值不能覆盖源IP地址，且介入的NAT必须能够修改该值，因此无法使用消息完整性检查来防止此攻击。相反，防止下面列出的攻击的一个解决方案是让客户端验证所学到的自反地址，如ICE[RFC8445]中所做的那样。
Other usages may use other means to prevent these attacks.
其他用途可能使用其他方法来防止这些攻击。
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 described 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 allows 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服务器的路径上的流量时有用，但通常不在路由到客户端的数据包路径上有用。
Note that this attack can be trivially launched by the STUN server itself, so users of STUN servers should have the same level of trust in the users of STUN servers as any other node that can insert itself into the communication flow.
请注意，此攻击很容易由STUN服务器本身发起，因此，STUN服务器的用户对STUN服务器用户的信任程度应与能够将自身插入通信流的任何其他节点相同。
This specification uses HMAC-SHA256 for computation of the message integrity, sometimes in combination with HMAC-SHA1. If, at a later time, HMAC-SHA256 is found to be compromised, the following remedy should be applied:
本规范使用HMAC-SHA256计算消息完整性，有时与HMAC-SHA1结合使用。如果以后发现HMAC-SHA256受损，应采取以下补救措施：
o Both a new message-integrity attribute and a new STUN Security Feature bit will be allocated in a Standards Track document. The new message-integrity attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously 1) signal to a STUN client using the long-term credential mechanism that this server supports this new hash algorithm and 2) prevent bid-down attacks on the new message-integrity attribute.
o 将在标准跟踪文档中分配新的消息完整性属性和新的STUN安全功能位。新的消息完整性属性将使用新的哈希计算其值。STUN安全功能位将用于同时1）使用长期凭证机制向STUN客户端发送信号，表明此服务器支持此新哈希算法，2）防止对新消息完整性属性的下标攻击。
o STUN clients and servers using the short-term credential mechanism will need to update the external mechanism that they use to signal what message-integrity attributes are in use.
o 使用短期凭证机制的STUN客户端和服务器将需要更新外部机制，这些机制用于通知正在使用哪些消息完整性属性。
The bid-down protection mechanism described in this document is new and thus cannot currently protect against a bid-down attack that lowers the strength of the hash algorithm to HMAC-SHA1. This is why,
本文档中描述的下标保护机制是新的，因此目前无法防止将哈希算法强度降低到HMAC-SHA1的下标攻击。这就是为什么,，
after a transition period, a new document updating this one will assign a new STUN Security Feature bit for deprecating HMAC-SHA1. When used, this bit will signal that HMAC-SHA1 is deprecated and should no longer be used.
过渡期过后，更新此文档的新文档将为弃用HMAC-SHA1分配新的STUN安全功能位。使用时，此位将表示HMAC-SHA1已弃用，不应再使用。
Similarly, if HMAC-SHA256 is found to be compromised, a new userhash attribute and a new STUN Security Feature bit will be allocated in a Standards Track document. The new userhash attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously 1) signal to a STUN client using the long-term credential mechanism that this server supports this new hash algorithm for the userhash attribute and 2) prevent bid-down attacks on the new userhash attribute.
类似地，如果发现HMAC-SHA256被破坏，将在标准跟踪文档中分配新的userhash属性和新的STUN安全功能位。新的userhash属性将使用新的hash计算其值。STUN安全功能位将用于同时1）使用长期凭证机制向STUN客户端发送信号，表明此服务器支持userhash属性的新哈希算法，2）防止对新userhash属性的下标攻击。
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 through a collaborative protocol reflection mechanism [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.
IAB研究了单边自地址固定（UNSAF）问题，该问题是客户端通过协作协议反射机制试图确定其在NAT另一侧另一个域中的地址的一般过程[RFC3424]。如果一个代理位于NAT后面，另一个位于NAT的公共端，则可以使用绑定请求/响应事务来执行此功能。
The IAB has suggested that protocols developed for this purpose document a specific set of considerations. Because some STUN Usages provide UNSAF functions (such as ICE [RFC8445]) and others do not (such as SIP Outbound [RFC5626]), answers to these considerations need to be addressed by the usages themselves.
IAB建议为此目的制定的协议记录一组具体的考虑因素。由于一些STUN使用提供UNSAF功能（如ICE[RFC8445]），而其他使用不提供（如SIP Outbound[RFC5626]），因此这些注意事项的答案需要由使用本身解决。
A STUN Security Feature set defines 24 bits as flags.
眩晕安全功能集将24位定义为标志。
IANA has created a new registry containing the STUN Security Features that are protected by the bid-down attack prevention mechanism described in Section 9.2.1.
IANA已经创建了一个新的注册表，其中包含受第9.2.1节所述的拒绝出价攻击预防机制保护的STUN安全功能。
The initial STUN Security Features are:
最初的眩晕安全功能包括：
Bit 0: Password algorithms Bit 1: Username anonymity Bit 2-23: Unassigned
第0位：密码算法第1位：用户名匿名第2-23位：未分配
Bits are assigned starting from the most significant side of the bit set, so Bit 0 is the leftmost bit and Bit 23 is the rightmost bit.
位从位集的最高有效侧开始分配，因此位0是最左边的位，位23是最右边的位。
New Security Features are assigned by Standards Action [RFC8126].
新的安全功能由标准行动[RFC8126]指定。
A STUN method is a hex number in the range 0x000-0x0FF. The encoding of a STUN method into a STUN message is described in Section 5.
眩晕方法是0x000-0x0FF范围内的十六进制数。第5节描述了将STUN方法编码为STUN消息的过程。
STUN methods in the range 0x000-0x07F are assigned by IETF Review [RFC8126]. STUN methods in the range 0x080-0x0FF are assigned by Expert Review [RFC8126]. The responsibility of the expert is to verify that the selected codepoint(s) is 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-0x07F范围内的STUN方法由IETF评审[RFC8126]分配。0x080-0x0FF范围内的STUN方法由专家评审分配[RFC8126]。专家的责任是验证所选的代码点未被使用，并且请求的代码点数量不是异常多。延期本身的技术审查不属于指定专家的责任范围。
IANA has updated the name for method 0x002 as described below as well as updated the reference from RFC 5389 to RFC 8489 for the following STUN methods:
IANA已更新方法0x002的名称，如下所述，并将以下STUN方法的参考从RFC 5389更新为RFC 8489：
0x000: Reserved 0x001: Binding 0x002: Reserved; was SharedSecret prior to [RFC5389]
0x000:保留0x001:绑定0x002:保留；在[RFC5389]之前是共享机密的
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代理以不同的方式处理未知的“必需理解”和“可选理解”属性。
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 [RFC8126]. 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 Expert Review [RFC8126]. 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[RFC8126]分配理解要求范围（0x0000-0x3FFF）前半部分和理解可选范围（0x8000-0xBFFF）前半部分的眩晕属性类型。理解要求范围（0x4000-0x7FFF）后半部分和理解可选范围（0xC000-0xFFFF）后半部分的眩晕属性类型由专家评审分配[RFC8126]。专家的责任是验证所选的代码点是否未被使用，以及请求的代码点数量是否异常多。延期本身的技术审查不属于指定专家的责任范围。
IANA has updated the names for attributes 0x0002, 0x0004, 0x0005, 0x0007, and 0x000B as well as updated the reference from RFC 5389 to RFC 8489 for each the following STUN methods.
IANA已更新了属性0x0002、0x0004、0x0005、0x0007和0x000B的名称，并更新了以下每种STUN方法从RFC 5389到RFC 8489的引用。
In addition, [RFC5389] introduced a mistake in the name of attribute 0x0003; [RFC5389] called it CHANGE-ADDRESS when it was actually previously called CHANGE-REQUEST. Thus, IANA has updated the description for 0x0003 to read "Reserved; was CHANGE-REQUEST prior to [RFC5389]".
此外，[RFC5389]在属性0x0003的名称中引入了一个错误；[RFC5389]将其称为变更地址，而实际上它以前被称为变更请求。因此，IANA已将0x0003的描述更新为“保留；在[RFC5389]之前是变更请求”。
Comprehension-required range (0x0000-0x7FFF):
0x0000: Reserved
0x0001: MAPPED-ADDRESS
0x0002: Reserved; was RESPONSE-ADDRESS prior to [RFC5389]
0x0003: Reserved; was CHANGE-REQUEST prior to [RFC5389]
0x0004: Reserved; was SOURCE-ADDRESS prior to [RFC5389]
0x0005: Reserved; was CHANGED-ADDRESS prior to [RFC5389]
0x0006: USERNAME
0x0007: Reserved; was PASSWORD prior to [RFC5389]
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x000B: Reserved; was REFLECTED-FROM prior to [RFC5389]
0x0014: REALM
0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS
Comprehension-required range (0x0000-0x7FFF):
0x0000: Reserved
0x0001: MAPPED-ADDRESS
0x0002: Reserved; was RESPONSE-ADDRESS prior to [RFC5389]
0x0003: Reserved; was CHANGE-REQUEST prior to [RFC5389]
0x0004: Reserved; was SOURCE-ADDRESS prior to [RFC5389]
0x0005: Reserved; was CHANGED-ADDRESS prior to [RFC5389]
0x0006: USERNAME
0x0007: Reserved; was PASSWORD prior to [RFC5389]
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x000B: Reserved; was REFLECTED-FROM prior to [RFC5389]
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:指纹
IANA has added the following attribute to the "STUN Attributes" registry:
IANA已将以下属性添加到“STUN属性”注册表中：
Comprehension-required range (0x0000-0x7FFF): 0x001C: MESSAGE-INTEGRITY-SHA256 0x001D: PASSWORD-ALGORITHM 0x001E: USERHASH
需要理解的范围（0x0000-0x7FFF）：0x001C:MESSAGE-INTEGRITY-SHA256 0x001D:PASSWORD-ALGORITHM 0x001E:USERHASH
Comprehension-optional range (0x8000-0xFFFF) 0x8002: PASSWORD-ALGORITHMS 0x8003: ALTERNATE-DOMAIN
理解可选范围（0x8000-0xFFFF）0x8002:PASSWORD-ALGORITHMS 0x8003:ALTERNATE-DOMAIN
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 [RFC7231].
STUN错误代码在代码点分配和语义上与SIP[RFC3261]和HTTP[RFC7231]一致。
New STUN error codes are assigned based on IETF Review [RFC8126]. 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 6.3.4.
根据IETF审查[RFC8126]分配新的STUN错误代码。规范必须仔细考虑不理解此错误代码的客户端在授予请求之前将如何处理该错误代码。参见第6.3.4节中的规则。
IANA has updated the reference from RFC 5389 to RFC 8489 for the error codes defined in Section 14.8.
IANA已将第14.8节中定义的错误代码的参考从RFC 5389更新为RFC 8489。
IANA has changed the name of the 401 error code from "Unauthorized" to "Unauthenticated".
IANA已将401错误代码的名称从“Unauthorized”更改为“Unauthorized”。
IANA has created a new registry titled "STUN Password Algorithms".
IANA创建了一个名为“STUN密码算法”的新注册表。
A password algorithm is a hex number in the range 0x0000-0xFFFF.
密码算法是0x0000-0xFFFF范围内的十六进制数。
The initial contents of the "Password Algorithm" registry are as follows:
“密码算法”注册表的初始内容如下：
0x0000: Reserved 0x0001: MD5 0x0002: SHA-256 0x0003-0xFFFF: Unassigned
0x0000:保留0x0001:MD5 0x0002:SHA-256 0x0003-0xFFFF:未分配
Password algorithms in the first half of the range (0x0000-0x7FFF) are assigned by IETF Review [RFC8126]. Password algorithms in the second half of the range (0x8000-0xFFFF) are assigned by Expert Review [RFC8126].
IETF Review[RFC8126]分配前一半范围（0x0000-0x7FFF）内的密码算法。范围后半部分（0x8000-0xFFFF）的密码算法由专家评审分配[RFC8126]。
This password algorithm is taken from [RFC1321].
此密码算法取自[RFC1321]。
The key length is 16 bytes, and the parameters value is empty.
密钥长度为16字节，参数值为空。
Note: This algorithm MUST only be used for compatibility with legacy systems.
注意：此算法只能用于与旧系统兼容。
key = MD5(username ":" OpaqueString(realm)
":" OpaqueString(password))
key = MD5(username ":" OpaqueString(realm)
":" OpaqueString(password))
This password algorithm is taken from [RFC7616].
此密码算法取自[RFC7616]。
The key length is 32 bytes, and the parameters value is empty.
密钥长度为32字节，参数值为空。
key = SHA-256(username ":" OpaqueString(realm)
":" OpaqueString(password))
key = SHA-256(username ":" OpaqueString(realm)
":" OpaqueString(password))
IANA has updated the reference from RFC 5389 to RFC 8489 for the following ports in the "Service Name and Transport Protocol Port Number Registry".
IANA已将“服务名称和传输协议端口号注册表”中以下端口的参考从RFC 5389更新为RFC 8489。
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/NAT（stun）端口的tcp会话遍历实用程序stun 3478/NAT（stun）端口的udp会话遍历实用程序stun 5349/NAT（stun）端口的tcp会话遍历实用程序
This specification obsoletes [RFC5389]. This specification differs from RFC 5389 in the following ways:
本规范废除了[RFC5389]。本规范与RFC 5389的不同之处如下：
o Added support for DTLS-over-UDP [RFC6347].
o 添加了对UDP上DTL的支持[RFC6347]。
o Made clear that the RTO is considered stale if there are no transactions with the server.
o 明确指出，如果与服务器没有事务，则RTO被视为过时。
o Aligned the RTO calculation with [RFC6298].
o 将RTO计算与[RFC6298]对齐。
o Updated the ciphersuites for TLS.
o 更新了TLS的密码套件。
o Added support for STUN URI [RFC7064].
o 增加了对stunuri[RFC7064]的支持。
o Added support for SHA256 message integrity.
o 增加了对SHA256消息完整性的支持。
o Updated the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) support to [RFC8265].
o 将国际化字符串（PRECIS）支持的准备、实施和比较更新为[RFC8265]。
o Added protocol and registry to choose the password encryption algorithm.
o 添加了协议和注册表以选择密码加密算法。
o Added support for anonymous username.
o 增加了对匿名用户名的支持。
o Added protocol and registry for preventing bid-down attacks.
o 增加了协议和注册表以防止出价下降攻击。
o Specified that sharing a NONCE is no longer permitted.
o 指定不再允许共享NONCE。
o Added the possibility of using a domain name in the alternate server mechanism.
o 增加了在备用服务器机制中使用域名的可能性。
o Added more C snippets.
o 添加了更多的C代码段。
o Added test vector.
o 添加了测试向量。
[ITU.V42.2002] International Telecommunication 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月。
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM '87, Proceedings of the ACM workshop on Frontiers in computer communications technology, Pages 2-7, DOI 10.1145/55483.55484, August 1987.
[KARN87]Karn，P.和C.Partridge，“改进可靠传输协议中的往返时间估计”，SIGCOMM'87，《计算机通信技术前沿ACM研讨会论文集》，第2-7页，DOI 10.1145/55483.55484，1987年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<https://www.rfc-editor.org/info/rfc1123>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC 1321，DOI 10.17487/RFC1321，1992年4月<https://www.rfc-editor.org/info/rfc1321>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 6151，DOI 10.17487/RFC6151，2011年3月<https://www.rfc-editor.org/info/rfc6151>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 6298，DOI 10.17487/RFC62982011年6月<https://www.rfc-editor.org/info/rfc6298>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-Huguenin, "URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064, November 2013, <https://www.rfc-editor.org/info/rfc7064>.
[RFC7064]Nandakumar，S.，Salgueiro，G.，Jones，P.，和M.Petit Huguenin，“NAT（STUN）协议会话遍历实用程序的URI方案”，RFC 7064，DOI 10.17487/RFC7064，2013年11月<https://www.rfc-editor.org/info/rfc7064>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[RFC7350]Petit Huguenin，M.和G.Salgueiro，“作为NAT（STUN）会话遍历实用程序传输的数据报传输层安全性（DTLS）”，RFC 7350，DOI 10.17487/RFC7350，2014年8月<https://www.rfc-editor.org/info/rfc7350>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<https://www.rfc-editor.org/info/rfc7616>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，STD 86，RFC 8200，DOI 10.17487/RFC8200，2017年7月<https://www.rfc-editor.org/info/rfc8200>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>.
[RFC8265]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 8265，DOI 10.17487/RFC8265，2017年10月<https://www.rfc-editor.org/info/rfc8265>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305]Schinazi，D.和T.Pauly，“快乐眼球第2版：使用并发实现更好的连接”，RFC 8305，DOI 10.17487/RFC8305，2017年12月<https://www.rfc-editor.org/info/rfc8305>.
[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "The memory-hard Argon2 password hash and proof-of-work function", Work in Progress, draft-irtf-cfrg-argon2-09, November 2019.
[Argon2]Biryukov，A.，Dinu，D.，Khovratovich，D.，和S.Josefsson，“内存硬Argon2密码哈希和工作证明函数”，正在进行的工作，草稿-irtf-cfrg-Argon2-092019年11月。
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <https://www.rfc-editor.org/info/bcp195>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<https://www.rfc-editor.org/info/bcp195>.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.
[RFC1952]Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC 1952，DOI 10.17487/RFC1952，1996年5月<https://www.rfc-editor.org/info/rfc1952>.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, DOI 10.17487/RFC2279, January 1998, <https://www.rfc-editor.org/info/rfc2279>.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，DOI 10.17487/RFC2279，1998年1月<https://www.rfc-editor.org/info/rfc2279>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <https://www.rfc-editor.org/info/rfc3424>.
[RFC3424]Daigle，L.，Ed.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 3424DOI 10.17487/RFC3424，2002年11月<https://www.rfc-editor.org/info/rfc3424>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化字符串的准备（“stringprep”）”，RFC 3454，DOI 10.17487/RFC3454，2002年12月<https://www.rfc-editor.org/info/rfc3454>.
[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, DOI 10.17487/RFC3489, March 2003, <https://www.rfc-editor.org/info/rfc3489>.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，DOI 10.17487/RFC3489，2003年3月<https://www.rfc-editor.org/info/rfc3489>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, <https://www.rfc-editor.org/info/rfc4013>.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC 4013，DOI 10.17487/RFC4013，2005年2月<https://www.rfc-editor.org/info/rfc4013>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，DOI 10.17487/RFC4107，2005年6月<https://www.rfc-editor.org/info/rfc4107>.
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, DOI 10.17487/RFC5090, February 2008, <https://www.rfc-editor.org/info/rfc5090>.
[RFC5090]Sterman，B.，Sadolevsky，D.，Schwartz，D.，Williams，D.，和W.Beck，“摘要认证的半径扩展”，RFC 5090DOI 10.17487/RFC5090，2008年2月<https://www.rfc-editor.org/info/rfc5090>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<https://www.rfc-editor.org/info/rfc5389>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>.
[RFC5626]Jennings，C.，Ed.，Mahy，R.，Ed.，和F.Audet，Ed.，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，DOI 10.17487/RFC5626，2009年10月<https://www.rfc-editor.org/info/rfc5626>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<https://www.rfc-editor.org/info/rfc5766>.
[RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769, April 2010, <https://www.rfc-editor.org/info/rfc5769>.
[RFC5769]Denis Courmont，R.，“NAT（STUN）会话遍历实用程序的测试向量”，RFC 5769，DOI 10.17487/RFC5769，2010年4月<https://www.rfc-editor.org/info/rfc5769>.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>.
[RFC5780]MacDonald，D.和B.Lowekamp，“使用NAT会话遍历实用程序进行NAT行为发现（STUN）”，RFC 5780，DOI 10.17487/RFC5780，2010年5月<https://www.rfc-editor.org/info/rfc5780>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC6544]Rosenberg，J.，Keranen，A.，Lowekamp，B.，和A.Roach，“具有交互式连接建立（ICE）的TCP候选者”，RFC 6544，DOI 10.17487/RFC65442012年3月<https://www.rfc-editor.org/info/rfc6544>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>.
[RFC8264]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备、实施和比较”，RFC 8264，DOI 10.17487/RFC8264，2017年10月<https://www.rfc-editor.org/info/rfc8264>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]Keranen，A.，Holmberg，C.，和J.Rosenberg，“交互式连接建立（ICE）：网络地址转换器（NAT）遍历协议”，RFC 8445，DOI 10.17487/RFC84452018年7月<https://www.rfc-editor.org/info/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[STUN-PMTUD] Petit-Huguenin, M., Salgueiro, G., and F. Garrido, "Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN)", Work in Progress, draft-ietf-tram-stun-pmtud-15, December 2019.
[STUN-PMTUD]Petit Huguenin，M.，Salgueiro，G.，和F.Garrido，“使用NAT会话遍历实用程序（STUN）的UDP传输包化层路径MTU发现（PLMTUD）”，正在进行中，草案-ietf-tram-STUN-PMTUD-152019年12月。
[UAX15] Unicode Standard Annex #15, "Unicode Normalization Forms", edited by Mark Davis and Ken Whistler. An integral part of The Unicode Standard, <http://unicode.org/reports/tr15/>.
[UAX15]Unicode标准附件#15，“Unicode规范化表单”，由Mark Davis和Ken Whistler编辑。Unicode标准不可分割的一部分<http://unicode.org/reports/tr15/>.
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宏：
<CODE BEGINS>
#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)
<CODE ENDS>
<CODE BEGINS>
#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)
<CODE ENDS>
A function to convert method and class into a message type:
将方法和类转换为消息类型的函数：
<CODE BEGINS>
int type(int method, int cls) {
return (method & 0x1F80) << 2 | (method & 0x0070) << 1
| (method & 0x000F) | (cls & 0x0002) << 7
| (cls & 0x0001) << 4;
}
<CODE ENDS>
<CODE BEGINS>
int type(int method, int cls) {
return (method & 0x1F80) << 2 | (method & 0x0070) << 1
| (method & 0x000F) | (cls & 0x0002) << 7
| (cls & 0x0001) << 4;
}
<CODE ENDS>
A function to extract the method from the message type:
从消息类型中提取方法的函数：
<CODE BEGINS>
int method(int type) {
return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1
| (type & 0x000F);
}
<CODE ENDS>
<CODE BEGINS>
int method(int type) {
return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1
| (type & 0x000F);
}
<CODE ENDS>
A function to extract the class from the message type:
从消息类型中提取类的函数：
<CODE BEGINS>
int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
}
<CODE ENDS>
<CODE BEGINS>
int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
}
<CODE ENDS>
This section augments the list of test vectors defined in [RFC5769] with MESSAGE-INTEGRITY-SHA256. All the formats and definitions listed in Section 2 of [RFC5769] apply here.
本节使用MESSAGE-INTEGRITY-SHA256扩充了[RFC5769]中定义的测试向量列表。[RFC5769]第2节中列出的所有格式和定义在此适用。
B.1. Sample Request with Long-Term Authentication with MESSAGE-INTEGRITY-SHA256 and USERHASH
B.1. 使用MESSAGE-INTEGRITY-SHA256和USERHASH进行长期身份验证的示例请求
This request uses the following parameters:
此请求使用以下参数：
Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without
quotes) unaffected by OpaqueString [RFC8265] processing
Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without
quotes) unaffected by OpaqueString [RFC8265] processing
Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
quotes) respectively before and after OpaqueString [RFC8265]
processing
Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
quotes) respectively before and after OpaqueString [RFC8265]
processing
Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes)
Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes)
Realm: "example.org" (without quotes)
领域：“example.org”（不带引号）
00 01 00 9c Request type and message length
21 12 a4 42 Magic cookie
78 ad 34 33 }
c6 ad 72 c0 } Transaction ID
29 da 41 2e }
00 1e 00 20 USERHASH attribute header
4a 3c f3 8f }
ef 69 92 bd }
a9 52 c6 78 }
04 17 da 0f } Userhash value (32 bytes)
24 81 94 15 }
56 9e 60 b2 }
05 c4 6e 41 }
40 7f 17 04 }
00 15 00 29 NONCE attribute header
6f 62 4d 61 }
74 4a 6f 73 }
32 41 41 41 }
43 66 2f 2f }
34 39 39 6b } Nonce value and padding (3 bytes)
39 35 34 64 }
36 4f 4c 33 }
34 6f 4c 39 }
46 53 54 76 }
79 36 34 73 }
41 00 00 00 }
00 01 00 9c Request type and message length
21 12 a4 42 Magic cookie
78 ad 34 33 }
c6 ad 72 c0 } Transaction ID
29 da 41 2e }
00 1e 00 20 USERHASH attribute header
4a 3c f3 8f }
ef 69 92 bd }
a9 52 c6 78 }
04 17 da 0f } Userhash value (32 bytes)
24 81 94 15 }
56 9e 60 b2 }
05 c4 6e 41 }
40 7f 17 04 }
00 15 00 29 NONCE attribute header
6f 62 4d 61 }
74 4a 6f 73 }
32 41 41 41 }
43 66 2f 2f }
34 39 39 6b } Nonce value and padding (3 bytes)
39 35 34 64 }
36 4f 4c 33 }
34 6f 4c 39 }
46 53 54 76 }
79 36 34 73 }
41 00 00 00 }
00 14 00 0b REALM attribute header
65 78 61 6d }
70 6c 65 2e } Realm value (11 bytes) and padding (1 byte)
6f 72 67 00 }
00 1c 00 20 MESSAGE-INTEGRITY-SHA256 attribute header
e4 68 6c 8f }
0e de b5 90 }
13 e0 70 90 }
01 0a 93 ef } HMAC-SHA256 value
cc bc cc 54 }
4c 0a 45 d9 }
f8 30 aa 6d }
6f 73 5a 01 }
00 14 00 0b REALM attribute header
65 78 61 6d }
70 6c 65 2e } Realm value (11 bytes) and padding (1 byte)
6f 72 67 00 }
00 1c 00 20 MESSAGE-INTEGRITY-SHA256 attribute header
e4 68 6c 8f }
0e de b5 90 }
13 e0 70 90 }
01 0a 93 ef } HMAC-SHA256 value
cc bc cc 54 }
4c 0a 45 d9 }
f8 30 aa 6d }
6f 73 5a 01 }
Acknowledgements
致谢
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston, Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson, Mihaly Meszaros, Tolga Asveren, Noriyuki Torii, Spencer Dawkins, Dale Worley, Matthew Miller, Peter Saint-Andre, Julien Elie, Mirja Kuehlewind, Eric Rescorla, Ben Campbell, Adam Roach, Alexey Melnikov, and Benjamin Kaduk for the comments, suggestions, and questions that helped improve this document.
感谢Michael Tuexen、Tirumaleswar Reddy、Oleg Moskalenko、Simon Perreault、Benjamin Schwartz、Rifaat Shekh Yusef、Alan Johnston、Jonathan Lennox、Brandon Williams、Olle Johansson、Martin Thomson、Mihaly Meszaros、Tolga Asveren、Noriyuki Tori、Spencer Dawkins、Dale Worley、Matthew Miller、Peter Saint Andre、Julie Elie、Mirja Kuehlewind、，Eric Rescorla、Ben Campbell、Adam Roach、Alexey Melnikov和Benjamin Kaduk为帮助改进本文档的评论、建议和问题。
The Acknowledgements section of RFC 5389 appeared as follows:
RFC 5389的确认部分如下所示：
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投入。
Contributors
贡献者
Christian Huitema and Joel Weinberger were original coauthors of RFC 3489.
Christian Huitema和Joel Weinberger是RFC 3489的最初合著者。
Authors' Addresses
作者地址
Marc Petit-Huguenin Impedance Mismatch
Marc Petit Huguenin阻抗失配
Email: marc@petit-huguenin.org
Email: marc@petit-huguenin.org
Gonzalo Salgueiro Cisco 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
冈萨罗·萨尔盖罗思科7200-12美国北卡罗来纳州基特克里克路三角研究公园27709
Email: gsalguei@cisco.com
Email: gsalguei@cisco.com
Jonathan Rosenberg Five9 Edison, NJ United States of America
Jonathan Rosenberg Five9 Edison，新泽西州美利坚合众国
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Dan Wing Citrix Systems, Inc. United States of America
Dan Wing Citrix Systems，Inc.美利坚合众国
Email: dwing-ietf@fuggles.com
Email: dwing-ietf@fuggles.com
Rohan Mahy Unaffiliated
Rohan Mahy非附属公司
Email: rohan.ietf@gmail.com
Email: rohan.ietf@gmail.com
Philip Matthews Nokia 600 March Road Ottawa, Ontario K2K 2T6 Canada
加拿大安大略省渥太华三月路600号菲利普·马修斯诺基亚K2K 2T6
Phone: 613-784-3139 Email: philip_matthews@magma.ca
电话：613-784-3139电子邮件：philip_matthews@magma.ca