Network Working Group J. Rosenberg
Request for Comments: 3489 J. Weinberger
Category: Standards Track dynamicsoft
C. Huitema
Microsoft
R. Mahy
Cisco
March 2003
Network Working Group J. Rosenberg
Request for Comments: 3489 J. Weinberger
Category: Standards Track dynamicsoft
C. Huitema
Microsoft
R. Mahy
Cisco
March 2003
STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure.
通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）（STUN）是一种轻量级协议，允许应用程序发现NAT的存在和类型以及它们与公共互联网之间的防火墙。它还为应用程序提供了确定NAT分配给它们的公共互联网协议（IP）地址的能力。STUN与许多现有NAT一起工作，不需要它们有任何特殊行为。因此，它允许各种各样的应用程序通过现有的NAT基础设施工作。
Table of Contents
目录
1. Applicability Statement ................................... 3
2. Introduction .............................................. 3
3. Terminology ............................................... 4
4. Definitions ............................................... 5
5. NAT Variations ............................................ 5
6. Overview of Operation ..................................... 6
7. Message Overview .......................................... 8
8. Server Behavior ........................................... 10
8.1 Binding Requests .................................... 10
1. Applicability Statement ................................... 3
2. Introduction .............................................. 3
3. Terminology ............................................... 4
4. Definitions ............................................... 5
5. NAT Variations ............................................ 5
6. Overview of Operation ..................................... 6
7. Message Overview .......................................... 8
8. Server Behavior ........................................... 10
8.1 Binding Requests .................................... 10
8.2 Shared Secret Requests .............................. 13
9. Client Behavior ........................................... 14
9.1 Discovery ........................................... 15
9.2 Obtaining a Shared Secret ........................... 15
9.3 Formulating the Binding Request ..................... 17
9.4 Processing Binding Responses ........................ 17
10. Use Cases ................................................. 19
10.1 Discovery Process ................................... 19
10.2 Binding Lifetime Discovery .......................... 21
10.3 Binding Acquisition ................................. 23
11. Protocol Details .......................................... 24
11.1 Message Header ...................................... 25
11.2 Message Attributes .................................. 26
11.2.1 MAPPED-ADDRESS .............................. 27
11.2.2 RESPONSE-ADDRESS ............................ 27
11.2.3 CHANGED-ADDRESS ............................. 28
11.2.4 CHANGE-REQUEST .............................. 28
11.2.5 SOURCE-ADDRESS .............................. 28
11.2.6 USERNAME .................................... 28
11.2.7 PASSWORD .................................... 29
11.2.8 MESSAGE-INTEGRITY ........................... 29
11.2.9 ERROR-CODE .................................. 29
11.2.10 UNKNOWN-ATTRIBUTES .......................... 31
11.2.11 REFLECTED-FROM .............................. 31
12. Security Considerations ................................... 31
12.1 Attacks on STUN ..................................... 31
12.1.1 Attack I: DDOS Against a Target ............. 32
12.1.2 Attack II: Silencing a Client ............... 32
12.1.3 Attack III: Assuming the Identity of a Client 32
12.1.4 Attack IV: Eavesdropping .................... 33
12.2 Launching the Attacks ............................... 33
12.2.1 Approach I: Compromise a Legitimate
STUN Server ................................. 33
12.2.2 Approach II: DNS Attacks .................... 34
12.2.3 Approach III: Rogue Router or NAT ........... 34
12.2.4 Approach IV: MITM ........................... 35
12.2.5 Approach V: Response Injection Plus DoS ..... 35
12.2.6 Approach VI: Duplication .................... 35
12.3 Countermeasures ..................................... 36
12.4 Residual Threats .................................... 37
13. IANA Considerations ....................................... 38
14. IAB Considerations ........................................ 38
14.1 Problem Definition .................................. 38
14.2 Exit Strategy ....................................... 39
14.3 Brittleness Introduced by STUN ...................... 40
14.4 Requirements for a Long Term Solution ............... 42
14.5 Issues with Existing NAPT Boxes ..................... 43
14.6 In Closing .......................................... 43
8.2 Shared Secret Requests .............................. 13
9. Client Behavior ........................................... 14
9.1 Discovery ........................................... 15
9.2 Obtaining a Shared Secret ........................... 15
9.3 Formulating the Binding Request ..................... 17
9.4 Processing Binding Responses ........................ 17
10. Use Cases ................................................. 19
10.1 Discovery Process ................................... 19
10.2 Binding Lifetime Discovery .......................... 21
10.3 Binding Acquisition ................................. 23
11. Protocol Details .......................................... 24
11.1 Message Header ...................................... 25
11.2 Message Attributes .................................. 26
11.2.1 MAPPED-ADDRESS .............................. 27
11.2.2 RESPONSE-ADDRESS ............................ 27
11.2.3 CHANGED-ADDRESS ............................. 28
11.2.4 CHANGE-REQUEST .............................. 28
11.2.5 SOURCE-ADDRESS .............................. 28
11.2.6 USERNAME .................................... 28
11.2.7 PASSWORD .................................... 29
11.2.8 MESSAGE-INTEGRITY ........................... 29
11.2.9 ERROR-CODE .................................. 29
11.2.10 UNKNOWN-ATTRIBUTES .......................... 31
11.2.11 REFLECTED-FROM .............................. 31
12. Security Considerations ................................... 31
12.1 Attacks on STUN ..................................... 31
12.1.1 Attack I: DDOS Against a Target ............. 32
12.1.2 Attack II: Silencing a Client ............... 32
12.1.3 Attack III: Assuming the Identity of a Client 32
12.1.4 Attack IV: Eavesdropping .................... 33
12.2 Launching the Attacks ............................... 33
12.2.1 Approach I: Compromise a Legitimate
STUN Server ................................. 33
12.2.2 Approach II: DNS Attacks .................... 34
12.2.3 Approach III: Rogue Router or NAT ........... 34
12.2.4 Approach IV: MITM ........................... 35
12.2.5 Approach V: Response Injection Plus DoS ..... 35
12.2.6 Approach VI: Duplication .................... 35
12.3 Countermeasures ..................................... 36
12.4 Residual Threats .................................... 37
13. IANA Considerations ....................................... 38
14. IAB Considerations ........................................ 38
14.1 Problem Definition .................................. 38
14.2 Exit Strategy ....................................... 39
14.3 Brittleness Introduced by STUN ...................... 40
14.4 Requirements for a Long Term Solution ............... 42
14.5 Issues with Existing NAPT Boxes ..................... 43
14.6 In Closing .......................................... 43
15. Acknowledgments ........................................... 44
16. Normative References ...................................... 44
17. Informative References .................................... 44
18. Authors' Addresses ........................................ 46
19. Full Copyright Statement................................... 47
15. Acknowledgments ........................................... 44
16. Normative References ...................................... 44
17. Informative References .................................... 44
18. Authors' Addresses ........................................ 46
19. Full Copyright Statement................................... 47
This protocol is not a cure-all for the problems associated with NAT. It does not enable incoming TCP connections through NAT. It allows incoming UDP packets through NAT, but only through a subset of existing NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs (defined below), which are common in large enterprises. STUN's discovery procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid down the road as new NAT devices are deployed. STUN does not work when it is used to obtain an address to communicate with a peer which happens to be behind the same NAT. STUN does not work when the STUN server is not in a common shared address realm. For a more complete discussion of the limitations of STUN, see Section 14.
该协议不是NAT相关问题的万灵丹。它不启用通过NAT的传入TCP连接。它允许通过NAT传入UDP数据包，但只能通过现有NAT类型的子集。特别是，STUN不支持通过对称NAT（定义如下）传入UDP数据包，这在大型企业中很常见。STUN的发现程序基于UDP的NAT处理假设；随着新NAT设备的部署，这些假设可能会被证明是无效的。当STUN用于获取一个地址以与恰好位于同一NAT后面的对等方通信时，它不起作用。当STUN服务器不在公共共享地址域中时，STUN不工作。有关STUN限制的更完整讨论，请参见第14节。
Network Address Translators (NATs), while providing many benefits, also come with many drawbacks. The most troublesome of those drawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Guidelines have been developed [8] that describe how to build "NAT friendly" protocols, but many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include almost all peer-to-peer protocols, such as multimedia communications, file sharing and games.
网络地址转换器（NAT）虽然有许多优点，但也有许多缺点。这些缺点中最麻烦的是，它们破坏了许多现有的IP应用程序，并使部署新的应用程序变得困难。已经制定了指南[8]，描述了如何构建“NAT友好”协议，但许多协议根本无法根据这些指南构建。此类协议的示例包括几乎所有的对等协议，例如多媒体通信、文件共享和游戏。
To combat this problem, Application Layer Gateways (ALGs) have been embedded in NATs. ALGs perform the application layer functions required for a particular protocol to traverse a NAT. Typically, this involves rewriting application layer messages to contain translated addresses, rather than the ones inserted by the sender of the message. ALGs have serious limitations, including scalability, reliability, and speed of deploying new applications. To resolve these problems, the Middlebox Communications (MIDCOM) protocol is being developed [9]. MIDCOM allows an application entity, such as an end client or network server of some sort (like a Session Initiation Protocol (SIP) proxy [10]) to control a NAT (or firewall), in order to obtain NAT bindings and open or close pinholes. In this way, NATs and applications can be separated once more, eliminating the need for embedding ALGs in NATs, and resolving the limitations imposed by current architectures.
为了解决这个问题，NAT中嵌入了应用层网关（ALG）。ALG执行特定协议穿越NAT所需的应用层功能。通常，这涉及重写应用层消息以包含翻译后的地址，而不是消息发送者插入的地址。ALG具有严重的局限性，包括可扩展性、可靠性和部署新应用程序的速度。为了解决这些问题，正在开发中间盒通信（MIDCOM）协议[9]。MIDCOM允许应用程序实体（如终端客户端或某种类型的网络服务器（如会话启动协议（SIP）代理[10]）控制NAT（或防火墙），以获得NAT绑定并打开或关闭针孔。通过这种方式，NAT和应用程序可以再次分离，消除了在NAT中嵌入ALG的需要，并解决了当前体系结构施加的限制。
Unfortunately, MIDCOM requires upgrades to existing NAT and firewalls, in addition to application components. Complete upgrades of these NAT and firewall products will take a long time, potentially years. This is due, in part, to the fact that the deployers of NAT and firewalls are not the same people who are deploying and using applications. As a result, the incentive to upgrade these devices will be low in many cases. Consider, for example, an airport Internet lounge that provides access with a NAT. A user connecting to the NATed network may wish to use a peer-to-peer service, but cannot, because the NAT doesn't support it. Since the administrators of the lounge are not the ones providing the service, they are not motivated to upgrade their NAT equipment to support it, using either an ALG, or MIDCOM.
不幸的是，除了应用程序组件外，MIDCOM还需要升级现有NAT和防火墙。这些NAT和防火墙产品的完整升级将需要很长时间，可能需要数年。这部分是由于NAT和防火墙的部署者与部署和使用应用程序的人不同。因此，在许多情况下，升级这些设备的动机很低。例如，考虑一个提供NAT访问的机场互联网休息室。连接到网络的用户可能希望使用对等服务，但不能，因为NAT不支持它。由于休息室的管理员不是提供服务的人，因此他们没有动力使用ALG或MIDCOM升级NAT设备以支持该服务。
Another problem is that the MIDCOM protocol requires that the agent controlling the middleboxes know the identity of those middleboxes, and have a relationship with them which permits control. In many configurations, this will not be possible. For example, many cable access providers use NAT in front of their entire access network. This NAT could be in addition to a residential NAT purchased and operated by the end user. The end user will probably not have a control relationship with the NAT in the cable access network, and may not even know of its existence.
另一个问题是，MIDCOM协议要求控制中间盒的代理知道这些中间盒的身份，并与它们建立允许控制的关系。在许多配置中，这是不可能的。例如，许多有线接入提供商在其整个接入网络前面使用NAT。该NAT可以是终端用户购买和操作的住宅NAT的补充。最终用户可能与有线接入网络中的NAT没有控制关系，甚至可能不知道它的存在。
Many existing proprietary protocols, such as those for online games (such as the games described in RFC 3027 [11]) and Voice over IP, have developed tricks that allow them to operate through NATs without changing those NATs. This document is an attempt to take some of those ideas, and codify them into an interoperable protocol that can meet the needs of many applications.
许多现有的专有协议，如在线游戏协议（如RFC 3027[11]中描述的游戏）和IP语音协议，已经开发出一些技巧，允许它们通过NAT进行操作，而不改变这些NAT。本文档试图采纳其中的一些想法，并将它们编成一个可互操作的协议，以满足许多应用程序的需要。
The protocol described here, Simple Traversal of UDP Through NAT (STUN), allows entities behind a NAT to first discover the presence of a NAT and the type of NAT, and then to learn the addresses bindings allocated by the NAT. STUN requires no changes to NATs, and works with an arbitrary number of NATs in tandem between the application entity and the public Internet.
这里描述的协议，通过NAT简单地遍历UDP（STUN），允许NAT后面的实体首先发现NAT的存在和NAT的类型，然后了解NAT分配的地址绑定。STUN不需要更改NAT，并且在应用程序实体和公共互联网之间串联使用任意数量的NAT。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant STUN implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出符合标准的STUN实施的要求级别。
STUN Client: A STUN client (also just referred to as a client) is an entity that generates STUN requests. A STUN client can execute on an end system, such as a user's PC, or can run in a network element, such as a conferencing server.
STUN客户端：STUN客户端（也称为客户端）是生成STUN请求的实体。STUN客户端可以在终端系统（如用户的PC）上执行，也可以在网络元素（如会议服务器）中运行。
STUN Server: A STUN Server (also just referred to as a server) is an entity that receives STUN requests, and sends STUN responses. STUN servers are generally attached to the public Internet.
STUN服务器：STUN服务器（也称为服务器）是接收STUN请求并发送STUN响应的实体。STUN服务器通常连接到公共互联网。
It is assumed that the reader is familiar with NATs. It has been observed that NAT treatment of UDP varies among implementations. The four treatments observed in implementations are:
假定读者熟悉NATs。据观察，UDP的NAT处理因实现而异。在实施过程中观察到的四种处理方法是：
Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
全锥：全锥NAT是一种将来自相同内部IP地址和端口的所有请求映射到相同外部IP地址和端口的NAT。此外，任何外部主机都可以通过向映射的外部地址发送数据包来向内部主机发送数据包。
Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
受限锥形：受限锥形NAT是指来自相同内部IP地址和端口的所有请求都映射到相同外部IP地址和端口的NAT。与全锥NAT不同，外部主机（具有IP地址X）只能在内部主机之前向IP地址X发送数据包的情况下向内部主机发送数据包。
Port Restricted Cone: A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
端口受限圆锥：端口受限圆锥NAT类似于受限圆锥NAT，但限制包括端口号。具体地说，只有在内部主机之前已向IP地址X和端口P发送数据包的情况下，外部主机才能向内部主机发送具有源IP地址X和源端口P的数据包。
Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
对称：对称NAT是指从同一内部IP地址和端口到特定目标IP地址和端口的所有请求都映射到同一外部IP地址和端口的NAT。如果同一主机发送具有相同源地址和端口的数据包，但发送到不同的目的地，则使用不同的映射。此外，只有接收数据包的外部主机才能将UDP数据包发送回内部主机。
Determining the type of NAT is important in many cases. Depending on what the application wants to do, it may need to take the particular behavior into account.
在许多情况下，确定NAT的类型很重要。根据应用程序想要做什么，它可能需要考虑特定的行为。
This section is descriptive only. Normative behavior is described in Sections 8 and 9.
本节仅作说明。第8节和第9节描述了规范行为。
/-----\
// STUN \\
| Server |
\\ //
\-----/
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
Figure 1: STUN Configuration
图1:STUN配置
The typical STUN configuration is shown in Figure 1. A STUN client 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 STUN server resides on the public Internet.
典型的STUN配置如图1所示。STUN客户端连接到专用网络1。该网络通过NAT 1连接到专用网络2。专用网络2通过NAT 2连接到公共互联网。STUN服务器位于公共Internet上。
STUN is a simple client-server protocol. A client sends a request to a server, and the server returns a response. There are two types of requests - Binding Requests, sent over UDP, and Shared Secret Requests, sent over TLS [2] over TCP. Shared Secret Requests ask the server to return a temporary username and password. This username and password are used in a subsequent Binding Request and Binding Response, for the purposes of authentication and message integrity.
STUN是一个简单的客户机-服务器协议。客户端向服务器发送请求，服务器返回响应。有两种类型的请求—通过UDP发送的绑定请求和通过TCP通过TLS[2]发送的共享机密请求。共享机密请求要求服务器返回临时用户名和密码。出于身份验证和消息完整性的目的，此用户名和密码将在后续绑定请求和绑定响应中使用。
Binding requests are used to determine the bindings allocated by NATs. The client sends a Binding Request to the server, over UDP. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client. There are some parameters in the request that allow the client to ask that the response be sent elsewhere, or that the server send the response from a different address and port. There are attributes for providing message integrity and authentication.
绑定请求用于确定NAT分配的绑定。客户端通过UDP向服务器发送绑定请求。服务器检查请求的源IP地址和端口，并将它们复制到发送回客户端的响应中。请求中有一些参数允许客户端请求将响应发送到其他地方，或者服务器从不同的地址和端口发送响应。有用于提供消息完整性和身份验证的属性。
The trick is using STUN to discover the presence of NAT, and to learn and use the bindings they allocate.
诀窍是使用STUN来发现NAT的存在，并学习和使用它们分配的绑定。
The STUN client is typically embedded in an application which needs to obtain a public IP address and port that can be used to receive data. For example, it might need to obtain an IP address and port to receive Real Time Transport Protocol (RTP) [12] traffic. When the application starts, the STUN client within the application sends a STUN Shared Secret Request to its server, obtains a username and password, and then sends it a Binding Request. STUN servers can be discovered through DNS SRV records [3], and it is generally assumed that the client is configured with the domain to use to find the STUN server. Generally, this will be the domain of the provider of the service the application is using (such a provider is incented to deploy STUN servers in order to allow its customers to use its application through NAT). Of course, a client can determine the address or domain name of a STUN server through other means. A STUN server can even be embedded within an end system.
STUN客户端通常嵌入到需要获取可用于接收数据的公共IP地址和端口的应用程序中。例如，它可能需要获取IP地址和端口以接收实时传输协议（RTP）[12]流量。当应用程序启动时，应用程序中的STUN客户端向其服务器发送一个STUN共享机密请求，获取用户名和密码，然后向其发送一个绑定请求。可以通过DNS SRV记录[3]发现STUN服务器，通常假设客户机配置了用于查找STUN服务器的域。通常，这将是应用程序正在使用的服务提供商的域（此类提供商被鼓励部署STUN服务器，以便允许其客户通过NAT使用其应用程序）。当然，客户机可以通过其他方式确定STUN服务器的地址或域名。STUN服务器甚至可以嵌入到终端系统中。
The STUN Binding Request is used to discover the presence of a NAT, and to discover the public IP address and port mappings generated by the NAT. Binding Requests are sent to the STUN server using UDP. When a Binding Request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server. As a result, the source address of the request received by the server will be the mapped address created by the NAT closest to the server. The STUN server copies that source IP address and port into a STUN Binding Response, and sends it back to the source IP address and port of the STUN request. For all of the NAT types above, this response will arrive at the STUN client.
STUN绑定请求用于发现NAT的存在，并发现NAT生成的公共IP地址和端口映射。绑定请求使用UDP发送到STUN服务器。当绑定请求到达STUN服务器时，它可能已经通过了STUN客户端和STUN服务器之间的一个或多个NAT。因此，服务器接收到的请求的源地址将是最靠近服务器的NAT创建的映射地址。STUN服务器将该源IP地址和端口复制到STUN绑定响应中，并将其发送回STUN请求的源IP地址和端口。对于上述所有NAT类型，此响应将到达STUN客户端。
When the STUN client receives the STUN Binding Response, it compares the IP address and port in the packet with the local IP address and port it bound to when the request was sent. If these do not match, the STUN client is behind one or more NATs. In the case of a full-cone NAT, the IP address and port in the body of the STUN response are public, and can be used by any host on the public Internet to send packets to the application that sent the STUN request. An application need only listen on the IP address and port from which
当STUN客户端收到STUN绑定响应时，它会将数据包中的IP地址和端口与发送请求时绑定到的本地IP地址和端口进行比较。如果这些不匹配，则STUN客户端位于一个或多个NAT后面。在全锥NAT的情况下，STUN响应主体中的IP地址和端口是公共的，并且可以被公共Internet上的任何主机用于向发送STUN请求的应用程序发送数据包。一个应用程序只需要监听它的IP地址和端口
the STUN request was sent. Any packets sent by a host on the public Internet to the public address and port learned by STUN will be received by the application.
发出了晕眩请求。应用程序将接收由公用Internet上的主机发送到STUN识别的公共地址和端口的任何数据包。
Of course, the host may not be behind a full-cone NAT. Indeed, it doesn't yet know what type of NAT it is behind. To determine that, the client uses additional STUN Binding Requests. The exact procedure is flexible, but would generally work as follows. The client would send a second STUN Binding Request, this time to a different IP address, but from the same source IP address and port. If the IP address and port in the response are different from those in the first response, the client knows it is behind a symmetric NAT. To determine if it's behind a full-cone NAT, the client can send a STUN Binding Request with flags that tell the STUN server to send a response from a different IP address and port than the request was received on. In other words, if the client sent a Binding Request to IP address/port A/B using a source IP address/port of X/Y, the STUN server would send the Binding Response to X/Y using source IP address/port C/D. If the client receives this response, it knows it is behind a full cone NAT.
当然，主机可能不在完整的锥形NAT后面。事实上，它还不知道它背后是什么类型的NAT。为了确定这一点，客户端使用额外的STUN绑定请求。确切的程序是灵活的，但通常工作如下。客户端将发送第二个STUN绑定请求，这次发送到不同的IP地址，但来自相同的源IP地址和端口。如果响应中的IP地址和端口与第一个响应中的IP地址和端口不同，则客户端知道它位于对称NAT后面。为了确定它是否在完整的cone NAT之后，客户端可以发送一个带有标志的STUN绑定请求，这些标志告诉STUN服务器从不同的IP地址和端口发送响应，而不是从上接收到请求。换句话说，如果客户机使用源IP地址/端口X/Y向IP地址/端口a/B发送绑定请求，STUN服务器将使用源IP地址/端口C/D向X/Y发送绑定响应。如果客户机收到此响应，它知道它在完整的cone NAT后面。
STUN also allows the client to ask the server to send the Binding Response from the same IP address the request was received on, but with a different port. This can be used to detect whether the client is behind a port restricted cone NAT or just a restricted cone NAT.
STUN还允许客户端请求服务器从接收请求的相同IP地址发送绑定响应，但使用不同的端口。这可用于检测客户端是位于端口受限的cone NAT后面，还是仅位于受限的cone NAT后面。
It should be noted that the configuration in Figure 1 is not the only permissible configuration. The STUN server can be located anywhere, including within another client. The only requirement is that the STUN server is reachable by the client, and if the client is trying to obtain a publicly routable address, that the server reside on the public Internet.
应该注意的是，图1中的配置不是唯一允许的配置。STUN服务器可以位于任何位置，包括另一个客户端内。唯一的要求是，客户机可以访问STUN服务器，如果客户机试图获取一个公开的可路由地址，那么服务器必须位于公共Internet上。
STUN messages are TLV (type-length-value) encoded using big endian (network ordered) binary. All STUN messages start with a STUN header, followed by a STUN payload. The payload is a series of STUN attributes, the set of which depends on the message type. The STUN header contains a STUN message type, transaction ID, and length. The message type can be Binding Request, Binding Response, Binding Error Response, Shared Secret Request, Shared Secret Response, or Shared Secret Error Response. The transaction ID is used to correlate requests and responses. The length indicates the total length of the STUN payload, not including the header. This allows STUN to run over TCP. Shared Secret Requests are always sent over TCP (indeed, using TLS over TCP).
STUN消息是使用big-endian（网络顺序）二进制编码的TLV（类型长度值）。所有晕眩信息都以晕眩头开始，然后是晕眩有效载荷。有效载荷是一系列STUN属性，其设置取决于消息类型。STUN标头包含STUN消息类型、事务ID和长度。消息类型可以是绑定请求、绑定响应、绑定错误响应、共享机密请求、共享机密响应或共享机密错误响应。事务ID用于关联请求和响应。长度表示STUN有效载荷的总长度，不包括收割台。这允许STUN通过TCP运行。共享秘密请求总是通过TCP发送（实际上，使用TCP上的TLS）。
Several STUN attributes are defined. The first is a MAPPED-ADDRESS attribute, which is an IP address and port. It is always placed in the Binding Response, and it indicates the source IP address and port the server saw in the Binding Request. There is also a RESPONSE-ADDRESS attribute, which contains an IP address and port. The RESPONSE-ADDRESS attribute can be present in the Binding Request, and indicates where the Binding Response is to be sent. It's optional, and when not present, the Binding Response is sent to the source IP address and port of the Binding Request.
定义了几个眩晕属性。第一个是MAPPED-ADDRESS属性，它是一个IP地址和端口。它总是放在绑定响应中，并指示服务器在绑定请求中看到的源IP地址和端口。还有一个RESPONSE-ADDRESS属性，它包含IP地址和端口。RESPONSE-ADDRESS属性可以出现在绑定请求中，并指示绑定响应的发送位置。它是可选的，当不存在时，绑定响应被发送到绑定请求的源IP地址和端口。
The third attribute is the CHANGE-REQUEST attribute, and it contains two flags to control the IP address and port used to send the response. These flags are called "change IP" and "change port" flags. The CHANGE-REQUEST attribute is allowed only in the Binding Request. The "change IP" and "change port" flags are useful for determining whether the client is behind a restricted cone NAT or restricted port cone NAT. They instruct the server to send the Binding Responses from a different source IP address and port. The CHANGE-REQUEST attribute is optional in the Binding Request.
第三个属性是CHANGE-REQUEST属性，它包含两个标志来控制用于发送响应的IP地址和端口。这些标志称为“更改IP”和“更改端口”标志。只有在绑定请求中才允许使用CHANGE-REQUEST属性。“change IP”和“change port”标志对于确定客户端是在受限cone NAT后面还是在受限端口cone NAT后面很有用。它们指示服务器从不同的源IP地址和端口发送绑定响应。在绑定请求中，CHANGE-REQUEST属性是可选的。
The fourth attribute is the CHANGED-ADDRESS attribute. It is present in Binding Responses. It informs the client of the source IP address and port that would be used if the client requested the "change IP" and "change port" behavior.
第四个属性是CHANGED-ADDRESS属性。它存在于绑定响应中。它通知客户机如果客户机请求“更改IP”和“更改端口”行为，将使用的源IP地址和端口。
The fifth attribute is the SOURCE-ADDRESS attribute. It is only present in Binding Responses. It indicates the source IP address and port where the response was sent from. It is useful for detecting twice NAT configurations.
第五个属性是源地址属性。它只存在于绑定响应中。它指示发送响应的源IP地址和端口。它对于检测两次NAT配置非常有用。
The sixth attribute is the USERNAME attribute. It is present in a Shared Secret Response, which provides the client with a temporary username and password (encoded in the PASSWORD attribute). The USERNAME is also present in Binding Requests, serving as an index to the shared secret used for the integrity protection of the Binding Request. The seventh attribute, PASSWORD, is only found in Shared Secret Response messages. The eight attribute is the MESSAGE-INTEGRITY attribute, which contains a message integrity check over the Binding Request or Binding Response.
第六个属性是USERNAME属性。它存在于共享机密响应中，该响应为客户端提供临时用户名和密码（在密码属性中编码）。用户名也存在于绑定请求中，作为用于绑定请求完整性保护的共享机密的索引。第七个属性PASSWORD仅在共享秘密响应消息中找到。八个属性是MESSAGE-INTEGRITY属性，它包含对绑定请求或绑定响应的消息完整性检查。
The ninth attribute is the ERROR-CODE attribute. This is present in the Binding Error Response and Shared Secret Error Response. It indicates the error that has occurred. The tenth attribute is the UNKNOWN-ATTRIBUTES attribute, which is present in either the Binding Error Response or Shared Secret Error Response. It indicates the mandatory attributes from the request which were unknown. The eleventh attribute is the REFLECTED-FROM attribute, which is present in Binding Responses. It indicates the IP address and port of the
第九个属性是错误代码属性。这出现在绑定错误响应和共享机密错误响应中。它指示已发生的错误。第十个属性是UNKNOWN-ATTRIBUTES属性，它出现在绑定错误响应或共享机密错误响应中。它表示请求中未知的强制属性。第十一个属性是REFLECTED-FROM属性，它出现在绑定响应中。它指示的IP地址和端口
sender of a Binding Request, used for traceability purposes to prevent certain denial-of-service attacks.
绑定请求的发送方，用于跟踪目的，以防止某些拒绝服务攻击。
The server behavior depends on whether the request is a Binding Request or a Shared Secret Request.
服务器行为取决于请求是绑定请求还是共享机密请求。
A STUN server MUST be prepared to receive Binding Requests on four address/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2, P2). (A1, P1) represent the primary address and port, and these are the ones obtained through the client discovery procedures below. Typically, P1 will be port 3478, the default STUN port. A2 and P2 are arbitrary. A2 and P2 are advertised by the server through the CHANGED-ADDRESS attribute, as described below.
STUN服务器必须准备好接收四个地址/端口组合（A1，P1）、（A2，P1）、（A1，P2）和（A2，P2）上的绑定请求。（A1，P1）表示主地址和端口，这些是通过下面的客户端发现过程获得的。通常，P1将是端口3478，默认的STUN端口。A2和P2是任意的。A2和P2由服务器通过CHANGED-ADDRESS属性播发，如下所述。
It is RECOMMENDED that the server check the Binding Request for a MESSAGE-INTEGRITY attribute. If not present, and the server requires integrity checks on the request, it generates a Binding Error Response with an ERROR-CODE attribute with response code 401. If the MESSAGE-INTEGRITY attribute was present, the server computes the HMAC over the request as described in Section 11.2.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be the one associated with the USERNAME attribute present in the request. If the USERNAME attribute was not present, the server MUST generate a Binding Error Response. The Binding Error Response MUST include an ERROR-CODE attribute with response code 432. If the USERNAME is present, but the server doesn't remember the shared secret for that USERNAME (because it timed out, for example), the server MUST generate a Binding Error Response. The Binding Error Response MUST include an ERROR-CODE attribute with response code 430. If the server does know the shared secret, but the computed HMAC differs from the one in the request, the server MUST generate a Binding Error Response with an ERROR-CODE attribute with response code 431. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sent from the IP address and port the Binding Request was sent to.
建议服务器检查绑定请求中的消息完整性属性。如果不存在，并且服务器需要对请求进行完整性检查，则会生成一个绑定错误响应，该响应具有错误代码属性，响应代码为401。如果存在MESSAGE-INTEGRITY属性，服务器将根据第11.2.8节中所述的请求计算HMAC。要使用的密钥取决于共享密钥机制。如果使用了STUN共享机密请求，则密钥必须是与请求中存在的用户名属性关联的密钥。如果用户名属性不存在，服务器必须生成绑定错误响应。绑定错误响应必须包含响应代码为432的错误代码属性。如果用户名存在，但服务器不记得该用户名的共享机密（例如，因为它超时），则服务器必须生成绑定错误响应。绑定错误响应必须包括响应代码为430的错误代码属性。如果服务器确实知道共享机密，但计算的HMAC与请求中的HMAC不同，则服务器必须生成一个绑定错误响应，该响应具有错误代码属性，响应代码为431。绑定错误响应发送到绑定请求来自的IP地址和端口，并从绑定请求发送到的IP地址和端口发送。
Assuming the message integrity check passed, processing continues. The server MUST check for any attributes in the request with values less than or equal to 0x7fff which it does not understand. If it encounters any, the server MUST generate a Binding Error Response, and it MUST include an ERROR-CODE attribute with a 420 response code.
假设消息完整性检查通过，处理将继续。服务器必须检查请求中是否存在其无法理解的值小于或等于0x7fff的任何属性。如果遇到任何错误，服务器必须生成绑定错误响应，并且必须包含带有420响应代码的错误代码属性。
That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing the attributes with values less than or equal to 0x7fff which were not understood. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sent from the IP address and port the Binding Request was sent to.
该响应必须包含一个UNKNOWN-ATTRIBUTES属性，该属性列出了值小于或等于0x7fff的未被理解的属性。绑定错误响应发送到绑定请求来自的IP地址和端口，并从绑定请求发送到的IP地址和端口发送。
Assuming the request was correctly formed, the server MUST generate a single Binding Response. The Binding Response MUST contain the same transaction ID contained in the Binding Request. The length in the message header MUST contain the total length of the message in bytes, excluding the header. The Binding Response MUST have a message type of "Binding Response".
假设请求格式正确，服务器必须生成单个绑定响应。绑定响应必须包含绑定请求中包含的相同事务ID。消息头中的长度必须包含消息的总长度（字节），不包括消息头。绑定响应必须具有“绑定响应”的消息类型。
The server MUST add a MAPPED-ADDRESS attribute to the Binding Response. The IP address component of this attribute MUST be set to the source IP address observed in the Binding Request. The port component of this attribute MUST be set to the source port observed in the Binding Request.
服务器必须向绑定响应添加MAPPED-ADDRESS属性。此属性的IP地址组件必须设置为绑定请求中观察到的源IP地址。此属性的端口组件必须设置为绑定请求中观察到的源端口。
If the RESPONSE-ADDRESS attribute was absent from the Binding Request, the destination address and port of the Binding Response MUST be the same as the source address and port of the Binding Request. Otherwise, the destination address and port of the Binding Response MUST be the value of the IP address and port in the RESPONSE-ADDRESS attribute.
如果绑定请求中缺少RESPONSE-ADDRESS属性，则绑定响应的目标地址和端口必须与绑定请求的源地址和端口相同。否则，绑定响应的目标地址和端口必须是Response-address属性中的IP地址和端口的值。
The source address and port of the Binding Response depend on the value of the CHANGE-REQUEST attribute and on the address and port the Binding Request was received on, and are summarized in Table 1.
绑定响应的源地址和端口取决于CHANGE-REQUEST属性的值以及接收绑定请求的地址和端口，汇总在表1中。
Let Da represent the destination IP address of the Binding Request (which will be either A1 or A2), and Dp represent the destination port of the Binding Request (which will be either P1 or P2). Let Ca represent the other address, so that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port" flag was set in CHANGE-REQUEST attribute of the Binding Request, and the "change IP" flag was not set, the source IP address of the Binding Response MUST be Da and the source port of the Binding Response MUST be Cp. If the "change IP" flag was set in the Binding Request, and the "change port" flag was not set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Dp. When both flags are set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Cp. If neither flag is set, or if the CHANGE-REQUEST attribute is absent entirely, the source IP address of the Binding Response MUST be Da and the source port of the Binding Response MUST be Dp.
让Da表示绑定请求的目标IP地址（将是A1或A2），Dp表示绑定请求的目标端口（将是P1或P2）。让Ca代表另一个地址，这样如果Da是A1，Ca就是A2。如果Da是A2，Ca是A1。类似地，让Cp表示另一个端口，这样，如果Dp是P1，Cp就是P2。如果Dp为P2，则Cp为P1。如果在绑定请求的change-REQUEST属性中设置了“change port”标志，而没有设置“change IP”标志，则绑定响应的源IP地址必须是Da，绑定响应的源端口必须是Cp。如果在绑定请求中设置了“change IP”标志，而没有设置“change port”标志，绑定响应的源IP地址必须是Ca，绑定响应的源端口必须是Dp。当两个标志都设置时，绑定响应的源IP地址必须是Ca，绑定响应的源端口必须是Cp。如果两个标志都未设置，或者如果更改请求属性完全不存在，则绑定响应的源IP地址必须是Da，绑定响应的源端口必须是Dp。
Flags Source Address Source Port CHANGED-ADDRESS none Da Dp Ca:Cp Change IP Ca Dp Ca:Cp Change port Da Cp Ca:Cp Change IP and Change port Ca Cp Ca:Cp
标记源地址源端口已更改-地址无Da Dp Ca:Cp更改IP Ca Dp Ca:Cp更改端口Da Cp Ca:Cp更改IP和更改端口Ca Cp Ca:Cp
Table 1: Impact of Flags on Packet Source and CHANGED-ADDRESS
表1：标志对数据包源和更改地址的影响
The server MUST add a SOURCE-ADDRESS attribute to the Binding Response, containing the source address and port used to send the Binding Response.
服务器必须向绑定响应添加源地址属性，该属性包含用于发送绑定响应的源地址和端口。
The server MUST add a CHANGED-ADDRESS attribute to the Binding Response. This contains the source IP address and port that would be used if the client had set the "change IP" and "change port" flags in the Binding Request. As summarized in Table 1, these are Ca and Cp, respectively, regardless of the value of the CHANGE-REQUEST flags.
服务器必须向绑定响应添加已更改的地址属性。这包含源IP地址和端口，如果客户端在绑定请求中设置了“change IP”和“change port”标志，则将使用这些地址和端口。如表1所示，无论变更请求标志的值如何，它们分别是Ca和Cp。
If the Binding Request contained both the USERNAME and MESSAGE-INTEGRITY attributes, the server MUST add a MESSAGE-INTEGRITY attribute to the Binding Response. The attribute contains an HMAC [13] over the response, as described in Section 11.2.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be the one associated with the USERNAME attribute present in the Binding Request.
如果绑定请求同时包含用户名和消息完整性属性，则服务器必须向绑定响应添加消息完整性属性。如第11.2.8节所述，该属性在响应上包含HMAC[13]。要使用的密钥取决于共享密钥机制。如果使用了STUN共享机密请求，则密钥必须是与绑定请求中存在的用户名属性关联的密钥。
If the Binding Request contained a RESPONSE-ADDRESS attribute, the server MUST add a REFLECTED-FROM attribute to the response. If the Binding Request was authenticated using a username obtained from a Shared Secret Request, the REFLECTED-FROM attribute MUST contain the source IP address and port where that Shared Secret Request came from. If the username present in the request was not allocated using a Shared Secret Request, the REFLECTED-FROM attribute MUST contain the source address and port of the entity which obtained the username, as best can be verified with the mechanism used to allocate the username. If the username was not present in the request, and the server was willing to process the request, the REFLECTED-FROM attribute SHOULD contain the source IP address and port where the request came from.
如果绑定请求包含RESPONSE-ADDRESS属性，则服务器必须向响应添加REFLECTED-FROM属性。如果绑定请求是使用从共享机密请求获得的用户名进行身份验证的，则REFLECTED-from属性必须包含共享机密请求来自的源IP地址和端口。如果请求中存在的用户名不是使用共享机密请求分配的，则反射自属性必须包含获取用户名的实体的源地址和端口，这可以通过用于分配用户名的机制进行验证。如果用户名不存在于请求中，并且服务器愿意处理该请求，那么REFLECTED-FROM属性应该包含请求来自的源IP地址和端口。
The server SHOULD NOT retransmit the response. Reliability is achieved by having the client periodically resend the request, each of which triggers a response from the server.
服务器不应重新传输响应。可靠性是通过让客户端定期重新发送请求来实现的，每个请求都会触发服务器的响应。
Shared Secret Requests are always received on TLS connections. When the server receives a request from the client to establish a TLS connection, it MUST proceed with TLS, and SHOULD present a site certificate. The TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA [4] SHOULD be used. Client TLS authentication MUST NOT be done, since the server is not allocating any resources to clients, and the computational burden can be a source of attacks.
共享机密请求总是通过TLS连接接收。当服务器从客户端接收到建立TLS连接的请求时，它必须继续TLS，并应提供站点证书。应使用TLS密码套件TLS_RSA_和_AES_128_CBC_SHA[4]。客户端TLS身份验证不能执行，因为服务器没有向客户端分配任何资源，并且计算负担可能是攻击的来源。
If the server receives a Shared Secret Request, it MUST verify that the request arrived on a TLS connection. If it did not receive the request over TLS, it MUST generate a Shared Secret Error Response, and it MUST include an ERROR-CODE attribute with a 433 response code. The destination for the error response depends on the transport on which the request was received. If the Shared Secret Request was received over TCP, the Shared Secret Error Response is sent over the same connection the request was received on. If the Shared Secret Request was receive over UDP, the Shared Secret Error Response is sent to the source IP address and port that the request came from.
如果服务器收到共享机密请求，则必须验证该请求是否通过TLS连接到达。如果它没有通过TLS接收请求，它必须生成一个共享机密错误响应，并且它必须包含一个错误代码属性和一个433响应代码。错误响应的目标取决于接收请求的传输。如果共享机密请求是通过TCP接收的，则共享机密错误响应将通过接收请求的同一连接发送。如果通过UDP接收共享机密请求，则会将共享机密错误响应发送到请求所来自的源IP地址和端口。
The server MUST check for any attributes in the request with values less than or equal to 0x7fff which it does not understand. If it encounters any, the server MUST generate a Shared Secret Error Response, and it MUST include an ERROR-CODE attribute with a 420 response code. That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing the attributes with values less than or equal to 0x7fff which were not understood. The Shared Secret Error Response is sent over the TLS connection.
服务器必须检查请求中是否存在其无法理解的值小于或等于0x7fff的任何属性。如果遇到任何错误，服务器必须生成共享机密错误响应，并且必须包含错误代码属性和420响应代码。该响应必须包含一个UNKNOWN-ATTRIBUTES属性，该属性列出了值小于或等于0x7fff的未被理解的属性。共享机密错误响应通过TLS连接发送。
All Shared Secret Error Responses MUST contain the same transaction ID contained in the Shared Secret Request. The length in the message header MUST contain the total length of the message in bytes, excluding the header. The Shared Secret Error Response MUST have a message type of "Shared Secret Error Response" (0x0112).
所有共享机密错误响应必须包含共享机密请求中包含的相同事务ID。消息头中的长度必须包含消息的总长度（字节），不包括消息头。共享机密错误响应的消息类型必须为“共享机密错误响应”（0x0112）。
Assuming the request was properly constructed, the server creates a Shared Secret Response. The Shared Secret Response MUST contain the same transaction ID contained in the Shared Secret Request. The length in the message header MUST contain the total length of the message in bytes, excluding the header. The Shared Secret Response MUST have a message type of "Shared Secret Response". The Shared Secret Response MUST contain a USERNAME attribute and a PASSWORD attribute. The USERNAME attribute serves as an index to the password, which is contained in the PASSWORD attribute. The server can use any mechanism it chooses to generate the username. However, the username MUST be valid for a period of at least 10 minutes. Validity means that the server can compute the password for that
假设请求构造正确，服务器将创建一个共享机密响应。共享机密响应必须包含共享机密请求中包含的相同事务ID。消息头中的长度必须包含消息的总长度（字节），不包括消息头。共享机密响应必须具有“共享机密响应”的消息类型。共享机密响应必须包含用户名属性和密码属性。USERNAME属性用作密码的索引，密码包含在password属性中。服务器可以使用它选择的任何机制来生成用户名。但是，用户名的有效期必须至少为10分钟。有效性意味着服务器可以为此计算密码
username. There MUST be a single password for each username. In other words, the server cannot, 10 minutes later, assign a different password to the same username. The server MUST hand out a different username for each distinct Shared Secret Request. Distinct, in this case, implies a different transaction ID. It is RECOMMENDED that the server explicitly invalidate the username after ten minutes. It MUST invalidate the username after 30 minutes. The PASSWORD contains the password bound to that username. The password MUST have at least 128 bits. The likelihood that the server assigns the same password for two different usernames MUST be vanishingly small, and the passwords MUST be unguessable. In other words, they MUST be a cryptographically random function of the username.
用户名。每个用户名必须有一个密码。换句话说，服务器不能在10分钟后为同一用户名分配不同的密码。服务器必须为每个不同的共享机密请求分配不同的用户名。在本例中，Distinct表示不同的事务ID。建议服务器在十分钟后显式使用户名无效。它必须在30分钟后使用户名无效。密码包含绑定到该用户名的密码。密码必须至少有128位。服务器为两个不同的用户名分配相同密码的可能性必须非常小，并且密码必须不可用。换句话说，它们必须是用户名的加密随机函数。
These requirements can still be met using a stateless server, by intelligently computing the USERNAME and PASSWORD. One approach is to construct the USERNAME as:
通过智能地计算用户名和密码，使用无状态服务器仍然可以满足这些要求。一种方法是将用户名构造为：
USERNAME = <prefix,rounded-time,clientIP,hmac>
USERNAME = <prefix,rounded-time,clientIP,hmac>
Where prefix is some random text string (different for each shared secret request), rounded-time is the current time modulo 20 minutes, clientIP is the source IP address where the Shared Secret Request came from, and hmac is an HMAC [13] over the prefix, rounded-time, and client IP, using a server private key.
其中prefix是一些随机文本字符串（每个共享密钥请求不同），rounded time是以20分钟为单位的当前时间，clientIP是共享密钥请求来自的源IP地址，hmac是前缀、rounded time和客户端IP上的hmac[13]，使用服务器私钥。
The password is then computed as:
然后将密码计算为：
password = <hmac(USERNAME,anotherprivatekey)>
password = <hmac(USERNAME,anotherprivatekey)>
With this structure, the username itself, which will be present in the Binding Request, contains the source IP address where the Shared Secret Request came from. That allows the server to meet the requirements specified in Section 8.1 for constructing the REFLECTED-FROM attribute. The server can verify that the username was not tampered with, using the hmac present in the username.
使用这种结构，绑定请求中出现的用户名本身包含共享机密请求来自的源IP地址。这允许服务器满足第8.1节中规定的构造反射自属性的要求。服务器可以使用用户名中的hmac验证用户名是否未被篡改。
The Shared Secret Response is sent over the same TLS connection the request was received on. The server SHOULD keep the connection open, and let the client close it.
共享机密响应通过接收请求的同一TLS连接发送。服务器应保持连接打开，并让客户端关闭连接。
The behavior of the client is very straightforward. Its task is to discover the STUN server, obtain a shared secret, formulate the Binding Request, handle request reliability, and process the Binding Responses.
客户的行为非常简单。它的任务是发现STUN服务器、获取共享机密、制定绑定请求、处理请求可靠性以及处理绑定响应。
Generally, the client will be configured with a domain name of the provider of the STUN servers. This domain name is resolved to an IP address and port using the SRV procedures specified in RFC 2782 [3].
通常，客户机将配置STUN服务器提供商的域名。使用RFC 2782[3]中规定的SRV程序将该域名解析为IP地址和端口。
Specifically, the service name is "stun". The protocol is "udp" for sending Binding Requests, or "tcp" for sending Shared Secret Requests. 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 are sorted and then tried. However, it 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. Those details are described here for STUN.
具体来说，服务名称是“stun”。协议是用于发送绑定请求的“udp”，或用于发送共享机密请求的“tcp”。按照RFC 2782的程序确定要联系的服务器。RFC2782详细说明了如何对一组SRV记录进行排序，然后进行尝试。但是，它只说明客户机应该“尝试连接到（协议、地址、服务）”，而没有给出发生故障时发生的任何细节。这些细节在这里为STUN描述。
For STUN requests, failure occurs if there is a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction fails due to timeout. This occurs 9.5 seconds after the first request is sent, for both Shared Secret Requests and Binding Requests. See Section 9.3 for details on transaction timeouts for Binding Requests. If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different transaction ID and MESSAGE INTEGRITY attribute (the HMAC will change because the transaction ID has changed). That request is sent to the next element in the list as specified by RFC 2782.
对于STUN请求，如果存在某种类型的传输故障（通常是由于UDP中的致命ICMP错误或TCP中的连接故障），则会发生故障。如果事务因超时而失败，也会发生失败。对于共享机密请求和绑定请求，在发送第一个请求后9.5秒都会发生这种情况。有关绑定请求的事务超时的详细信息，请参见第9.3节。如果出现故障，客户端应创建一个新请求，该请求与前一个请求相同，但具有不同的事务ID和消息完整性属性（HMAC将更改，因为事务ID已更改）。该请求被发送到RFC 2782指定的列表中的下一个元素。
The default port for STUN requests is 3478, for both TCP and UDP. Administrators SHOULD use this port in their SRV records, but MAY use others.
对于TCP和UDP，STUN请求的默认端口为3478。管理员应在其SRV记录中使用此端口，但也可以使用其他端口。
If no SRV records were found, the client performs an A record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the default port.
如果未找到SRV记录，客户端将对域名执行记录查找。结果将是一个IP地址列表，每个IP地址都可以通过默认端口联系。
This would allow a firewall admin to open the STUN port, so hosts within the enterprise could access new applications. Whether they will or won't do this is a good question.
这将允许防火墙管理员打开STUN端口，以便企业内的主机可以访问新的应用程序。他们是否会这样做是个好问题。
As discussed in Section 12, there are several attacks possible on STUN systems. Many of these are prevented through integrity of requests and responses. To provide that integrity, STUN makes use of a shared secret between client and server, used as the keying material for an HMAC used in both the Binding Request and Binding Response. STUN allows for the shared secret to be obtained in any way (for example, Kerberos [14]). However, it MUST have at least 128
如第12节所述，有几种可能对眩晕系统进行的攻击。其中许多是通过请求和响应的完整性来防止的。为了提供完整性，STUN使用了客户端和服务器之间的共享秘密，作为绑定请求和绑定响应中使用的HMAC的密钥材料。STUN允许以任何方式获得共享秘密（例如，Kerberos[14]）。但是，它必须至少有128个
bits of randomness. In order to ensure interoperability, this specification describes a TLS-based mechanism. This mechanism, described in this section, MUST be implemented by clients and servers.
一些随机性。为了确保互操作性，本规范描述了基于TLS的机制。本节介绍的这种机制必须由客户端和服务器实现。
First, the client determines the IP address and port that it will open a TCP connection to. This is done using the discovery procedures in Section 9.1. The client opens up the connection to that address and port, and immediately begins TLS negotiation [2]. The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [5]. Those procedures assume the client is dereferencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 9.1 as the host portion of the URI that has been dereferenced.
首先，客户端确定它将打开TCP连接的IP地址和端口。这是使用第9.1节中的发现程序完成的。客户端打开与该地址和端口的连接，并立即开始TLS协商[2]。客户端必须验证服务器的标识。为此，应遵循RFC 2818[5]第3.1节规定的识别程序。这些过程假定客户端正在取消对URI的引用。为了与本规范一起使用，客户机将第9.1节中使用的域名或IP地址视为已取消引用的URI的主机部分。
Once the connection is opened, the client sends a Shared Secret request. This request has no attributes, just the header. The transaction ID in the header MUST meet the requirements outlined for the transaction ID in a binding request, described in Section 9.3 below. The server generates a response, which can either be a Shared Secret Response or a Shared Secret Error Response.
连接打开后，客户端将发送一个共享机密请求。此请求没有属性，只有头。标头中的事务ID必须满足绑定请求中事务ID的要求，如下文第9.3节所述。服务器生成一个响应，该响应可以是共享机密响应，也可以是共享机密错误响应。
If the response was a Shared Secret Error Response, the client checks the response code in the ERROR-CODE attribute. Interpretation of those response codes is identical to the processing of Section 9.4 for the Binding Error Response.
如果响应是共享机密错误响应，则客户端将检查Error-code属性中的响应代码。这些响应代码的解释与第9.4节对绑定错误响应的处理相同。
If a client receives a Shared Secret Response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. If the client receives a Shared Secret Response with an attribute whose type is less than or equal to 0x7fff, the response is ignored.
如果客户端接收到具有类型大于0x7fff的属性的共享机密响应，则必须忽略该属性。如果客户端接收到具有类型小于或等于0x7fff的属性的共享机密响应，则将忽略该响应。
If the response was a Shared Secret Response, it will contain a short lived username and password, encoded in the USERNAME and PASSWORD attributes, respectively.
如果响应是共享机密响应，则它将包含一个分别在username和password属性中编码的短期用户名和密码。
The client MAY generate multiple Shared Secret Requests on the connection, and it MAY do so before receiving Shared Secret Responses to previous Shared Secret Requests. The client SHOULD close the connection as soon as it has finished obtaining usernames and passwords.
客户端可以在连接上生成多个共享机密请求，并且可以在接收到对先前共享机密请求的共享机密响应之前生成多个共享机密请求。客户端应在获得用户名和密码后立即关闭连接。
Section 9.3 describes how these passwords are used to provide integrity protection over Binding Requests, and Section 8.1 describes how it is used in Binding Responses.
第9.3节描述了如何使用这些密码为绑定请求提供完整性保护，第8.1节描述了如何在绑定响应中使用这些密码。
A Binding Request formulated by the client follows the syntax rules defined in Section 11. Any two requests that are not bit-wise identical, and not sent to the same server from the same IP address and port, MUST carry different transaction IDs. The transaction ID MUST be uniformly and randomly distributed between 0 and 2**128 - 1. The large range is needed because the transaction ID serves as a form of randomization, helping to prevent replays of previously signed responses from the server. The message type of the request MUST be "Binding Request".
客户机制定的绑定请求遵循第11节中定义的语法规则。任何两个不完全相同的请求，如果不是从同一IP地址和端口发送到同一服务器，则必须携带不同的事务ID。事务ID必须在0和2**128-1之间均匀随机分布。需要较大的范围，因为事务ID作为随机化的一种形式，有助于防止重播来自服务器的先前签名的响应。请求的消息类型必须是“绑定请求”。
The RESPONSE-ADDRESS attribute is optional in the Binding Request. It is used if the client wishes the response to be sent to a different IP address and port than the one the request was sent from. This is useful for determining whether the client is behind a firewall, and for applications that have separated control and data components. See Section 10.3 for more details. The CHANGE-REQUEST attribute is also optional. Whether it is present depends on what the application is trying to accomplish. See Section 10 for some example uses.
在绑定请求中，RESPONSE-ADDRESS属性是可选的。如果客户端希望将响应发送到与发送请求的IP地址和端口不同的IP地址和端口，则使用该选项。这对于确定客户端是否位于防火墙后面以及对于具有分离的控制和数据组件的应用程序非常有用。详见第10.3节。更改请求属性也是可选的。它是否存在取决于应用程序试图实现什么。参见第10节了解一些示例用途。
The client SHOULD add a MESSAGE-INTEGRITY and USERNAME attribute to the Binding Request. This MESSAGE-INTEGRITY attribute contains an HMAC [13]. The value of the username, and the key to use in the MESSAGE-INTEGRITY attribute depend on the shared secret mechanism. If the STUN Shared Secret Request was used, the USERNAME must be a valid username obtained from a Shared Secret Response within the last nine minutes. The shared secret for the HMAC is the value of the PASSWORD attribute obtained from the same Shared Secret Response.
客户端应向绑定请求添加消息完整性和用户名属性。此消息完整性属性包含HMAC[13]。用户名的值和要在MESSAGE-INTEGRITY属性中使用的密钥取决于共享密钥机制。如果使用了STUN共享机密请求，则用户名必须是在过去九分钟内从共享机密响应中获得的有效用户名。HMAC的共享机密是从同一共享机密响应获得的密码属性的值。
Once formulated, the client sends the Binding Request. Reliability is accomplished through client retransmissions. Clients SHOULD retransmit the request starting with an interval of 100ms, doubling every retransmit until the interval reaches 1.6s. Retransmissions continue with intervals of 1.6s until a response is received, or a total of 9 requests have been sent. If no response is received by 1.6 seconds after the last request has been sent, the client SHOULD consider the transaction to have failed. In other words, requests would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 9500ms, the client considers the transaction to have failed if no response has been received.
一旦制定，客户机将发送绑定请求。可靠性是通过客户端重新传输来实现的。客户端应以100ms的间隔重新传输请求，每次重新传输应加倍，直到间隔达到1.6s。重新传输以1.6秒的间隔继续，直到收到响应，或者总共发送了9个请求。如果在发送完最后一个请求后1.6秒钟没有收到响应，客户端应该认为事务失败。换句话说，请求将以0毫秒、100毫秒、300毫秒、700毫秒、1500毫秒、3100毫秒、4700毫秒、6300毫秒和7900毫秒的时间发送。在9500ms时，如果未收到响应，则客户端认为事务失败。
The response can either be a Binding Response or Binding Error Response. Binding Error Responses are always received on the source address and port the request was sent from. A Binding Response will
响应可以是绑定响应或绑定错误响应。绑定错误响应始终在发送请求的源地址和端口上接收。一个有约束力的回应将
be received on the address and port placed in the RESPONSE-ADDRESS attribute of the request. If none was present, the Binding Responses will be received on the source address and port the request was sent from.
在请求的RESPONSE-address属性中的地址和端口上接收。如果不存在绑定响应，则将在发送请求的源地址和端口上接收绑定响应。
If the response is a Binding Error Response, the client checks the response code from the ERROR-CODE attribute of the response. For a 400 response code, the client SHOULD display the reason phrase to the user. For a 420 response code, the client SHOULD retry the request, this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES attribute of the response. For a 430 response code, the client SHOULD obtain a new shared secret, and retry the Binding Request with a new transaction. For 401 and 432 response codes, if the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute as indicated by the error, it SHOULD try again with those attributes. For a 431 response code, the client SHOULD alert the user, and MAY try the request again after obtaining a new username and password. For a 500 response code, the client MAY wait several seconds and then retry the request. For a 600 response code, the client MUST NOT retry the request, and SHOULD display the reason phrase to the user. Unknown attributes between 400 and 499 are treated like a 400, unknown attributes between 500 and 599 are treated like a 500, and unknown attributes between 600 and 699 are treated like a 600. Any response between 100 and 399 MUST result in the cessation of request retransmissions, but otherwise is discarded.
如果响应是绑定错误响应，则客户端将从响应的Error-code属性检查响应代码。对于400响应代码，客户端应向用户显示原因短语。对于420响应代码，客户机应该重试请求，这次忽略响应的UNKNOWN-attributes属性中列出的任何属性。对于430响应代码，客户端应获取新的共享机密，并使用新事务重试绑定请求。对于401和432响应代码，如果客户端忽略了错误指示的用户名或消息完整性属性，则应使用这些属性重试。对于431响应代码，客户端应提醒用户，并可在获得新用户名和密码后重试请求。对于500响应代码，客户端可能会等待几秒钟，然后重试请求。对于600响应代码，客户端不得重试请求，并应向用户显示原因短语。400和499之间的未知属性被视为400，500和599之间的未知属性被视为500，600和699之间的未知属性被视为600。100和399之间的任何响应都必须导致停止请求重传，否则将被丢弃。
If a client receives a response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. If the client receives a response with an attribute whose type is less than or equal to 0x7fff, request retransmissions MUST cease, but the entire response is otherwise ignored.
如果客户端接收到的响应具有类型大于0x7fff的属性，则必须忽略该属性。如果客户端接收到一个属性类型小于或等于0x7fff的响应，则必须停止请求重传，否则将忽略整个响应。
If the response is a Binding Response, the client SHOULD check the response for a MESSAGE-INTEGRITY attribute. If not present, and the client placed a MESSAGE-INTEGRITY attribute into the request, it MUST discard the response. If present, the client computes the HMAC over the response as described in Section 11.2.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be same as used to compute the MESSAGE-INTEGRITY attribute in the request. If the computed HMAC differs from the one in the response, the client MUST discard the response, and SHOULD alert the user about a possible attack. If the computed HMAC matches the one from the response, processing continues.
如果响应是绑定响应，则客户端应检查响应的消息完整性属性。如果不存在，并且客户端将消息完整性属性放入请求中，则必须放弃响应。如果存在，客户端将根据第11.2.8节中所述的响应计算HMAC。要使用的密钥取决于共享密钥机制。如果使用了STUN共享机密请求，则密钥必须与用于计算请求中的MESSAGE-INTEGRITY属性的密钥相同。如果计算的HMAC与响应中的HMAC不同，则客户端必须放弃响应，并应提醒用户可能发生的攻击。如果计算出的HMAC与响应中的HMAC匹配，则继续处理。
Reception of a response (either Binding Error Response or Binding Response) to a Binding Request will terminate retransmissions of that request. However, clients MUST continue to listen for responses to a Binding Request for 10 seconds after the first response. If it
接收到对绑定请求的响应（绑定错误响应或绑定响应）将终止该请求的重新传输。但是，客户端必须在第一次响应后的10秒钟内继续侦听绑定请求的响应。如果是
receives any responses in this interval with different message types (Binding Responses and Binding Error Responses, for example) or different MAPPED-ADDRESSes, it is an indication of a possible attack. The client MUST NOT use the MAPPED-ADDRESS from any of the responses it received (either the first or the additional ones), and SHOULD alert the user.
在此时间间隔内接收具有不同消息类型（例如绑定响应和绑定错误响应）或不同映射地址的任何响应，这表明可能存在攻击。客户端不得使用其收到的任何响应（第一个或其他响应）中的映射地址，并应提醒用户。
Furthermore, if a client receives more than twice as many Binding Responses as the number of Binding Requests it sent, it MUST NOT use the MAPPED-ADDRESS from any of those responses, and SHOULD alert the user about a potential attack.
此外，如果客户机收到的绑定响应数量是其发送的绑定请求数量的两倍以上，则它不得使用这些响应中的映射地址，并应提醒用户潜在的攻击。
If the Binding Response is authenticated, and the MAPPED-ADDRESS was not discarded because of a potential attack, the CLIENT MAY use the MAPPED-ADDRESS and SOURCE-ADDRESS attributes.
如果绑定响应经过身份验证，并且映射地址没有因为潜在的攻击而被丢弃，则客户端可以使用映射地址和源地址属性。
The rules of Sections 8 and 9 describe exactly how a client and server interact to send requests and get responses. However, they do not dictate how the STUN protocol is used to accomplish useful tasks. That is at the discretion of the client. Here, we provide some useful scenarios for applying STUN.
第8节和第9节的规则准确地描述了客户机和服务器如何交互以发送请求和获取响应。但是，它们并不规定如何使用STUN协议来完成有用的任务。这由客户自行决定。这里，我们提供了一些应用STUN的有用场景。
In this scenario, a user is running a multimedia application which needs to determine which of the following scenarios applies to it:
在此场景中，用户正在运行多媒体应用程序，需要确定以下哪种场景适用于该应用程序：
o On the open Internet
o 在开放的互联网上
o Firewall that blocks UDP
o 阻止UDP的防火墙
o Firewall that allows UDP out, and responses have to come back to the source of the request (like a symmetric NAT, but no translation. We call this a symmetric UDP Firewall)
o 允许UDP输出的防火墙，响应必须返回到请求源（如对称NAT，但不转换。我们称之为对称UDP防火墙）
o Full-cone NAT
o 全锥NAT
o Symmetric NAT
o 对称nat
o Restricted cone or restricted port cone NAT
o 受限圆锥或受限端口圆锥NAT
Which of the six scenarios applies can be determined through the flow chart described in Figure 2. The chart refers only to the sequence of Binding Requests; Shared Secret Requests will, of course, be needed to authenticate each Binding Request used in the sequence.
可以通过图2中描述的流程图来确定这六种场景中的哪一种适用。图表仅指绑定请求的顺序；当然，需要共享秘密请求来验证序列中使用的每个绑定请求。
The flow makes use of three tests. In test I, the client sends a STUN Binding Request to a server, without any flags set in the CHANGE-REQUEST attribute, and without the RESPONSE-ADDRESS attribute. This causes the server to send the response back to the address and port that the request came from. In test II, the client sends a Binding Request with both the "change IP" and "change port" flags from the CHANGE-REQUEST attribute set. In test III, the client sends a Binding Request with only the "change port" flag set.
该流程使用三个测试。在测试I中，客户端向服务器发送一个STUN绑定请求，而不在CHANGE-Request属性中设置任何标志，也不在RESPONSE-ADDRESS属性中设置任何标志。这会导致服务器将响应发送回请求来自的地址和端口。在测试II中，客户机发送一个绑定请求，其中包含change-Request属性集中的“change IP”和“change port”标志。在测试III中，客户机发送绑定请求时只设置了“ChangePort”标志。
The client begins by initiating test I. If this test yields no response, the client knows right away that it is not capable of UDP connectivity. If the test produces a response, the client examines the MAPPED-ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not natted. It executes test II.
客户端首先启动测试I。如果此测试未产生响应，则客户端立即知道它无法进行UDP连接。如果测试生成响应，客户端将检查MAPPED-ADDRESS属性。如果此地址和端口与用于发送请求的套接字的本地IP地址和端口相同，则客户端知道它未被NATT。它执行测试II。
If a response is received, the client knows that it has open access to the Internet (or, at least, its behind a firewall that behaves like a full-cone NAT, but without the translation). If no response is received, the client knows its behind a symmetric UDP firewall.
如果收到响应，客户端知道它可以开放访问Internet（或者，至少在防火墙后面，其行为类似于完整的cone NAT，但没有翻译）。如果没有收到响应，则客户端知道其位于对称UDP防火墙后面。
In the event that the IP address and port of the socket did not match the MAPPED-ADDRESS attribute in the response to test I, the client knows that it is behind a NAT. It performs test II. If a response is received, the client knows that it is behind a full-cone NAT. If no response is received, it performs test I again, but this time, does so to the address and port from the CHANGED-ADDRESS attribute from the response to test I. If the IP address and port returned in the MAPPED-ADDRESS attribute are not the same as the ones from the first test I, the client knows its behind a symmetric NAT. If the address and port are the same, the client is either behind a restricted or port restricted NAT. To make a determination about which one it is behind, the client initiates test III. If a response is received, its behind a restricted NAT, and if no response is received, its behind a port restricted NAT.
如果套接字的IP地址和端口与对测试I的响应中的MAPPED-address属性不匹配，则客户端知道它在NAT后面。它执行测试II。如果收到响应，客户机知道它在完整的cone NAT后面。如果没有收到响应，它将再次执行测试I，但这次将对测试I响应中更改的-address属性中的地址和端口执行此操作。如果MAPPED-address属性中返回的IP地址和端口与第一个测试I中返回的IP地址和端口不同，则客户机知道它在对称NAT后面。如果地址和端口相同，则客户端位于受限NAT或端口受限NAT之后。为了确定它在哪一个后面，客户端启动测试III。如果收到响应，它在受限NAT后面，如果没有收到响应，它在端口受限NAT后面。
This procedure yields substantial information about the operating condition of the client application. In the event of multiple NATs between the client and the Internet, the type that is discovered will be the type of the most restrictive NAT between the client and the Internet. The types of NAT, in order of restrictiveness, from most to least, are symmetric, port restricted cone, restricted cone, and full cone.
此过程生成有关客户端应用程序操作条件的大量信息。如果客户端和Internet之间存在多个NAT，则发现的类型将是客户端和Internet之间限制最严格的NAT类型。NAT的类型，按限制程度从大到小依次为对称、端口限制锥、限制锥和全锥。
Typically, a client will re-do this discovery process periodically to detect changes, or look for inconsistent results. It is important to note that when the discovery process is redone, it should not
通常，客户机会定期重新执行此发现过程，以检测更改或查找不一致的结果。重要的是要注意，当发现过程重做时，不应重复
generally be done from the same local address and port used in the previous discovery process. If the same local address and port are reused, bindings from the previous test may still be in existence, and these will invalidate the results of the test. Using a different local address and port for subsequent tests resolves this problem. An alternative is to wait sufficiently long to be confident that the old bindings have expired (half an hour should more than suffice).
通常可以从先前发现过程中使用的相同本地地址和端口执行。如果重复使用相同的本地地址和端口，则来自上一个测试的绑定可能仍然存在，并且这些绑定将使测试结果无效。在后续测试中使用不同的本地地址和端口可以解决此问题。另一种方法是等待足够长的时间，以确信旧绑定已经过期（半小时应该足够了）。
STUN can also be used to discover the lifetimes of the bindings created by the NAT. In many cases, the client will need to refresh the binding, either through a new STUN request, or an application packet, in order for the application to continue to use the binding. By discovering the binding lifetime, the client can determine how frequently it needs to refresh.
STUN还可以用来发现由NAT创建的绑定的生命周期。在许多情况下，客户机需要通过新的STUN请求或应用程序数据包刷新绑定，以便应用程序继续使用绑定。通过发现绑定生存期，客户机可以确定需要刷新的频率。
+--------+
| Test |
| I |
+--------+
|
|
V
/\ /\
N / \ Y / \ Y +--------+
UDP <-------/Resp\--------->/ IP \------------->| Test |
Blocked \ ? / \Same/ | II |
\ / \? / +--------+
\/ \/ |
| N |
| V
V /\
+--------+ Sym. N / \
| Test | UDP <---/Resp\
| II | Firewall \ ? /
+--------+ \ /
| \/
V |Y
/\ /\ |
Symmetric N / \ +--------+ N / \ V
NAT <--- / IP \<-----| Test |<--- /Resp\ Open
\Same/ | I | \ ? / Internet
\? / +--------+ \ /
\/ \/
| |Y
| |
| V
| Full
| Cone
V /\
+--------+ / \ Y
| Test |------>/Resp\---->Restricted
| III | \ ? /
+--------+ \ /
\/
|N
| Port
+------>Restricted
+--------+
| Test |
| I |
+--------+
|
|
V
/\ /\
N / \ Y / \ Y +--------+
UDP <-------/Resp\--------->/ IP \------------->| Test |
Blocked \ ? / \Same/ | II |
\ / \? / +--------+
\/ \/ |
| N |
| V
V /\
+--------+ Sym. N / \
| Test | UDP <---/Resp\
| II | Firewall \ ? /
+--------+ \ /
| \/
V |Y
/\ /\ |
Symmetric N / \ +--------+ N / \ V
NAT <--- / IP \<-----| Test |<--- /Resp\ Open
\Same/ | I | \ ? / Internet
\? / +--------+ \ /
\/ \/
| |Y
| |
| V
| Full
| Cone
V /\
+--------+ / \ Y
| Test |------>/Resp\---->Restricted
| III | \ ? /
+--------+ \ /
\/
|N
| Port
+------>Restricted
Figure 2: Flow for type discovery process
图2：类型发现过程的流程
To determine the binding lifetime, the client first sends a Binding Request to the server from a particular socket, X. This creates a binding in the NAT. The response from the server contains a MAPPED-ADDRESS attribute, providing the public address and port on the NAT. Call this Pa and Pp, respectively. The client then starts a timer with a value of T seconds. When this timer fires, the client sends another Binding Request to the server, using the same destination address and port, but from a different socket, Y. This request contains a RESPONSE-ADDRESS address attribute, set to (Pa,Pp). This will create a new binding on the NAT, and cause the STUN server to send a Binding Response that would match the old binding, if it still exists. If the client receives the Binding Response on socket X, it knows that the binding has not expired. If the client receives the Binding Response on socket Y (which is possible if the old binding expired, and the NAT allocated the same public address and port to the new binding), or receives no response at all, it knows that the binding has expired.
要确定绑定生存期，客户端首先从特定套接字X向服务器发送绑定请求。这将在NAT中创建绑定。来自服务器的响应包含MAPPED-ADDRESS属性，提供NAT上的公共地址和端口。分别称之为Pa和Pp。然后，客户端启动一个值为T秒的计时器。当此计时器触发时，客户端使用相同的目标地址和端口，但从不同的套接字Y向服务器发送另一个绑定请求。此请求包含一个RESPONSE-address-address属性，设置为（Pa，Pp）。这将在NAT上创建一个新绑定，并导致STUN服务器发送一个绑定响应，该响应将匹配旧绑定（如果它仍然存在）。如果客户端在套接字X上接收到绑定响应，则它知道绑定尚未过期。如果客户机在套接字Y上接收到绑定响应（如果旧绑定过期，并且NAT将相同的公共地址和端口分配给新绑定，则这是可能的），或者根本没有收到响应，则它知道绑定已过期。
The client can find the value of the binding lifetime by doing a binary search through T, arriving eventually at the value where the response is not received for any timer greater than T, but is received for any timer less than T.
客户机可以通过对T进行二进制搜索来找到绑定生存期的值，最终得到的值是，对于大于T的任何计时器都不会收到响应，但是对于小于T的任何计时器都会收到响应。
This discovery process takes quite a bit of time, and is something that will typically be run in the background on a device once it boots.
这一发现过程需要相当长的时间，而且一旦设备启动，通常会在后台运行。
It is possible that the client can get inconsistent results each time this process is run. For example, if the NAT should reboot, or be reset for some reason, the process may discover a lifetime than is shorter than the actual one. For this reason, implementations are encouraged to run the test numerous times, and be prepared to get inconsistent results.
每次运行此进程时，客户端可能会得到不一致的结果。例如，如果NAT应该重新启动，或者由于某种原因被重置，则进程可能会发现一个比实际生存期短的生存期。出于这个原因，我们鼓励实现多次运行测试，并准备得到不一致的结果。
Consider once more the case of a VoIP phone. It used the discovery process above when it started up, to discover its environment. Now, it wants to make a call. As part of the discovery process, it determined that it was behind a full-cone NAT.
再次考虑VoIP电话的情况。它在启动时使用上述发现过程来发现其环境。现在，它想打个电话。作为发现过程的一部分，它确定它是在一个完整的锥形NAT之后。
Consider further that this phone consists of two logically separated components - a control component that handles signaling, and a media component that handles the audio, video, and RTP [12]. Both are behind the same NAT. Because of this separation of control and media, we wish to minimize the communication required between them. In fact, they may not even run on the same host.
进一步考虑，该电话由两个逻辑分离的组件组成：一个处理信令的控制组件，和一个处理音频、视频和RTP的媒体组件[12 ]。两人都支持同一个NAT。由于控制和媒体的分离，我们希望尽量减少它们之间需要的通信。事实上，它们甚至可能不在同一台主机上运行。
In order to make a voice call, the phone needs to obtain an IP address and port that it can place in the call setup message as the destination for receiving audio.
要进行语音通话，手机需要获得IP地址和端口，以便将其作为接收音频的目的地放入通话设置信息中。
To obtain an address, the control component sends a Shared Secret Request to the server, obtains a shared secret, and then sends a Binding Request to the server. No CHANGE-REQUEST attribute is present in the Binding Request, and neither is the RESPONSE-ADDRESS attribute. The Binding Response contains a mapped address. The control component then formulates a second Binding Request. This request contains a RESPONSE-ADDRESS, which is set to the mapped address learned from the previous Binding Response. This Binding Request is passed to the media component, along with the IP address and port of the STUN server. The media component sends the Binding Request. The request goes to the STUN server, which sends the Binding Response back to the control component. The control component receives this, and now has learned an IP address and port that will be routed back to the media component that sent the request.
为了获取地址，控制组件向服务器发送共享密钥请求，获取共享密钥，然后向服务器发送绑定请求。绑定请求中不存在CHANGE-REQUEST属性，RESPONSE-ADDRESS属性也不存在。绑定响应包含映射的地址。然后，控制组件制定第二个绑定请求。此请求包含一个RESPONSE-ADDRESS，该地址设置为从上一个绑定响应中学习到的映射地址。此绑定请求连同STUN服务器的IP地址和端口一起传递给媒体组件。媒体组件发送绑定请求。该请求发送到STUN服务器，该服务器将绑定响应发送回控制组件。控制组件接收到该请求，现在已了解将路由回发送请求的媒体组件的IP地址和端口。
The client will be able to receive media from anywhere on this mapped address.
客户端将能够从此映射地址上的任何位置接收媒体。
In the case of silence suppression, there may be periods where the client receives no media. In this case, the UDP bindings could timeout (UDP bindings in NATs are typically short; 30 seconds is common). To deal with this, the application can periodically retransmit the query in order to keep the binding fresh.
在静默抑制的情况下，可能存在客户端未接收媒体的时段。在这种情况下，UDP绑定可能会超时（NAT中的UDP绑定通常较短；通常为30秒）。为了处理这个问题，应用程序可以定期重新传输查询，以保持绑定的新鲜。
It is possible that both participants in the multimedia session are behind the same NAT. In that case, both will repeat this procedure above, and both will obtain public address bindings. When one sends media to the other, the media is routed to the NAT, and then turns right back around to come back into the enterprise, where it is translated to the private address of the recipient. This is not particularly efficient, and unfortunately, does not work in many commercial NATs. In such cases, the clients may need to retry using private addresses.
多媒体会话中的两个参与者可能都在同一个NAT后面。在这种情况下，两者都将重复上述过程，并且都将获得公共地址绑定。当一方向另一方发送介质时，介质被路由到NAT，然后右转弯返回企业，在企业中，介质被转换为接收方的私有地址。这不是特别有效，不幸的是，在许多商业NAT中不起作用。在这种情况下，客户端可能需要使用专用地址重试。
This section presents the detailed encoding of a STUN message.
本节介绍STUN消息的详细编码。
STUN is a request-response protocol. Clients send a request, and the server sends a response. There are two requests, Binding Request, and Shared Secret Request. The response to a Binding Request can
STUN是一种请求-响应协议。客户端发送请求，服务器发送响应。有两个请求，绑定请求和共享机密请求。对绑定请求的响应可以是
either be the Binding Response or Binding Error Response. The response to a Shared Secret Request can either be a Shared Secret Response or a Shared Secret Error Response.
可以是绑定响应，也可以是绑定错误响应。对共享机密请求的响应可以是共享机密响应或共享机密错误响应。
STUN messages are encoded using binary fields. All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in Appendix B of RFC 791 [6]. Unless otherwise noted, numeric constants are in decimal (base 10).
STUN消息使用二进制字段进行编码。所有整数字段都是按网络字节顺序进行的，也就是说，最高有效字节（八位字节）排在第一位。这种字节顺序通常称为big-endian。RFC 791[6]附录B详细描述了传输顺序。除非另有说明，否则数值常量为十进制（以10为基数）。
All STUN messages consist of a 20 byte header:
所有STUN消息都由一个20字节的标题组成：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transaction ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transaction ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Types can take on the following values:
消息类型可以采用以下值：
0x0001 : Binding Request 0x0101 : Binding Response 0x0111 : Binding Error Response 0x0002 : Shared Secret Request 0x0102 : Shared Secret Response 0x0112 : Shared Secret Error Response
0x0001:绑定请求0x0101:绑定响应0x0111:绑定错误响应0x0002:共享机密请求0x0102:共享机密响应0x0112:共享机密错误响应
The message length is the count, in bytes, of the size of the message, not including the 20 byte header.
消息长度是消息大小的计数（字节），不包括20字节的头。
The transaction ID is a 128 bit identifier. It also serves as salt to randomize the request and the response. All responses carry the same identifier as the request they correspond to.
事务ID是一个128位的标识符。它还可以作为salt来随机化请求和响应。所有响应都带有与其对应的请求相同的标识符。
After the header are 0 or more attributes. Each attribute is TLV encoded, with a 16 bit type, 16 bit length, and variable value:
标题后面是0个或多个属性。每个属性都是TLV编码的，具有16位类型、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following types are defined:
定义了以下类型：
0x0001: MAPPED-ADDRESS 0x0002: RESPONSE-ADDRESS 0x0003: CHANGE-REQUEST 0x0004: SOURCE-ADDRESS 0x0005: CHANGED-ADDRESS 0x0006: USERNAME 0x0007: PASSWORD 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000a: UNKNOWN-ATTRIBUTES 0x000b: REFLECTED-FROM
0x0001:映射地址0x0002:响应地址0x0003:更改请求0x0004:源地址0x0005:更改地址0x0006:用户名0x0007:密码0x0008:消息完整性0x0009:错误代码0x000a:未知属性0x000b:反射自
To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into optional and mandatory ones. Attributes with values greater than 0x7fff are optional, which means that the message can be processed by the client or server even though the attribute is not understood. Attributes with values less than or equal to 0x7fff are mandatory to understand, which means that the client or server cannot process the message unless it understands the attribute.
为了允许本规范的未来版本在需要时添加新属性，属性空间分为可选和必需属性。值大于0x7fff的属性是可选的，这意味着即使不理解该属性，客户机或服务器也可以处理该消息。值小于或等于0x7fff的属性是必须理解的，这意味着客户端或服务器无法处理消息，除非它理解该属性。
The MESSAGE-INTEGRITY attribute MUST be the last attribute within a message. Any attributes that are known, but are not supposed to be present in a message (MAPPED-ADDRESS in a request, for example) MUST be ignored.
MESSAGE-INTEGRITY属性必须是消息中的最后一个属性。必须忽略任何已知但不应出现在消息中的属性（例如，请求中的映射地址）。
Table 2 indicates which attributes are present in which messages. An M indicates that inclusion of the attribute in the message is mandatory, O means its optional, C means it's conditional based on some other aspect of the message, and N/A means that the attribute is not applicable to that message type.
表2显示了哪些消息中存在哪些属性。M表示在消息中包含属性是强制性的，O表示其可选，C表示其基于消息的某些其他方面是有条件的，N/A表示该属性不适用于该消息类型。
Binding Shared Shared Shared
Binding Binding Error Secret Secret Secret
Att. Req. Resp. Resp. Req. Resp. Error
Resp.
_____________________________________________________________________
MAPPED-ADDRESS N/A M N/A N/A N/A N/A
RESPONSE-ADDRESS O N/A N/A N/A N/A N/A
CHANGE-REQUEST O N/A N/A N/A N/A N/A
SOURCE-ADDRESS N/A M N/A N/A N/A N/A
CHANGED-ADDRESS N/A M N/A N/A N/A N/A
USERNAME O N/A N/A N/A M N/A
PASSWORD N/A N/A N/A N/A M N/A
MESSAGE-INTEGRITY O O N/A N/A N/A N/A
ERROR-CODE N/A N/A M N/A N/A M
UNKNOWN-ATTRIBUTES N/A N/A C N/A N/A C
REFLECTED-FROM N/A C N/A N/A N/A N/A
Binding Shared Shared Shared
Binding Binding Error Secret Secret Secret
Att. Req. Resp. Resp. Req. Resp. Error
Resp.
_____________________________________________________________________
MAPPED-ADDRESS N/A M N/A N/A N/A N/A
RESPONSE-ADDRESS O N/A N/A N/A N/A N/A
CHANGE-REQUEST O N/A N/A N/A N/A N/A
SOURCE-ADDRESS N/A M N/A N/A N/A N/A
CHANGED-ADDRESS N/A M N/A N/A N/A N/A
USERNAME O N/A N/A N/A M N/A
PASSWORD N/A N/A N/A N/A M N/A
MESSAGE-INTEGRITY O O N/A N/A N/A N/A
ERROR-CODE N/A N/A M N/A N/A M
UNKNOWN-ATTRIBUTES N/A N/A C N/A N/A C
REFLECTED-FROM N/A C N/A N/A N/A N/A
Table 2: Summary of Attributes
表2：属性摘要
The length refers to the length of the value element, expressed as an unsigned integral number of bytes.
长度是指value元素的长度，表示为无符号整数字节数。
The MAPPED-ADDRESS attribute indicates the mapped IP address and port. It consists of an eight bit address family, and a sixteen bit port, followed by a fixed length value representing the IP address.
MAPPED-ADDRESS属性表示映射的IP地址和端口。它由一个8位地址系列和一个16位端口组成，后面是一个表示IP地址的固定长度值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The port is a network byte ordered representation of the mapped port. The address family is always 0x01, corresponding to IPv4. The first 8 bits of the MAPPED-ADDRESS are ignored, for the purposes of aligning parameters on natural boundaries. The IPv4 address is 32 bits.
端口是映射端口的网络字节顺序表示。地址族始终为0x01，对应于IPv4。为了在自然边界上对齐参数，将忽略映射地址的前8位。IPv4地址为32位。
The RESPONSE-ADDRESS attribute indicates where the response to a Binding Request should be sent. Its syntax is identical to MAPPED-ADDRESS.
RESPONSE-ADDRESS属性指示绑定请求的响应应该发送到哪里。其语法与MAPPED-ADDRESS相同。
The CHANGED-ADDRESS attribute indicates the IP address and port where responses would have been sent from if the "change IP" and "change port" flags had been set in the CHANGE-REQUEST attribute of the Binding Request. The attribute is always present in a Binding Response, independent of the value of the flags. Its syntax is identical to MAPPED-ADDRESS.
CHANGED-ADDRESS属性表示如果在绑定请求的change-REQUEST属性中设置了“change IP”和“change port”标志，则发送响应的IP地址和端口。该属性始终存在于绑定响应中，与标志的值无关。其语法与MAPPED-ADDRESS相同。
The CHANGE-REQUEST attribute is used by the client to request that the server use a different address and/or port when sending the response. The attribute is 32 bits long, although only two bits (A and B) are used:
客户机使用CHANGE-REQUEST属性请求服务器在发送响应时使用不同的地址和/或端口。该属性的长度为32位，但仅使用两位（A和B）：
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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the flags is:
旗帜的含义是：
A: This is the "change IP" flag. If true, it requests the server to send the Binding Response with a different IP address than the one the Binding Request was received on.
答：这是“更改IP”标志。如果为true，它将请求服务器发送绑定响应，该响应的IP地址与接收绑定请求的IP地址不同。
B: This is the "change port" flag. If true, it requests the server to send the Binding Response with a different port than the one the Binding Request was received on.
B:这是“更改端口”标志。如果为true，则请求服务器使用与接收绑定请求的端口不同的端口发送绑定响应。
The SOURCE-ADDRESS attribute is present in Binding Responses. It indicates the source IP address and port that the server is sending the response from. Its syntax is identical to that of MAPPED-ADDRESS.
绑定响应中存在源地址属性。它指示服务器从中发送响应的源IP地址和端口。它的语法与MAPPED-ADDRESS的语法相同。
The USERNAME attribute is used for message integrity. It serves as a means to identify the shared secret used in the message integrity check. The USERNAME is always present in a Shared Secret Response, along with the PASSWORD. It is optionally present in a Binding Request when message integrity is used.
USERNAME属性用于消息完整性。它用作标识消息完整性检查中使用的共享机密的方法。用户名和密码始终存在于共享机密响应中。当使用消息完整性时，它可以选择性地出现在绑定请求中。
The value of USERNAME is a variable length opaque value. Its length MUST be a multiple of 4 (measured in bytes) in order to guarantee alignment of attributes on word boundaries.
用户名的值是可变长度的不透明值。它的长度必须是4的倍数（以字节为单位），以保证字边界上的属性对齐。
The PASSWORD attribute is used in Shared Secret Responses. It is always present in a Shared Secret Response, along with the USERNAME.
密码属性用于共享机密响应。它总是与用户名一起出现在共享机密响应中。
The value of PASSWORD is a variable length value that is to be used as a shared secret. Its length MUST be a multiple of 4 (measured in bytes) in order to guarantee alignment of attributes on word boundaries.
PASSWORD的值是一个可变长度的值，用作共享密钥。它的长度必须是4的倍数（以字节为单位），以保证字边界上的属性对齐。
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [13] of the STUN message. It can be present in Binding Requests or Binding Responses. Since it uses the SHA1 hash, the HMAC will be 20 bytes. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. That text is then padded with zeroes so as to be a multiple of 64 bytes. As a result, the MESSAGE-INTEGRITY attribute MUST be the last attribute in any STUN message. The key used as input to HMAC depends on the context.
MESSAGE-INTEGRITY属性包含STUN消息的HMAC-SHA1[13]。它可以出现在绑定请求或绑定响应中。由于它使用SHA1散列，HMAC将是20个字节。用作HMAC输入的文本是STUN消息，包括标题，最多包括message-INTEGRITY属性前面的属性。然后用零填充该文本，使其成为64字节的倍数。因此，MESSAGE-INTEGRITY属性必须是任何STUN消息中的最后一个属性。用作HMAC输入的键取决于上下文。
The ERROR-CODE attribute is present in the Binding Error Response and Shared Secret Error Response. It is a numeric value in the range of 100 to 699 plus a textual reason phrase encoded in UTF-8, and is consistent in its code assignments and semantics with SIP [10] and HTTP [15]. The reason phrase is meant for user consumption, and can be anything appropriate for the response code. The lengths of the reason phrases MUST be a multiple of 4 (measured in bytes). This can be accomplished by added spaces to the end of the text, if necessary. Recommended reason phrases for the defined response codes are presented below.
错误代码属性出现在绑定错误响应和共享机密错误响应中。它是一个介于100到699之间的数值加上一个以UTF-8编码的文本原因短语，其代码分配和语义与SIP[10]和HTTP[15]一致。原因短语是供用户使用的，可以是任何适合响应代码的内容。原因短语的长度必须是4的倍数（以字节为单位）。如有必要，可在文本末尾添加空格。定义的响应代码的推荐原因短语如下所示。
To facilitate processing, the class of the error code (the hundreds digit) is encoded separately from the rest of the code.
为了便于处理，错误代码的类别（数百位）与代码的其余部分分开编码。
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 |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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The class represents the hundreds digit of the response code. The value MUST be between 1 and 6. The number represents the response code modulo 100, and its value MUST be between 0 and 99.
该类表示响应代码的数百位数字。该值必须介于1和6之间。该数字表示以100为模的响应代码，其值必须介于0和99之间。
The following response codes, along with their recommended reason phrases (in brackets) are defined at this time:
此时定义了以下响应代码及其建议的原因短语（括号中）：
400 (Bad Request): The request was malformed. The client should not retry the request without modification from the previous attempt.
400（错误请求）：请求的格式不正确。如果未对上一次尝试进行修改，客户端不应重试该请求。
401 (Unauthorized): The Binding Request did not contain a MESSAGE-INTEGRITY attribute.
401（未经授权）：绑定请求不包含消息完整性属性。
420 (Unknown Attribute): The server did not understand a mandatory attribute in the request.
420（未知属性）：服务器不理解请求中的强制属性。
430 (Stale Credentials): The Binding Request did contain a MESSAGE-INTEGRITY attribute, but it used a shared secret that has expired. The client should obtain a new shared secret and try again.
430（过时凭据）：绑定请求确实包含消息完整性属性，但它使用的共享机密已过期。客户端应获取新的共享机密并重试。
431 (Integrity Check Failure): The Binding Request contained a MESSAGE-INTEGRITY attribute, but the HMAC failed verification. This could be a sign of a potential attack, or client implementation error.
431（完整性检查失败）：绑定请求包含消息完整性属性，但HMAC验证失败。这可能是潜在攻击或客户端实现错误的迹象。
432 (Missing Username): The Binding Request contained a MESSAGE-INTEGRITY attribute, but not a USERNAME attribute. Both must be present for integrity checks.
432（缺少用户名）：绑定请求包含消息完整性属性，但不包含用户名属性。两者都必须存在以进行完整性检查。
433 (Use TLS): The Shared Secret request has to be sent over TLS, but was not received over TLS.
433（使用TLS）：共享机密请求必须通过TLS发送，但未通过TLS接收。
500 (Server Error): The server has suffered a temporary error. The client should try again.
500（服务器错误）：服务器遇到临时错误。客户端应重试。
600 (Global Failure:) The server is refusing to fulfill the request. The client should not retry.
600（全局故障：）服务器拒绝满足请求。客户端不应重试。
The UNKNOWN-ATTRIBUTES attribute is present only in a Binding Error Response or Shared Secret Error Response when the response code in the ERROR-CODE attribute is 420.
当错误代码属性中的响应代码为420时，未知属性仅出现在绑定错误响应或共享机密错误响应中。
The attribute contains a list of 16 bit values, each of which represents an attribute type that was not understood by the server. If the number of unknown attributes is an odd number, one of the attributes MUST be repeated in the list, so that the total length of the list is a multiple of 4 bytes.
该属性包含一个16位值的列表，每个值表示服务器无法理解的属性类型。如果未知属性的数量为奇数，则必须在列表中重复其中一个属性，以便列表的总长度为4字节的倍数。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The REFLECTED-FROM attribute is present only in Binding Responses, when the Binding Request contained a RESPONSE-ADDRESS attribute. The attribute contains the identity (in terms of IP address) of the source where the request came from. Its purpose is to provide traceability, so that a STUN server cannot be used as a reflector for denial-of-service attacks.
当绑定请求包含RESPONSE-ADDRESS属性时，REFLECTED-FROM属性仅出现在绑定响应中。该属性包含请求来自的源的标识（根据IP地址）。其目的是提供可跟踪性，以便STUN服务器不能用作拒绝服务攻击的反射器。
Its syntax is identical to the MAPPED-ADDRESS attribute.
其语法与MAPPED-ADDRESS属性相同。
Generally speaking, attacks on STUN can be classified into denial of service attacks and eavesdropping attacks. Denial of service attacks can be launched against a STUN server itself, or against other elements using the STUN protocol.
一般来说，对STUN的攻击可分为拒绝服务攻击和窃听攻击。可以对STUN服务器本身或使用STUN协议的其他元素发起拒绝服务攻击。
STUN servers create state through the Shared Secret Request mechanism. To prevent being swamped with traffic, a STUN server SHOULD limit the number of simultaneous TLS connections it will hold open by dropping an existing connection when a new connection request arrives (based on an Least Recently Used (LRU) policy, for example). Similarly, it SHOULD limit the number of shared secrets it will store, in the event that the server is storing the shared secrets.
STUN服务器通过共享秘密请求机制创建状态。为了防止流量过多，STUN服务器应在新连接请求到达时（例如，基于最近使用最少的（LRU）策略），通过删除现有连接来限制其将保持打开的同时TLS连接的数量。类似地，在服务器存储共享机密的情况下，它应该限制将存储的共享机密的数量。
The attacks of greater interest are those in which the STUN server and client are used to launch DOS attacks against other entities, including the client itself.
更令人感兴趣的攻击是那些使用STUN服务器和客户端对其他实体（包括客户端本身）发起DOS攻击的攻击。
Many of the attacks require the attacker to generate a response to a legitimate STUN request, in order to provide the client with a faked MAPPED-ADDRESS. The attacks that can be launched using such a technique include:
许多攻击都要求攻击者对合法的电击请求做出响应，以便向客户端提供伪造的映射地址。使用这种技术可以发起的攻击包括：
In this case, the attacker provides a large number of clients with the same faked MAPPED-ADDRESS that points to the intended target. This will trick all the STUN clients into thinking that their addresses are equal to that of the target. The clients then hand out that address in order to receive traffic on it (for example, in SIP or H.323 messages). However, all of that traffic becomes focused at the intended target. The attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications.
在这种情况下，攻击者提供大量客户端，这些客户端具有指向目标的相同伪造映射地址。这将诱使所有晕眩客户认为他们的地址等于目标地址。然后，客户端分发该地址以接收其上的流量（例如，在SIP或H.323消息中）。但是，所有这些流量都集中在预期目标上。该攻击可以提供大量放大，尤其是与使用STUN启用多媒体应用程序的客户端一起使用时。
In this attack, the attacker seeks to deny a client access to services enabled by STUN (for example, a client using STUN to enable SIP-based multimedia traffic). To do that, the attacker provides that client with a faked MAPPED-ADDRESS. The MAPPED-ADDRESS it provides is an IP 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 MAPPED-ADDRESS.
在此攻击中，攻击者试图拒绝客户端访问由STUN启用的服务（例如，客户端使用STUN启用基于SIP的多媒体通信）。为此，攻击者向该客户端提供伪造的映射地址。它提供的映射地址是一个无处路由的IP地址。因此，当客户机发出映射地址时，它将不会接收到它期望接收的任何数据包。
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.
攻击者对此攻击不感兴趣。它影响单个客户机，而这通常不是期望的目标。此外，任何能够发起攻击的攻击者也可以通过其他方式拒绝向客户端提供服务，例如阻止客户端接收来自STUN服务器甚至DHCP服务器的任何响应。
This attack is similar to attack II. However, the faked MAPPED-ADDRESS points to the attacker themself. This allows the attacker to receive traffic which was destined for the client.
此攻击类似于攻击II。但是，伪造的映射地址指向攻击者本人。这使攻击者能够接收发送给客户端的通信量。
In this attack, the attacker forces the client to use a MAPPED-ADDRESS that routes to itself. It then forwards any packets it receives to the client. This attack would allow the attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, as a result, only useful for observing traffic by attackers on the path from the client to the STUN server, but not generally on the path of packets being routed towards the client.
在此攻击中，攻击者强制客户端使用路由到自身的映射地址。然后，它将接收到的任何数据包转发给客户端。此攻击将允许攻击者观察发送到客户端的所有数据包。但是，为了发起攻击，攻击者必须已经能够观察到从客户端到STUN服务器的数据包。在大多数情况下（例如从访问网络发起攻击），这意味着攻击者可能已经观察到发送到客户端的数据包。因此，这种攻击只在攻击者观察从客户端到STUN服务器的路径上的流量时有用，但通常不在路由到客户端的数据包路径上有用。
It is important to note that attacks of this nature (injecting responses with fake MAPPED-ADDRESSes) require that the attacker be capable of eavesdropping requests sent from the client to the server (or to act as a MITM for such attacks). This is because STUN requests contain a transaction identifier, selected by the client, which is random with 128 bits of entropy. The server echoes this value in the response, and the client ignores any responses that don't have a matching transaction ID. Therefore, in order for an attacker to provide a faked response that is accepted by the client, the attacker needs to know what the transaction ID in the request was. The large amount of randomness, combined with the need to know when the client sends a request, precludes attacks that involve guessing the transaction ID.
需要注意的是，这种性质的攻击（使用假映射地址注入响应）要求攻击者能够窃听从客户端发送到服务器的请求（或充当此类攻击的MITM）。这是因为STUN请求包含由客户端选择的事务标识符，该标识符是随机的，具有128位的熵。服务器在响应中回显此值，而客户端忽略任何没有匹配事务ID的响应。因此，为了让攻击者提供客户端接受的伪造响应，攻击者需要知道请求中的事务ID是什么。大量的随机性，再加上需要知道客户端何时发送请求，排除了涉及猜测事务ID的攻击。
Since all of the above attacks rely on this one primitive - injecting a response with a faked MAPPED-ADDRESS - preventing the attacks is accomplished by preventing this one operation. To prevent it, we need to consider the various ways in which it can be accomplished. There are several:
由于上述所有攻击都依赖于这一原语（使用伪造的映射地址注入响应），因此通过防止这一操作来防止攻击。为了防止它的发生，我们需要考虑它可以实现的各种方式。有几种：
In this attack, the attacker compromises a legitimate STUN server through a virus or Trojan horse. Presumably, this would allow the attacker to take over the STUN server, and control the types of responses it generates.
在此攻击中，攻击者通过病毒或特洛伊木马破坏合法的STUN服务器。据推测，这将允许攻击者接管STUN服务器，并控制其生成的响应类型。
Compromise of a STUN server can also lead to discovery of open ports. Knowledge of an open port creates an opportunity for DoS attacks on those ports (or DDoS attacks if the traversed NAT is a full cone NAT). Discovering open ports is already fairly trivial using port probing, so this does not represent a major threat.
STUN服务器受损也可能导致发现开放端口。了解开放端口会为这些端口上的DoS攻击创造机会（如果穿越的NAT是全锥NAT，则为DDoS攻击）。使用端口探测发现打开的端口已经相当简单，因此这并不代表重大威胁。
STUN servers are discovered using DNS SRV records. If an attacker can compromise the DNS, it can inject fake records which map a domain name to the IP address of a STUN server run by the attacker. This will allow it to inject fake responses to launch any of the attacks above.
STUN服务器是使用DNS SRV记录发现的。如果攻击者可以破坏DNS，它可以注入将域名映射到攻击者运行的STUN服务器IP地址的虚假记录。这将允许它注入虚假响应来发起上述任何攻击。
Rather than compromise the STUN server, an attacker can cause a STUN server to generate responses with the wrong MAPPED-ADDRESS by compromising a router or NAT on the path from the client to the STUN server. When the STUN request passes through the rogue router or NAT, it rewrites the source address of the packet to be that of the desired MAPPED-ADDRESS. This address cannot be arbitrary. If the attacker is on the public Internet (that is, there are no NATs between it and the STUN server), and the attacker doesn't modify the STUN request, the address has to have the property that packets sent from the STUN server to that address would route through the compromised router. This is because the STUN server will send the responses back to the source address of the request. With a modified source address, the only way they can reach the client is if the compromised router directs them there. If the attacker is on the public Internet, but they can modify the STUN request, they can insert a RESPONSE-ADDRESS attribute into the request, containing the actual source address of the STUN request. This will cause the server to send the response to the client, independent of the source address the STUN server sees. This gives the attacker the ability to forge an arbitrary source address when it forwards the STUN request.
攻击者可以通过破坏从客户端到STUN服务器的路径上的路由器或NAT，使STUN服务器生成具有错误映射地址的响应，而不是破坏STUN服务器。当STUN请求通过rogue路由器或NAT时，它会将数据包的源地址重写为所需的映射地址。此地址不能是任意的。如果攻击者位于公共互联网上（即，它与STUN服务器之间没有NAT），并且攻击者没有修改STUN请求，则该地址必须具有这样的属性：从STUN服务器发送到该地址的数据包将通过受损路由器路由。这是因为STUN服务器会将响应发送回请求的源地址。通过修改源地址，他们能够到达客户机的唯一方式是如果受损的路由器将他们引导到那里。如果攻击者位于公共Internet上，但他们可以修改STUN请求，则可以在请求中插入RESPONSE-ADDRESS属性，该属性包含STUN请求的实际源地址。这将导致服务器向客户端发送响应，而不依赖于STUN服务器看到的源地址。这使攻击者能够在转发STUN请求时伪造任意源地址。
If the attacker is on a private network (that is, there are NATs between it and the STUN server), the attacker will not be able to force the server to generate arbitrary MAPPED-ADRESSes in responses. They will only be able force the STUN server to generate MAPPED-ADDRESSes which route to the private network. This is because the NAT between the attacker and the STUN server will rewrite the source address of the STUN request, mapping it to a public address that routes to the private network. Because of this, the attacker can only force the server to generate faked mapped addresses that route to the private network. Unfortunately, it is possible that a low quality NAT would be willing to map an allocated public address to another public address (as opposed to an internal private address), in which case the attacker could forge the source address in a STUN request to be an arbitrary public address. This kind of behavior from NATs does appear to be rare.
如果攻击者位于专用网络上（即，它与STUN服务器之间存在NAT），则攻击者将无法强制服务器在响应中生成任意映射地址。它们只能强制STUN服务器生成路由到专用网络的映射地址。这是因为攻击者和STUN服务器之间的NAT将重写STUN请求的源地址，并将其映射到路由到专用网络的公共地址。因此，攻击者只能强制服务器生成路由到专用网络的伪造映射地址。不幸的是，低质量NAT可能愿意将分配的公共地址映射到另一个公共地址（而不是内部私人地址），在这种情况下，攻击者可能会将STUN请求中的源地址伪造为任意公共地址。NATs的这种行为确实很少见。
As an alternative to approach III, if the attacker can place an element on the path from the client to the server, the element can act as a man-in-the-middle. In that case, it can intercept a STUN request, and generate a STUN response directly with any desired value of the MAPPED-ADDRESS field. Alternatively, it can forward the STUN request to the server (after potential modification), receive the response, and forward it to the client. When forwarding the request and response, this attack is subject to the same limitations on the MAPPED-ADDRESS described in Section 12.2.3.
作为第三种方法的替代方法，如果攻击者可以在从客户端到服务器的路径上放置一个元素，那么该元素可以充当中间人。在这种情况下，它可以截获STUN请求，并直接使用MAPPED-ADDRESS字段的任何所需值生成STUN响应。或者，它可以将STUN请求转发给服务器（在可能的修改之后），接收响应，然后转发给客户端。转发请求和响应时，此攻击受第12.2.3节所述映射地址的相同限制。
In this approach, the attacker does not need to be a MITM (as in approaches III and IV). Rather, it only needs to be able to eavesdrop onto a network segment that carries STUN requests. This is easily done in multiple access networks such as ethernet or unprotected 802.11. To inject the fake response, the attacker listens on the network for a STUN request. When it sees one, it simultaneously launches a DoS attack on the STUN server, and generates its own STUN response with the desired MAPPED-ADDRESS value. The STUN response generated by the attacker will reach the client, and the DoS attack against the server is aimed at preventing the legitimate response from the server from reaching the client. Arguably, the attacker can do without the DoS attack on the server, so long as the faked response beats the real response back to the client, and the client uses the first response, and ignores the second (even though it's different).
在这种方法中，攻击者不需要是MITM（如方法III和IV）。相反，它只需要能够窃听承载STUN请求的网段。这在多址网络（如以太网或不受保护的802.11）中很容易实现。为了注入假响应，攻击者会在网络上侦听一个眩晕请求。当它看到一个时，它会同时对STUN服务器发起DoS攻击，并使用所需的映射地址值生成自己的STUN响应。攻击者生成的STUN响应将到达客户端，针对服务器的DoS攻击旨在阻止服务器的合法响应到达客户端。可以说，攻击者可以在服务器上不受DoS攻击，只要伪造的响应比客户机的真实响应快，客户机使用第一个响应，而忽略第二个响应（即使它不同）。
This approach is similar to approach V. The attacker listens on the network for a STUN request. When it sees it, it generates its own STUN request towards the server. This STUN request is identical to the one it saw, but with a spoofed source IP address. The spoofed address is equal to the one that the attacker desires to have placed in the MAPPED-ADDRESS of the STUN response. In fact, the attacker generates a flood of such packets. The STUN server will receive the one original request, plus a flood of duplicate fake ones. It generates responses to all of them. If the flood is sufficiently large for the responses to congest routers or some other equipment, there is a reasonable probability that the one real response is lost (along with many of the faked ones), but the net result is that only the faked responses are received by the STUN client. These responses are all identical and all contain the MAPPED-ADDRESS that the attacker wanted the client to use.
此方法类似于方法V。攻击者在网络上侦听昏迷请求。当它看到它时，它会向服务器生成自己的STUN请求。此STUN请求与它看到的相同，但具有伪造的源IP地址。伪造地址等于攻击者希望在STUN响应的映射地址中放置的地址。事实上，攻击者会生成大量此类数据包。STUN服务器将收到一个原始请求，加上大量重复的伪造请求。它生成对所有这些问题的响应。如果洪水足够大，足以响应拥塞路由器或某些其他设备，则一个真实响应（以及许多伪造响应）丢失的可能性是合理的，但最终结果是，STUN客户端只接收到伪造响应。这些响应都是相同的，并且都包含攻击者希望客户端使用的映射地址。
The flood of duplicate packets is not needed (that is, only one faked request is sent), so long as the faked response beats the real response back to the client, and the client uses the first response, and ignores the second (even though it's different).
不需要大量重复数据包（也就是说，只发送一个伪造的请求），只要伪造的响应将真实的响应打回到客户端，并且客户端使用第一个响应，而忽略第二个响应（即使它不同）。
Note that, in this approach, launching a DoS attack against the STUN server or the IP network, to prevent the valid response from being sent or received, is problematic. The attacker needs the STUN server to be available to handle its own request. Due to the periodic retransmissions of the request from the client, this leaves a very tiny window of opportunity. The attacker must start the DoS attack immediately after the actual request from the client, causing the correct response to be discarded, and then cease the DoS attack in order to send its own request, all before the next retransmission from the client. Due to the close spacing of the retransmits (100ms to a few seconds), this is very difficult to do.
请注意，在这种方法中，对STUN服务器或IP网络发起DoS攻击以阻止发送或接收有效响应是有问题的。攻击者需要STUN服务器来处理自己的请求。由于客户机定期重新传输请求，这留下了一个非常小的机会窗口。攻击者必须在收到客户端的实际请求后立即启动DoS攻击，从而放弃正确的响应，然后停止DoS攻击以发送自己的请求，所有这些都必须在客户端下次重新传输之前进行。由于重传间隔很近（100毫秒到几秒钟），因此很难做到这一点。
Besides DoS attacks, there may be other ways to prevent the actual request from the client from reaching the server. Layer 2 manipulations, for example, might be able to accomplish it.
除了DoS攻击之外，还可能有其他方法来阻止客户端的实际请求到达服务器。例如，第2层操作可能能够完成它。
Fortunately, Approach IV is subject to the same limitations documented in Section 12.2.3, which limit the range of MAPPED-ADDRESSes the attacker can cause the STUN server to generate.
幸运的是，方法IV受到第12.2.3节中记录的相同限制，这限制了攻击者可以导致STUN服务器生成的映射地址的范围。
STUN provides mechanisms to counter the approaches described above, and additional, non-STUN techniques can be used as well.
STUN提供了对抗上述方法的机制，还可以使用其他非STUN技术。
First off, it is RECOMMENDED that networks with STUN clients implement ingress source filtering (RFC 2827 [7]). This is particularly important for the NATs themselves. As Section 12.2.3 explains, NATs which do not perform this check can be used as "reflectors" in DDoS attacks. Most NATs do perform this check as a default mode of operation. We strongly advise people that purchase NATs to ensure that this capability is present and enabled.
首先，建议使用STUN客户端的网络实施入口源过滤（RFC 2827[7]）。这对NAT本身尤其重要。如第12.2.3节所述，未执行此检查的NAT可在DDoS攻击中用作“反射器”。大多数NAT将此检查作为默认操作模式执行。我们强烈建议人们购买NAT，以确保此功能的存在和启用。
Secondly, it is RECOMMENDED that STUN servers be run on hosts dedicated to STUN, with all UDP and TCP ports disabled except for the STUN ports. This is to prevent viruses and Trojan horses from infecting STUN servers, in order to prevent their compromise. This helps mitigate Approach I (Section 12.2.1).
其次，建议在专用于STUN的主机上运行STUN服务器，禁用除STUN端口之外的所有UDP和TCP端口。这是为了防止病毒和特洛伊木马感染STUN服务器，以防止其危害。这有助于缓解方法I（第12.2.1节）。
Thirdly, to prevent the DNS attack of Section 12.2.2, Section 9.2 recommends that the client verify the credentials provided by the server with the name used in the DNS lookup.
第三，为了防止第12.2.2节中的DNS攻击，第9.2节建议客户端使用DNS查找中使用的名称验证服务器提供的凭据。
Finally, all of the attacks above rely on the client taking the mapped address it learned from STUN, and using it in application layer protocols. If encryption and message integrity are provided within those protocols, the eavesdropping and identity assumption attacks can be prevented. As such, applications that make use of STUN addresses in application protocols SHOULD use integrity and encryption, even if a SHOULD level strength is not specified for that protocol. For example, multimedia applications using STUN addresses to receive RTP traffic would use secure RTP [16].
最后，上述所有攻击都依赖于客户端获取从STUN学到的映射地址，并将其用于应用层协议。如果在这些协议中提供加密和消息完整性，则可以防止窃听和身份假设攻击。因此，在应用程序协议中使用STUN地址的应用程序应该使用完整性和加密，即使没有为该协议指定应级别强度。例如，使用STUN地址接收RTP流量的多媒体应用程序将使用安全RTP[16]。
The above three techniques are non-STUN mechanisms. STUN itself provides several countermeasures.
以上三种技术均为非眩晕机制。眩晕本身提供了几种对策。
Approaches IV (Section 12.2.4), when generating the response locally, and V (Section 12.2.5) require an attacker to generate a faked response. This attack is prevented using the message integrity mechanism provided in STUN, described in Section 8.1.
在本地生成响应时，方法IV（第12.2.4节）和方法V（第12.2.5节）要求攻击者生成伪造响应。使用STUN中提供的消息完整性机制（如第8.1节所述）可防止此攻击。
Approaches III (Section 12.2.3) IV (Section 12.2.4), when using the relaying technique, and VI (12.2.6), however, are not preventable through server signatures. Both approaches are most potent when the attacker can modify the request, inserting a RESPONSE-ADDRESS that routes to the client. Fortunately, such modifications are preventable using the message integrity techniques described in Section 9.3. However, these three approaches are still functional when the attacker modifies nothing but the source address of the STUN request. Sadly, this is the one thing that cannot be protected through cryptographic means, as this is the change that STUN itself is seeking to detect and report. It is therefore an inherent weakness in NAT, and not fixable in STUN. To help mitigate these attacks, Section 9.4 provides several heuristics for the client to follow. The client looks for inconsistent or extra responses, both of which are signs of the attacks described above. However, these heuristics are just that - heuristics, and cannot be guaranteed to prevent attacks. The heuristics appear to prevent the attacks as we know how to launch them today. Implementors should stay posted for information on new heuristics that might be required in the future. Such information will be distributed on the IETF MIDCOM mailing list, midcom@ietf.org.
然而，当使用中继技术时，方法III（第12.2.3节）、方法IV（第12.2.4节）和方法VI（第12.2.6节）不能通过服务器签名来防止。当攻击者可以修改请求，插入路由到客户端的响应地址时，这两种方法都是最有效的。幸运的是，使用第9.3节中描述的消息完整性技术可以防止此类修改。然而，当攻击者只修改STUN请求的源地址时，这三种方法仍然有效。可悲的是，这是一件无法通过加密手段保护的事情，因为这是STUN本身试图检测和报告的变化。因此，这是NAT固有的弱点，在晕眩中无法修复。为了帮助减轻这些攻击，第9.4节提供了一些启发式方法供客户端遵循。客户端查找不一致或额外的响应，这两种响应都是上述攻击的迹象。然而，这些启发法只是一种启发法，不能保证能够防止攻击。启发式似乎可以防止攻击，因为我们现在知道如何发动攻击。实现者应该随时了解未来可能需要的新启发式的信息。此类信息将在IETF MIDCOM邮件列表中分发，midcom@ietf.org.
None of the countermeasures listed above can prevent the attacks described in Section 12.2.3 if the attacker is in the appropriate network paths. Specifically, consider the case in which the attacker wishes to convince client C that it has address V. The attacker needs to have a network element on the path between A and the server (in order to modify the request) and on the path between the server
如果攻击者位于适当的网络路径中，则上述任何对策都无法阻止第12.2.3节所述的攻击。具体地，考虑攻击者希望说服客户端C它具有地址V的情况。攻击者需要在A和服务器之间的路径上具有网络元素（以修改请求）并在服务器之间的路径上。
and V so that it can forward the response to C. Furthermore, if there is a NAT between the attacker and the server, V must also be behind the same NAT. In such a situation, the attacker can either gain access to all the application-layer traffic or mount the DDOS attack described in Section 12.1.1. Note that any host which exists in the correct topological relationship can be DDOSed. It need not be using STUN.
和V，以便将响应转发给C。此外，如果攻击者和服务器之间存在NAT，则V也必须位于同一NAT后面。在这种情况下，攻击者可以获得对所有应用层流量的访问权，也可以发起第12.1.1节所述的DDOS攻击。请注意，存在于正确拓扑关系中的任何主机都可以被DDoS攻击。它不需要使用眩晕。
STUN cannot be extended. Changes to the protocol are made through a standards track revision of this specification. As a result, no IANA registries are needed. Any future extensions will establish any needed registries.
晕眩不能延长。通过对本规范的标准跟踪修订对协议进行更改。因此，不需要IANA注册。今后的任何扩展都将建立任何必要的登记册。
The IAB has studied the problem of "Unilateral Self Address Fixing", 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 (RFC 3424 [17]). STUN is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
IAB研究了“单边自我地址固定”问题，这是一个一般过程，客户机通过协作协议反射机制试图确定其在NAT另一侧另一领域的地址（RFC 3424[17]）。STUN是执行此类功能的协议的一个示例。IAB已授权为此目的制定的任何协议都应记录一组特定的考虑因素。本节满足这些要求。
From RFC 3424 [17], any UNSAF proposal must provide:
根据RFC 3424[17]，任何UNSAF提案必须提供：
Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't".
精确定义一个具体的、范围有限的问题，该问题将通过UNSAF提案解决。短期解决方案不应泛化为解决其他问题；这就是为什么“短期修复通常不是”。
The specific problems being solved by STUN are:
STUN正在解决的具体问题有：
o Provide a means for a client to detect the presence of one or more NATs between it and a server run by a service provider on the public Internet. The purpose of such detection is to determine additional steps that might be necessary in order to receive service from that particular provider.
o 为客户端提供一种方法，以检测其与公共Internet上服务提供商运行的服务器之间是否存在一个或多个NAT。这种检测的目的是确定可能需要的额外步骤，以便从该特定提供者接收服务。
o Provide a means for a client to detect the presence of one or more NATs between it and another client, where the second client is reachable from the first, but it is not known whether the second client resides on the public Internet.
o 为客户端提供一种方法，以检测其与另一客户端之间是否存在一个或多个NAT，其中第二客户端可以从第一客户端访问，但不知道第二客户端是否驻留在公共Internet上。
o Provide a means for a client to obtain an address on the public Internet from a non-symmetric NAT, for the express purpose of receiving incoming UDP traffic from another host, targeted to that address.
o 为客户端提供从非对称NAT获取公共Internet上地址的方法，以明确接收来自另一个主机（针对该地址）的传入UDP流量。
STUN does not address TCP, either incoming or outgoing, and does not address outgoing UDP communications.
STUN不寻址TCP（传入或传出），也不寻址传出UDP通信。
From [17], any UNSAF proposal must provide:
从[17]开始，任何UNSAF提案必须提供：
Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
退出战略/过渡计划的说明。更好的短期修复方法是，随着适当技术的部署，自然会看到越来越少的使用。
STUN comes with its own built in exit strategy. This strategy is the detection operation that is performed as a precursor to the actual UNSAF address-fixing operation. This discovery operation, documented in Section 10.1, attempts to discover the existence of, and type of, any NATS between the client and the service provider network. Whilst the detection of the specific type of NAT may be brittle, the discovery of the existence of NAT is itself quite robust. As NATs are phased out through the deployment of IPv6, the discovery operation will return immediately with the result that there is no NAT, and no further operations are required. Indeed, the discovery operation itself can be used to help motivate deployment of IPv6; if a user detects a NAT between themselves and the public Internet, they can call up their access provider and complain about it.
STUN有自己的内置退出策略。该策略是作为实际UNSAF地址固定操作的前驱执行的检测操作。第10.1节中记录的该发现操作试图发现客户端和服务提供商网络之间存在的任何NAT及其类型。虽然特定类型NAT的检测可能很脆弱，但NAT存在的发现本身就相当可靠。由于NAT通过部署IPv6而逐步淘汰，发现操作将立即返回，结果是没有NAT，并且不需要进一步的操作。事实上，发现操作本身可以用来帮助推动IPv6的部署；如果用户检测到自己与公共互联网之间存在NAT，他们可以致电接入提供商投诉。
STUN can also help facilitate the introduction of midcom. As midcom-capable NATs are deployed, applications will, instead of using STUN (which also resides at the application layer), first allocate an address binding using midcom. However, it is a well-known limitation of midcom that it only works when the agent knows the middleboxes through which its traffic will flow. Once bindings have been allocated from those middleboxes, a STUN detection procedure can validate that there are no additional middleboxes on the path from the public Internet to the client. If this is the case, the application can continue operation using the address bindings allocated from midcom. If it is not the case, STUN provides a mechanism for self-address fixing through the remaining midcom-unaware middleboxes. Thus, STUN provides a way to help transition to full midcom-aware networks.
STUN还可以帮助促进midcom的引入。在部署支持midcom的NAT时，应用程序将首先使用midcom分配地址绑定，而不是使用STUN（它也位于应用程序层）。然而，众所周知，midcom的一个限制是，只有当代理知道其流量将通过的中间盒时，它才起作用。一旦从这些中间盒分配了绑定，STUN检测过程可以验证从公共Internet到客户端的路径上是否没有其他中间盒。如果是这种情况，应用程序可以使用从midcom分配的地址绑定继续操作。如果不是这样，STUN提供了一种机制，通过剩余的midcom不知道的中间盒进行自我地址修复。因此，STUN提供了一种帮助过渡到完全支持midcom的网络的方法。
From [17], any UNSAF proposal must provide:
从[17]开始，任何UNSAF提案必须提供：
Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
讨论可能使系统更“脆弱”的具体问题。例如，涉及在多个网络层使用数据的方法会产生更多的依赖性，增加调试挑战，并使转换更加困难。
STUN introduces brittleness into the system in several ways:
STUN通过几种方式将脆性引入系统：
o The discovery process assumes a certain classification of devices based on their treatment of UDP. There could be other types of NATs that are deployed that would not fit into one of these molds. Therefore, future NATs may not be properly detected by STUN. STUN clients (but not servers) would need to change to accommodate that.
o 发现过程假定根据设备对UDP的处理对设备进行特定分类。可能会部署其他类型的NAT，而这些NAT不适合这些模具中的任何一个。因此，STUN可能无法正确检测未来的NAT。STUN客户端（而不是服务器）需要进行更改以适应这种情况。
o The binding acquisition usage of STUN does not work for all NAT types. It will work for any application for full cone NATs only. For restricted cone and port restricted cone NAT, it will work for some applications depending on the application. Application specific processing will generally be needed. For symmetric NATs, the binding acquisition will not yield a usable address. The tight dependency on the specific type of NAT makes the protocol brittle.
o STUN的绑定获取用法并不适用于所有NAT类型。它只适用于全锥NAT的任何应用。对于受限圆锥和端口受限圆锥NAT，它将根据应用程序适用于某些应用程序。通常需要特定于应用程序的处理。对于对称NAT，绑定获取将不会产生可用地址。对特定类型的NAT的紧密依赖性使协议变得脆弱。
o STUN assumes that the server exists on the public Internet. If the server is located in another private address realm, the user may or may not be able to use its discovered address to communicate with other users. There is no way to detect such a condition.
o STUN假定服务器存在于公共Internet上。如果服务器位于另一个私有地址域中，则用户可能无法使用发现的地址与其他用户通信。没有办法检测到这种情况。
o The bindings allocated from the NAT need to be continuously refreshed. Since the timeouts for these bindings is very implementation specific, the refresh interval cannot easily be determined. When the binding is not being actively used to receive traffic, but to wait for an incoming message, the binding refresh will needlessly consume network bandwidth.
o 从NAT分配的绑定需要不断刷新。由于这些绑定的超时是特定于实现的，所以刷新间隔很难确定。当绑定不是主动用于接收流量，而是用于等待传入消息时，绑定刷新将不必要地消耗网络带宽。
o The use of the STUN server as an additional network element introduces another point of potential security attack. These attacks are largely prevented by the security measures provided by STUN, but not entirely.
o 将STUN服务器用作额外的网络元素会引入另一个潜在的安全攻击点。这些攻击在很大程度上是通过STUN提供的安全措施防止的，但并非完全如此。
o The use of the STUN server as an additional network element introduces another point of failure. If the client cannot locate a STUN server, or if the server should be unavailable due to failure, the application cannot function.
o 将STUN服务器用作额外的网元会导致另一个故障点。如果客户端找不到STUN服务器，或者服务器因故障而不可用，则应用程序无法运行。
o The use of STUN to discover address bindings will result in an increase in latency for applications. For example, a Voice over IP application will see an increase of call setup delays equal to at least one RTT to the STUN server.
o 使用STUN发现地址绑定将导致应用程序的延迟增加。例如，IP语音应用程序将看到呼叫设置延迟的增加，至少相当于STUN服务器的一个RTT。
o The discovery of binding lifetimes is prone to error. It assumes that the same lifetime will exist for all bindings. This may not be true if the NAT uses dynamic binding lifetimes to handle overload, or if the NAT itself reboots during the discovery process.
o 绑定生存期的发现容易出错。它假定所有绑定都存在相同的生存期。如果NAT使用动态绑定生存期来处理过载，或者NAT本身在发现过程中重新启动，则情况可能并非如此。
o STUN imposes some restrictions on the network topologies for proper operation. If client A obtains an address from STUN server X, and sends it to client B, B may not be able to send to A using that IP address. The address will not work if any of the following is true:
o STUN对网络拓扑施加了一些限制，以确保正常运行。如果客户端A从STUN服务器X获得地址并将其发送给客户端B，则B可能无法使用该IP地址发送给A。如果以下任何一项为真，则该地址将不起作用：
- The STUN server is not in an address realm that is a common ancestor (topologically) of both clients A and B. For example, consider client A and B, both of which have residential NAT devices. Both devices connect them to their cable operators, but both clients have different providers. Each provider has a NAT in front of their entire network, connecting it to the public Internet. If the STUN server used by A is in A's cable operator's network, an address obtained by it will not be usable by B. The STUN server must be in the network which is a common ancestor to both - in this case, the public Internet.
- STUN服务器不是一个地址域，它是客户端A和B的共同祖先（拓扑），例如，考虑客户端A和B，它们都具有住宅NAT设备。这两种设备都将它们连接到其有线电视运营商，但两个客户端都有不同的提供商。每个提供商在其整个网络前面都有一个NAT，将其连接到公共互联网。如果A使用的STUN服务器位于A的有线电视运营商的网络中，B将无法使用其获得的地址。STUN服务器必须位于网络中，该网络是两者的共同祖先，在这种情况下，是公共互联网。
- The STUN server is in an address realm that is a common ancestor to both clients, but both clients are behind the same NAT connecting to that address realm. For example, if the two clients in the previous example had the same cable operator, that cable operator had a single NAT connecting their network to the public Internet, and the STUN server was on the public Internet, the address obtained by A would not be usable by B. That is because some NATs will not accept an internal packet sent to a public IP address which is mapped back to an internal address. To deal with this, additional protocol mechanisms or configuration parameters need to be introduced which detect this case.
- STUN服务器位于一个地址域中，该地址域是两个客户端的共同祖先，但两个客户端都位于连接到该地址域的相同NAT后面。例如，如果前一个示例中的两个客户端具有相同的有线电视运营商，则该有线电视运营商具有一个将其网络连接到公共互联网的NAT，并且STUN服务器位于公共互联网上，由A获得的地址将不可由B使用。这是因为某些NAT将不接受发送到公共IP地址的内部数据包，该地址被映射回内部地址。为了解决这个问题，需要引入额外的协议机制或配置参数来检测这种情况。
o Most significantly, STUN introduces potential security threats which cannot be eliminated. This specification describes heuristics that can be used to mitigate the problem, but it is provably unsolvable given what STUN is trying to accomplish. These security problems are described fully in Section 12.
o 最重要的是，STUN引入了无法消除的潜在安全威胁。本规范描述了可用于缓解问题的启发式方法，但鉴于STUN试图实现的目标，它是无法解决的。这些安全问题在第12节中有详细描述。
From [17], any UNSAF proposal must provide:
从[17]开始，任何UNSAF提案必须提供：
Identify requirements for longer term, sound technical solutions -- contribute to the process of finding the right longer term solution.
确定长期、可靠的技术解决方案的需求——为找到正确的长期解决方案的过程做出贡献。
Our experience with STUN has led to the following requirements for a long term solution to the NAT problem:
我们在STUN方面的经验导致了长期解决NAT问题的以下要求：
Requests for bindings and control of other resources in a NAT need to be explicit. Much of the brittleness in STUN derives from its guessing at the parameters of the NAT, rather than telling the NAT what parameters to use.
NAT中绑定和控制其他资源的请求需要是显式的。STUN的脆弱性很大程度上源于它对NAT参数的猜测，而不是告诉NAT使用什么参数。
Control needs to be "in-band". There are far too many scenarios in which the client will not know about the location of middleboxes ahead of time. Instead, control of such boxes needs to occur in-band, traveling along the same path as the data will itself travel. This guarantees that the right set of middleboxes are controlled. This is only true for first-party controls; third-party controls are best handled using the midcom framework.
控制需要是“带内的”。在很多情况下，客户无法提前知道中间包的位置。相反，这些盒子的控制需要在频带内进行，沿着数据本身的路径进行。这保证了控制正确的中间盒集。这仅适用于第一方控制；最好使用midcom框架处理第三方控件。
Control needs to be limited. Users will need to communicate through NATs which are outside of their administrative control. In order for providers to be willing to deploy NATs which can be controlled by users in different domains, the scope of such controls needs to be extremely limited - typically, allocating a binding to reach the address where the control packets are coming from.
控制需要加以限制。用户需要通过NAT进行通信，NAT不在其管理控制范围内。为了让提供商愿意部署可由不同域中的用户控制的NAT，此类控制的范围需要非常有限——通常，分配绑定以到达控制数据包来自的地址。
Simplicity is Paramount. The control protocol will need to be implement in very simple clients. The servers will need to support extremely high loads. The protocol will need to be extremely robust, being the precursor to a host of application protocols. As such, simplicity is key.
简单是最重要的。控制协议需要在非常简单的客户端中实现。服务器需要支持极高的负载。该协议需要非常健壮，作为一系列应用程序协议的前身。因此，简单性是关键。
From [17], any UNSAF proposal must provide:
从[17]开始，任何UNSAF提案必须提供：
Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
与现有的、已部署的NA[P]Ts和经验报告讨论指出的实际问题的影响。
Several of the practical issues with STUN involve future proofing - breaking the protocol when new NAT types get deployed. Fortunately, this is not an issue at the current time, since most of the deployed NATs are of the types assumed by STUN. The primary usage STUN has found is in the area of VoIP, to facilitate allocation of addresses for receiving RTP [12] traffic. In that application, the periodic keepalives are provided by the RTP traffic itself. However, several practical problems arise for RTP. First, RTP assumes that RTCP traffic is on a port one higher than the RTP traffic. This pairing property cannot be guaranteed through NATs that are not directly controllable. As a result, RTCP traffic may not be properly received. Protocol extensions to SDP have been proposed which mitigate this by allowing the client to signal a different port for RTCP [18]. However, there will be interoperability problems for some time.
STUN的几个实际问题涉及到未来的验证——在部署新的NAT类型时破坏协议。幸运的是，目前这不是一个问题，因为大多数部署的NAT都是STUN假定的类型。STUN发现的主要用途是在VoIP领域，以便于分配用于接收RTP[12]流量的地址。在该应用程序中，定期保留由RTP流量本身提供。然而，RTP出现了几个实际问题。首先，RTP假设RTCP流量位于高于RTP流量的端口1上。无法通过不可直接控制的NAT保证此配对属性。因此，RTCP通信可能无法正确接收。已经提出了SDP的协议扩展，通过允许客户端向RTCP发送不同端口的信号来缓解这种情况[18]。但是，在一段时间内会出现互操作性问题。
For VoIP, silence suppression can cause a gap in the transmission of RTP packets. This could result in the loss of a binding in the middle of a call, if that silence period exceeds the binding timeout. This can be mitigated by sending occasional silence packets to keep the binding alive. However, the result is additional brittleness; proper operation depends on the silence suppression algorithm in use, the usage of a comfort noise codec, the duration of the silence period, and the binding lifetime in the NAT.
对于VoIP，静音抑制可能会在RTP数据包的传输中造成间隙。如果该静默期超过绑定超时，则这可能导致呼叫中间的绑定丢失。这可以通过偶尔发送静默数据包来缓解，以保持绑定的活动性。然而，结果是额外的脆性；正确的操作取决于所使用的静默抑制算法、舒适噪声编解码器的使用、静默期的持续时间以及NAT中的绑定寿命。
The problems with STUN are not design flaws in STUN. The problems in STUN have to do with the lack of standardized behaviors and controls in NATs. The result of this lack of standardization has been a proliferation of devices whose behavior is highly unpredictable, extremely variable, and uncontrollable. STUN does the best it can in such a hostile environment. Ultimately, the solution is to make the environment less hostile, and to introduce controls and standardized behaviors into NAT. However, until such time as that happens, STUN provides a good short term solution given the terrible conditions under which it is forced to operate.
STUN的问题不是STUN的设计缺陷。眩晕的问题与NATs缺乏标准化的行为和控制有关。缺乏标准化的结果是，设备的行为高度不可预测、变化无常且无法控制。在这样一个充满敌意的环境中，眩晕尽了最大的努力。最终，解决方案是减少环境的敌意，并在NAT中引入控制和标准化行为。然而，在这种情况发生之前，STUN提供了一个很好的短期解决方案，因为它被迫在恶劣的条件下运行。
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield 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.
作者要感谢Cedric Aoun、Pete Cordell、Cullen Jennings、Bob Penfield和Chris Sullivan的评论，以及Baruch Sterman和Alan Hawrylyshen的初步实施。感谢Leslie Daigle、Allison Mankin、Eric Rescorla和Henning Schulzrinne对这项工作的IESG和IAB投入。
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Dierks, T. and C. Allen, "The TLS protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[4] Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[5] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[5] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[8] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[8] Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 3235，2002年1月。
[9] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox Communication Architecture and Framework", RFC 3303, August 2002.
[9] Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.和A.Rayhan，“中间箱通信架构和框架”，RFC3303，2002年8月。
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[10] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[11] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[11] Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[12] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[13] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[14] Kohl, J. and C. Neuman, "The kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[14] Kohl，J.和C.Neuman，“kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[15] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[16] Baugher M., et al., "The secure real-time transport protocol", Work in Progress.
[16] Baugher M.等人，“安全实时传输协议”，正在进行中。
[17] Daigle, L., Editor, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[17] Daigle，L.，编辑，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[18] Huitema, C., "RTCP attribute in SDP", Work in Progress.
[18] Huitema，C.，“SDP中的RTCP属性”，正在进行的工作。
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Joel Weinberger dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Joel Weinberger dynamicsoft 72 Eagle Rock Avenue一楼东汉诺威，NJ 07936
EMail: jweinberger@dynamicsoft.com
EMail: jweinberger@dynamicsoft.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Rohan Mahy Cisco Systems 101 Cooper St Santa Cruz, CA 95060
加利福尼亚州圣克鲁斯库珀101号罗汉·马希思科系统公司，邮编95060
EMail: rohan@cisco.com
EMail: rohan@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。