Internet Engineering Task Force (IETF) D. MacDonald
Request for Comments: 5780 B. Lowekamp
Category: Experimental Skype
ISSN: 2070-1721 May 2010
Internet Engineering Task Force (IETF) D. MacDonald
Request for Comments: 5780 B. Lowekamp
Category: Experimental Skype
ISSN: 2070-1721 May 2010
NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
使用NAT会话遍历实用程序发现NAT行为（STUN）
Abstract
摘要
This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server.
本规范定义了NAT会话遍历实用程序（STUN）协议的实验性使用，该协议用于发现STUN客户端和STUN服务器之间NAT和防火墙的存在和当前行为。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5780.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5780.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.translate error, please retry
Table of Contents
目录
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 6
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Goals . . . . . . . . . . . . . . . . . . . . 8
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 10
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11
3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 12
4.2. Checking for UDP Connectivity with the STUN Server . . . . 13
4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 14
4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 15
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22
7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 23
8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
8.4. Requirements for a Long-Term Solution . . . . . . . . . . 24
8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
9.2. Port Numbers and SRV Registry . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 6
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Goals . . . . . . . . . . . . . . . . . . . . 8
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 10
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11
3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 12
4.2. Checking for UDP Connectivity with the STUN Server . . . . 13
4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 14
4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 15
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22
7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 23
8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
8.4. Requirements for a Long-Term Solution . . . . . . . . . . 24
8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
9.2. Port Numbers and SRV Registry . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
This experimental NAT Behavior Discovery STUN usage provides information about a NAT device's observable transient behavior; it determines a NAT's behavior with regard to the STUN server used and the particular client ports used at the instant the test is run. This STUN usage does not allow an application behind a NAT to make an absolute determination of the NAT's characteristics. NAT devices do not behave consistently enough to predict future behavior with any guarantee. Applications requiring reliable reach between two particular endpoints must establish a communication channel through NAT using another technique. IETF has proposed standards including [RFC5245] and [RFC5626] for establishing communication channels when a publicly accessible rendezvous service is available.
这个实验性的NAT行为发现STUN使用提供了有关NAT设备可观察到的瞬态行为的信息；它决定了NAT在测试运行时使用的STUN服务器和特定客户端端口的行为。这种眩晕用法不允许NAT背后的应用程序绝对确定NAT的特性。NAT设备的行为不一致，无法在任何保证的情况下预测未来的行为。需要在两个特定端点之间可靠到达的应用程序必须使用另一种技术通过NAT建立通信信道。IETF提出了包括[RFC5245]和[RFC5626]在内的标准，用于在可公开访问的会合服务可用时建立通信信道。
The uses envisioned for the STUN attributes included in this document are diagnostics and real-time tuning of applications. For example, determining what may work and should be tried first compared to more expensive methods. The attributes can also be used to observe behaviors that causes an application's communication to fail, thus enabling better selection of methods of recovery. The STUN attributes could also be a basis for a network technician's diagnostics tool to observe NAT behavior.
本文档中包含的STUN属性的预期用途是诊断和实时调整应用程序。例如，与更昂贵的方法相比，确定哪些方法可能有效并且应该首先尝试。这些属性还可用于观察导致应用程序通信失败的行为，从而更好地选择恢复方法。STUN属性也可以作为网络技术人员诊断工具观察NAT行为的基础。
This document proposes experimental usage of these attributes for real-time optimization of parameters for protocols in situations where a publicly accessible rendezvous service is not available. Such a use of these techniques is only possible when the results are applied as an optimization and a reliable fallback is available in case the NAT's behavior becomes more restrictive than determined by the Behavior Discovery tests. One possible application is role selection in peer-to-peer (P2P) networks based on statistical experience with establishing direct connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. Consider a node that tries to join an overlay as a full peer when its NAT prevents sufficient connectivity; joining and withdrawing from the overlay might be expensive and/or lead to unreliable or poorly performing operations. Even if the behavior discovery check is only "correct" 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure.
本文档建议在公共可访问的集合服务不可用的情况下，实验性地使用这些属性来实时优化协议的参数。只有将结果作为优化应用，并且在NAT的行为变得比行为发现测试所确定的更严格的情况下，可靠的回退才可能使用这些技术。一个可能的应用是基于统计经验的对等（P2P）网络中的角色选择，这些经验包括建立直接连接和诊断与各种对等的NAT行为。实验性的问题是这样的测试是否有用。考虑一个节点，当它的NAT阻止足够的连接性时，尝试加入覆盖作为一个完整的对等体；加入和退出覆盖可能成本高昂和/或导致操作不可靠或性能不佳。即使行为发现检查只有75%的时间是“正确”的，但其相对廉价性可能会使其对优化覆盖网络的行为非常有用。第2.2节更详细地描述了该实验应用，并讨论了如何评估其成功或失败。
The applications of this STUN usage differ from the original use of STUN (originally RFC 3489 [RFC3489], now RFC 5389 [RFC5389]). This specification acknowledges that the information gathered in this
此STUN用途的应用不同于STUN的原始用途（最初为RFC 3489[RFC3489]，现在为RFC 5389[RFC5389]）。本规范确认本规范中收集的信息
usage is not, and cannot be, correct 100% of the time, whereas STUN focused only on getting information that could be known to be correct and static.
使用率不是，也不可能是100%正确的，而STUN只关注于获取可以被认为是正确和静态的信息。
This specification can also be compared to ICE. ICE requires a fallback to TURN be available whereas RFC 3489 based applications tried to determine in advance whether they would need a relay and what their peer reflexive address will be, which is not generally achievable.
该规范也可与ICE进行比较。ICE需要一个后备回合，以供使用，而基于RFC 3489的应用程序试图提前确定是否需要中继以及它们的对等自反地址是什么，这通常是无法实现的。
This STUN usage requires an application using it to have a fallback. However, unlike ICE's focus on the problems inherent in VoIP sessions, this STUN usage doesn't assume that it will be used to establish a connection between a single pair of machines, so alternative fallback mechanisms may be available.
这种晕眩的使用需要使用它的应用程序进行回退。然而，与ICE关注VoIP会话中固有的问题不同，这种STUN用法并不假设它将用于在一对机器之间建立连接，因此可以使用其他备用机制。
For example, in a P2P application it may be possible to simply switch out of the role where such connections need to be established or to select an alternative indirect route if the peer discovers that, in practice, 10% of its connection attempts fail.
例如，在P2P应用程序中，如果对等方发现实际上有10%的连接尝试失败，则可以简单地切换出需要建立此类连接的角色，或者选择替代的间接路由。
It is submitted to the Internet community as an experimental protocol that, when applied with appropriate statistical underpinnings and application behavior that is ultimately based on experienced connectivity patterns, can lead to more stability and increased performance than is available without the knowledge it provides.
它作为一个实验协议提交给互联网社区，当应用适当的统计基础和应用程序行为（最终基于经验丰富的连接模式）时，它可以带来比没有它提供的知识时更高的稳定性和更高的性能。
If a Standards Track document specifies the use of any portion of this STUN usage, that document MUST describe how incorrect information derived using these methods will be managed, either through identifying when a NAT's behavior changed or because the protocol uses such knowledge as an optimization but remains functional when the NAT's behavior changes. The referencing document MUST also define when the fallback mechanism will be invoked. Applications in different domains may vary greatly in how aggressively the fallback mechanism is utilized, so there must be a clear definition of when the fallback mechanism is invoked.
如果标准跟踪文件指定使用此STUN使用的任何部分，则该文件必须说明如何管理使用这些方法生成的错误信息，或者通过识别NAT的行为何时改变，或者因为协议使用这些知识作为优化，但在NAT的行为改变时仍保持功能。引用文档还必须定义何时调用回退机制。不同领域中的应用程序在使用回退机制的积极程度上可能会有很大差异，因此必须明确定义何时调用回退机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
"Session Traversal Utilities for NAT (STUN)" [RFC5389] provides a mechanism to discover the reflexive transport address toward the STUN server, using the Binding Request. This specification defines the NAT Behavior Discovery STUN usage, which allows a STUN client to probe the current behavior of the NAT/firewall (NAT/FW) devices between the client and the STUN server. This usage defines new STUN attributes for the Binding Request and Binding Response.
“NAT会话遍历实用程序（STUN）”[RFC5389]提供了一种机制，使用绑定请求来发现指向STUN服务器的自反传输地址。此规范定义了NAT行为发现STUN用法，它允许STUN客户端探测客户端和STUN服务器之间NAT/防火墙（NAT/FW）设备的当前行为。此用法为绑定请求和绑定响应定义了新的STUN属性。
Many NAT/FW devices do not behave consistently and will change their behavior under load and over time. Applications requiring high reliability must be prepared for the NAT's behavior to become more restrictive. Specifically, it has been found that under load NATs may transition to the most restrictive filtering and mapping behavior and shorten the lifetime of new and existing bindings. In short, applications can discover how bad things currently are, but not how bad things will get.
许多NAT/FW设备的行为并不一致，在负载和时间的推移会改变它们的行为。需要高可靠性的应用程序必须为NAT的行为变得更加严格做好准备。具体地说，已经发现负载不足的NAT可能会转变为最严格的过滤和映射行为，并缩短新绑定和现有绑定的生命周期。简言之，应用程序可以发现当前的情况有多糟糕，但不能发现情况会变得有多糟糕。
Despite this limitation, instantaneous observations are often quite useful in troubleshooting network problems, and repeated tests over time, or in known load situations, may be used to characterize a NAT's behavior. In particular, in the hands of a person knowledgeable about the needs of an application and the nodes an application needs to communicate with, it can be a powerful tool.
尽管存在这一限制，但瞬时观测通常在网络故障排除中非常有用，并且随着时间的推移或在已知负载情况下的重复测试可用于描述NAT的行为。特别是，在了解应用程序需求和应用程序需要与之通信的节点的人员手中，它可能是一个强大的工具。
Applications that work well in the lab, but fail in a deployment, are notoriously common within distributed systems. There are few systems developers who have not had the experience of searching to determine the difference in the environments for insight as to what real-network behavior was missed in the testing lab. The Behavior Discovery usage offers a powerful tool that can be used to check NAT and firewall behavior as the application is running. For example, an application could be designed to perform Behavior Discovery tests whenever it experiences significant communications problems when running. Such analysis might be included as part of the diagnostic information logged by the application.
在实验室工作良好但部署失败的应用程序在分布式系统中非常常见。很少有系统开发人员没有搜索以确定环境差异的经验，以了解测试实验室中遗漏了哪些真实网络行为。行为发现使用提供了一个强大的工具，可用于在应用程序运行时检查NAT和防火墙行为。例如，应用程序可以设计为在运行时遇到重大通信问题时执行行为发现测试。此类分析可能作为应用程序记录的诊断信息的一部分。
As they are being used to detect instantaneous behavior for analysis by an experienced developer or administrator, there are relatively few concerns about this application of the NAT Behavior Discovery STUN usage. However, the user should be aware that
由于它们被经验丰富的开发人员或管理员用来检测瞬时行为进行分析，所以对于NAT行为发现STUN的这种应用程序的使用相对较少关注。但是，用户应该知道
o adding new traffic to new destinations (STUN servers) has the potential to itself change the behavior of a NAT and
o 向新的目的地（STUN服务器）添加新流量本身就有可能改变NAT的行为和性能
o the user must be careful to select a STUN server that is appropriately located, ideally collocated (or even integrated) with the communication partners of the application in question, for the results to be applicable to the network conditions experienced by the application.
o 用户必须小心选择适当位置的STUN服务器，理想情况下与相关应用程序的通信伙伴并置（甚至集成），以使结果适用于应用程序所经历的网络条件。
An application could use Behavior Discovery in a P2P protocol to determine if a particular endpoint is a reasonable candidate to participate as a peer or supernode (defined here as a peer in the overlay that offers services, including message routing, to other members or clients of the overlay network). This P2P network application is willing to select supernodes that might be located behind NATs to avoid the cost of dedicated servers. A supernode candidate requires that its NAT or NATs offer Endpoint-Independent Filtering. It might periodically re-run tests and would remove itself as a supernode if its NAT/FW chain lost this characteristic. These tests could be run with other supernodes acting as STUN servers as well as with dedicated STUN servers. As many P2P algorithms tolerate non-transitive connectivity between a portion of their peers, guaranteed pair-wise reliable reach might be sacrificed in order to distribute the P2P overlay's load across peers that can be directly contacted by the majority of users.
应用程序可以使用P2P协议中的行为发现来确定特定端点是否是作为对等节点或超级节点（此处定义为覆盖中向覆盖网络的其他成员或客户端提供服务（包括消息路由）的对等节点）参与的合理候选方。这个P2P网络应用程序愿意选择可能位于NAT后面的超级节点，以避免专用服务器的成本。超级节点候选节点要求其NAT或NAT提供与端点无关的过滤。它可能会定期重新运行测试，如果其NAT/FW链失去此特性，则会将自身作为超级节点删除。这些测试可以使用其他超级节点作为STUN服务器以及专用STUN服务器运行。由于许多P2P算法容忍其部分对等点之间的非传递连接，因此可能会牺牲有保证的成对可靠到达，以便将P2P覆盖的负载分布在大多数用户可以直接接触的对等点之间。
Consider an example from a hypothetical P2P protocol in more detail: when P2P node A starts up, it tests its NAT(s) relative to other peers already in the overlay. If the results of its testing indicate A is behind a "good" NAT (with Endpoint-Independent Mapping and Filtering), A will join the overlay and establish connections with appropriate peers in the overlay to join the overlay's topology. Although A is reachable by routing messages across the overlay topology, A will also include in its communication with other nodes that they may reach it directly using its reflexive IP address (or addresses) that A discovered in its initial testing. Suppose that later, node B wants to send a message to A, and B is not a neighbor of A in the overlay topology. B may send the message directly to A's IP address and start a timer. If B doesn't receive a response within a certain amount of time, then it routes the message to A across the overlay instead and includes a flag that indicates a direct connection was attempted but failed. (Alternatively, B could simultaneously send the message to A's IP address across the overlay, which guarantees minimum response latency, but can waste bandwidth.) Over time, A observes the percentage of successful direct messages it receives out of those attempted. If the percentage of successful direct connections is below some threshold (perhaps 75%), then A may stop advertising for direct connections because it has determined in practice that its NATs are not providing sufficiently reliable
从一个假设的P2P协议中更详细地考虑一个例子：当P2P节点A启动时，它测试它的NAT（s）相对于已经在覆盖中的其他对等体。如果测试结果表明A在“良好”NAT之后（具有端点独立映射和过滤），A将加入覆盖，并与覆盖中的适当对等方建立连接，以加入覆盖的拓扑。虽然A可以通过在覆盖拓扑上路由消息来访问，但A也将在与其他节点的通信中包括，这些节点可以使用A在初始测试中发现的自反IP地址（一个或多个地址）直接访问A。假设稍后，节点B想要向a发送消息，而B不是覆盖拓扑中a的邻居。B可以将消息直接发送到A的IP地址并启动计时器。如果B在一定时间内没有收到响应，则它会将消息通过覆盖路由到a，并包含一个标志，指示尝试了直接连接但失败。（或者，B可以通过覆盖层同时将消息发送到A的IP地址，这保证了最小的响应延迟，但可能会浪费带宽。）随着时间的推移，A会观察其从尝试发送的直接消息中接收到的成功消息的百分比。如果成功的直接连接的百分比低于某个阈值（可能为75%），则A可能会停止直接连接的广告，因为它在实践中已确定其nat没有提供足够的可靠性
connectivity to justify the cost of attempting the direct message. But if the percentage is high enough, A continues to advertise because the successful direct connections are improving the overlay's performance by reducing the routing load imposed on the overlay. If at some point, A's NAT or NATs change behavior, A will notice a change in its percentage of successful direct connections and may re-evaluate its decision to advertise a public address. In this hypothetical example, behavior discovery is used for A's initial operating mode selection, but the actual decision for whether to continue advertising that public IP/port pair is made based on actual operating data. The results of the Behavior Discovery usage are also used as a performance optimization, as A is at all times able to establish connectivity through the overlay if the attempted direct connection fails.
连接以证明尝试直接消息的成本。但是，如果百分比足够高，A将继续播发，因为成功的直接连接通过减少施加在覆盖上的路由负载来提高覆盖的性能。如果在某个时刻，A的NAT或NAT改变了行为，A将注意到其成功直接连接的百分比发生了变化，并可能重新评估其发布公共广播的决定。在此假设示例中，行为发现用于A的初始操作模式选择，但是否继续公布该公共IP/端口对的实际决策是基于实际操作数据做出的。行为发现使用的结果也被用作性能优化，因为如果尝试的直接连接失败，a始终能够通过覆盖建立连接。
Use of behavior discovery for such an application requires:
为此类应用程序使用行为发现需要：
o Use of a protocol capable of offering reliable end-user performance while using unreliable links between pairs of nodes.
o 使用能够提供可靠最终用户性能的协议，同时在成对节点之间使用不可靠的链路。
o A protocol offering a reliable fallback to connections attempted based on the results of Behavior Discovery probing.
o 一种协议，为基于行为发现探测结果尝试的连接提供可靠的回退。
o The application is deployed behind NATs that provide Endpoint-Independent Filtering and that remain in this mode for an amount of time sufficient for the application to identify their behavior, distribute this information to the rest of the overlay, and provide useful work for the application.
o 应用程序部署在NAT后面，NAT提供独立于端点的过滤，并在此模式下保持足够长的时间，以便应用程序识别其行为，将此信息分发到覆盖的其余部分，并为应用程序提供有用的工作。
This document is experimental as applications implementing open protocols have yet to be deployed in such environments to demonstrate that these three requirements have been met. However, anecdotal evidence suggests that NATs targeted at households and small businesses have stable behavior, especially when there are few clients behind them. Numerous P2P applications have been deployed that appear to have these properties, although their protocols have not yet been subjected to rigorous evaluation by standards bodies.
本文档是实验性的，因为实现开放协议的应用程序尚未部署在此类环境中，以证明已满足这三个要求。然而，轶事证据表明，针对家庭和小企业的NAT具有稳定的行为，特别是当背后几乎没有客户时。尽管其协议尚未经过标准机构的严格评估，但已经部署了许多似乎具有这些特性的P2P应用程序。
The criteria for an application to successfully demonstrate use of the NAT Behavior Discovery STUN usage would include:
应用程序成功演示NAT行为发现STUN使用的标准包括：
o An implementation that relies on this usage to determine its run-time behavior, most likely using it to determine an initial choice of options that are then adjusted based on experience with its network connections.
o 一种依赖此用法来确定其运行时行为的实现，最有可能使用它来确定选项的初始选择，然后根据其网络连接的经验进行调整。
o The implementation must either demonstrate its applicability in environments where it is realistic to expect a provider to deploy dedicated STUN servers with multiple IP addresses, or it must demonstrate duplicating the behavior of such a dedicated STUN server with two nodes that share the role of providing the address-changing operations required by this usage.
o 实施必须证明其适用于期望提供商部署具有多个IP地址的专用STUN服务器的环境，或者，它必须演示使用两个节点复制这种专用STUN服务器的行为，这两个节点共享提供此使用所需的地址更改操作的角色。
o Experimental evidence that the application of this usage results in improved behavior of the application in real-world conditions. The exact metrics for this improvement may vary, some possibilities include: faster convergence to the proper parameters, less work to set up initial connections, fewer reconfigurations required after startup, etc.
o 实验证据表明，应用此用法可以改善应用程序在真实环境中的行为。这种改进的确切指标可能会有所不同，一些可能性包括：更快地收敛到正确的参数，更少的建立初始连接的工作，启动后需要更少的重新配置，等等。
o A protocol specification that defines how the implementation applies this usage.
o 定义实现如何应用此用法的协议规范。
The P2P scenario described above is a likely experimental test case for this usage, but others applications are possible as well.
上面描述的P2P场景很可能是这种用法的实验测试用例，但其他应用程序也可以。
In a typical configuration, a STUN client is connected to a private network and through one or more NATs to the public Internet. The client is configured with the address of a STUN server on the public Internet. The Behavior Discovery usage makes use of SRV records so that a server may use a different transport address for this usage than for other usages. This usage does not provide backward compatibility with RFC 3489 [RFC3489] for either clients or servers. Implementors of clients that wish to be compliant with RFC 3489 servers should see that specification. Implementors of servers SHOULD NOT include support for RFC 3489 clients, as the original uses of that protocol have been deprecated.
在典型配置中，STUN客户端连接到专用网络，并通过一个或多个NAT连接到公共互联网。客户机配置有公共Internet上的STUN服务器地址。行为发现使用使用使用SRV记录，因此服务器可以为此使用与其他使用不同的传输地址。此用法不为客户端或服务器提供与RFC 3489[RFC3489]的向后兼容性。希望与RFC 3489服务器兼容的客户机的实现者应该看到该规范。服务器的实现者不应包括对RFC 3489客户端的支持，因为该协议的最初用途已被弃用。
Because STUN forbids a server from creating a new TCP or TCP/TLS connection to the client, many tests apply only to UDP. The applicability of the various tests is indicated below.
由于STUN禁止服务器创建到客户端的新TCP或TCP/TLS连接，因此许多测试仅适用于UDP。各种试验的适用性如下所示。
The STUN NAT Behavior Discovery usage defines new attributes on the STUN Binding Request and STUN Binding Response that allow these messages to be used to diagnose the current behavior of the NAT(s) between the client and server.
STUN NAT行为发现用法在STUN绑定请求和STUN绑定响应上定义了新属性，允许使用这些消息诊断客户端和服务器之间NAT的当前行为。
This section provides a descriptive overview of the typical use of these attributes. Normative behavior is described in Sections 5, 6, and 7.
本节对这些属性的典型用法进行了描述性概述。第5、6和7节描述了规范行为。
A client behind a NAT wishes to determine if that NAT is currently using Endpoint-Independent, Address-Dependent, or Address and Port-Dependent Mapping [RFC4787]. The client performs a series of tests that make use of the OTHER-ADDRESS attribute; these tests are described in detail in Section 4. These tests send binding requests to the alternate address and port of the STUN server to determine mapping behavior. These tests can be used for UDP, TCP, or TCP/TLS connections.
NAT背后的客户端希望确定NAT当前是否使用端点无关、地址相关或地址和端口相关映射[RFC4787]。客户机使用OTHER-ADDRESS属性执行一系列测试；第4节详细描述了这些试验。这些测试将绑定请求发送到STUN服务器的备用地址和端口，以确定映射行为。这些测试可用于UDP、TCP或TCP/TLS连接。
A client behind a NAT wishes to determine if that NAT is currently using Endpoint-Independent, Address-Dependent, or Address and Port-Dependent Filtering [RFC4787]. The client performs a series of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST attributes; these tests are described in Section 4. These tests request responses from the alternate address and port of the STUN server; a precondition to these tests is that no binding be established to the alternate address and port. See below for more information. Because the NAT does not know that the alternate address and port belong to the same server as the primary address and port, it treats these responses the same as it would those from any other host on the Internet. Therefore, the success of the binding responses sent from the alternate address and port indicate whether the NAT is currently performing Endpoint-Independent Filtering, Address-Dependent Filtering, or Address and Port-Dependent Filtering. This test applies only to UDP datagrams.
NAT背后的客户端希望确定NAT当前是否使用端点无关、地址相关或地址和端口相关过滤[RFC4787]。客户机使用其他地址和变更请求属性执行一系列测试；第4节中描述了这些试验。这些测试从STUN服务器的备用地址和端口请求响应；这些测试的一个先决条件是不建立对备用地址和端口的绑定。有关更多信息，请参见下文。因为NAT不知道备用地址和端口与主地址和端口属于同一台服务器，所以它会像对待来自Internet上任何其他主机的响应一样对待这些响应。因此，从备用地址和端口发送的绑定响应的成功表明NAT当前是否正在执行端点无关过滤、地址相关过滤或地址和端口相关过滤。此测试仅适用于UDP数据报。
Many systems, such as VoIP, rely on being able to keep a connection open between a client and server or between peers of a P2P system. Because NAT bindings expire over time, keepalive messages must be sent across the connection to preserve it. Because keepalives impose some overhead on the network and servers, reducing the frequency of keepalives can be useful.
许多系统，如VoIP，依赖于能够保持客户端和服务器之间或P2P系统对等方之间的连接打开。由于NAT绑定会随着时间的推移而过期，因此必须通过连接发送keepalive消息以保留它。由于keepalive会在网络和服务器上增加一些开销，因此降低keepalive的频率可能是有用的。
A normal request-response protocol cannot be used to test binding lifetime because the initial request resets the binding timer. Behavior discovery defines the RESPONSE-PORT attribute to allow the client and server to set up a "control channel" using one port on the client that is used to test the binding lifetime of a different port allocated on the client. More generally, RESPONSE-PORT allows the client to allocate two ports and request that responses to queries sent from one port be delivered to the other. The client uses its second port and the STUN server's alternate address to check if an
正常的请求-响应协议不能用于测试绑定生存期，因为初始请求会重置绑定计时器。行为发现定义RESPONSE-PORT属性，以允许客户端和服务器使用客户端上的一个端口设置“控制通道”，该端口用于测试客户端上分配的不同端口的绑定生存期。更一般地说，RESPONSE-PORT允许客户端分配两个端口，并请求将对从一个端口发送的查询的响应传递到另一个端口。客户端使用其第二个端口和STUN服务器的备用地址来检查
existing binding that hasn't had traffic sent on it is still open after time T. This approach is described in detail in Section 4.6. This test applies only to UDP datagrams.
尚未发送流量的现有绑定在时间t后仍然打开。第4.6节详细描述了这种方法。此测试仅适用于UDP数据报。
STUN Binding Requests allow a client to determine whether it is behind a NAT that supports hairpinning of connections. To perform this test, the client first sends a Binding Request to its STUN server to determine its mapped address. The client then sends a STUN Binding Request to this mapped address from a different port. If the client receives its own request, the NAT hairpins connections. This test applies to UDP, TCP, or TCP/TLS connections.
STUN绑定请求允许客户端确定它是否位于支持连接发夹的NAT后面。要执行此测试，客户端首先向其STUN服务器发送绑定请求以确定其映射地址。然后，客户端从另一个端口向该映射地址发送STUN绑定请求。如果客户机接收到自己的请求，则NAT发夹连接。此测试适用于UDP、TCP或TCP/TLS连接。
Some NATs exhibit different behavior when forwarding fragments than when forwarding a single-frame datagram. In particular, some NATs do not hairpin fragments at all and some platforms discard fragments under load. To diagnose this behavior, STUN messages may be sent with the PADDING attribute, which simply inserts additional space into the message. By forcing the STUN message to be divided into multiple fragments, the NAT's behavior can be observed.
某些NAT在转发片段时表现出与转发单帧数据报时不同的行为。特别是，一些NAT根本没有发夹式碎片，而一些平台在加载时丢弃碎片。要诊断此行为，可以使用PADDING属性发送STUN消息，该属性只是在消息中插入额外的空间。通过强制将STUN消息分成多个片段，可以观察NAT的行为。
All of the previous tests can be performed with PADDING if a NAT's fragment behavior is important for an application, or only those tests that are most interesting to the application can be retested. PADDING only applies to UDP datagrams. PADDING can not be used with RESPONSE-PORT.
如果NAT的片段行为对应用程序很重要，或者只有应用程序最感兴趣的测试可以重新测试，则可以使用填充来执行前面的所有测试。填充仅适用于UDP数据报。填充不能与响应端口一起使用。
A number of NAT boxes are now being deployed into the market that try to provide "generic" ALG functionality. These generic ALGs hunt for IP addresses, either in text or binary form within a packet, and rewrite them if they match a binding. This behavior can be detected because the STUN server returns both the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in the same response. If the result in the two does not match, there is a NAT with a generic ALG in the path. This test apples to UDP and TCP, but not TLS over TCP connections.
许多NAT盒现在正部署到市场上，试图提供“通用”ALG功能。这些通用ALG在数据包中搜索文本或二进制形式的IP地址，如果它们与绑定匹配，则重写它们。由于STUN服务器在同一响应中返回MAPPED-ADDRESS和XOR-MAPPED-ADDRESS，因此可以检测到此行为。如果两者中的结果不匹配，则路径中存在具有通用ALG的NAT。此测试适用于UDP和TCP，但不适用于TCP连接上的TLS。
This section provides a descriptive overview of how the NAT Behavior Discovery usage primitives allow checks to be made to discover the current behavior of the NAT or NATs an application is behind. These tests can only give the instantaneous behavior of a NAT; it has been found that NATs can change behavior under load and over time. The
本节提供了NAT行为发现使用原语如何允许进行检查以发现应用程序背后的NAT或NAT的当前行为的描述性概述。这些测试只能给出NAT的瞬时行为；已经发现，NAT可以在负载和时间上改变行为。这个
results of these tests therefore can be regarded as upper bounds -- an application must assume that NAT behavior can become more restrictive at any time. Results from tests performed using a particular port on the client may also not indicate the behavior experienced by a different port, as described in Section 4.1.
因此，这些测试的结果可以被视为上限——应用程序必须假设NAT行为在任何时候都会变得更加严格。如第4.1节所述，在客户端上使用特定端口执行的测试结果也可能不会表明不同端口所经历的行为。
Definitions for NAT filtering and mapping behavior are from [RFC4787]. The tests described here are for UDP connectivity, NAT mapping behavior, NAT filtering behavior, and NAT binding lifetime discovery; additional tests could be designed using this usage's mechanisms. The tests described below include only tests that can be performed using a client with a single IP address. A client with multiple IP addresses (or multiple clients collaborating) behind the same NAT can combine their probes to test additional aspects of NAT behavior, such as port overloading. This section provides a descriptive overview of how the primitives provided by the STUN attributes in this specification may be used to perform behavior tests.
NAT过滤和映射行为的定义来自[RFC4787]。这里描述的测试用于UDP连接、NAT映射行为、NAT过滤行为和NAT绑定生存期发现；可以使用此用法的机制设计其他测试。下面描述的测试仅包括可以使用具有单个IP地址的客户端执行的测试。在同一NAT后面具有多个IP地址（或多个客户端协作）的客户端可以组合其探测来测试NAT行为的其他方面，例如端口过载。本节提供了如何使用本规范中STUN属性提供的原语执行行为测试的描述性概述。
Normative specifications for the attributes are defined in later sections.
属性的规范性规范将在后面的章节中定义。
Proper source port selection is important to ensuring the usefulness and accuracy of the Behavior Discovery tests. There are two preconditions for tests:
正确的源端口选择对于确保行为发现测试的有用性和准确性非常重要。测试有两个先决条件：
o Because mapping behavior can vary on a port-by-port basis, an application should perform its tests using the source port intended for use by the application whenever possible. If it intends to use multiple source ports, it should repeat these tests for each source port. Such tests should be performed sequentially to reduce load on the NAT.
o 由于映射行为可能因端口而异，因此应用程序应尽可能使用应用程序预期使用的源端口执行测试。如果它打算使用多个源端口，它应该对每个源端口重复这些测试。此类测试应按顺序进行，以减少NAT上的负载。
o Because the results of some diagnostic checks depend on previous state in the NAT created by prior traffic, the tests should be performed using a source port that has not generated recent traffic. Therefore, the application should use a random source port or ensure that no traffic has previously occurred on the selected port prior to performing tests, generally by allocating a port and holding it unused for at least 15 minutes prior to the tests.
o 由于某些诊断检查的结果取决于先前流量创建的NAT中的先前状态，因此应使用未生成最近流量的源端口执行测试。因此，应用程序应使用随机源端口，或确保在执行测试之前所选端口上未发生任何流量，通常是在测试之前分配端口并保持其未使用至少15分钟。
Ensuring both of these preconditions can be challenging, particularly for a device or application wishing to perform Behavior Discovery tests at startup. The following guidelines are suggested for reducing the likelihood of problems:
确保这两个前提条件都具有挑战性，特别是对于希望在启动时执行行为发现测试的设备或应用程序而言。建议采用以下准则来降低出现问题的可能性：
o An application intended to operate behind a NAT should not attempt to allocate a specific or well-known port. Because such software must be designed to interoperate using whatever port is mapped to it by the NAT, the specific port is unnecessary. Instead, on startup, a random port should be selected (see below for recommended ranges). An application, particularly on an embedded device, should not rely on the host operating system to select the next available port because that might result in the application receiving the same port on each restart. An application using the same port between restarts may not receive accurate results from Behavior Discovery tests that are intended to test state-related behavior of NATs, such as filtering and binding lifetime.
o 打算在NAT后面运行的应用程序不应尝试分配特定或已知的端口。由于此类软件必须设计为使用NAT映射到它的任何端口进行互操作，因此不需要特定端口。相反，在启动时，应选择一个随机端口（请参阅下面的推荐范围）。应用程序（尤其是嵌入式设备上的应用程序）不应依赖主机操作系统来选择下一个可用端口，因为这可能导致应用程序在每次重新启动时接收相同的端口。在重启之间使用相同端口的应用程序可能无法从旨在测试NAT状态相关行为（如筛选和绑定生存期）的行为发现测试中收到准确的结果。
o An application requiring multiple ports, such as separate ports for control and media, should allocate those ports on startup when possible. Even if there is no immediate need for media flow, if Behavior Discovery tests will be run on those ports, allocating them early will allow them to be left idle, increasing the chance of obtaining accurate results from Behavior Discovery tests.
o 需要多个端口的应用程序（例如用于控制和介质的单独端口）应尽可能在启动时分配这些端口。即使不需要立即使用媒体流，如果行为发现测试将在这些端口上运行，那么提前分配这些端口将使它们处于空闲状态，从而增加从行为发现测试中获得准确结果的机会。
o Although the most reliable results are obtained when performing tests with the specific ports that the application will use, in many cases an application will need to allocate and use ports without being able to perform complete Behavior Discovery tests on those ports. In those cases, an application should randomly select its ports from a range likely to receive the same treatment by the NAT. This document recommends ranges of 32768-49151, which is the upper end of IANA's Registered Ports range, and 49152- 65535, which is IANA's Dynamic and/or Private port range, for random selection. To attempt to characterize a NAT's general treatment of ports in these ranges, a small number of ports within a range can be randomly selected and characterized.
o 虽然在使用应用程序将使用的特定端口执行测试时可以获得最可靠的结果，但在许多情况下，应用程序需要分配和使用端口，而无法在这些端口上执行完整的行为发现测试。在这些情况下，应用程序应该从可能接受NAT相同处理的范围内随机选择其端口。本文档建议随机选择的范围为32768-49151（IANA注册端口范围的上限）和49152-65535（IANA动态和/或专用端口范围）。为了尝试描述NAT对这些范围内端口的一般处理，可以随机选择和描述范围内的少量端口。
Those tests particularly sensitive to prior state on a NAT will be indicated below.
下面将说明对NAT上先前状态特别敏感的测试。
The client sends a STUN Binding Request to a server. This causes the server to send the response back to the address and port that the request came from. If this test yields no response, the client knows right away that it does not have UDP connectivity with the STUN server. This test requires only STUN [RFC5389] functionality.
客户端向服务器发送STUN绑定请求。这会导致服务器将响应发送回请求来自的地址和端口。如果此测试未产生响应，则客户端立即知道它与STUN服务器没有UDP连接。此测试只需要STUN[RFC5389]功能。
This will require at most three tests. In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run. The client examines the XOR-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 NATed and the effective mapping will be Endpoint-Independent.
这最多需要三次测试。在测试I中，客户端执行UDP连接测试。服务器将在绑定响应中以其他地址返回其备用地址和端口。如果未返回OTHER-ADDRESS，则服务器不支持此用法，并且无法运行此测试。客户端检查XOR-MAPPED-ADDRESS属性。如果此地址和端口与用于发送请求的套接字的本地IP地址和端口相同，则客户机知道该地址和端口不存在，并且有效映射将与端点无关。
In test II, the client sends a Binding Request to the alternate address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding Response is the same as test I the NAT currently has Endpoint-Independent Mapping. If not, test III is performed: the client sends a Binding Request to the alternate address and port. If the XOR-MAPPED-ADDRESS matches test II, the NAT currently has Address-Dependent Mapping; if it doesn't match it currently has Address and Port-Dependent Mapping.
在测试II中，客户机向备用地址（但不是主端口）发送绑定请求。如果绑定响应中的XOR映射地址与测试I相同，则NAT当前具有端点无关映射。如果没有，则执行测试III：客户端向备用地址和端口发送绑定请求。如果XOR映射地址与测试II匹配，则NAT当前具有地址依赖映射；如果不匹配，则当前具有地址和端口相关映射。
This will also require at most three tests. These tests are sensitive to prior state on the NAT.
这也最多需要三次测试。这些测试对NAT上的先前状态敏感。
In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run.
在测试I中，客户端执行UDP连接测试。服务器将在绑定响应中以其他地址返回其备用地址和端口。如果未返回OTHER-ADDRESS，则服务器不支持此用法，并且无法运行此测试。
In test II, the client sends a binding request to the primary address of the server with the CHANGE-REQUEST attribute set to change-port and change-IP. This will cause the server to send its response from its alternate IP address and alternate port. If the client receives a response, the current behavior of the NAT is Endpoint-Independent Filtering.
在测试II中，客户机向服务器的主地址发送绑定请求，并将CHANGE-request属性设置为CHANGE-port和CHANGE-IP。这将导致服务器从其备用IP地址和备用端口发送响应。如果客户端收到响应，则NAT的当前行为与端点无关。
If no response is received, test III must be performed to distinguish between Address-Dependent Filtering and Address and Port-Dependent Filtering. In test III, the client sends a binding request to the original server address with CHANGE-REQUEST set to change-port. If the client receives a response, the current behavior is Address-Dependent Filtering; if no response is received, the current behavior is Address and Port-Dependent Filtering.
如果未收到响应，则必须执行测试III以区分地址相关过滤和地址及端口相关过滤。在测试III中，客户机向原始服务器地址发送绑定请求，并将CHANGE-request设置为CHANGE-port。如果客户端收到响应，则当前行为是地址相关过滤；如果未收到响应，则当前行为是地址和端口相关过滤。
Clients may wish to combine and parallelize these tests to reduce the number of packets sent and speed the discovery process. For example, test I of the filtering and mapping tests also checks if UDP is blocked. Furthermore, an application or user may not need as much detail as these sample tests provide. For example, establishing connectivity between nodes becomes significantly more difficult if a NAT has any behavior other than Endpoint-Independent Mapping, which requires only test I and II of Section 4.3. An application that determines its NAT does not always provide Endpoint-Independent Mapping might notify the user if no relay is configured, whereas an application behind a NAT that provides Endpoint-Independent Mapping might not notify the user until a subsequent connection actually fails or might provide a less urgent notification that no relay is configured. Such a test does not alleviate the need for [RFC5245], but it does provide some information regarding whether ICE is likely to be successful establishing non-relayed connections.
客户端可能希望合并并并行这些测试，以减少发送的数据包数量并加快发现过程。例如，过滤和映射测试的测试I还检查UDP是否被阻止。此外，应用程序或用户可能不需要这些示例测试提供的那么多细节。例如，如果NAT具有端点无关映射以外的任何行为，则在节点之间建立连接将变得非常困难，这只需要第4.3节的测试I和II。确定其NAT不总是提供端点独立映射的应用程序可能会在未配置中继时通知用户，然而，NAT后面提供端点独立映射的应用程序可能在后续连接实际失败之前不会通知用户，或者可能会提供未配置中继的不太紧急的通知。这种测试并不能缓解[RFC5245]的需求，但它确实提供了一些关于ICE是否可能成功建立非中继连接的信息。
Care must be taken when combining and parallelizing tests, due to the sensitivity of certain tests to prior state on the NAT and because some NAT devices have an upper limit on how quickly bindings will be allocated. Section 5 restricts the rate at which clients may begin new STUN transactions.
在组合和并行测试时必须小心，因为某些测试对NAT上的先前状态很敏感，而且一些NAT设备对绑定的分配速度有上限。第5节限制了客户开始新的STUN交易的速率。
STUN can also be used to probe the lifetimes of the bindings created by the NAT. Such tests are sensitive to prior state on the NAT. For many NAT devices, an absolute refresh interval cannot be determined; bindings might be closed more quickly under heavy load or might not behave as the tests suggest. For this reason, applications that require reliable bindings must send keepalives as frequently as required by all NAT devices that will be encountered. Suggested refresh intervals are outside the scope of this document. [RFC5245] and OUTBOUND [RFC5626] have suggested refresh intervals.
STUN还可以用来探测NAT创建的绑定的生命周期。此类测试对NAT上的先前状态敏感。对于许多NAT设备，无法确定绝对刷新间隔；绑定可能会在重载情况下更快地关闭，或者可能不会像测试所建议的那样工作。因此，需要可靠绑定的应用程序必须按照将遇到的所有NAT设备的要求频率发送keepalives。建议的刷新间隔超出了本文档的范围。[RFC5245]和出站[RFC5626]已建议刷新间隔。
Determining the binding lifetime relies on two separate source ports being used to send STUN Binding Requests to the STUN server. The general approach is that the client uses a source port X to send a single Binding Request. After a period of time during which source port X is not used, the client uses a second source port Y to send a Binding Request to the STUN server that indicates the response should be sent to the binding established to port X. If the binding for port X has timed out, that response will not be received. By varying the time between the original Binding Request sent from X and the subsequent request sent from Y, the client can determine the binding lifetime.
确定绑定生存期依赖于用于向STUN服务器发送STUN绑定请求的两个独立源端口。一般的方法是客户端使用源端口X发送单个绑定请求。在源端口X未使用的一段时间后，客户端使用第二个源端口Y向STUN服务器发送绑定请求，该请求指示应将响应发送到建立到端口X的绑定。如果端口X的绑定超时，则不会收到该响应。通过改变从X发送的原始绑定请求和从Y发送的后续请求之间的时间，客户机可以确定绑定生存期。
To determine the binding lifetime, the client first sends a Binding Request to the server from a particular source port, 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 source port, Y. This request contains an RESPONSE-PORT attribute, set to Pp, to request the response be delivered 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, (Pa, Pp), if it still exists. If the client receives the Binding Response on port X, it knows that the binding has not expired. If the client receives the Binding Response on port 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-port属性，设置为Pp，以请求将响应传递到（Pa，Pp）。这将在NAT上创建一个新绑定，并导致STUN服务器发送一个绑定响应，该响应将匹配旧绑定（Pa，Pp），如果它仍然存在的话。如果客户端在端口X上接收到绑定响应，则它知道绑定尚未过期。如果客户端在端口Y上接收到绑定响应（如果旧绑定过期，并且NAT为新绑定分配了相同的公共地址和端口，则这是可能的），或者根本没有收到响应，则它知道绑定已过期。
Because some NATs only refresh bindings when outbound traffic is sent, the client must resend a binding request from the original source port before beginning a second test with a different value of T. 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. Note also that the binding refresh behavior (outbound only or all traffic) can be determined by sending multiple Binding Requests from port Y without refreshes from the original source port X.
由于某些NAT仅在发送出站流量时刷新绑定，因此客户端必须从原始源端口重新发送绑定请求，然后才能开始第二次测试，测试值为T。客户端可以通过T进行二进制搜索来找到绑定生存期的值，最终到达一个值，在该值中，任何大于T的计时器都不会收到响应，但任何小于T的计时器都会收到响应。还请注意，绑定刷新行为（仅出站或所有流量）可以通过从端口Y发送多个绑定请求来确定，而不需要从原始源端口X进行刷新。
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 that is shorter than the actual one. Binding lifetime may also be dependent on the traffic load on the NAT. For this reason, implementations are encouraged to run the test numerous times and be prepared to get inconsistent results.
每次运行此进程时，客户端可能会得到不一致的结果。例如，如果NAT应该重新启动，或者由于某种原因被重置，那么进程可能会发现一个比实际生存期短的生存期。绑定寿命也可能取决于NAT上的流量负载。出于这个原因，我们鼓励实现多次运行测试，并准备得到不一致的结果。
Like the other diagnostics, this test is inherently unstable. In particular, an overloaded NAT might reduce binding lifetime to shed load. A client might find this diagnostic useful at startup, for example, setting the initial keepalive interval on its connection to the server to 10 seconds while beginning this check. After determining the current lifetime, the keepalive interval used by the
与其他诊断一样，该测试本质上是不稳定的。特别是，过载的NAT可能会缩短卸载的绑定寿命。客户机可能会在启动时发现此诊断很有用，例如，在开始此检查时，将其与服务器的连接的初始keepalive间隔设置为10秒。确定当前生存期后，将指定
connection to the server can be set to this appropriate value. Subsequent checks of the binding lifetime can then be performed using the keepalives in the server connection. The STUN Keepalive Usage [RFC5626] provides a response that confirms the connection is open and allows the client to check that its mapped address has not changed. As that provides both the keepalive action and diagnostic that it is working, it should be preferred over any attempt to characterize the connection by a secondary technique.
可以将与服务器的连接设置为此适当的值。然后可以使用服务器连接中的keepalives执行绑定生存期的后续检查。STUN Keepalive用法[RFC5626]提供一个响应，确认连接已打开，并允许客户端检查其映射地址是否未更改。由于它同时提供了keepalive操作和它正在工作的诊断，因此它应该优先于通过二次技术来描述连接的任何尝试。
Unless otherwise specified here, all procedures for preparing, sending, and processing messages as described in the STUN Binding Usage [RFC5389] are followed.
除非此处另有规定，否则遵循STUN绑定用法[RFC5389]中所述的准备、发送和处理消息的所有过程。
As support for RESPONSE-PORT is optional, a client MUST be prepared to receive a 420 (Unknown Attribute) error to requests that include RESPONSE-PORT. Support for OTHER-ADDRESS and CHANGE-REQUEST is optional, but MUST be supported by servers advertised via SRV, as described below. This is to allow the use of PADDING and RESPONSE-PORT in applications where servers do not have multiple IP addresses. Clients MUST be prepared to receive a 420 for requests that include CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding Response messages from the server.
由于对RESPONSE-PORT的支持是可选的，客户端必须准备好接收包含RESPONSE-PORT的请求的420（未知属性）错误。对OTHER-ADDRESS和CHANGE-REQUEST的支持是可选的，但必须由通过SRV发布的服务器支持，如下所述。这是为了允许在服务器没有多个IP地址的应用程序中使用填充和响应端口。当从服务器的绑定响应消息中未接收到其他地址时，客户端必须准备接收包含更改请求的请求的420。
If an application makes use of the NAT Behavior Discovery STUN usage by multiplexing it in a flow with application traffic, a FINGERPRINT attribute SHOULD be included unless it is always possible to distinguish a STUN message from an application message based on their header.
如果应用程序通过在具有应用程序流量的流中多路复用NAT行为发现STUN使用，则应包括指纹属性，除非始终可以根据STUN消息头将其与应用程序消息区分开来。
When PADDING is used, it SHOULD be equal to the MTU of the outgoing interface.
使用填充时，它应等于传出接口的MTU。
Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response unless they are using authentication with a provider of STUN servers that is aware of the topology requirements of the tests being performed.
客户机应忽略响应中的ALTERNATE-SERVER属性，除非他们正在使用STUN服务器提供商的身份验证，该提供商了解正在执行的测试的拓扑要求。
A client SHOULD NOT generate more than ten new STUN transactions per second and SHOULD pace them such that the retransmission timeouts (RTOs) do not synchronize the retransmissions of each transaction.
客户端每秒不应生成超过十个新的STUN事务，并应调整它们的速度，使重传超时（RTO）不会同步每个事务的重传。
Unless the user or application is aware of the transport address of a STUN server supporting the NAT Behavior Discovery usage through other means, a client is configured with the domain name of the provider of
除非用户或应用程序知道通过其他方式支持NAT行为发现使用的STUN服务器的传输地址，否则客户端将配置为NAT行为发现提供程序的域名
the STUN servers. The domain is resolved to a transport address using SRV procedures [RFC2782]. The mechanism for configuring the client with the domain name of the STUN servers or of acquiring a specific transport address is out of scope for this document.
眩晕服务器。使用SRV过程[RFC2782]将域解析为传输地址。使用STUN服务器的域名配置客户端或获取特定传输地址的机制不在本文档的范围内。
For the Behavior Discovery usage, the service name is "stun-behavior" for UDP and TCP. The service name is "stun-behaviors" for TLS over TCP. Only "tcp" is defined as a protocol for "stun-behaviors". Other aspects of handling failures and default ports are followed as described in STUN [RFC5389].
对于行为发现用法，UDP和TCP的服务名称为“stun Behavior”。TCP上TLS的服务名称为“stun behaviors”。只有“tcp”被定义为“眩晕行为”的协议。处理故障和默认端口的其他方面如STUN[RFC5389]所述。
Servers MAY require authentication before allowing a client to make use of its services. The method for obtaining these credentials, should the server require them, is outside the scope of this usage. Presumably, the administrator or application relying on this usage should have its own method for obtaining credentials. If the client receives a 401 (Unauthorized) Response to a Request, then it must either acquire the appropriate credential from the application before retrying or report a permanent failure. Procedures for encoding the MESSAGE-INTEGRITY attribute for a request are described in STUN [RFC5389].
在允许客户端使用其服务之前，服务器可能需要身份验证。如果服务器需要，获取这些凭据的方法不在此使用范围内。据推测，依赖此用法的管理员或应用程序应该有自己的获取凭据的方法。如果客户端收到对请求的401（未经授权）响应，则它必须在重试之前从应用程序获取适当的凭据，或者报告永久性故障。STUN[RFC5389]中描述了为请求编码消息完整性属性的过程。
Unless otherwise specified here, all procedures for preparing, sending, and processing messages as described for the STUN Binding Usage of STUN [RFC5389] are followed.
除非此处另有规定，否则应遵循针对STUN[RFC5389]的STUN绑定用法所述的准备、发送和处理消息的所有过程。
A server implementing the NAT Behavior Discovery usage SHOULD be configured with two separate IP addresses on the public Internet. On startup, the server SHOULD allocate a pair of ports for each of the UDP, TCP, and TCP/TLS transport protocols, such that it can send and receive datagrams using the same ports on each IP address (normally a wildcard binding accomplishes this). TCP and TCP/TLS MUST use different ports. If a server cannot allocate the same ports on two different IP address, then it MUST NOT include an OTHER-ADDRESS attribute in any Response and MUST respond with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST attribute. A server with only one IP address MUST NOT be advertised using the SRV service name "stun-behavior" or "stun-behaviors".
实现NAT行为发现使用的服务器应在公共Internet上配置两个单独的IP地址。在启动时，服务器应该为每个UDP、TCP和TCP/TLS传输协议分配一对端口，这样它就可以在每个IP地址上使用相同的端口发送和接收数据报（通常通过通配符绑定实现）。TCP和TCP/TLS必须使用不同的端口。如果服务器无法在两个不同的IP地址上分配相同的端口，那么它在任何响应中都不能包含OTHER-address属性，并且必须使用420（未知属性）响应任何具有CHANGE-Request属性的请求。只有一个IP地址的服务器不得使用SRV服务名称“stun behavior”或“stun behaviors”进行广告。
After performing all authentication and verification steps, the server begins processing specific to this Usage if the Binding Request contains any request attributes defined in this document:
执行所有身份验证和验证步骤后，如果绑定请求包含本文档中定义的任何请求属性，则服务器将开始处理特定于此用途的请求：
RESPONSE-PORT, CHANGE-REQUEST, or PADDING. If the Binding Request does not contain any attributes from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are still included in the Binding Response.
响应端口、更改请求或填充。如果绑定请求不包含此文档中的任何属性，则绑定响应中仍然包括OTHER-ADDRESS和RESPONSE-ORIGIN。
The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in its Response.
服务器必须在其响应中同时包含MAPPED-ADDRESS和XOR-MAPPED-ADDRESS。
If the Request contains the CHANGE-REQUEST attribute and the server does not have an alternate address and port as described above, the server MUST generate an error response of type 420.
如果请求包含CHANGE-Request属性，并且服务器没有如上所述的备用地址和端口，则服务器必须生成420类型的错误响应。
The source address and port of the Binding Response depend on the value of the CHANGE-REQUEST attribute and on the address and port on which the Binding Request was received; this is summarized in Table 1.
绑定响应的源地址和端口取决于CHANGE-REQUEST属性的值以及接收绑定请求的地址和端口；表1对此进行了总结。
Let A1 and A2 be the two IP addresses used by the server, and P1 and P2 be the ports used by the server. 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 the 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.
设A1和A2为服务器使用的两个IP地址，P1和P2为服务器使用的端口。让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 | OTHER-ADDRESS |
+--------------------+----------------+-------------+---------------+
| none | Da | Dp | Ca:Cp |
| Change IP | Ca | Dp | Ca:Cp |
| Change port | Da | Cp | Ca:Cp |
| Change IP and | Ca | Cp | Ca:Cp |
| Change port | | | |
+--------------------+----------------+-------------+---------------+
+--------------------+----------------+-------------+---------------+
| Flags | Source Address | Source Port | OTHER-ADDRESS |
+--------------------+----------------+-------------+---------------+
| none | Da | Dp | Ca:Cp |
| Change IP | Ca | Dp | Ca:Cp |
| Change port | Da | Cp | Ca:Cp |
| Change IP and | Ca | Cp | Ca:Cp |
| Change port | | | |
+--------------------+----------------+-------------+---------------+
Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS
表1：标志对数据包源和其他地址的影响
The server MUST add a RESPONSE-ORIGIN attribute to the Binding Response, containing the source address and port used to send the Binding Response.
服务器必须向绑定响应添加RESPONSE-ORIGIN属性，该属性包含用于发送绑定响应的源地址和端口。
If the server supports an alternate address and port, the server MUST add an OTHER-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.
如果服务器支持备用地址和端口，则服务器必须向绑定响应添加OTHER-address属性。这包含源IP地址和端口，如果客户端在绑定请求中设置了“change IP”和“change port”标志，则将使用这些地址和端口。如表1所示，无论变更请求标志的值如何，它们分别是Ca和Cp。
If the Request contained a PADDING attribute, PADDING MUST be included in the Binding Response. The server SHOULD use a length of PADDING equal to the MTU on the outgoing interface, rounded up to an even multiple of four bytes. If the Request also contains the RESPONSE-PORT attribute the server MUST return an error response of type 400.
如果请求包含PADDING属性，则绑定响应中必须包含PADDING。服务器应该使用与传出接口上的MTU相同的填充长度，四舍五入到四个字节的偶数倍。如果请求还包含RESPONSE-PORT属性，则服务器必须返回类型为400的错误响应。
Following that, the server completes the remainder of the processing from STUN [RFC5389]. If authentication is being required, the server MUST include a MESSAGE-INTEGRITY and associated attributes as appropriate. A FINGERPRINT attribute is only required if the STUN messages are being multiplexed with application traffic that requires use of a FINGERPRINT to distinguish STUN messages.
然后，服务器完成STUN[RFC5389]的其余处理。如果需要身份验证，服务器必须包括消息完整性和相关属性（视情况而定）。仅当STUN消息与需要使用指纹来区分STUN消息的应用程序流量多路复用时，才需要指纹属性。
An ALTERNATE-SERVER attribute MUST NOT be included with any other attribute defined in this specification.
备用服务器属性不得包含在本规范中定义的任何其他属性中。
When the server sends the Response, it is sent from the source address as determined above and to the source address of the Request. If RESPONSE-PORT is present, the server sends the response to that port instead of the originating port.
当服务器发送响应时，它从上面确定的源地址发送到请求的源地址。如果存在RESPONSE-PORT，则服务器将响应发送到该端口，而不是原始端口。
This document defines several STUN attributes that are required for NAT Behavior Discovery. These attributes are all used only with Binding Requests and Binding Responses. CHANGE-REQUEST was originally defined in RFC 3489 [RFC3489] but is redefined here as that document is obsoleted by [RFC5389].
本文档定义了NAT行为发现所需的几个STUN属性。这些属性都仅用于绑定请求和绑定响应。变更请求最初在RFC 3489[RFC3489]中定义，但由于该文件已被[RFC5389]废弃，因此在此重新定义。
Comprehension-required range (0x0000-0x7FFF): 0x0003: CHANGE-REQUEST 0x0026: PADDING 0x0027: RESPONSE-PORT
需要理解的范围（0x0000-0x7FFF）：0x0003:更改请求0x0026:填充0x0027:响应端口
Comprehension-optional range (0x8000-0xFFFF): 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS
理解可选范围（0x8000-0xFFFF）：0x802b:响应源0x802c:其他地址
Whenever an attribute contains a transport IP address and port, it has the same format as MAPPED-ADDRESS. Similarly, the XOR-attributes have the same format as XOR-MAPPED-ADDRESS [RFC5389].
每当属性包含传输IP地址和端口时，其格式与映射IP地址相同。类似地，XOR属性具有与XOR映射地址[RFC5389]相同的格式。
The CHANGE-REQUEST attribute contains two flags to control the IP address and port that the server uses to send the response. These flags are called the "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 the current filtering behavior of a NAT. They instruct the server to send the Binding Responses from the alternate source IP address and/or alternate port. The CHANGE-REQUEST attribute is optional in the Binding Request.
CHANGE-REQUEST属性包含两个标志，用于控制服务器用于发送响应的IP地址和端口。这些标志称为“更改IP”和“更改端口”标志。只有在绑定请求中才允许使用CHANGE-REQUEST属性。“更改IP”和“更改端口”标志对于确定NAT的当前过滤行为非常有用。它们指示服务器从备用源IP地址和/或备用端口发送绑定响应。在绑定请求中，CHANGE-REQUEST属性是可选的。
The attribute is 32 bits long, although only two bits (A and B) are used:
该属性的长度为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 meanings of the flags are:
这些旗帜的含义如下：
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 RESPONSE-ORIGIN attribute is inserted by the server and indicates the source IP address and port the response was sent from. It is useful for detecting double NAT configurations. It is only present in Binding Responses.
RESPONSE-ORIGIN属性由服务器插入，并指示发送响应的源IP地址和端口。它对于检测双NAT配置非常有用。它只存在于绑定响应中。
The OTHER-ADDRESS attribute is used 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. OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the server has a second IP address.
另一个地址属性用于绑定响应。它通知客户机如果客户机请求“更改IP”和“更改端口”行为，将使用的源IP地址和端口。除非服务器具有第二个IP地址，否则不能将其他IP地址插入到绑定响应中。
OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from RFC 3489 [RFC3489] because it is simply a new name with the same semantics as CHANGED-ADDRESS. It has been renamed to more clearly indicate its function.
OTHER-ADDRESS使用与RFC 3489[RFC3489]中的CHANGED-ADDRESS相同的属性号，因为它只是一个新名称，具有与CHANGED-ADDRESS相同的语义。它已被重命名，以更清楚地表明其功能。
The RESPONSE-PORT attribute contains a port. The RESPONSE-PORT attribute can be present in the Binding Request and indicates which port the Binding Response will be sent to. For servers which support the RESPONSE-PORT attribute, the Binding Response MUST be transmitted to the source IP address of the Binding Request and the port contained in RESPONSE-PORT. It is used in tests such as Section 4.6. When not present, the server sends the Binding Response to the source IP address and port of the Binding Request. The server MUST NOT process a request containing a RESPONSE-PORT and a PADDING attribute. The RESPONSE-PORT attribute is optional in the Binding Request. Server support for RESPONSE-PORT is optional.
RESPONSE-PORT属性包含一个端口。RESPONSE-PORT属性可以出现在绑定请求中，并指示绑定响应将发送到哪个端口。对于支持RESPONSE-PORT属性的服务器，绑定响应必须传输到绑定请求的源IP地址和RESPONSE-PORT中包含的端口。在第4.6节等试验中使用。当不存在时，服务器将绑定响应发送到绑定请求的源IP地址和端口。服务器不得处理包含响应端口和填充属性的请求。在绑定请求中，RESPONSE-PORT属性是可选的。服务器对响应端口的支持是可选的。
RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65536.
RESPONSE-PORT是网络字节顺序的16位无符号整数，后跟2个字节的填充。响应端口的允许值为0-65536。
The PADDING attribute allows for the entire message to be padded to force the STUN message to be divided into IP fragments. PADDING consists entirely of a free-form string, the value of which does not matter. PADDING can be used in either Binding Requests or Binding Responses.
PADDING属性允许对整个消息进行填充，以强制将STUN消息划分为IP片段。填充完全由自由格式字符串组成，其值无关紧要。填充可以在绑定请求或绑定响应中使用。
PADDING MUST NOT be longer than the length that brings the total IP datagram size to 64K. It SHOULD be equal in length to the MTU of the outgoing interface, rounded up to an even multiple of four bytes. Because STUN messages with PADDING are intended to test the behavior of UDP fragments, they are an exception to the usual rule that STUN messages be less than the MTU of the path.
填充长度不得超过使IP数据报总大小达到64K的长度。它的长度应该等于输出接口的MTU，四舍五入到四个字节的偶数倍。由于带填充的STUN消息旨在测试UDP片段的行为，因此它们是STUN消息小于路径的MTU的常规规则的例外。
The IAB has studied the problem of "Unilateral Self-Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. The STUN NAT Behavior Discovery usage 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已经研究了“单边自地址固定”（UNSAF）问题，这是一个一般过程，通过该过程，客户端试图通过协作协议反射机制确定NAT另一侧另一领域中的地址[RFC3424]。STUN-NAT行为发现用法是执行此类功能的协议的一个示例。IAB已授权为此目的制定的任何协议都应记录一组特定的考虑因素。本节满足这些要求。
From RFC 3424 [RFC3424], any UNSAF proposal must provide:
根据RFC 3424[RFC3424]，任何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. Such generalizations lead to the prolonged dependence on and usage of the supposed short term fix -- meaning that it is no longer accurate to call it "short term".
精确定义一个具体的、范围有限的问题，该问题将通过UNSAF提案解决。不应将短期修复推广到解决其他问题。这种泛化导致长期依赖和使用所谓的短期修正——这意味着称之为“短期修正”不再准确。
The specific problem being solved by the STUN NAT Behavior Discovery usage is for a client, which may be located behind a NAT of any type, to determine the instantaneous characteristics of that NAT. This determination allows either the diagnosis of the cause of problems experienced by that or other applications or the modification of an application's behavior based on the current behavior of the NAT and an appropriate statistical model of the behavior required for the application to succeed.
STUN-NAT行为发现用法所解决的具体问题是，客户机可以位于任何类型的NAT后面，以确定该NAT的瞬时特性。此确定允许诊断该应用程序或其他应用程序遇到的问题的原因，或基于NAT的当前行为和应用程序成功所需的行为的适当统计模型修改应用程序的行为。
From [RFC3424], any UNSAF proposal must provide:
根据[RFC3424]，任何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.
退出战略/过渡计划的说明。更好的短期修复方法是，随着适当技术的部署，自然会看到越来越少的使用。
The STUN NAT Behavior Discovery usage does not itself provide an exit strategy for v4 NATs. At the time of this writing, it appears some sort of NAT will be necessary between v6 clients and v4 servers, but this specification will not be necessary with those v6-to-v4 NATs because the IETF is planning to adequately describe their operation. This specification will be of no interest for v6-to-v6 connectivity.
stunnat行为发现用法本身并不为v4 NAT提供退出策略。在撰写本文时，似乎v6客户机和v4服务器之间需要某种NAT，但这些v6到v4 NAT不需要此规范，因为IETF计划充分描述其操作。本规范对v6到v6的连接不感兴趣。
From [RFC3424], any UNSAF proposal must provide:
根据[RFC3424]，任何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.
讨论可能使系统更“脆弱”的具体问题。例如，涉及在多个网络层使用数据的方法会产生更多的依赖性，增加调试挑战，并使转换更加困难。
The STUN NAT Behavior Discovery usage allows a client to determine the current behavior of a NAT. This information can be quite useful to a developer or network administrator outside of an application, and as such can be used to diagnose the brittleness induced in another application. When used within an application itself, STUN NAT Behavior Discovery allows the application to adjust its behavior according to the current behavior of the NAT. This document is experimental because the extent to which brittleness is introduced to an application relying on the Behavior Discovery usage is unclear and must be carefully evaluated by the designers of the protocol making use of it. The experimental test for this protocol is essentially determining whether an application can be made less brittle through the use of behavior-discovery information than it would be if attempted to make use of the network without any awareness of the NATs its traffic must pass through.
StunNAT行为发现用法允许客户端确定NAT的当前行为。这些信息对于应用程序之外的开发人员或网络管理员非常有用，因此可以用来诊断另一个应用程序中的脆性。在应用程序本身中使用时，STUN NAT行为发现允许应用程序根据NAT的当前行为调整其行为。本文档是实验性的，因为依赖行为发现使用的应用程序的脆性程度尚不清楚，必须由使用它的协议设计者仔细评估。该协议的实验测试本质上是确定是否可以通过使用行为发现信息使应用程序比在不知道其流量必须通过的NAT的情况下尝试使用网络时更不脆弱。
From [RFC3424], any UNSAF proposal must provide:
根据[RFC3424]，任何UNSAF提案必须提供：
Identify requirements for longer-term, sound technical solutions -- contribute to the process of finding the right longer-term solution.
确定长期、可靠的技术解决方案的需求——为找到正确的长期解决方案的过程做出贡献。
As long as v4 NATs are present, means of adapting to their presence will be required. As described above, well-behaved v6 to v4 NATs and direct v6 to v6 connections will not require behavior characterization.
只要存在v4 NAT，就需要适应其存在的方法。如上所述，性能良好的v6到v4 NAT和直接v6到v6连接不需要行为特征。
From [RFC3424], any UNSAF proposal must provide:
根据[RFC3424]，任何UNSAF提案必须提供：
Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
与现有已部署NAT和经验报告讨论已注意到的实际问题的影响。
This usage provides a set of generic attributes that can be assembled to test many types of NAT behavior. While tests for the most commonly known NAT box behaviors are described, the BEHAVE mailing
这种用法提供了一组通用属性，可以组合这些属性来测试多种类型的NAT行为。虽然描述了最常见的NAT盒行为的测试，但是
list regularly has descriptions of new behaviors, some of which may not be readily detected using the tests described herein. However, the techniques described in this usage can be assembled in different combinations to test NAT behaviors not now known or envisioned.
该列表定期对新行为进行描述，其中一些行为可能无法通过本文所述的测试轻易检测到。但是，本用法中描述的技术可以以不同的组合进行组装，以测试目前未知或未设想的NAT行为。
This specification defines several new STUN attributes. IANA has added these new protocol elements to the "STUN Attributes" registry.
本规范定义了几个新的眩晕属性。IANA已将这些新的协议元素添加到“STUN属性”注册表中。
0x0003: CHANGE-REQUEST 0x0027: RESPONSE-PORT 0x0026: PADDING 0x8027: CACHE-TIMEOUT 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS
0x0003:更改请求0x0027:响应端口0x0026:填充0x8027:缓存超时0x802b:响应源0x802c:其他地址
By default, the STUN NAT Behavior Discovery usage runs on the same ports as STUN: 3478 over UDP and TCP, and 5349 for TCP over TLS. However, the Behavior Discovery usage has its own set of Service Record (SRV) names: "stun-behavior" for UDP and TCP, and "stun-behaviors" for TLS. Either the SRV procedures or the ALTERNATE-SERVER procedures, subject to the recommendations of Section 5, can be used to run Behavior Discovery on a different port.
默认情况下，STUN NAT行为发现使用在与STUN相同的端口上运行：3478通过UDP和TCP，5349通过TLS的TCP。但是，行为发现使用有自己的一组服务记录（SRV）名称：“stun Behavior”用于UDP和TCP，而“stun Behavior”用于TLS。根据第5节的建议，可以使用SRV过程或备用服务器过程在不同的端口上运行行为发现。
This specification defines the "stun-behavior" and "stun-behaviors" SRV service names. "stun-behavior" may be used with SRV protocol specifiers "udp" and "tcp". "stun-behaviors" may only be specified with "tcp". Thus, the allowable SRV queries are:
本规范定义了“眩晕行为”和“眩晕行为”SRV服务名称。“stun行为”可与SRV协议说明符“udp”和“tcp”一起使用。“眩晕行为”只能用“tcp”指定。因此，允许的SRV查询是：
_stun-behavior._udp UDP _stun-behavior._tcp TCP _stun-behaviors._tcp TLS over TCP
_眩晕行为。_udp_眩晕行为。_tcp_眩晕行为。_TCPTLS over tcp
This usage inherits the security considerations of STUN [RFC5389]. This usage adds several new attributes; security considerations for those are detailed here.
这种用法继承了STUN[RFC5389]的安全注意事项。这种用法增加了几个新属性；这里详细介绍了这些方面的安全注意事项。
OTHER-ADDRESS does not permit any new attacks; it provides another place where an attacker can impersonate a STUN server but it is not an interesting attack. An attacker positioned where it can compromise the Binding Response can completely hide the STUN server from the client.
其他地址不允许任何新的攻击；它提供了另一个攻击者可以模拟昏迷服务器的地方，但这不是一个有趣的攻击。攻击者位于可以破坏绑定响应的位置，可以对客户端完全隐藏STUN服务器。
o Requests containing both RESPONSE-PORT and PADDING are rejected by the server. This prevents an amplification attack that is targeted at the originating address.
o 服务器拒绝同时包含响应端口和填充的请求。这可以防止针对原始地址的放大攻击。
The only attack possible with the PADDING attribute is to have a large padding length that could cause a server to allocate a large amount of memory. As servers will ignore any padding length greater than 64K so the scope of this attack is limited. In general, servers should not allocate more memory than the size of the received datagram. This attack would only affect non-compliant implementations.
PADDING属性唯一可能的攻击是具有较大的PADDING长度，这可能导致服务器分配大量内存。由于服务器将忽略任何大于64K的填充长度，因此此攻击的范围是有限的。通常，服务器分配的内存不应超过接收到的数据报的大小。此攻击只会影响不兼容的实现。
RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional attacks.
RESPONSE-ORIGIN和RESPONSE-PORT不提供任何其他攻击。
The authors would like to thank the authors of the original STUN specification [RFC3489] from which many of the ideas, attributes, and description in this document originated. Thanks to Dan Wing, Cullen Jennings, and Magnus Westerlund for detailed comments.
作者要感谢原始STUN规范[RFC3489]的作者，本文档中的许多想法、属性和描述都源自该规范。感谢Dan Wing、Cullen Jennings和Magnus Westerlund的详细评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
Authors' Addresses
作者地址
Derek C. MacDonald Skype Palo Alto, CA USA
德里克·C·麦克唐纳Skype帕洛阿尔托，加利福尼亚州，美国
EMail: derek.macdonald@gmail.com
EMail: derek.macdonald@gmail.com
Bruce B. Lowekamp Skype Palo Alto, CA USA
Bruce B.Lowekamp Skype Palo Alto，美国加利福尼亚州
EMail: bbl@lowekamp.net
EMail: bbl@lowekamp.net