Network Working Group C. Huitema
Request for Comments: 4380 Microsoft
Category: Standards Track February 2006
Network Working Group C. Huitema
Request for Comments: 4380 Microsoft
Category: Standards Track February 2006
Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
Teredo：通过网络地址转换（NAT）通过UDP传输IPv6
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4".
我们在这里提出了一种服务，使位于一个或多个IPv4网络地址转换（NAT）后面的节点能够通过UDP上的隧道数据包获得IPv6连接；我们称之为Teredo服务。运行该服务需要“Teredo服务器”和“Teredo中继”的帮助。Teredo服务器是无状态的，只需管理Teredo客户端之间的一小部分流量；Teredo中继充当Teredo服务和“本机”IPv6 Internet之间的IPv6路由器。中继还可以使用其他转换机制（如“6to4”）提供与主机的互操作性。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Teredo Service .............................................4
2.2. Teredo Client ..............................................4
2.3. Teredo Server ..............................................4
2.4. Teredo Relay ...............................................4
2.5. Teredo IPv6 Service Prefix .................................4
2.6. Global Teredo IPv6 Service Prefix ..........................4
2.7. Teredo UDP Port ............................................4
2.8. Teredo Bubble ..............................................4
2.9. Teredo Service Port ........................................5
2.10. Teredo Server Address .....................................5
2.11. Teredo Mapped Address and Teredo Mapped Port ..............5
2.12. Teredo IPv6 Client Prefix .................................5
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Teredo Service .............................................4
2.2. Teredo Client ..............................................4
2.3. Teredo Server ..............................................4
2.4. Teredo Relay ...............................................4
2.5. Teredo IPv6 Service Prefix .................................4
2.6. Global Teredo IPv6 Service Prefix ..........................4
2.7. Teredo UDP Port ............................................4
2.8. Teredo Bubble ..............................................4
2.9. Teredo Service Port ........................................5
2.10. Teredo Server Address .....................................5
2.11. Teredo Mapped Address and Teredo Mapped Port ..............5
2.12. Teredo IPv6 Client Prefix .................................5
2.13. Teredo Node Identifier ....................................5
2.14. Teredo IPv6 Address .......................................5
2.15. Teredo Refresh Interval ...................................5
2.16. Teredo Secondary Port .....................................6
2.17. Teredo IPv4 Discovery Address .............................6
3. Design Goals, Requirements, and Model of Operation ..............6
3.1. Hypotheses about NAT Behavior ..............................6
3.2. IPv6 Provider of Last Resort ...............................8
3.3. Operational Requirements ...................................9
3.4. Model of Operation ........................................10
4. Teredo Addresses ...............................................11
5. Specification of Clients, Servers, and Relays ..................13
5.1. Message Formats ...........................................13
5.2. Teredo Client Specification ...............................16
5.3. Teredo Server Specification ...............................31
5.4. Teredo Relay Specification ................................33
5.5. Implementation of Automatic Sunset ........................36
6. Further Study, Use of Teredo to Implement a Tunnel Service .....37
7. Security Considerations ........................................38
7.1. Opening a Hole in the NAT .................................38
7.2. Using the Teredo Service for a Man-in-the-Middle Attack ...39
7.3. Denial of the Teredo service ..............................42
7.4. Denial of Service against Non-Teredo Nodes ................43
8. IAB Considerations .............................................46
8.1. Problem Definition ........................................46
8.2. Exit Strategy .............................................47
8.3. Brittleness Introduced by Teredo ..........................48
8.4. Requirements for a Long-Term Solution .....................50
9. IANA Considerations ............................................50
10. Acknowledgements ..............................................50
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
2.13. Teredo Node Identifier ....................................5
2.14. Teredo IPv6 Address .......................................5
2.15. Teredo Refresh Interval ...................................5
2.16. Teredo Secondary Port .....................................6
2.17. Teredo IPv4 Discovery Address .............................6
3. Design Goals, Requirements, and Model of Operation ..............6
3.1. Hypotheses about NAT Behavior ..............................6
3.2. IPv6 Provider of Last Resort ...............................8
3.3. Operational Requirements ...................................9
3.4. Model of Operation ........................................10
4. Teredo Addresses ...............................................11
5. Specification of Clients, Servers, and Relays ..................13
5.1. Message Formats ...........................................13
5.2. Teredo Client Specification ...............................16
5.3. Teredo Server Specification ...............................31
5.4. Teredo Relay Specification ................................33
5.5. Implementation of Automatic Sunset ........................36
6. Further Study, Use of Teredo to Implement a Tunnel Service .....37
7. Security Considerations ........................................38
7.1. Opening a Hole in the NAT .................................38
7.2. Using the Teredo Service for a Man-in-the-Middle Attack ...39
7.3. Denial of the Teredo service ..............................42
7.4. Denial of Service against Non-Teredo Nodes ................43
8. IAB Considerations .............................................46
8.1. Problem Definition ........................................46
8.2. Exit Strategy .............................................47
8.3. Brittleness Introduced by Teredo ..........................48
8.4. Requirements for a Long-Term Solution .....................50
9. IANA Considerations ............................................50
10. Acknowledgements ..............................................50
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
Classic tunneling methods envisaged for IPv6 transition operate by sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal [RFC3056] proposes automatic discovery in this context. A problem with these methods is that they don't work when the IPv6 candidate node is isolated behind a Network Address Translator (NAT) device: NATs are typically not programmed to allow the transmission of arbitrary payload types; even when they are, the local address cannot be used in a 6to4 scheme. 6to4 will work with a NAT if the NAT and 6to4 router functions are in the same box; we want to cover the relatively frequent case when the NAT cannot be readily upgraded to provide a 6to4 router function.
为IPv6过渡设想的经典隧道方法通过发送IPv6数据包作为IPv4数据包的有效负载来运行；6to4提案[RFC3056]建议在这种情况下进行自动发现。这些方法的一个问题是，当IPv6候选节点被隔离在网络地址转换器（NAT）设备后面时，它们不起作用：NAT通常不被编程为允许传输任意有效负载类型；即使是这样，也不能在6to4方案中使用本地地址。如果NAT和6to4路由器功能在同一个框中，6to4将与NAT一起工作；我们想讨论NAT不能轻易升级以提供6to4路由器功能的相对频繁的情况。
A possible way to solve the problem is to rely on a set of "tunnel brokers". However, there are limits to any solution that is based on such brokers: the quality of service may be limited, since the traffic follows a dogleg route from the source to the broker and then the destination; the broker has to provide sufficient transmission capacity to relay all packets and thus suffers a high cost. For these two reasons, it may be desirable to have solutions that allow for "automatic tunneling", i.e., let the packets follow a direct path to the destination.
解决这个问题的一个可能办法是依靠一组“隧道经纪人”。然而，基于此类代理的任何解决方案都有局限性：服务质量可能会受到限制，因为流量遵循从源到代理再到目的地的狗腿路线；代理必须提供足够的传输容量来中继所有数据包，因此成本很高。出于这两个原因，可能需要具有允许“自动隧道”的解决方案，即，让分组沿着直接路径到达目的地。
The automatic tunneling requirement is indeed at odds with some of the specificities of NATs. Establishing a direct path supposes that the IPv6 candidate node can retrieve a "globally routable" address that results from the translation of its local address by one or more NATs; it also supposes that we can find a way to bypass the various "per destination protections" that many NATs implement. In this memo, we will explain how IPv6 candidates located behind NATs use "Teredo servers" to learn their "global address" and to obtain connectivity, how they exchange packets with native IPv6 hosts through "Teredo relays", and how clients, servers, and relays can be organized in Teredo networks.
自动隧道要求确实与NAT的某些特殊性不符。建立直接路径假设IPv6候选节点可以检索由一个或多个nat转换其本地地址而产生的“全局可路由”地址；它还假设我们可以找到一种绕过许多NAT实现的各种“每目的地保护”的方法。在本备忘录中，我们将解释位于NAT后面的IPv6候选服务器如何使用“Teredo服务器”来了解其“全局地址”并获得连接性，它们如何通过“Teredo中继”与本机IPv6主机交换数据包，以及如何在Teredo网络中组织客户端、服务器和中继。
The specification is organized as follows. Section 2 contains the definition of the terms used in the memo. Section 3 presents the hypotheses on NAT behavior used in the design, as well as the operational requirements that the design should meet. Section 4 presents the IPv6 address format used by Teredo. Section 5 contains the format of the messages and the specification of the protocol. Section 6 presents guidelines for further work on configured tunnels that would be complementary to the current approach. Section 7 contains a security discussion, section 8 contains a discussion of the Unilateral Self Address Fixing (UNSAF) issues, and section 9 contains IANA considerations.
本规范组织如下。第2节包含备忘录中所用术语的定义。第3节介绍了设计中使用的NAT行为的假设，以及设计应满足的操作要求。第4节介绍Teredo使用的IPv6地址格式。第5节包含消息格式和协议规范。第6节介绍了对现有方法进行补充的配置隧道的进一步工作指南。第7节讨论了安全问题，第8节讨论了单边自定址（UNSAF）问题，第9节讨论了IANA注意事项。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification uses the following definitions:
本规范使用以下定义：
The transmission of IPv6 packets over UDP, as defined in this memo.
本备忘录中定义的通过UDP传输IPv6数据包。
A node that has some access to the IPv4 Internet and wants to gain access to the IPv6 Internet.
可以访问IPv4 Internet并希望访问IPv6 Internet的节点。
A node that has access to the IPv4 Internet through a globally routable address, and is used as a helper to provide IPv6 connectivity to Teredo clients.
一种节点，可通过全局可路由地址访问IPv4 Internet，并用作向Teredo客户端提供IPv6连接的助手。
An IPv6 router that can receive traffic destined to Teredo clients and forward it using the Teredo service.
一种IPv6路由器，可接收发送至Teredo客户端的流量，并使用Teredo服务转发该流量。
An IPv6 addressing prefix that is used to construct the IPv6 address of Teredo clients.
用于构造Teredo客户端的IPv6地址的IPv6寻址前缀。
An IPv6 addressing prefix whose value is 2001:0000:/32.
值为2001:0000:/32的IPv6寻址前缀。
The UDP port number at which Teredo servers are waiting for packets. The value of this port is 3544.
Teredo服务器等待数据包的UDP端口号。此端口的值为3544。
A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and a null payload. The payload type is set to 59, No Next Header, as per [RFC2460]. The Teredo clients and relays may send bubbles in order to create a mapping in a NAT.
Teredo bubble是一个最小的IPv6数据包，由IPv6头和空负载组成。根据[RFC2460]，有效负载类型设置为59，无下一个收割台。Teredo客户端和中继可以发送气泡，以便在NAT中创建映射。
The port from which the Teredo client sends Teredo packets. This port is attached to one of the client's IPv4 addresses. The IPv4 address may or may not be globally routable, as the client may be located behind one or more NAT.
Teredo客户端从中发送Teredo数据包的端口。此端口连接到客户端的一个IPv4地址。IPv4地址可能是全局可路由的，也可能不是全局可路由的，因为客户端可能位于一个或多个NAT后面。
The IPv4 address of the Teredo server selected by a particular client.
特定客户端选择的Teredo服务器的IPv4地址。
A global IPv4 address and a UDP port that results from the translation of the IPv4 address and UDP port of a client's Teredo service port by one or more NATs. The client learns these values through the Teredo protocol described in this memo.
由一个或多个NAT转换客户端Teredo服务端口的IPv4地址和UDP端口而产生的全局IPv4地址和UDP端口。客户通过本备忘录中描述的Teredo协议了解这些值。
A global scope IPv6 prefix composed of the Teredo IPv6 service prefix and the Teredo server address.
由Teredo IPv6服务前缀和Teredo服务器地址组成的全局作用域IPv6前缀。
A 64-bit identifier that contains the UDP port and IPv4 address at which a client can be reached through the Teredo service, as well as a flag indicating the type of NAT through which the client accesses the IPv4 Internet.
一个64位标识符，其中包含UDP端口和IPv4地址，通过Teredo服务可以在该地址访问客户端，同时还包含一个标志，指示客户端访问IPv4 Internet时使用的NAT类型。
A Teredo IPv6 address obtained by combining a Teredo IPv6 client prefix and a Teredo node identifier.
通过组合Teredo IPv6客户端前缀和Teredo节点标识符获得的Teredo IPv6地址。
The interval during which a Teredo IPv6 address is expected to remain valid in the absence of "refresh" traffic. For a client located behind a NAT, the interval depends on configuration parameters of the local NAT, or the combination of NATs in the path to the Teredo server. By default, clients assume an interval value of 30 seconds; a longer value may be determined by local tests, as described in section 5.
在没有“刷新”通信量的情况下，Teredo IPv6地址保持有效的时间间隔。对于位于NAT后面的客户端，间隔取决于本地NAT的配置参数，或Teredo服务器路径中NAT的组合。默认情况下，客户端假定间隔值为30秒；如第5节所述，可通过局部试验确定较长的值。
A UDP port used to send or receive packets in order to determine the appropriate value of the refresh interval, but not used to carry any Teredo traffic.
一种UDP端口，用于发送或接收数据包以确定刷新间隔的适当值，但不用于承载任何Teredo通信量。
An IPv4 multicast address used to discover other Teredo clients on the same IPv4 subnet. The value of this address is 224.0.0.253.
用于发现同一IPv4子网上的其他Teredo客户端的IPv4多播地址。此地址的值为224.0.0.253。
The proposed solution transports IPv6 packets as the payload of UDP packets. This is based on the observation that TCP and UDP are the only protocols guaranteed to cross the majority of NAT devices. Tunneling packets over TCP would be possible, but would result in a poor quality of service; encapsulation over UDP is a better choice.
建议的解决方案将IPv6数据包作为UDP数据包的有效负载进行传输。这是基于TCP和UDP是保证跨大多数NAT设备的唯一协议的观察。通过TCP传输数据包是可能的，但会导致服务质量差；UDP封装是更好的选择。
The design of our solution is based on a set of hypotheses and observations on the behavior of NATs, our desire to provide an "IPv6 provider of last resort", and a list of operational requirements. It results in a model of operation in which the Teredo service is enabled by a set of servers and relays.
我们的解决方案的设计基于对NAT行为的一系列假设和观察，我们希望提供“最后的IPv6提供商”，以及一系列操作要求。它产生了一个操作模型，其中Teredo服务由一组服务器和继电器启用。
NAT devices typically incorporate some support for UDP, in order to enable users in the natted domain to use UDP-based applications. The NAT will typically allocate a "mapping" when it sees a UDP packet coming through for which there is not yet an existing mapping. The handling of UDP "sessions" by NAT devices differs by two important parameters, the type and the duration of the mappings.
NAT设备通常包含一些对UDP的支持，以便使NAT域中的用户能够使用基于UDP的应用程序。NAT通常会在看到UDP数据包通过时分配一个“映射”，而该数据包尚未存在映射。NAT设备对UDP“会话”的处理有两个重要参数不同，即映射的类型和持续时间。
The type of mappings is analyzed in [RFC3489], which distinguishes between "cone NAT", "restricted cone NAT", "port restricted cone NAT" and "symmetric NAT". The Teredo solution ensures connectivity for clients located behind cone NATs, restricted cone NATs, or port-restricted cone NATs.
[RFC3489]对映射类型进行了分析，区分了“锥形NAT”、“受限锥形NAT”、“端口受限锥形NAT”和“对称NAT”。Teredo解决方案确保位于cone NAT、受限cone NAT或端口受限cone NAT后面的客户端的连接。
Transmission of regular IPv6 packets only takes place after an exchange of "bubbles" between the parties. This exchange would often fail for clients behind symmetric NAT, because their peer cannot predict the UDP port number that the NAT expects.
常规IPv6数据包的传输仅在双方交换“气泡”后进行。对于对称NAT后面的客户端，这种交换通常会失败，因为它们的对等方无法预测NAT所期望的UDP端口号。
Clients located behind a symmetric NAT will only be able to use Teredo if they can somehow program the NAT and reserve a Teredo service port for each client, for example, using the DMZ functions of
位于对称NAT后面的客户端只有在能够以某种方式编程NAT并为每个客户端保留Teredo服务端口（例如，使用的DMZ功能）的情况下才能使用Teredo
the NAT. This is obviously an onerous requirement, at odds with the design goal of an automatic solution. However, measurement campaigns and studies of documentations have shown that, at least in simple "unmanaged" networks, symmetric NATs are a small minority; moreover, it seems that new NAT models or firmware upgrades avoid the "symmetric" design.
纳特。这显然是一个繁重的要求，与自动解决方案的设计目标不一致。然而，测量活动和文献研究表明，至少在简单的“非托管”网络中，对称NAT是少数；此外，新的NAT型号或固件升级似乎避免了“对称”设计。
Investigations on the performance of [RFC3489] have shown the relative frequency of a particular NAT design, which we might call "port conserving". In this design, the NAT tries to keep the same port number inside and outside, unless the "outside" port number is already in use for another mapping with the same host. Port conserving NAT appear as "cone" or "restricted cone NAT" most of the time, but they will behave as "symmetric NAT" when multiple internal hosts use the same port number to communicate to the same server.
对[RFC3489]性能的调查显示了特定NAT设计的相对频率，我们可以称之为“端口保护”。在这种设计中，NAT尝试在内部和外部保持相同的端口号，除非“外部”端口号已用于同一主机的另一个映射。端口保护NAT在大多数情况下显示为“cone”或“受限cone NAT”，但当多个内部主机使用相同的端口号与同一服务器通信时，它们将表现为“对称NAT”。
The Teredo design minimizes the risk of encountering the "symmetric" behavior by asking multiple hosts located behind the same NAT to use different Teredo service ports.
Teredo设计要求位于同一NAT后面的多个主机使用不同的Teredo服务端口，从而将遇到“对称”行为的风险降至最低。
Other investigation in the behavior of NAT also outlined the "probabilistic rewrite" behavior. Some brands of NAT will examine all packets for "embedded addresses", IP addresses, and port numbers present in application payloads. They will systematically replace 32-bit values that match a local address by the corresponding mapped address. The Teredo specification includes an "obfuscation" procedure in order to avoid this behavior.
对NAT行为的其他调查也概述了“概率重写”行为。一些品牌的NAT将检查应用程序有效负载中存在的所有数据包的“嵌入式地址”、IP地址和端口号。它们将系统地用相应的映射地址替换与本地地址匹配的32位值。Teredo规范包括一个“混淆”过程以避免这种行为。
Regardless of their types, UDP mappings are not kept forever. The typical algorithm is to remove the mapping if no traffic is observed on the specified port for a "lifetime" period. The Teredo client that wants to maintain a mapping open in the NAT will have to send some "keep alive" traffic before the lifetime expires. For that, it needs an estimate of the "lifetime" parameter used in the NAT. We observed that the implementation of lifetime control can vary in several ways.
无论其类型如何，UDP映射都不会永远保留。典型的算法是，如果指定端口在“生存期”内未观察到任何通信量，则删除映射。想要在NAT中保持打开的映射的Teredo客户端必须在生存期到期之前发送一些“保持活动”流量。为此，需要估计NAT中使用的“寿命”参数。我们观察到，生命周期控制的实现可以在几个方面有所不同。
Most NATs implement a "minimum lifetime", which is set as a parameter of the implementation. Our observations of various boxes showed that this parameter can vary between about 45 seconds and several minutes.
大多数NAT实现一个“最小生存期”，它被设置为实现的一个参数。我们对各种盒子的观察表明，该参数可以在45秒到几分钟之间变化。
In many NATs, mappings can be kept for a duration that exceeds this minimum, even in the absence of traffic. We suspect that many implementation perform "garbage collection" of unused mappings on special events, e.g., when the overall number of mappings exceeds some limit.
在许多NAT中，映射可以保留超过此最小值的时间，即使在没有流量的情况下也是如此。我们怀疑许多实现在特殊事件上对未使用的映射执行“垃圾收集”，例如，当映射的总数超过某个限制时。
In some cases, e.g., NATs that manage Integrated Services Digital Network (ISDN) or dial-up connections, the mappings will be released when the connection is released, i.e., when no traffic is observed on the connection for a period of a few minutes.
在某些情况下，当一个数字连接被释放时（例如，当一个数字连接被释放时，在一个数字连接被释放时，即数分钟）。
Any algorithm used to estimate the lifetime of mapping will have to be robust against these variations.
任何用于估计映射生存期的算法都必须对这些变化具有鲁棒性。
In some cases, clients are located behind multiple NAT. The Teredo procedures will ensure communications between clients between multiple NATs and clients "on the other side" of these NATs. They will also ensure communication when clients are located in a single subnet behind the same NAT.
在某些情况下，客户端位于多个NAT后面。Teredo程序将确保多个NAT和这些NAT“另一端”的客户端之间的通信。当客户端位于同一NAT后面的单个子网中时，它们还将确保通信。
The procedures do not make any hypothesis about the type of IPv4 address used behind a NAT, and in particular do not assume that these are private addresses defined in [RFC1918].
这些过程不会对NAT背后使用的IPv4地址类型做出任何假设，尤其不会假设这些地址是[RFC1918]中定义的专用地址。
Teredo is designed to provide an "IPv6 access of last resort" to nodes that need IPv6 connectivity but cannot use any of the other IPv6 transition schemes. This design objective has several consequences on when to use Teredo, how to program clients, and what to expect of servers. Another consequence is that we expect to see a point in time at which the Teredo technology ceases to be used.
Teredo旨在为需要IPv6连接但不能使用任何其他IPv6转换方案的节点提供“最后的IPv6访问”。这个设计目标对何时使用Teredo、如何编程客户机以及服务器的预期有几个影响。另一个结果是，我们期望看到Teredo技术停止使用的时间点。
Teredo is designed to robustly enable IPv6 traffic through NATs, and the price of robustness is a reasonable amount of overhead, due to UDP encapsulation and transmission of bubbles. Nodes that want to connect to the IPv6 Internet SHOULD only use the Teredo service as a "last resort" option: they SHOULD prefer using direct IPv6 connectivity if it is locally available, if it is provided by a 6to4 router co-located with the local NAT, or if it is provided by a configured tunnel service; and they SHOULD prefer using the less onerous 6to4 encapsulation if they can use a global IPv4 address.
Teredo设计用于通过NAT稳健地启用IPv6流量，由于UDP封装和气泡传输，稳健的代价是合理的开销。想要连接到IPv6 Internet的节点应仅使用Teredo服务作为“最后手段”选项：如果直接IPv6连接在本地可用，如果由与本地NAT位于同一位置的6to4路由器提供，或者如果由配置的隧道服务提供，则应首选使用直接IPv6连接；如果他们可以使用全局IPv4地址，他们应该更喜欢使用不那么繁重的6to4封装。
In an IPv6-enabled network, the IPv6 service is configured automatically, by using mechanisms such as IPv6 Stateless Address Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A design objective is to configure the Teredo service as automatically as possible. In practice, however, it is required that the client learn the IPv4 address of a server that is willing to serve the client; some servers may also require some form of access control.
在支持IPv6的网络中，通过使用IPv6无状态地址自动配置[RFC2462]和邻居发现[RFC2461]等机制自动配置IPv6服务。设计目标是尽可能自动地配置Teredo服务。然而，在实践中，要求客户机了解愿意为客户机服务的服务器的IPv4地址；某些服务器可能还需要某种形式的访问控制。
During the peak of the transition, there will be a requirement to deploy Teredo servers supporting a large number of Teredo clients. Minimizing the load on the server is a good way to facilitate this deployment. To achieve this goal, servers should be as stateless as possible, and they should also not be required to carry any more traffic than necessary. To achieve this objective, we require only that servers enable the packet exchange between clients, but we don't require servers to carry the actual data packets: these packets will have to be exchanged directly between the Teredo clients, or through a destination-selected relay for exchanges between Teredo clients and other IPv6 clients.
在过渡的高峰期，需要部署支持大量Teredo客户端的Teredo服务器。最小化服务器上的负载是促进此部署的一个好方法。为了实现这一目标，服务器应尽可能无状态，并且不应要求它们承载超过必要的流量。为了实现这一目标，我们只要求服务器支持客户端之间的数据包交换，但不要求服务器携带实际的数据包：这些数据包必须在Teredo客户端之间直接交换，或者通过Teredo客户端和其他IPv6客户端之间交换的目的地选择的中继进行交换。
Teredo is meant as a short-term solution to the specific problem of providing IPv6 service to nodes located behind a NAT. The problem is expected to be resolved over time by transforming the "IPv4 NAT" into an "IPv6 router". This can be done in one of two ways: upgrading the NAT to provide 6to4 functions or upgrading the Internet connection used by the NAT to a native IPv6 service, and then adding IPv6 router functionality in the NAT. In either case, the former NAT can present itself as an IPv6 router to the systems behind it. These systems will start receiving the "router advertisements"; they will notice that they have IPv6 connectivity and will stop using Teredo.
Teredo是为位于NAT后面的节点提供IPv6服务这一特定问题的短期解决方案。随着时间的推移，通过将“IPv4 NAT”转换为“IPv6路由器”，这个问题有望得到解决。这可以通过以下两种方式之一完成：升级NAT以提供6to4功能，或者将NAT使用的Internet连接升级到本机IPv6服务，然后在NAT中添加IPv6路由器功能。在任何一种情况下，前一个NAT都可以作为一个IPv6路由器呈现给它后面的系统。这些系统将开始接收“路由器广告”；他们会注意到他们有IPv6连接，并将停止使用Teredo。
The Teredo service is designed primarily for robustness: packets are carried over UDP in order to cross as many NAT implementations as possible. The servers are designed to be stateless, which means that they can easily be replicated. We expect indeed to find many such servers replicated at multiple Internet locations.
Teredo服务主要是为了健壮性而设计的：数据包通过UDP传输，以便尽可能多地跨NAT实现。服务器被设计成无状态，这意味着它们可以很容易地被复制。我们确实希望在多个互联网位置发现许多这样的服务器。
The service requires the support of Teredo servers and Teredo relays. In order to facilitate the deployment of these servers and relays, the Teredo procedures are designed to minimize the amount of coordination required between servers and relays.
该服务需要Teredo服务器和Teredo中继的支持。为了便于部署这些服务器和继电器，Teredo程序旨在最大限度地减少服务器和继电器之间所需的协调量。
Meeting this objective implies that the Teredo addresses will incorporate the IPv4 address and UDP port through which a Teredo client can be reached. This creates an implicit limit on the
满足这一目标意味着Teredo地址将包含IPv4地址和UDP端口，通过它们可以访问Teredo客户端。这会对
stability of the Teredo addresses, which can only remain valid as long as the underlying IPv4 address and UDP port remain valid.
Teredo地址的稳定性，只有在基础IPv4地址和UDP端口保持有效时，Teredo地址才能保持有效。
The Teredo clients obtain mapped addresses and ports from the Teredo servers. The service must be protected against denial of service attacks in which a third party spoofs a Teredo server and sends improper information to the client.
Teredo客户端从Teredo服务器获取映射的地址和端口。必须保护服务免受拒绝服务攻击，其中第三方欺骗Teredo服务器并向客户端发送不正确的信息。
Teredo relays will act as a relay for IPv6 packets. Improperly designed packet relays can be used by denial of service attackers to hide their address, making the attack untraceable. The Teredo service must include adequate protection against such misuse.
Teredo中继将充当IPv6数据包的中继。设计不当的数据包中继可被拒绝服务攻击者用来隐藏其地址，从而使攻击无法追踪。Teredo服务必须包括防止此类滥用的充分保护。
Routers may perform ingress filtering by checking that the source address of the packets received on a given interface is "legitimate", i.e., belongs to network prefixes from which traffic is expected at a network interface. Ingress filtering is a recommended practice, as it thwarts the use of forged source IP addresses by malfeasant hackers, notably to cover their tracks during denial of service attacks. The Teredo specification must not force networks to disable ingress filtering.
路由器可以通过检查在给定接口上接收的分组的源地址是否“合法”来执行入口过滤，即，属于网络接口处预期流量来自的网络前缀。入口过滤是一种推荐做法，因为它可以阻止恶意黑客使用伪造的源IP地址，尤其是在拒绝服务攻击期间掩盖其踪迹。Teredo规范不得强制网络禁用入口过滤。
The operation of Teredo involves four types of nodes: Teredo clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes.
Teredo的操作涉及四种类型的节点：Teredo客户端、Teredo服务器、Teredo中继和“普通”IPv6节点。
Teredo clients start operation by interacting with a Teredo server, performing a "qualification procedure". During this procedure, the client will discover whether it is behind a cone, restricted cone, or symmetric NAT. If the client is not located behind a symmetric NAT, the procedure will be successful and the client will configure a "Teredo address".
Teredo客户端通过与Teredo服务器交互开始操作，执行“鉴定过程”。在此过程中，客户端将发现它是否位于圆锥体、受限圆锥体或对称NAT后面。如果客户端不位于对称NAT后面，则该过程将成功，客户端将配置“Teredo地址”。
The Teredo IPv6 address embeds the "mapped address and port" through which the client can receive IPv4/UDP packets encapsulating IPv6 packets. If the client is not located behind a cone NAT, transmission of regular IPv6 packets must be preceded by an exchange of "bubbles" that will install a mapping in the NAT. This document specifies how the bubbles can be exchanged between Teredo clients in order to enable transmission along a direct path.
Teredo IPv6地址嵌入了“映射地址和端口”，客户端可以通过该地址和端口接收封装IPv6数据包的IPv4/UDP数据包。如果客户端不位于cone NAT后面，则常规IPv6数据包的传输必须在交换“气泡”之前进行，该气泡将在NAT中安装映射。本文档指定如何在Teredo客户机之间交换气泡，以便能够沿直接路径进行传输。
Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g., native nodes or 6to4 nodes) through Teredo relays. Teredo relays advertise reachability of the Teredo prefix to a certain subset of the IPv6 Internet: a relay set up by an ISP will typically serve only the IPv6 customers of this ISP; a relay set-up for a site will only serve the IPv6 hosts of this site. Dual-stack hosts may implement a "local relay", allowing them to communicate directly with Teredo hosts by sending IPv6 packets over UDP and IPv4 without having to advertise a Teredo IPv6 address.
Teredo客户端可以通过Teredo中继与普通IPv6节点（例如，本机节点或6to4节点）交换IPv6数据包。Teredo中继将Teredo前缀的可达性宣传到IPv6 Internet的某个子集：由ISP设置的中继通常只服务于该ISP的IPv6客户；站点的中继设置将仅服务于此站点的IPv6主机。双栈主机可以实现“本地中继”，允许它们通过UDP和IPv4发送IPv6数据包直接与Teredo主机通信，而无需公布Teredo IPv6地址。
Teredo clients have to discover the relay that is closest to each native IPv6 or 6to4 peer. They have to perform this discovery for each native IPv6 or 6to4 peer with which they communicate. In order to prevent spoofing, the Teredo clients perform a relay discovery procedure by sending an ICMP echo request to the native host. This message is a regularly formatted IPv6 ICMP packet, which is encapsulated in UDP and sent by the client to its Teredo server; the server decapsulates the IPv6 message and forwards it to the intended IPv6 destination. The payload of the echo request contains a large random number. The echo reply is sent by the peer to the IPv6 address of the client, and is forwarded through standard IPv6 routing mechanisms. It will naturally reach the Teredo relay closest to the native or 6to4 peer, and will be forwarded by this relay using the Teredo mechanisms. The Teredo client will discover the IPv4 address and UDP port used by the relay to send the echo reply, and will send further IPv6 packets to the peer by encapsulating them in UDP packets sent to this IPv4 address and port. In order to prevent spoofing, the Teredo client verifies that the payload of the echo reply contains the proper random number.
Teredo客户端必须发现距离每个本机IPv6或6to4对等点最近的中继。他们必须为与之通信的每个本机IPv6或6to4对等方执行此发现。为了防止欺骗，Teredo客户端通过向本机主机发送ICMP回显请求来执行中继发现过程。此消息是一个定期格式化的IPv6 ICMP数据包，它封装在UDP中，由客户端发送到Teredo服务器；服务器解除对IPv6消息的封装并将其转发到预期的IPv6目标。echo请求的有效负载包含一个大的随机数。回送回复由对等方发送到客户端的IPv6地址，并通过标准IPv6路由机制转发。它自然会到达最靠近本机或6to4对等机的Teredo中继，并将由该中继使用Teredo机制转发。Teredo客户端将发现中继用来发送回显回复的IPv4地址和UDP端口，并将进一步的IPv6数据包封装在发送到此IPv4地址和端口的UDP数据包中，从而将它们发送到对等方。为了防止欺骗，Teredo客户端验证回送回复的有效负载是否包含正确的随机数。
The procedures are designed so that the Teredo server only participates in the qualification procedure and in the exchange of bubbles and ICMP echo requests. The Teredo server never carries actual data traffic. There are two rationales for this design: reduce the load on the server in order to enable scaling, and avoid privacy issues that could occur if a Teredo server kept copies of the client's data packets.
这些过程的设计使得Teredo服务器只参与鉴定过程以及气泡和ICMP回显请求的交换。Teredo服务器从不承载实际的数据流量。此设计有两个基本原理：减少服务器上的负载以实现扩展，并避免Teredo服务器保留客户端数据包副本时可能出现的隐私问题。
The Teredo addresses are composed of 5 components:
Teredo地址由5个组件组成：
+-------------+-------------+-------+------+-------------+
| Prefix | Server IPv4 | Flags | Port | Client IPv4 |
+-------------+-------------+-------+------+-------------+
+-------------+-------------+-------+------+-------------+
| Prefix | Server IPv4 | Flags | Port | Client IPv4 |
+-------------+-------------+-------+------+-------------+
- Prefix: the 32-bit Teredo service prefix. - Server IPv4: the IPv4 address of a Teredo server.
- 前缀：32位Teredo服务前缀。-服务器IPv4:Teredo服务器的IPv4地址。
- Flags: a set of 16 bits that document type of address and NAT. - Port: the obfuscated "mapped UDP port" of the Teredo service at the client. - Client IPv4: the obfuscated "mapped IPv4 address" of the client.
- 标志：记录地址类型和NAT的一组16位端口：客户端Teredo服务的模糊“映射UDP端口”。-客户端IPv4：客户端的模糊“映射IPv4地址”。
In this format, both the "mapped UDP port" and "mapped IPv4 address" of the client are obfuscated. Each bit in the address and port number is reversed; this can be done by an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.
在这种格式中，客户端的“映射UDP端口”和“映射IPv4地址”都是模糊的。地址和端口号中的每一位都是反向的；这可以通过十六进制值为0xFFFF的16位端口号的异或和十六进制值为0xFFFFFF的32位地址的异或来实现。
The IPv6 addressing rules specify that "for all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format". This dictates the encoding of the flags, 16 intermediate bits that should correspond to valid values of the most significant 16 bits of a Modified EUI-64 ID:
IPv6寻址规则规定，“对于所有单播地址，除了以二进制值000开头的地址外，接口ID的长度必须为64位，并且必须以修改后的EUI-64格式构造”。这规定了标志的编码，16个中间位应对应于修改的EUI-64 ID的最高有效16位的有效值：
0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+
0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+
In this format:
以这种格式：
- The bits "UG" should be set to the value "00", indicating a non-global unicast identifier; - The bit "C" (cone) should be set to 1 if the client believes it is behind a cone NAT, to 0 otherwise; these values determine different server behavior during the qualification procedure, as specified in Section 5.2.1, as well as different bubble processing by clients and relays. - The bits indicated with "z" must be set to zero and ignored on receipt.
- 位“UG”应设置为值“00”，表示非全局单播标识符；-如果客户端认为位“C”（cone）位于cone NAT后面，则应将其设置为1，否则设置为0；根据第5.2.1节的规定，这些值决定了鉴定过程中不同的服务器行为，以及客户端和中继的不同气泡处理。-带有“z”的位必须设置为零，并在收到时忽略。
Thus, there are two currently specified values of the Flags field: "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the cone bit is set to 1. (Further versions of this specification may assign new values to the reserved bits.)
因此，标志字段有两个当前指定的值：如果锥形位设置为0，则为“0x0000”（全部为空）；如果锥形位设置为1，则为“0x8000”。（本规范的其他版本可能会将新值分配给保留位。）
In some cases, Teredo nodes use link-local addresses. These addresses contain a link-local prefix (FE80::/64) and a 64-bit identifier, constructed using the same format as presented above. A difference between link-local addresses and global addresses is that the identifiers used in global addresses MUST include a global scope unicast IPv4 address, while the identifiers used in link-local addresses MAY include a private IPv4 address.
在某些情况下，Teredo节点使用链路本地地址。这些地址包含一个链路本地前缀（FE80:：/64）和一个64位标识符，其构造格式与上述格式相同。链路本地地址和全局地址之间的区别在于，全局地址中使用的标识符必须包括全局范围单播IPv4地址，而链路本地地址中使用的标识符可能包括专用IPv4地址。
The Teredo service is realized by having clients interact with Teredo servers through the Teredo service protocol. The clients will also receive IPv6 packets through Teredo relays. The client behavior is specified in Section 5.2.
Teredo服务是通过让客户端通过Teredo服务协议与Teredo服务器交互来实现的。客户端还将通过Teredo中继接收IPv6数据包。第5.2节规定了客户行为。
The Teredo server is designed to be stateless. It waits for Teredo requests and for IPv6 packets on the Teredo UDP port; it processes the requests by sending a response to the appropriate address and port; it forwards some Teredo IPv6 packets to the appropriate IPv4 address and UDP port, or to native IPv6 peers of Teredo clients. The precise behavior of the server is specified in Section 5.3.
Teredo服务器设计为无状态。它在Teredo UDP端口上等待Teredo请求和IPv6数据包；它通过向适当的地址和端口发送响应来处理请求；它将一些Teredo IPv6数据包转发到适当的IPv4地址和UDP端口，或者转发到Teredo客户端的本机IPv6对等方。第5.3节规定了服务器的精确行为。
The Teredo relay advertises reachability of the Teredo service prefix over IPv6. The scope of advertisement may be the entire Internet or a smaller subset such as an ISP network or an IPv6 site; it may even be as small as a single host in the case of "local relays". The relay forwards Teredo IPv6 packets to the appropriate IPv4 address and UDP port. The relay behavior is specified in Section 5.4.
Teredo中继通过IPv6播发Teredo服务前缀的可达性。广告的范围可以是整个互联网或更小的子集，例如ISP网络或IPv6站点；在“本地继电器”的情况下，它甚至可能与单个主机一样小。中继将Teredo IPv6数据包转发到适当的IPv4地址和UDP端口。第5.4节规定了继电器的行为。
Teredo clients, servers, and relays must implement the sunset procedure defined in Section 5.5.
Teredo客户端、服务器和继电器必须执行第5.5节中定义的日落程序。
Teredo IPv6 packets are transmitted as UDP packets [RFC768] within IPv4 [RFC791]. The source and destination IP addresses and UDP ports take values that are specified in this section. Packets can come in one of two formats, simple encapsulation and encapsulation with origin indication.
Teredo IPv6数据包在IPv4[RFC791]中作为UDP数据包[RFC768]传输。源和目标IP地址以及UDP端口采用本节中指定的值。数据包可以采用两种格式之一，简单封装和带原点指示的封装。
When simple encapsulation is used, the packet will have a simple format, in which the IPv6 packet is carried as the payload of a UDP datagram:
当使用简单封装时，数据包将具有简单格式，其中IPv6数据包作为UDP数据报的有效负载携带：
+------+-----+-------------+
| IPv4 | UDP | IPv6 packet |
+------+-----+-------------+
+------+-----+-------------+
| IPv4 | UDP | IPv6 packet |
+------+-----+-------------+
When relaying some packets received from third parties, the server may insert an origin indication in the first bytes of the UDP payload:
当中继从第三方接收的一些数据包时，服务器可以在UDP有效负载的第一个字节中插入原点指示：
+------+-----+-------------------+-------------+
| IPv4 | UDP | Origin indication | IPv6 packet |
+------+-----+-------------------+-------------+
+------+-----+-------------------+-------------+
| IPv4 | UDP | Origin indication | IPv6 packet |
+------+-----+-------------------+-------------+
The origin indication encapsulation is an 8-octet element, with the following content:
原点指示封装是一个8-octet元素，具有以下内容：
+--------+--------+-----------------+
| 0x00 | 0x00 | Origin port # |
+--------+--------+-----------------+
| Origin IPv4 address |
+-----------------------------------+
+--------+--------+-----------------+
| 0x00 | 0x00 | Origin port # |
+--------+--------+-----------------+
| Origin IPv4 address |
+-----------------------------------+
The first two octets of the origin indication are set to a null value; this is used to discriminate between the simple encapsulation, in which the first 4 bits of the packet contain the indication of the IPv6 protocol, and the origin indication.
原点指示的前两个八位字节设置为空值；这用于区分简单封装（其中数据包的前4位包含IPv6协议的指示）和来源指示。
The following 16 bits contain the obfuscated value of the port number from which the packet was received, in network byte order. The next 32 bits contain the obfuscated IPv4 address from which the packet was received, in network byte order. In this format, both the original "IPv4 address" and "UDP port" of the client are obfuscated. Each bit in the address and port number is reversed; this can be done by an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.
以下16位包含接收数据包的端口号的模糊值（按网络字节顺序）。接下来的32位以网络字节顺序包含接收数据包的模糊IPv4地址。在这种格式中，客户机的原始“IPv4地址”和“UDP端口”都是模糊的。地址和端口号中的每一位都是反向的；这可以通过十六进制值为0xFFFF的16位端口号的异或和十六进制值为0xFFFFFF的32位地址的异或来实现。
For example, if the original UDP port number was 337 (hexadecimal 0151) and original IPv4 address was 1.2.3.4 (hexadecimal 01020304), the origin indication would contain the value "0000FEAEFEFDFCFB".
例如，如果原始UDP端口号为337（十六进制0151），原始IPv4地址为1.2.3.4（十六进制01020304），则原点指示将包含值“0000FEAEFEFDFCFB”。
When exchanging Router Solicitation (RS) and Router Advertisement (RA) messages between a client and its server, the packets may include an authentication parameter:
当在客户端及其服务器之间交换路由器请求（RS）和路由器广告（RA）消息时，分组可以包括认证参数：
+------+-----+----------------+-------------+
| IPv4 | UDP | Authentication | IPv6 packet |
+------+-----+----------------+-------------+
+------+-----+----------------+-------------+
| IPv4 | UDP | Authentication | IPv6 packet |
+------+-----+----------------+-------------+
The authentication encapsulation is a variable-length element, containing a client identifier, an authentication value, a nonce value, and a confirmation byte.
身份验证封装是一个可变长度的元素，包含客户端标识符、身份验证值、nonce值和确认字节。
+--------+--------+--------+--------+
| 0x00 | 0x01 | ID-len | AU-len |
+--------+--------+--------+--------+
| Client identifier (ID-len |
+-----------------+-----------------+
| octets) | Authentication |
+-----------------+--------+--------+
| value (AU-len octets) | Nonce |
+--------------------------+--------+
| value (8 octets) |
+--------------------------+--------+
| | Conf. |
+--------------------------+--------+
+--------+--------+--------+--------+
| 0x00 | 0x01 | ID-len | AU-len |
+--------+--------+--------+--------+
| Client identifier (ID-len |
+-----------------+-----------------+
| octets) | Authentication |
+-----------------+--------+--------+
| value (AU-len octets) | Nonce |
+--------------------------+--------+
| value (8 octets) |
+--------------------------+--------+
| | Conf. |
+--------------------------+--------+
The first octet of the authentication encapsulation is set to a null value, and the second octet is set to the value 1; this enables differentiation from IPv6 packets and from origin information indication encapsulation. The third octet indicates the length in bytes of the client identifier; the fourth octet indicates the length in bytes of the authentication value. The computation of the authentication value is specified in Section 5.2.2. The authentication value is followed by an 8-octet nonce, and by a confirmation byte.
认证封装的第一个八位组设置为空值，第二个八位组设置为值1；这使得区分IPv6数据包和来源信息指示封装成为可能。第三个八位字节表示客户端标识符的字节长度；第四个八位字节表示身份验证值的字节长度。第5.2.2节规定了认证值的计算。身份验证值后跟一个8位字节的nonce和一个确认字节。
Both ID-len and AU-len can be set to null values if the server does not require an explicit authentication of the client.
如果服务器不需要客户端的显式身份验证，则ID len和AU len都可以设置为null值。
Authentication and origin indication encapsulations may sometimes be combined, for example, in the RA responses sent by the server. In this case, the authentication encapsulation MUST be the first element in the UDP payload:
例如，在服务器发送的RA响应中，有时可以组合认证和来源指示封装。在这种情况下，身份验证封装必须是UDP有效负载中的第一个元素：
+------+-----+----------------+--------+-------------+
| IPv4 | UDP | Authentication | Origin | IPv6 packet |
+------+-----+----------------+--------+-------------+
+------+-----+----------------+--------+-------------+
| IPv4 | UDP | Authentication | Origin | IPv6 packet |
+------+-----+----------------+--------+-------------+
Since Teredo uses UDP as an underlying transport, a Teredo Maximum Transmission Unit (MTU) could potentially be as large as the payload of the largest valid UDP datagram (65507 bytes). However, since Teredo packets can travel on unpredictable paths over the Internet, it is best to contain this MTU to a small size, in order to minimize the effect of IPv4 packet fragmentation and reassembly. The default link MTU assumed by a host, and the link MTU supplied by a Teredo server during router advertisement SHOULD normally be set to the minimum IPv6 MTU size of 1280 bytes [RFC2460].
由于Teredo使用UDP作为底层传输，Teredo最大传输单元（MTU）可能与最大有效UDP数据报（65507字节）的有效负载一样大。但是，由于Teredo数据包可以在Internet上以不可预测的路径传输，因此最好将此MTU控制在较小的大小，以便将IPv4数据包碎片化和重新组装的影响降至最低。主机假定的默认链路MTU，以及路由器播发期间Teredo服务器提供的链路MTU，通常应设置为1280字节的最小IPv6 MTU大小[RFC2460]。
Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of the encapsulating IPv4 header.
Teredo实现不应设置封装IPv4报头的Don't Fragment（DF）位。
Before using the Teredo service, the client must be configured with:
在使用Teredo服务之前，客户端必须配置：
- the IPv4 address of a server. - a secondary IPv4 address of that server.
- 服务器的IPv4地址。-该服务器的辅助IPv4地址。
If secure discovery is required, the client must also be configured with:
如果需要安全发现，客户端还必须配置：
- a client identifier, - a secret value, shared with the server, - an authentication algorithm, shared with the server.
- 客户端标识符，-与服务器共享的秘密值，-与服务器共享的身份验证算法。
A Teredo client expects to exchange IPv6 packets through a UDP port, the Teredo service port. To avoid problems when operating behind a "port conserving" NAT, different clients operating behind the same NAT should use different service port numbers. This can be achieved through explicit configuration or, in the absence of configuration, by picking the service port number at random.
Teredo客户端希望通过UDP端口（Teredo服务端口）交换IPv6数据包。为了避免在“端口保护”NAT后面操作时出现问题，在同一NAT后面操作的不同客户端应使用不同的服务端口号。这可以通过显式配置或在没有配置的情况下随机选取服务端口号来实现。
The client will maintain the following variables that reflect the state of the Teredo service:
客户端将维护以下反映Teredo服务状态的变量：
- Teredo connectivity status, - Mapped address and port number associated with the Teredo service port, - Teredo IPv6 prefix associated with the Teredo service port, - Teredo IPv6 address or addresses derived from the prefix, - Link local address, - Date and time of the last interaction with the Teredo server, - Teredo Refresh Interval, - Randomized Refresh Interval, - List of recent Teredo peers.
- Teredo连接状态，-与Teredo服务端口关联的映射地址和端口号，-与Teredo服务端口关联的Teredo IPv6前缀，-Teredo IPv6地址或从前缀派生的地址，-链路本地地址，-上次与Teredo服务器交互的日期和时间，-Teredo刷新间隔，-随机刷新间隔，-最近Teredo对等点列表。
Before sending any packets, the client must perform the Teredo qualification procedure, which determines the Teredo connectivity status, the mapped address and port number, and the Teredo IPv6 prefix. It should then perform the cone NAT determination procedure, which determines the cone NAT status and may alter the value of the prefix. If the qualification is successful, the client may use the Teredo service port to transmit and receive IPv6 packets, according to the transmission and reception procedures. These procedures use the "list of recent peers". For each peer, the list contains:
在发送任何数据包之前，客户端必须执行Teredo鉴定过程，该过程确定Teredo连接状态、映射地址和端口号以及Teredo IPv6前缀。然后，它应该执行cone NAT确定程序，该程序确定cone NAT状态，并可能更改前缀的值。如果鉴定成功，客户机可以根据传输和接收程序使用Teredo服务端口发送和接收IPv6数据包。这些程序使用“最近同行名单”。对于每个对等方，该列表包含：
- The IPv6 address of the peer, - The mapped IPv4 address and mapped UDP port of the peer, - The status of the mapped address, i.e., trusted or not, - The value of the last nonce sent to the peer, - The date and time of the last reception from the peer, - The date and time of the last transmission to the peer, - The number of bubbles transmitted to the peer.
- 对等方的IPv6地址，-对等方的映射IPv4地址和映射UDP端口，-映射地址的状态，即受信任与否，-发送到对等方的最后一个nonce的值，-对等方最后一次接收的日期和时间，-最后一次传输到对等方的日期和时间，-传输到对等方的气泡数。
The list of peers is used to enable the transmission of IPv6 packets by using a "direct path" for the IPv6 packets. The list of peers could grow over time. Clients should implement a list management strategy, for example, deleting the least recently used entries. Clients should make sure that the list has a sufficient size, to avoid unnecessary exchanges of bubbles.
对等点列表用于通过使用IPv6数据包的“直接路径”来启用IPv6数据包的传输。同行名单可能会随着时间的推移而增加。客户机应实施列表管理策略，例如，删除最近使用最少的条目。客户应确保列表有足够的大小，以避免不必要的泡沫交换。
The client must regularly perform the maintenance procedure in order to guarantee that the Teredo service port remains usable. The need to use this procedure or not depends on the delay since the last interaction with the Teredo server. The refresh procedure takes as a parameter the "Teredo refresh interval". This parameter is initially set to 30 seconds; it can be updated as a result of the optional "interval determination procedure". The randomized refresh interval is set to a value randomly chosen between 75% and 100% of the refresh interval.
客户必须定期执行维护程序，以确保Teredo服务端口保持可用。是否需要使用此过程取决于自上次与Teredo服务器交互以来的延迟。刷新过程将“Teredo刷新间隔”作为参数。该参数最初设置为30秒；可根据可选的“间隔确定程序”进行更新。随机选择刷新间隔的75%和设置为100%之间的随机刷新间隔。
In order to avoid triangle routing for stations that are located behind the same NAT, the Teredo clients MAY use the optional local client discovery procedure defined in Section 5.2.8. Using this procedure will also enhance connectivity when the NAT cannot do "hairpin" routing, i.e., cannot redirect a packet sent from one internal host to the mapped address and port of another internal host.
为了避免位于同一NAT后面的站点采用三角形路由，Teredo客户端可以使用第5.2.8节中定义的可选本地客户端发现程序。当NAT无法进行“发夹式”路由时，也就是说，无法将从一个内部主机发送的数据包重定向到另一个内部主机的映射地址和端口时，使用此过程还将增强连接性。
The purposes of the qualification procedure are to establish the status of the local IPv4 connection and to determine the Teredo IPv6 client prefix of the local Teredo interface. The procedure starts when the service is in the "initial" state, and it results in a "qualified" state if successful, and in an "off-line" state if unsuccessful.
鉴定过程的目的是建立本地IPv4连接的状态，并确定本地Teredo接口的Teredo IPv6客户端前缀。当服务处于“初始”状态时，该过程开始，如果成功，将导致“合格”状态，如果失败，将导致“脱机”状态。
/---------\
| Initial |
\---------/
|
+----+----------+
| Set ConeBit=1 |
+----+----------+
|
+<-------------------------------------------+
| |
+----+----+ |
| Start |<------+ |
+----+----+ | +----------+----+
| | | Set ConeBit=0 |
v | +----------+----+
/---------\ Timer | N ^
|Starting |-------+ attempts /----------------\Yes|
\---------/----------------->| ConeBit == 1 ? |---+
| Response \----------------/
| | No
V V
/---------------\ Yes /----------\
| ConeBit == 1? |-----+ | Off line |
\---------------/ | \----------/
No | v
| /----------\
| | Cone NAT |
+-----+-----+ \----------/
| New Server|
+-----+-----+
|
+----+----+
| Start |<------+
+----+----+ |
| |
v |
/---------\ Timer |
|Starting |-------+ N attempts /----------\
\---------/------------------->| Off line |
| Response \----------/
|
V
/---------\
| Initial |
\---------/
|
+----+----------+
| Set ConeBit=1 |
+----+----------+
|
+<-------------------------------------------+
| |
+----+----+ |
| Start |<------+ |
+----+----+ | +----------+----+
| | | Set ConeBit=0 |
v | +----------+----+
/---------\ Timer | N ^
|Starting |-------+ attempts /----------------\Yes|
\---------/----------------->| ConeBit == 1 ? |---+
| Response \----------------/
| | No
V V
/---------------\ Yes /----------\
| ConeBit == 1? |-----+ | Off line |
\---------------/ | \----------/
No | v
| /----------\
| | Cone NAT |
+-----+-----+ \----------/
| New Server|
+-----+-----+
|
+----+----+
| Start |<------+
+----+----+ |
| |
v |
/---------\ Timer |
|Starting |-------+ N attempts /----------\
\---------/------------------->| Off line |
| Response \----------/
|
V
/------------\ No /---------------\
| Same port? |-------->| Symmetric NAT |
\------------/ \---------------/
| Yes
V
/----------------------\
| Restricted Cone NAT |
\----------------------/
/------------\ No /---------------\
| Same port? |-------->| Symmetric NAT |
\------------/ \---------------/
| Yes
V
/----------------------\
| Restricted Cone NAT |
\----------------------/
Initially, the Teredo connectivity status is set to "Initial".
最初，Teredo连接状态设置为“初始”。
When the interface is initialized, the system first performs the "start action" by sending a Router Solicitation message, as defined in [RFC2461]. The client picks a link-local address and uses it as the IPv6 source of the message; the cone bit in the address is set to 1 (see Section 4 for the address format); the IPv6 destination of the RS is the all-routers multicast address; the packet will be sent over UDP from the service port to the Teredo server's IPv4 address and Teredo UDP port. The connectivity status moves then to "Starting".
接口初始化时，系统首先通过发送路由器请求消息执行“启动操作”，如[RFC2461]中所定义。客户端选择链路本地地址并将其用作消息的IPv6源；地址中的锥形位设置为1（地址格式见第4节）；RS的IPv6目的地是所有路由器的多播地址；数据包将通过UDP从服务端口发送到Teredo服务器的IPv4地址和Teredo UDP端口。然后连接状态移动到“开始”。
In the starting state, the client waits for a router advertisement from the Teredo server. If no response comes within a time-out T, the client should repeat the start action, by resending the Router Solicitation message. If no response has arrived after N repetitions, the client concludes that it is not behind a cone NAT. It sets the cone bit to 0, and repeats the procedure. If after N other timer expirations and retransmissions there is still no response, the client concludes that it cannot use UDP, and that the Teredo service is not available; the status is set to "Off-line". In accordance with [RFC2461], the default time-out value is set to T=4 seconds, and the maximum number of repetitions is set to N=3.
在启动状态下，客户端等待Teredo服务器发出的路由器公告。如果在超时T内没有响应，则客户端应通过重新发送路由器请求消息来重复启动操作。如果N次重复后没有收到响应，则客户会得出结论，它不是在锥形NAT后面。它将锥位设置为0，并重复该过程。如果在N次其他计时器过期和重新传输之后仍然没有响应，则客户端认为它无法使用UDP，并且Teredo服务不可用；状态设置为“离线”。根据[RFC2461]，默认超时值设置为T=4秒，最大重复次数设置为N=3。
If a response arrives, the client checks that the response contains an origin indication and a valid router advertisement as defined in [RFC2461], that the IPv6 destination address is equal to the link-local address used in the router solicitation, and that the router advertisement contains exactly one advertised Prefix Information option. This prefix should be a valid Teredo IPv6 server prefix: the first 32 bits should contain the global Teredo IPv6 service prefix, and the next 32 bits should contain the server's IPv4 address. If this is the case, the client learns the Teredo mapped address and Teredo mapped port from the origin indication. The IPv6 source address of the Router Advertisement is a link-local server address of the Teredo server. (Responses that are not valid advertisements are simply discarded.)
如果响应到达，客户端将检查响应是否包含来源指示和[RFC2461]中定义的有效路由器通告，IPv6目标地址是否等于路由器请求中使用的链路本地地址，以及路由器通告是否仅包含一个通告的前缀信息选项。此前缀应为有效的Teredo IPv6服务器前缀：前32位应包含全局Teredo IPv6服务前缀，后32位应包含服务器的IPv4地址。如果是这种情况，客户端将从原点指示中学习Teredo映射地址和Teredo映射端口。路由器播发的IPv6源地址是Teredo服务器的链路本地服务器地址。（无效广告的响应将被丢弃。）
If the client has received an RA with the cone bit in the IPv6 destination address set to 1, it is behind a cone NAT and is fully qualified. If the RA is received with the cone bit set to 0, the client does not know whether the local NAT is restricted or symmetric. The client selects the secondary IPv4 server address, and repeats the procedure, the cone bit remaining to the value zero. If the client does not receive a response, it detects that the service is not usable. If the client receives a response, it compares the mapped address and mapped port in this second response to the first received values. If the values are different, the client detects a symmetric NAT: it cannot use the Teredo service. If the values are the same, the client detects a port-restricted or restricted cone NAT: the client is qualified to use the service. (Teredo operates the same way for restricted and port-restricted NAT.)
如果客户端已接收到IPv6目标地址中的锥形位设置为1的RA，则它位于锥形NAT之后，并且完全合格。如果接收到RA时圆锥位设置为0，则客户端不知道本地NAT是受限的还是对称的。客户端选择辅助IPv4服务器地址，并重复该过程，锥形位保留为零。如果客户端没有收到响应，它会检测到服务不可用。如果客户端接收到响应，它会将第二个响应中的映射地址和映射端口与第一个接收到的值进行比较。如果值不同，客户端将检测到对称NAT：它无法使用Teredo服务。如果值相同，则客户端检测到端口受限或受限的cone NAT：客户端有资格使用该服务。（Teredo对受限NAT和端口受限NAT的操作方式相同。）
If the client is qualified, it builds a Teredo IPv6 address using the Teredo IPv6 server prefix learned from the RA and the obfuscated values of the UDP port and IPv4 address learned from the origin indication. The cone bit should be set to the value used to receive the RA, i.e., 1 if the client is behind a cone NAT, 0 otherwise. The client can start using the Teredo service.
如果客户端合格，它将使用从RA中学习到的Teredo IPv6服务器前缀以及从源指示中学习到的UDP端口和IPv4地址的模糊值来构建Teredo IPv6地址。锥形位应设置为用于接收RA的值，即，如果客户端位于锥形NAT后面，则设置为1，否则设置为0。客户端可以开始使用Teredo服务。
The client may be required to perform secured qualification. The client will perform exactly the algorithm described in Section 5.2.1, but it will incorporate an authentication encapsulation in the UDP packet carrying the router solicitation message, and it will verify the presence of a valid authentication parameter in the UDP message that carries the router advertisement provided by the sender.
客户可能需要进行安全鉴定。客户端将严格执行第5.2.1节中描述的算法，但它将在承载路由器请求消息的UDP数据包中包含身份验证封装，并将验证承载发送方提供的路由器广告的UDP消息中是否存在有效的身份验证参数。
In these packets, the nonce value is chosen by the client, and is repeated in the response from the server; the client identifier is a value with which the client was configured.
在这些数据包中，nonce值由客户端选择，并在服务器的响应中重复；客户端标识符是配置客户端时使用的值。
A first level of protection is provided by just checking that the value of the nonce in the response matches the value initially sent by the client. If they don't match, the packet MUST be discarded. If no other protection is used, the authentication payload does not contain any identifier or authentication field; the ID-len and AU-len fields are set to a null value. When stronger protection is required, the authentication payload contains the identifier and location fields, as explained in the following paragraphs.
通过检查响应中nonce的值是否与客户端最初发送的值匹配，可以提供第一级保护。如果它们不匹配，则必须丢弃数据包。如果未使用其他保护，则认证有效载荷不包含任何标识符或认证字段；ID len和AU len字段设置为空值。当需要更强的保护时，身份验证有效负载包含标识符和位置字段，如下段所述。
The confirmation byte is set to 0 by the client. A null value returned by the server indicates that the client's key is still valid; a non-null value indicates that the client should obtain a new key.
客户端将确认设置为0。服务器返回的空值表示客户端的密钥仍然有效；非空值表示客户端应获取新密钥。
When stronger authentication is provided, the client and the server are provisioned with a client identifier, a shared secret, and the identification of an authentication algorithm. Before transmission, the authentication value is computed according to the specified algorithm; on reception, the same algorithm is used to compute a target value from the content of the receive packet. The receiver deems the authentication successful if the two values match. If they don't, the packet MUST be discarded.
当提供更强的认证时，向客户端和服务器提供客户端标识符、共享密钥和认证算法的标识。在传输之前，根据指定的算法计算认证值；在接收时，使用相同的算法从接收分组的内容计算目标值。如果两个值匹配，则接收方认为身份验证成功。如果没有，则必须丢弃数据包。
To maximize interoperability, this specification defines a default algorithm in which the authentication value is computed according the HMAC specification [RFC2104] and the SHA1 function [FIPS-180]. Clients and servers may agree to use HMAC combined with a different function, or to use a different algorithm altogether, such as for example AES-XCBC-MAC-96 [RFC3566].
为了最大限度地提高互操作性，本规范定义了一种默认算法，其中根据HMAC规范[RFC2104]和SHA1函数[FIPS-180]计算身份验证值。客户机和服务器可能同意将HMAC与不同的功能结合使用，或者完全使用不同的算法，例如AES-XCBC-MAC-96[RFC3566]。
The default authentication algorithm is based on the HMAC algorithm according to the following specifications:
根据以下规范，默认身份验证算法基于HMAC算法：
- the hash function shall be the SHA1 function [FIPS-180]. - the secret value shall be the shared secret with which the client was configured.
- 散列函数应为SHA1函数[FIPS-180]。-机密值应为配置客户端时使用的共享机密。
The clear text to be protected includes:
要保护的明文包括：
- the nonce value, - the confirmation byte, - the origin indication encapsulation, if it is present, - the IPv6 packet.
- nonce值，-确认字节，-原点指示封装，如果存在，-IPv6数据包。
The HMAC procedure is applied to the concatenation of these four components, without any additional padding.
HMAC过程应用于这四个组件的串联，无需任何额外填充。
The Teredo client receives packets over the Teredo interface. The role of the packet reception procedure, besides receiving packets, is to maintain the date and time of the last interaction with the Teredo server and the "list of recent peers".
Teredo客户端通过Teredo接口接收数据包。除了接收数据包外，数据包接收程序的作用是维护与Teredo服务器最后一次交互的日期和时间以及“最近的对等点列表”。
When a UDP packet is received over the Teredo service port, the Teredo client checks that it is encoded according to the packet encoding rules defined in Section 5.1.1, and that it contains either a valid IPv6 packet or the combination of a valid origin indication encapsulation and a valid IPv6 packet, possibly protected by a valid authentication encapsulation. If this is not the case, the packet is silently discarded.
当通过Teredo服务端口接收到UDP数据包时，Teredo客户端将检查该数据包是否根据第5.1.1节中定义的数据包编码规则进行编码，并且该数据包是否包含有效的IPv6数据包或有效的来源指示封装和有效的IPv6数据包的组合，可能受有效的身份验证封装保护。如果情况并非如此，则数据包将被悄悄丢弃。
An IPv6 packet is deemed valid if it conforms to [RFC2460]: the protocol identifier should indicate an IPv6 packet and the payload length should be consistent with the length of the UDP datagram in which the packet is encapsulated. In addition, the client should check that the IPv6 destination address correspond to its own Teredo address.
如果IPv6数据包符合[RFC2460]：协议标识符应指示IPv6数据包，且有效负载长度应与封装该数据包的UDP数据报的长度一致，则认为该数据包有效。此外，客户端应检查IPv6目标地址是否与其自己的Teredo地址相对应。
Then, the Teredo client examines the IPv4 source address and UDP port number from which the packet is received. If these values match the IPv4 address of the server and the Teredo port, the client updates the "date and time of the last interaction with the Teredo server" to the current date and time; if an origin indication is present, the client should perform the "direct IPv6 connectivity test" described in Section 5.2.9.
然后，Teredo客户端检查从中接收数据包的IPv4源地址和UDP端口号。如果这些值与服务器和Teredo端口的IPv4地址匹配，则客户端将“上次与Teredo服务器交互的日期和时间”更新为当前日期和时间；如果存在原点指示，客户端应执行第5.2.9节中所述的“直接IPv6连接测试”。
If the IPv4 source address and UDP port number are different from the IPv4 address of the server and the Teredo port, the client examines the IPv6 source address of the packet:
如果IPv4源地址和UDP端口号与服务器的IPv4地址和Teredo端口不同，客户端将检查数据包的IPv6源地址：
1) If there is an entry for the source IPv6 address in the list of peers whose status is trusted, the client compares the mapped IPv4 address and mapped port in the entry with the source IPv4 address and source port of the packet. If the values match, the packet is accepted; the date and time of the last reception from the peer is updated.
1) 如果在状态受信任的对等方列表中有一个源IPv6地址条目，则客户端会将该条目中的映射IPv4地址和映射端口与数据包的源IPv4地址和源端口进行比较。如果值匹配，则接受数据包；来自对等方的最后一次接收的日期和时间被更新。
2) If there is an entry for the source IPv6 address in the list of peers whose status is not trusted, the client checks whether the packet is an ICMPv6 echo reply. If this is the case, and if the ICMPv6 data of the reply matches the nonce stored in the peer entry, the packet should be accepted; the status of the entry should be changed to "trusted", the mapped IPv4 and mapped port in the entry should be set to the source IPv4 address and source port from which the packet was received, and the date and time of the last reception from the peer should be updated. Any packet queued for this IPv6 peer (as specified in Section 5.2.4) should be de-queued and forwarded to the newly learned IPv4 address and UDP port.
2) 如果在状态不受信任的对等方列表中存在源IPv6地址的条目，则客户端将检查该数据包是否为ICMPv6回显回复。如果是这种情况，并且应答的ICMPv6数据与对等条目中存储的nonce匹配，则应接受该数据包；条目的状态应更改为“受信任”，条目中的映射IPv4和映射端口应设置为从中接收数据包的源IPv4地址和源端口，并且应更新上次从对等方接收数据包的日期和时间。为该IPv6对等方排队的任何数据包（如第5.2.4节所述）都应取消排队并转发到新获知的IPv4地址和UDP端口。
3) If the source IPv6 address is a Teredo address, the client compares the mapped IPv4 address and mapped port in the source address with the source IPv4 address and source port of the packet. If the values match, the client MUST create a peer entry for the IPv6 source address in the list of peers; it should update the entry if one already existed; the mapped IPv4 address and mapped port in the entry should be set to the value from which the packet was received, and the status should be set to "trusted". If a new entry is created, the last transmission date is set to 30 seconds before the current date, and the number of bubbles to zero. If the packet is a
3) 如果源IPv6地址是Teredo地址，则客户端将源地址中的映射IPv4地址和映射端口与数据包的源IPv4地址和源端口进行比较。如果值匹配，客户端必须为对等方列表中的IPv6源地址创建对等方条目；如果已经存在条目，则应更新该条目；条目中的映射IPv4地址和映射端口应设置为从中接收数据包的值，并且状态应设置为“受信任”。如果创建了新条目，则上次传输日期设置为当前日期前30秒，气泡数设置为零。如果数据包是一个
bubble, it should be discarded after this processing; otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination.
气泡，处理后应丢弃；否则，应接受该数据包。在所有情况下，客户机都必须取消排队并转发为该目的地排队的任何数据包。
4) If the IPv4 destination address through which the packet was received is the Teredo IPv4 Discovery Address, the source address is a valid Teredo address, and the destination address is the "all nodes on link" multicast address, the packet should be treated as a local discovery bubble. If no local entry already existed for the source address, a new one is created, but its status is set to "not trusted". The client SHOULD reply with a unicast Teredo bubble, sent to the source IPv4 address and source port of the local discovery bubble; the IPv6 source address of the bubble will be set to local Teredo IPv6 address; the IPv6 destination address of the bubble should be set to the IPv6 source address of the local discovery bubble. (Clients that do not implement the optional local discovery procedure will not process local discovery bubbles.)
4) 如果接收数据包的IPv4目标地址是Teredo IPv4发现地址，源地址是有效的Teredo地址，目标地址是“链路上的所有节点”多播地址，则应将数据包视为本地发现气泡。如果源地址的本地条目不存在，则会创建一个新条目，但其状态设置为“不受信任”。客户端应使用单播Teredo气泡进行回复，发送到本地发现气泡的源IPv4地址和源端口；气泡的IPv6源地址将设置为本地Teredo IPv6地址；气泡的IPv6目标地址应设置为本地发现气泡的IPv6源地址。（未实现可选本地发现过程的客户端将不会处理本地发现气泡。）
5) If the source IPv6 address is a Teredo address, and the mapped IPv4 address and mapped port in the source address do not match the source IPv4 address and source port of the packet, the client checks whether there is an existing "local" entry for that IPv6 address. If there is such an entry, and if the local IPv4 address and local port indicated in that entry match the source IPv4 address and source
5) 如果源IPv6地址是Teredo地址，并且源地址中的映射IPv4地址和映射端口与数据包的源IPv4地址和源端口不匹配，则客户端将检查该IPv6地址是否存在现有的“本地”条目。如果存在这样一个条目，并且该条目中指示的本地IPv4地址和本地端口是否与源IPv4地址和源相匹配
port of the packet, the client updates the "local" entry, whose status should be set to "trusted". If the packet is a bubble, it should be discarded after this processing; otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination.
在数据包的端口，客户端更新“本地”条目，其状态应设置为“受信任”。如果该数据包是一个气泡，则应在该处理之后丢弃该数据包；否则，应接受该数据包。在所有情况下，客户机都必须取消排队并转发为该目的地排队的任何数据包。
6) In the other cases, the packet may be accepted, but the client should be conscious that the source address may be spoofed; before processing the packet, the client should perform the "direct IPv6 connectivity test" described in Section 5.2.9.
6) 在其他情况下，数据包可以被接受，但是客户端应该意识到源地址可能被欺骗；在处理数据包之前，客户端应执行第5.2.9节所述的“直接IPv6连接测试”。
Whatever the IPv4 source address and UDP source port, the client that receives an IPv6 packet MAY send a Teredo bubble towards that target, as specified in Section 5.2.6.
无论IPv4源地址和UDP源端口是什么，接收IPv6数据包的客户端都可以向该目标发送Teredo气泡，如第5.2.6节所述。
When a Teredo client has to transmit a packet over a Teredo interface, it examines the destination IPv6 address. The client checks first if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid: an entry associated with a local peer is valid if the last reception date and time associated with that list entry is less that 30 seconds from the
当Teredo客户端必须通过Teredo接口传输数据包时，它会检查目标IPv6地址。客户端首先检查最近的Teredo对等方列表中是否有此IPv6地址的条目，以及该条目是否仍然有效：如果与该列表条目关联的最后接收日期和时间距离目标时间少于30秒，则与本地对等方关联的条目有效
current time; an entry associated with a non-local peer is valid if the last reception date and time associated with that list entry is less that 30 seconds from the current time. (Local peer entries can only be present if the client uses the local discovery procedure discussed in Section 5.2.8.)
当前时间；如果与非本地对等方关联的最后接收日期和时间与当前时间的距离小于30秒，则与该列表条目关联的条目有效。（只有当客户端使用第5.2.8节中讨论的本地发现程序时，才能显示本地对等条目。）
The client then performs the following:
然后，客户端执行以下操作：
1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the IPv4 address and UDP port specified in the entry. The client updates the date of last transmission in the peer entry.
1) 如果对等方列表中有该IPv6地址的条目，并且该条目的状态设置为“受信任”，则应通过UDP将IPv6数据包发送到条目中指定的IPv4地址和UDP端口。客户端更新对等条目中最后一次传输的日期。
2) If the destination is not a Teredo IPv6 address, the packet is queued, and the client performs the "direct IPv6 connectivity test" described in Section 5.2.9. The packet will be de-queued and forwarded if this procedure completes successfully. If the direct IPv6 connectivity test fails to complete within a 2-second time-out, it should be repeated up to 3 times.
2) 如果目的地不是Teredo IPv6地址，则数据包将排队，客户端将执行第5.2.9节所述的“直接IPv6连接测试”。如果此过程成功完成，数据包将被取消排队并转发。如果直接IPv6连接测试未能在2秒钟的超时时间内完成，则应重复最多3次。
3) If the destination is the Teredo IPv6 address of a local peer (i.e., a Teredo address from which a local discovery bubble has been received in the last 600 seconds), the packet is queued. The client sends a unicast Teredo bubble to the local IPv4 address and local port specified in the entry, and a local Teredo bubble to the Teredo IPv4 discovery address.
3) 如果目的地是本地对等方的Teredo IPv6地址（即，在过去600秒内从中接收到本地发现气泡的Teredo地址），则分组排队。客户端向条目中指定的本地IPv4地址和本地端口发送单播Teredo气泡，并向Teredo IPv4发现地址发送本地Teredo气泡。
4) If the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address.
4) 如果目标是Teredo IPv6地址，其中cone位设置为1，则数据包将通过UDP发送到映射的IPv4地址和从该IPv6地址提取的映射UDP端口。
5) If the destination is a Teredo IPv6 address in which the cone bit is set to 0, the packet is queued. If the client is not located behind a cone NAT, it sends a direct bubble to the Teredo destination, i.e., to the mapped IP address and mapped port of the destination. In all cases, the client sends an indirect bubble to the Teredo destination, sending it over UDP to the server address and to the Teredo port. The packet will be de-queued and forwarded when the client receives a bubble or another packet directly from this Teredo peer. If no bubble is received within a 2-second time-out, the bubble transmission should be repeated up to 3 times.
5) 如果目标是Teredo IPv6地址，其中cone位设置为0，则数据包将排队。如果客户端不位于cone NAT后面，它会向Teredo目的地（即，目的地的映射IP地址和映射端口）发送一个直接气泡。在所有情况下，客户端都会向Teredo目标发送一个间接气泡，通过UDP将其发送到服务器地址和Teredo端口。当客户机直接从Teredo对等机接收到气泡或另一个数据包时，数据包将被取消排队并转发。如果在2秒钟的超时时间内没有收到气泡，则气泡传输应重复最多3次。
In cases 4 and 5, before sending a packet over UDP, the client MUST check that the IPv4 destination address is in the format of a global unicast address; if this is not the case, the packet MUST be silently
在情况4和5中，在通过UDP发送数据包之前，客户端必须检查IPv4目标地址是否为全局单播地址格式；如果不是这种情况，则必须以静默方式发送数据包
discarded. (Note that a packet can legitimately be sent to a non-global unicast address in case 1, as a result of the local discovery procedure.)
丢弃的。（注意，在情况1中，由于本地发现过程，数据包可以合法地发送到非全局单播地址。）
The global unicast address check is designed to thwart a number of possible attacks in which an attacker tries to use a Teredo host to attack either a single local IPv4 target or a set of such targets. For the purpose of this specification, and IPv4 address is deemed to be a global unicast address if it does not belong to or match:
全局单播地址检查旨在阻止攻击者试图使用Teredo主机攻击单个本地IPv4目标或一组此类目标的多种可能攻击。在本规范中，如果IPv4地址不属于或不匹配以下地址，则视为全局单播地址：
- the "local" subnet 0.0.0.0/8, - the "loopback" subnet 127.0.0.0/8, - the local addressing ranges 10.0.0.0/8, - the local addressing ranges 172.16.0.0/12, - the local addressing ranges 192.168.0.0/16, - the link local block 169.254.0.0/16, - the block reserved for 6to4 anycast addresses 192.88.99.0/24, - the multicast address block 224.0.0.0/4, - the "limited broadcast" destination address 255.255.255.255, - the directed broadcast addresses corresponding to the subnets to which the host is attached.
- “本地”子网0.0.0/8，-“环回”子网127.0.0.0/8，-本地寻址范围10.0.0.0/8，-本地寻址范围172.16.0.0/12，-本地寻址范围192.168.0.0/16，-链路本地块169.254.0.0/16，-为6to4选播地址192.88.99.0/24保留的块，-多播地址块224.0.0.0/4，-“有限广播”目标地址255.255.255.255，-与主机连接到的子网对应的定向广播地址。
A list of special-use IPv4 addresses is provided in [RFC3330].
[RFC3330]中提供了特殊用途IPv4地址列表。
For reliability reasons, clients MAY decide to ignore the value of the cone bit in the flag, skip the "case 4" test and always perform the "case 5", i.e., treat all Teredo peers as if they were located behind non-cone NAT. This will result in some increase in traffic, but may avoid reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, clients MAY also decide to always send a direct bubble in case 5, even if they do not believe that they are located behind a non-cone NAT.
出于可靠性原因，客户可能会决定忽略标志中的锥形位值，跳过“案例4”测试并始终执行“案例5”，即，将所有Teredo对等点视为位于非锥形NAT后面。这将导致通信量有所增加，但如果NAT状态的确定因某种原因出错，则可能避免可靠性问题。出于同样的原因，客户也可能决定在案例5中始终发送直接气泡，即使他们不相信自己位于非锥形NAT后面。
The Teredo client must ensure that the mappings that it uses remain valid. It does so by checking that packets are regularly received from the Teredo server.
Teredo客户端必须确保它使用的映射保持有效。它通过检查是否定期从Teredo服务器接收数据包来实现。
At regular intervals, the client MUST check the "date and time of the last interaction with the Teredo server" to ensure that at least one packet has been received in the last Randomized Teredo Refresh Interval. If this is not the case, the client SHOULD send a router solicitation message to the server, as specified in Section 5.2.1; the client should use the same value of the cone bit that resulted in the reception of an RA during the qualification procedure.
客户机必须定期检查“上次与Teredo服务器交互的日期和时间”，以确保在上次随机Teredo刷新间隔内至少收到一个数据包。如果情况并非如此，则客户端应按照第5.2.1节的规定向服务器发送路由器请求消息；客户应使用在鉴定程序中导致接收RA的牙轮钻头的相同值。
When the router advertisement is received, the client SHOULD check its validity as specified in Section 5.2.1; invalid advertisements are silently discarded. If the advertisement is valid, the client MUST check that the mapped address and port correspond to the current Teredo address. If this is not the case, the mapping has changed; the client must mark the old address as invalid and start using the new address.
当收到路由器广告时，客户应按照第5.2.1节的规定检查其有效性；无效的广告被悄悄地丢弃。如果播发有效，客户端必须检查映射的地址和端口是否与当前Teredo地址相对应。如果不是这样，则映射已更改；客户端必须将旧地址标记为无效，并开始使用新地址。
The Teredo client may have to send a bubble towards another Teredo client, either after a packet reception or after a transmission attempt, as explained in Sections 5.2.3 and 5.2.4. There are two kinds of bubbles: direct bubbles, which are sent directly to the mapped IPv4 address and mapped UDP port of the peer, and indirect bubbles, which are sent through the Teredo server of the peer.
Teredo客户端可能必须在数据包接收后或传输尝试后向另一Teredo客户端发送气泡，如第5.2.3和5.2.4节所述。有两种气泡：直接气泡，直接发送到对等方的映射IPv4地址和映射UDP端口；间接气泡，通过对等方的Teredo服务器发送。
When a Teredo client attempts to send a direct bubble, it extracts the mapped IPv4 address and mapped UDP port from the Teredo IPv6 address of the target. It then checks whether there is already an entry for this IPv6 address in the current list of peers. If there is no entry, the client MUST create a new list entry for the address, setting the last reception date and the last transmission date to 30 seconds before the current date, and the number of bubbles to zero.
Teredo客户端尝试发送直接气泡时，会从目标的Teredo IPv6地址提取映射的IPv4地址和映射的UDP端口。然后检查当前对等方列表中是否已存在此IPv6地址的条目。如果没有条目，客户端必须为地址创建新的列表条目，将上次接收日期和上次传输日期设置为当前日期前30秒，气泡数设置为零。
When a Teredo client attempts to send an indirect bubble, it extracts the Teredo server IPv4 address from the Teredo prefix of the IPv6 address of the target (different clients may be using different servers); the bubble will be sent to that IPv4 address and the Teredo UDP port.
当Teredo客户端尝试发送间接气泡时，它会从目标IPv6地址的Teredo前缀中提取Teredo服务器IPv4地址（不同的客户端可能使用不同的服务器）；气泡将被发送到该IPv4地址和Teredo UDP端口。
Bubbles may be lost in transit, and it is reasonable to enhance the reliability of the Teredo service by allowing multiple transmissions; however, bubbles will also be lost systematically in certain NAT configurations. In order to strike a balance between reliability and unnecessary retransmissions, we specify the following:
气泡可能在传输过程中丢失，通过允许多次传输来提高Teredo服务的可靠性是合理的；然而，在某些NAT配置中，气泡也会系统性地丢失。为了在可靠性和不必要的重新传输之间取得平衡，我们规定如下：
- The client MUST NOT send a bubble if the last transmission date and time is less than 2 seconds before the current date and time;
- 如果上次传输日期和时间比当前日期和时间早2秒，则客户端不得发送气泡；
- The client MUST NOT send a bubble if it has already sent 4 bubbles to the peer in the last 300 seconds without receiving a direct response.
- 如果客户端在过去300秒内已向对等方发送了4个气泡，但未收到直接响应，则客户端不得发送气泡。
In the other cases, the client MAY proceed with the transmission of the bubble. When transmitting the bubble, the client MUST update the last transmission date and time to that peer, and must also increment the number of transmitted bubbles.
在其他情况下，客户可以继续传输气泡。在传输气泡时，客户端必须向该对等方更新上次传输日期和时间，并且还必须增加传输气泡的数量。
In addition to the regular client resources described in the beginning of this section, the refresh interval determination procedure uses an additional UDP port, the Teredo secondary port, and the following variables:
除了本节开头所述的常规客户端资源外，刷新间隔确定过程还使用一个附加的UDP端口、Teredo次要端口和以下变量：
- Teredo secondary connectivity status, - Mapped address and port number of the Teredo secondary port, - Teredo secondary IPv6 prefix associated with the secondary port, - Teredo secondary IPv6 address derived from this prefix, - Date and time of the last interaction on the secondary port, - Maximum Teredo Refresh Interval. - Candidate Teredo Refresh Interval.
- Teredo次要连接状态，-Teredo次要端口的映射地址和端口号，-与次要端口关联的Teredo次要IPv6前缀，-从此前缀派生的Teredo次要IPv6地址，-次要端口上上次交互的日期和时间，-最大Teredo刷新间隔。-候选Teredo刷新间隔。
The secondary connectivity status, mapped address and prefix are determined by running the qualification procedure on the secondary port. When the client uses the interval determination procedure, the qualification procedure MUST be run for the secondary port immediately after running it on the service port. If the secondary qualification fails, the interval determination procedure will not be used, and the interval value will remain to the default value, 30 seconds. If the secondary qualification succeeds, the maximum refresh interval is set to 120 seconds, and the candidate Teredo refresh interval is set to 60 seconds, i.e., twice the Teredo refresh interval. The procedure is then performed at regular intervals, until it concludes:
辅助连接状态、映射地址和前缀通过在辅助端口上运行鉴定过程来确定。当客户端使用间隔确定过程时，必须在服务端口上运行辅助端口后立即对其运行鉴定过程。如果二次鉴定失败，将不使用间隔确定程序，间隔值将保持默认值30秒。如果二次鉴定成功，则最大刷新间隔设置为120秒，候选Teredo刷新间隔设置为60秒，即Teredo刷新间隔的两倍。然后定期执行该程序，直到结束：
1) wait until the candidate refresh interval is elapsed after the last interaction on the secondary port.
1) 等待，直到辅助端口上的最后一次交互后候选刷新间隔结束。
2) send a Teredo bubble to the Teredo secondary IPv6 address, through the service port.
2) 通过服务端口向Teredo辅助IPv6地址发送Teredo气泡。
3) wait for reception of the bubble on the secondary port. If a timer of 2 seconds elapses without reception, repeat step 2 at most three times. If there is still no reception, the candidate has failed; if there is a reception, the candidate has succeeded.
3) 等待在辅助端口上接收气泡。如果计时器持续2秒而未收到信号，则最多重复步骤2三次。如果仍然没有接收，则表示候选人失败；如果举行招待会，则表明候选人成功了。
4) if the candidate has succeeded, set the Teredo refresh interval to the candidate value, and set a new candidate value to the minimum of twice the new refresh interval, or the average of the refresh interval and the maximum refresh interval.
4) 如果候选已成功，请将Teredo刷新间隔设置为候选值，并将新候选值设置为新刷新间隔的最小值（或刷新间隔和最大刷新间隔的平均值）的两倍。
5) if the candidate has failed, set the maximum refresh interval to the candidate value. If the current refresh interval is larger than or equal to 75% of the maximum, the determination procedure has concluded; otherwise, set a new candidate value to the average of the refresh interval and the maximum refresh interval.
5) 如果候选者失败，请将最大刷新间隔设置为候选者值。如果当前刷新间隔大于或等于最大值的75%，则确定过程结束；否则，将新的候选值设置为刷新间隔和最大刷新间隔的平均值。
6) if the procedure has not concluded, perform the maintenance procedure on the secondary port, which will reset the date and time of the last interaction on the secondary port, and may result in the allocation of a new Teredo secondary IPv6 address; this would not affect the values of the refresh interval, candidate interval, or maximum refresh interval.
6) 如果该过程尚未结束，则在辅助端口上执行维护过程，这将重置辅助端口上最后一次交互的日期和时间，并可能导致分配新的Teredo辅助IPv6地址；这不会影响刷新间隔、候选间隔或最大刷新间隔的值。
The secondary port MUST NOT be used for any other purpose than the interval determination procedure. It should be closed when the procedure ends.
辅助端口不得用于间隔确定程序以外的任何其他用途。程序结束时，应将其关闭。
It is desirable to enable direct communication between Teredo clients that are located behind the same NAT, without forcing a systematic relay through a Teredo server. It is hard to design a general solution to this problem, but we can design a partial solution when the Teredo clients are connected through IPv4 to the same link.
希望能够在位于同一NAT后面的Teredo客户端之间实现直接通信，而无需通过Teredo服务器强制进行系统中继。很难为这个问题设计一个通用的解决方案，但是当Teredo客户端通过IPv4连接到同一链路时，我们可以设计一个部分解决方案。
A Teredo client who wishes to enable local discovery SHOULD join the IPv4 multicast group identified by Teredo IPv4 Discovery Address. The client SHOULD wait for discovery bubbles to be received on the Teredo IPv4 Discovery Address. The client SHOULD send local discovery bubbles to the Teredo IPv4 Discovery Address at random intervals, uniformly distributed between 200 and 300 seconds. A local Teredo bubble has the following characteristics:
希望启用本地发现的Teredo客户端应加入由Teredo IPv4发现地址标识的IPv4多播组。客户端应等待Teredo IPv4发现地址上接收到发现气泡。客户端应以随机间隔向Teredo IPv4发现地址发送本地发现气泡，均匀分布在200到300秒之间。局部Teredo气泡具有以下特征：
- IPv4 source address: the IPv4 address of the sender
- IPv4源地址：发送方的IPv4地址
- IPv4 destination address: the Teredo IPv4 Discovery Address
- IPv4目标地址：Teredo IPv4发现地址
- IPv4 ttl: 1
- IPv4 ttl:1
- UDP source port: the Teredo service port of the sender
- UDP源端口：发送方的Teredo服务端口
- UDP destination port: the Teredo UDP port
- UDP目标端口：Teredo UDP端口
- UDP payload: a minimal IPv6 packet, as follows
- UDP有效负载：最小IPv6数据包，如下所示
- IPv6 source: the global Teredo IPv6 address of the sender
- IPv6源：发送方的全局Teredo IPv6地址
- IPv6 destination: the all-nodes on-link multicast address
- IPv6目标：链路上的所有节点多播地址
- IPv6 payload type: 59 (No Next Header, as per [RFC2460])
- IPv6有效负载类型：59（根据[RFC2460]，无下一个标头）
- IPv6 payload length: 0
- IPv6有效负载长度：0
- IPv6 hop limit: 1
- IPv6跃点限制：1
The local discovery procedure carries a denial of service risk, as malevolent nodes could send fake bubbles to unsuspecting parties, and thus capture the traffic originating from these parties. The risk is mitigated by the filtering rules described in Section 5.2.5, and also by "link only" multicast scope of the Teredo IPv4 Discovery Address, which implies that packets sent to this address will not be forwarded across routers.
本地发现过程具有拒绝服务的风险，因为恶意节点可能会向不知情的方发送假气泡，从而捕获来自这些方的流量。通过第5.2.5节中描述的过滤规则以及Teredo IPv4发现地址的“仅链路”多播作用域（这意味着发送到此地址的数据包不会通过路由器转发），可以降低风险。
To benefit from the "link only multicast" protection, the clients should silently discard all local discovery bubbles that are received over a unicast address. To further mitigate the denial of service risk, the client MUST silently discard all local discovery bubbles whose IPv6 source address is not a well-formed Teredo IPv6 address, or whose IPv4 source address does not belong to the local IPv4 subnet; the client MAY decide to silently discard all local discovery bubbles whose Teredo IPv6 address do not include the same mapped IPv4 address as its own.
为了从“仅链路多播”保护中获益，客户端应该悄悄地丢弃通过单播地址接收的所有本地发现气泡。为了进一步降低拒绝服务风险，客户端必须静默地丢弃其IPv6源地址不是格式良好的Teredo IPv6地址或其IPv4源地址不属于本地IPv4子网的所有本地发现气泡；客户端可能会决定以静默方式放弃其Teredo IPv6地址不包含与其自己的映射IPv4地址相同的本地发现气泡。
If the bubble is accepted, the client checks whether there is an entry in the list of recent peers that correspond to the mapped IPv4 address and mapped UDP port associated with the source IPv6 address of the bubble. If there is such an entry, the client MUST update the local peer address and local peer port parameters to reflect the IPv4 source address and UDP source port of the bubble. If there is no entry, the client MUST create one, setting the local peer address and local peer port parameters to reflect the IPv4 source address and UDP source port of the bubble, the last reception date to the current date and time, the last transmission date to 30 seconds before the current date, and the number of bubbles to zero. The state of the entry is set to "not trusted".
如果接受了冒泡，则客户端将检查最近对等方列表中是否存在与冒泡的源IPv6地址关联的映射IPv4地址和映射UDP端口相对应的条目。如果存在这样的条目，客户端必须更新本地对等地址和本地对等端口参数，以反映冒泡的IPv4源地址和UDP源端口。如果没有条目，客户端必须创建一个条目，设置本地对等地址和本地对等端口参数，以反映气泡的IPv4源地址和UDP源端口，最后接收日期到当前日期和时间，最后传输日期到当前日期前30秒，气泡数为零。条目的状态设置为“不受信任”。
Upon reception of a discovery bubble, clients reply with a unicast bubble as specified in Section 5.2.3.
在接收到发现气泡后，客户机按照第5.2.3节的规定回复单播气泡。
The Teredo procedures are designed to enable direct connections between a Teredo host and a Teredo relay. Teredo hosts located behind a cone NAT will receive packets directly from relays; other Teredo hosts will learn the original addresses and UDP ports of third parties through the local Teredo server. In all of these cases, there is a risk that the IPv6 address of the source will be spoofed
Teredo程序旨在实现Teredo主机和Teredo继电器之间的直接连接。位于cone NAT后面的Teredo主机将直接从中继接收数据包；其他Teredo主机将通过本地Teredo服务器了解第三方的原始地址和UDP端口。在所有这些情况下，都存在源的IPv6地址被欺骗的风险
by a malevolent party. Teredo hosts must make two decisions, whether to accept the packet for local processing and whether to transmit further packets to the IPv6 address through the newly
被一个恶毒的政党杀害。Teredo主机必须做出两个决定，是否接受数据包进行本地处理，以及是否通过新的服务器将更多数据包传输到IPv6地址
learned IPv4 address and UDP port. The basic rule is that the hosts should be generous in what they accept and careful in what they send. Refusing to accept packets due to spoofing concerns would compromise connectivity and should only be done when there is a near certainty that the source address is spoofed. On the other hand, sending packets to the wrong address should be avoided.
了解IPv4地址和UDP端口。基本原则是，主人在接受时应该慷慨，在发送时应该谨慎。由于欺骗问题而拒绝接受数据包会损害连接，并且只有在几乎确定源地址被欺骗时才应这样做。另一方面，应该避免将数据包发送到错误的地址。
When the client wants to send a packet to a native IPv6 node or a 6to4 node, it should check whether a valid peer entry already exists for the IPv6 address of the destination. If this is not the case, the client will pick a random number (a nonce) and format an ICMPv6 Echo Request message whose source is the local Teredo address, whose destination is the address of the IPv6 node, and whose Data field is set to the nonce. (It is recommended to use a random number at least 64 bits long.) The nonce value and the date at which the packet was sent will be documented in a provisional peer entry for the IPV6 destination. The ICMPv6 packet will then be sent encapsulated in a UDP packet destined to the Teredo server IPv4 address and to the Teredo port. The rules of Section 5.2.3 specify how the reply to this packet will be processed.
当客户端希望向本机IPv6节点或6to4节点发送数据包时，它应该检查目标IPv6地址是否已经存在有效的对等条目。如果不是这样，客户端将选择一个随机数（nonce）并格式化ICMPv6回显请求消息，该消息的源是本地Teredo地址，目的地是IPv6节点的地址，其数据字段设置为nonce。（建议使用至少64位长的随机数。）当前值和数据包发送日期将记录在IPV6目标的临时对等条目中。然后，ICMPv6数据包将封装在UDP数据包中发送到Teredo服务器IPv4地址和Teredo端口。第5.2.3节的规则规定了如何处理对此数据包的回复。
The client procedures are designed to enable IPv6 connectivity through the most common types of NAT, which are commonly called "cone NAT" and "restricted cone NAT" [RFC3489]. Some NATs employ a different design; they are often called "symmetric NAT". The qualification algorithm in Section 5.2.1 will not succeed when the local NAT is a symmetric NAT.
客户端过程旨在通过最常见的NAT类型（通常称为“cone NAT”和“受限cone NAT”）实现IPv6连接[RFC3489]。一些NAT采用不同的设计；它们通常被称为“对称NAT”。当本地NAT是对称NAT时，第5.2.1节中的鉴定算法将不会成功。
In many cases, it is possible to work around the limitations of these NATs by explicitly reserving a UDP port for Teredo service on a client, using a function often called "DMZ" in the NAT's manual. This port will become the "service port" used by the Teredo hosts. The implementers of Teredo functions in hosts must make sure that the value of the service port can be explicitly provisioned, so that the user can provision the same value in the host and in the NAT.
在许多情况下，通过使用NAT手册中通常称为“DMZ”的函数，在客户端上为Teredo服务显式保留UDP端口，可以绕过这些NAT的限制。此端口将成为Teredo主机使用的“服务端口”。主机中Teredo函数的实现者必须确保可以显式地提供服务端口的值，以便用户可以在主机和NAT中提供相同的值。
The reservation procedure guarantees that the port mapping will remain the same for all destinations. After the explicit reservation, the qualification algorithm in Section 5.2.1 will succeed, and the Teredo client will behave as if behind a "cone NAT".
保留过程保证所有目的地的端口映射保持不变。明确保留后，第5.2.1节中的鉴定算法将成功，Teredo客户机的行为将如同在“cone NAT”后面一样。
When different clients use Teredo behind a single symmetric NAT, each of these clients must reserve and use a different service port.
当不同的客户端在单个对称NAT后面使用Teredo时，这些客户端中的每个都必须保留并使用不同的服务端口。
The Teredo server is designed to be stateless. The Teredo server waits for incoming UDP packets at the Teredo Port, using the IPv4 address that has been selected for the service. In addition, the server is able to receive and transmit some packets using a different IPv4 address and a different port number.
Teredo服务器设计为无状态。Teredo服务器使用为服务选择的IPv4地址在Teredo端口等待传入UDP数据包。此外，服务器能够使用不同的IPv4地址和不同的端口号接收和传输某些数据包。
The Teredo server acts as an IPv6 router. As such, it will receive Router Solicitation messages, to which it will respond with Router Advertisement messages as explained in Section 5.3.2. It may also receive other packets, for example, ICMPv6 messages and Teredo bubbles, which are processed according to the IPv6 specification.
Teredo服务器充当IPv6路由器。因此，它将接收路由器请求消息，并根据第5.3.2节中的解释，以路由器广告消息响应。它还可以接收根据IPv6规范处理的其他数据包，例如ICMPv6消息和Teredo气泡。
By default, the routing functions of the Teredo server are limited. Teredo servers are expected to relay Teredo bubbles, ICMPv6 Echo requests, and ICMPv6 Echo replies, but they are not expected to relay other types of IPv6 packets. Operators may, however, decide to combine the functions of "Teredo server" and "Teredo relay", as explained in Section 5.4.
默认情况下，Teredo服务器的路由功能是有限的。Teredo服务器应中继Teredo气泡、ICMPv6回显请求和ICMPv6回显回复，但不应中继其他类型的IPv6数据包。然而，运营商可决定将“Teredo服务器”和“Teredo中继”的功能结合起来，如第5.4节所述。
Before processing the packet, the Teredo server MUST check the validity of the encapsulated IPv6 source address, the IPv4 source address, and the UDP source port:
在处理数据包之前，Teredo服务器必须检查封装的IPv6源地址、IPv4源地址和UDP源端口的有效性：
1) If the UDP content is not a well-formed Teredo IPv6 packet, as defined in Section 5.1.1, the packet MUST be silently discarded.
1) 如果UDP内容不是第5.1.1节中定义的格式良好的Teredo IPv6数据包，则必须以静默方式丢弃该数据包。
2) If the UDP packet is not a Teredo bubble or an ICMPv6 message, it SHOULD be discarded. (The packet may be processed if the Teredo server also operates as a Teredo relay, as explained in Section 5.4.)
2) 如果UDP数据包不是Teredo气泡或ICMPv6消息，则应将其丢弃。（如第5.4节所述，如果Teredo服务器也作为Teredo中继运行，则可以处理数据包。）
3) If the IPv4 source address is not in the format of a global unicast address, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
3) 如果IPv4源地址的格式不是全局单播地址，则必须以静默方式丢弃数据包（有关全局单播地址的定义，请参阅第5.2.4节）。
4) If the IPv6 source address is an IPv6 link-local address, the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), and the packet contains an ICMPv6 Router Solicitation message, the packet MUST be accepted. It MUST be discarded if the server requires secure qualification and the authentication encapsulation is absent or verification fails.
4) 如果IPv6源地址是IPv6链路本地地址，IPv6目标地址是链路本地作用域所有路由器多播地址（FF02:：2），并且数据包包含ICMPv6路由器请求消息，则必须接受数据包。如果服务器需要安全鉴定，并且身份验证封装不存在或验证失败，则必须放弃该验证。
5) If the IPv6 source address is a Teredo IPv6 address, and if the IPv4 address and UDP port embedded in that address match the IPv4 source address and UDP source port, the packet SHOULD be accepted.
5) 如果IPv6源地址是Teredo IPv6地址，并且该地址中嵌入的IPv4地址和UDP端口与IPv4源地址和UDP源端口匹配，则应接受该数据包。
6) If the IPv6 source address is not a Teredo IPv6 address, and if the IPv6 destination address is a Teredo address allocated through this server, the packet SHOULD be accepted.
6) 如果IPv6源地址不是Teredo IPv6地址，并且IPv6目标地址是通过此服务器分配的Teredo地址，则应接受数据包。
7) In all other cases, the packet MUST be silently discarded.
7) 在所有其他情况下，必须悄悄地丢弃数据包。
The Teredo server will then check the IPv6 destination address of the encapsulated IPv6 packet:
Teredo服务器随后将检查封装的IPv6数据包的IPv6目标地址：
If the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), or the link-local address of the server, the Teredo server processes the packet; it may have to process Router Solicitation messages and ICMPv6 Echo Request messages.
如果IPv6目的地址是链路本地作用域所有路由器多播地址（FF02:：2）或服务器的链路本地地址，Teredo服务器处理数据包；它可能必须处理路由器请求消息和ICMPv6回显请求消息。
If the destination IPv6 address is not a global scope IPv6 address, the packet MUST NOT be forwarded.
如果目标IPv6地址不是全局作用域IPv6地址，则不得转发数据包。
If the destination address is not a Teredo IPv6 address, the packet should be relayed to the IPv6 Internet using regular IPv6 routing.
如果目标地址不是Teredo IPv6地址，则应使用常规IPv6路由将数据包中继到IPv6 Internet。
If the IPv6 destination address is a valid Teredo IPv6 address as defined in Section 2.13, the Teredo Server MUST check that the IPv4 address derived from this IPv6 address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded.
如果IPv6目标地址是第2.13节中定义的有效Teredo IPv6地址，Teredo服务器必须检查从该IPv6地址派生的IPv4地址是否为全局单播地址格式；如果不是这样，则必须悄悄地丢弃数据包。
If the address is valid, the Teredo server encapsulates the IPv6 packet in a new UDP datagram, in which the following parameters are set:
如果地址有效，Teredo服务器将IPv6数据包封装在新的UDP数据报中，其中设置了以下参数：
- The destination IPv4 address is derived from the IPv6 destination.
- 目标IPv4地址派生自IPv6目标。
- The source IPv4 address is the Teredo server IPv4 address.
- 源IPv4地址是Teredo服务器IPv4地址。
- The destination UDP port is derived from the IPv6 destination.
- 目标UDP端口派生自IPv6目标。
- The source UDP port is set to the Teredo UDP Port.
- 源UDP端口设置为Teredo UDP端口。
If the destination IPv6 address is a Teredo client whose address is serviced by this specific server, the server should insert an origin indication in the first bytes of the UDP payload, as specified in Section 5.1.1. (To verify that the client is served by this server, the server compares bits 32-63 of the client's Teredo IPv6 address to the server's IPv4 address.)
如果目标IPv6地址是Teredo客户端，其地址由该特定服务器提供服务，则服务器应按照第5.1.1节的规定，在UDP有效负载的第一个字节中插入原点指示。（为了验证客户端是否由该服务器提供服务，服务器将客户端的Teredo IPv6地址的32-63位与服务器的IPv4地址进行比较。）
When the Teredo server receives a Router Solicitation message (RS, [RFC2461]), it retains the IPv4 address and UDP port from which the solicitation was received; these become the Teredo mapped address and Teredo mapped port of the client. The router uses these values to compose the origin indication encapsulation that will be sent with the response to the solicitation.
当Teredo服务器接收到路由器请求消息（RS[RFC2461]）时，它保留接收请求的IPv4地址和UDP端口；这些将成为客户端的Teredo映射地址和Teredo映射端口。路由器使用这些值组成将与请求响应一起发送的原点指示封装。
The Teredo server responds to the router solicitation by sending a Router Advertisement message [RFC2461]. The router advertisement MUST advertise the Teredo IPv6 prefix composed from the service
Teredo服务器通过发送路由器广告消息[RFC2461]来响应路由器请求。路由器播发必须播发由服务组成的Teredo IPv6前缀
prefix and the server's IPv4 address. The IPv6 source address should be set to a Teredo link-local server address associated to the local interface; this address is derived from the IPv4 address of the server and from the Teredo port, as specified in Section 4; the cone bit is set to 1. The IPv6 destination address is set to the IPv6 source address of the RS. The Router Advertisement message must be sent over UDP to the Teredo mapped address and Teredo mapped port of the client; the IPv4 source address and UDP source port should be set to the server's IPv4 address and Teredo Port. If the cone bit of the client's IPv6 address is set to 1, the RA must be sent from a different IPv4 source address than the server address over which the RS was received; if the cone bit is set to zero, the response must be sent back from the same address.
前缀和服务器的IPv4地址。IPv6源地址应设置为与本地接口关联的Teredo链路本地服务器地址；如第4节所述，此地址源自服务器的IPv4地址和Teredo端口；牙轮钻头设置为1。IPv6目标地址设置为RS的IPv6源地址。路由器广告消息必须通过UDP发送到客户端的Teredo映射地址和Teredo映射端口；IPv4源地址和UDP源端口应设置为服务器的IPv4地址和Teredo端口。如果客户端IPv6地址的锥形位设置为1，则必须从不同于接收RS的服务器地址的IPv4源地址发送RA；如果锥形位设置为零，则必须从同一地址发回响应。
Before sending the packet, the Teredo server MUST check that the IPv4 destination address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
在发送数据包之前，Teredo服务器必须检查IPv4目标地址是否为全局单播地址格式；如果不是这种情况，则必须以静默方式丢弃数据包（有关全局单播地址的定义，请参阅第5.2.4节）。
If secure qualification is required, the server MUST insert a valid authentication parameter in the UDP packet carrying the router advertisement. The client identifier and the nonce value used in the authentication parameter MUST be the same identifier and nonce as received in the router solicitation. The confirmation byte MUST be set to zero if the client identifier is still valid, and a non-null value otherwise; the authentication value SHOULD be computed using the secret that corresponds to the client identifier.
如果需要安全认证，服务器必须在承载路由器公告的UDP数据包中插入有效的身份验证参数。身份验证参数中使用的客户端标识符和nonce值必须与路由器请求中接收的标识符和nonce相同。如果客户端标识符仍然有效，则确认字节必须设置为零，否则为非空值；应该使用与客户端标识符相对应的密码来计算身份验证值。
Teredo relays are IPv6 routers that advertise reachability of the Teredo service IPv6 prefix through the IPv6 routing protocols. (A minimal Teredo relay may serve just a local host, and would not advertise the prefix beyond this host.) Teredo relays will receive IPv6 packets bound to Teredo clients. Teredo relays should be able
Teredo中继是IPv6路由器，通过IPv6路由协议公布Teredo服务IPv6前缀的可达性。（最小Teredo中继可能仅服务于本地主机，并且不会在该主机之外播发前缀。）Teredo中继将接收绑定到Teredo客户端的IPv6数据包。Teredo继电器应能够
to receive packets sent over IPv4 and UDP by Teredo clients; they may apply filtering rules, e.g., only accept packets from Teredo clients if they have previously sent traffic to these Teredo clients.
接收Teredo客户端通过IPv4和UDP发送的数据包；他们可以应用过滤规则，例如，如果他们以前向Teredo客户端发送过流量，则只接受Teredo客户端的数据包。
The receiving and sending rules used by Teredo relays are very similar to those of Teredo clients. Teredo relays must use a Teredo service port to transmit packets to Teredo clients; they must maintain a "list of peers", identical to the list of peers maintained by Teredo clients.
Teredo中继使用的接收和发送规则与Teredo客户端非常相似。Teredo中继必须使用Teredo服务端口向Teredo客户端传输数据包；他们必须维护一个“对等点列表”，与Teredo客户端维护的对等点列表相同。
When a Teredo relay has to transmit a packet to a Teredo client, it examines the destination IPv6 address. By definition, the Teredo relays will only send over UDP IPv6 packets whose IPv6 destination address is a valid Teredo IPv6 address.
当Teredo中继必须向Teredo客户端传输数据包时，它会检查目标IPv6地址。根据定义，Teredo中继将仅通过IPv6目标地址为有效Teredo IPv6地址的UDP IPv6数据包发送。
Before processing these packets, the Teredo Relay MUST check that the IPv4 destination address embedded in the Teredo IPv6 address is in the format of a global unicast address; if this is not the case, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
在处理这些数据包之前，Teredo中继必须检查嵌入Teredo IPv6地址中的IPv4目标地址是否为全局单播地址格式；如果不是这种情况，则必须以静默方式丢弃数据包（有关全局单播地址的定义，请参阅第5.2.4节）。
The relay then checks if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid. The relay then performs the following:
然后，中继检查最近Teredo对等点列表中是否有此IPv6地址的条目，以及该条目是否仍然有效。然后，继电器执行以下操作：
1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the mapped IPv4 address and mapped UDP port of the entry. The relay updates the date of last transmission in the peer entry.
1) 如果对等方列表中有该IPv6地址的条目，并且该条目的状态设置为“受信任”，则应通过UDP将IPv6数据包发送到该条目的映射IPv4地址和映射UDP端口。中继更新对等条目中最后一次传输的日期。
2) If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address.
2) 如果对等方列表中没有受信任的条目，并且如果目标是Teredo IPv6地址，其中cone位设置为1，则通过UDP将数据包发送到映射的IPv4地址，并从该IPv6地址提取映射的UDP端口。
3) If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 0, the Teredo relay creates a bubble whose source address is set to a local IPv6 address, and whose destination address is set to the Teredo IPv6 address of the packet's destination. The bubble is sent to the server address corresponding to the Teredo destination. The entry becomes trusted when a bubble or another packet is received from this IPv6 address; if no such packet is received before a time-out of 2 seconds, the Teredo relay may repeat the bubble, up to three times. If the relay fails to receive a bubble after these
3) 如果对等方列表中没有受信任的条目，并且如果目的地是Teredo IPv6地址，其中锥形位设置为0，Teredo中继将创建一个气泡，其源地址设置为本地IPv6地址，其目的地地址设置为数据包目的地的Teredo IPv6地址。气泡被发送到Teredo目标对应的服务器地址。当从该IPv6地址接收到气泡或另一个数据包时，该条目变得可信；如果在2秒的超时之前没有收到这样的数据包，Teredo中继可能会重复气泡，最多三次。如果继电器在这些操作之后没有接收到气泡
repetitions, the entry is removed from the list of peers. The relay MAY queue packets bound to untrusted entries; the queued packets SHOULD be de-queued and forwarded when the entry becomes trusted; they SHOULD be deleted if the entry is deleted. To avoid denial of service attacks, the relays SHOULD limit the number of packets in such queues.
重复，该条目将从对等项列表中删除。中继可以对绑定到不可信条目的数据包进行排队；当条目变得可信时，应将排队的数据包解排队并转发；如果条目被删除，则应将其删除。为避免拒绝服务攻击，中继应限制此类队列中的数据包数量。
In cases 2 and 3, the Teredo relay should create a peer entry for the IPv6 address; the entry status is marked as trusted in case 2 (cone NAT) and not trusted in case 3. In case 3, if the Teredo relay happens to be located behind a non-cone NAT, it should also send a bubble directly to the mapped IPv4 address and mapped port number of the Teredo destination. This will "open the path" for the return bubble from the Teredo client.
在情况2和3中，Teredo中继应为IPv6地址创建对等条目；在案例2中，条目状态标记为受信任（cone NAT），在案例3中标记为不受信任。在案例3中，如果Teredo中继恰好位于非cone NAT后面，它还应该直接向Teredo目的地的映射IPv4地址和映射端口号发送气泡。这将为Teredo客户端的返回气泡“打开路径”。
For reliability reasons, relays MAY decide to ignore the value of the cone bit in the flag, and always perform the "case 3", i.e., treat all Teredo peers as if they were located behind a non-cone NAT. This will result in some increase in traffic, but may avoid
出于可靠性原因，继电器可能决定忽略标志中锥形位的值，并始终执行“情况3”，即，将所有Teredo对等点视为位于非锥形NAT后面。这将导致流量增加，但可能会避免
reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, relays MAY also decide to always send a direct bubble to the mapped IPv4 address and mapped port number of the Teredo destination, even if they do not believe that they are located behind a non-cone NAT.
如果NAT状态的确定由于某种原因出错，则会出现可靠性问题。出于同样的原因，中继也可能决定始终向Teredo目的地的映射IPv4地址和映射端口号发送直接气泡，即使它们不相信自己位于非cone NAT后面。
The Teredo relay may receive packets from Teredo clients; the packets should normally only be sent by clients to which the relay previously transmitted packets, i.e., clients whose IPv6 address is present in the list of peers. Relays, like clients, use the packet reception procedure to maintain the date and time of the last interaction with the Teredo server and the "list of recent peers".
Teredo中继可以从Teredo客户端接收分组；数据包通常只应由中继先前向其发送数据包的客户端发送，即，对等方列表中存在IPv6地址的客户端。中继与客户端一样，使用数据包接收过程来维护与Teredo服务器最后一次交互的日期和时间以及“最近的对等方列表”。
When a UDP packet is received over the Teredo service port, the Teredo relay checks that it contains a valid IPv6 packet as specified in [RFC2460]. If this is not the case, the packet is silently discarded.
当通过Teredo服务端口接收到UDP数据包时，Teredo中继将检查其是否包含[RFC2460]中指定的有效IPv6数据包。如果情况并非如此，则数据包将被悄悄丢弃。
Then, the Teredo relay examines whether the IPv6 source address is a valid Teredo address, and if the mapped IPv4 address and mapped port match the IPv4 source address and port number from which the packet is received. If this is not the case, the packet is silently discarded.
然后，Teredo中继检查IPv6源地址是否为有效的Teredo地址，以及映射的IPv4地址和映射的端口是否与接收数据包的IPv4源地址和端口号匹配。如果情况并非如此，则数据包将被悄悄丢弃。
The Teredo relay then examines whether there is an entry for the IPv6 source address in the list of recent peers. If this is not the case,
Teredo中继然后检查最近的对等方列表中是否有IPv6源地址条目。如果不是这样的话，
the packet may be silently discarded. If this is the case, the entry status is set to "trusted"; the relay updates the "date and time of the last interaction" to the current date and time.
数据包可能会被悄悄地丢弃。如果是这种情况，则条目状态设置为“受信任”；中继将“上次交互的日期和时间”更新为当前日期和时间。
Finally, the relay examines the destination IPv6 address. If the destination belongs to a range of IPv6 addresses served by the relay, the packet SHOULD be accepted and forwarded to the destination. In the other cases, the packet SHOULD be silently discarded.
最后，中继检查目标IPv6地址。如果目的地属于中继服务的IPv6地址范围，则应接受数据包并将其转发到目的地。在其他情况下，数据包应该被悄悄地丢弃。
Because Teredo servers can relay Teredo packets over IPv6, all Teredo servers must be capable of behaving as Teredo relays. There is, however, no requirement that Teredo relays behave as Teredo servers.
因为Teredo服务器可以通过IPv6中继Teredo数据包，所以所有Teredo服务器都必须能够像Teredo中继一样工作。但是，没有要求Teredo中继的行为与Teredo服务器相同。
The dual role of server and relays implies an additional complexity for the programming of servers: the processing of incoming packets should be a combination of the server processing rules defined in Section 5.3.1, and the relay processing rules defined in Section 5.4.2. (Section 5.3 only specifies the rules implemented by a pure server, not a combination relay+server.)
服务器和中继的双重作用意味着服务器编程的额外复杂性：传入数据包的处理应结合第5.3.1节中定义的服务器处理规则和第5.4.2节中定义的中继处理规则。（第5.3节仅规定了由纯服务器实现的规则，而不是中继+服务器的组合。）
Teredo is designed as an interim transition mechanism, and it is important that it should not be used any longer than necessary. The "sunset" procedure will be implemented by Teredo clients, servers, and relays, as specified in this section.
Teredo被设计为一种临时过渡机制，重要的是，它的使用时间不应超过必要的时间。“日落”程序将由Teredo客户端、服务器和继电器执行，如本节所述。
The Teredo-capable nodes MUST NOT behave as Teredo clients if they already have IPv6 connectivity through any other means, such as native IPv6 connectivity. In particular, nodes that have a global IPv4 address SHOULD obtain connectivity through the 6to4 service rather than through the Teredo service. The classic reason why a node that does not need connectivity would still enable the Teredo service is to guarantee good performance when interacting with Teredo clients; however, a Teredo-capable node that has IPv4 connectivity and that has obtained IPv6 connectivity outside the Teredo service MAY decide to behave as a Teredo relay, and still obtain good performance when interacting with Teredo clients.
如果支持Teredo的节点已经通过任何其他方式（如本机IPv6连接）实现了IPv6连接，则这些节点不得表现为Teredo客户端。特别是，具有全局IPv4地址的节点应通过6to4服务而不是Teredo服务获得连接。不需要连接的节点仍然可以启用Teredo服务的经典原因是，在与Teredo客户端交互时，要保证良好的性能；但是，具有IPv4连接且在Teredo服务之外获得IPv6连接的Teredo功能节点可能决定充当Teredo中继，并且在与Teredo客户端交互时仍能获得良好的性能。
The Teredo servers are expected to participate in the sunset procedure by announcing a date at which they will stop providing the service. This date depends on the availability of alternative solutions to their clients, such as "dual-mode" gateways that behave simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers will not be expected to operate more than a few years. Teredo relays are expected to have the same life span as Teredo servers.
Teredo服务器预计将通过宣布停止提供服务的日期来参与日落程序。这一日期取决于其客户端是否有替代解决方案，如同时充当IPv4 NAT和IPv6路由器的“双模”网关。大多数Teredo服务器预计运行时间不会超过几年。Teredo继电器预期与Teredo服务器具有相同的寿命。
Teredo defines a NAT traversal solution that can be provided using very little resource at the server. Ongoing IETF discussions have outlined the need for both a solution like Teredo and a more controlled NAT traversal solution, using configured tunnels to a service provider [RFC3904]. This section provides a tentative analysis of how Teredo could be extended to also support a configured tunnel service.
Teredo定义了一个NAT遍历解决方案，它可以在服务器上使用很少的资源来提供。正在进行的IETF讨论概述了对Teredo这样的解决方案和更可控的NAT穿越解决方案的需求，该解决方案使用到服务提供商的配置隧道[RFC3904]。本节对Teredo如何扩展以支持已配置的隧道服务进行了初步分析。
It may be possible to design a tunnel server protocol that is compatible with Teredo, in the sense that the same client could be used either in the Teredo service or with a tunnel service. In fact, this could be done by configuring the client with:
设计与Teredo兼容的隧道服务器协议是可能的，因为同一客户机既可以用于Teredo服务，也可以用于隧道服务。事实上，这可以通过配置客户端来实现：
- The IPv4 address of a Teredo server that acts as a tunnel broker - A client identifier - A shared secret with that server - An agreed-upon authentication algorithm.
- 充当隧道代理的Teredo服务器的IPv4地址—客户端标识符—与该服务器共享的秘密—商定的身份验证算法。
The Teredo client would use the secure qualification procedure, as specified in Section 5.2.2. Instead of returning a Teredo prefix in the router advertisement, the server would return a globally routable IPv6 prefix; this prefix could be permanently assigned to the client, which would provide the client with a stable address. The server would have to keep state, i.e., memorize the association between the prefix assigned to the client and the mapped IPv4 address and mapped UDP port of the client.
Teredo客户将使用第5.2.2节规定的安全鉴定程序。服务器将返回全局可路由IPv6前缀，而不是在路由器公告中返回Teredo前缀；这个前缀可以永久地分配给客户机，这将为客户机提供一个稳定的地址。服务器必须保持状态，即存储分配给客户端的前缀与客户端的映射IPv4地址和映射UDP端口之间的关联。
The Teredo server would advertise reachability of the client prefix to the IPv6 Internet. Any packet bound to that prefix would be transmitted to the mapped IPv4 address and mapped UDP port of the client.
Teredo服务器将向IPv6 Internet公布客户端前缀的可达性。绑定到该前缀的任何数据包都将被传输到客户端的映射IPv4地址和映射UDP端口。
The Teredo client, when it receives the prefix, would notice that this prefix is a global IPv6 prefix, not in the form of a Teredo prefix. The client would at that point recognize that it should operate in tunnel mode. A client that operates in tunnel mode would execute a much simpler transmission procedure: it would forward any packet sent to the Teredo interface to the IPv4 address and Teredo UDP port of the server.
Teredo客户端在收到前缀时会注意到该前缀是全局IPv6前缀，而不是Teredo前缀的形式。此时，客户将认识到它应该在隧道模式下运行。在隧道模式下运行的客户端将执行一个简单得多的传输过程：它将发送到Teredo接口的任何数据包转发到服务器的IPv4地址和Teredo UDP端口。
The Teredo client would have to perform the maintenance procedure described in Section 5.2.5. The server would receive the router solicitation, and could notice a possible change of mapped IPv4 address and mapped UDP port that could result from the reconfiguration of the mappings inside the NAT. The server should continue advertising the same IPv6 prefix to the client, and should
Teredo客户必须执行第5.2.5节所述的维护程序。服务器将接收路由器请求，并可能注意到映射IPv4地址和映射UDP端口的可能更改，这可能是由于NAT内映射的重新配置造成的。服务器应继续向客户端播发相同的IPv6前缀，并且应
update the mapped IPv4 address and mapped UDP port associated to this prefix, if necessary.
如有必要，更新与此前缀关联的映射IPv4地址和映射UDP端口。
There is as yet no consensus that a tunnel-mode extension to Teredo should be developed. This section is only intended to provide suggestions to the future developers of such services. Many details would probably have to be worked out before a tunnel-mode extension would be agreed upon.
到目前为止，还没有达成共识，即应该开发Teredo的隧道模式扩展。本节仅为此类服务的未来开发者提供建议。在商定隧道模式扩展之前，可能需要制定许多细节。
The main objective of Teredo is to provide nodes located behind a NAT with a globally routable IPv6 address. The Teredo nodes can use IP security (IPsec) services such as Internet Key Exchange (IKE), Authentication Header (AH), or Encapsulation Security Payload (ESP) [RFC4306, RFC4302, RFC4303], without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947]. As such, we can argue that the service has a positive effect on network security. However, the security analysis must also envisage the negative effects of the Teredo services, which we can group in four categories: security risks of directly connecting a node to the IPv6 Internet, spoofing of Teredo servers to enable a man-in-the-middle attack, potential attacks aimed at denying the Teredo service to a Teredo client, and denial of service attacks against non-Teredo participating nodes that would be enabled by the Teredo service.
Teredo的主要目标是为位于NAT后面的节点提供一个全局可路由的IPv6地址。Teredo节点可以使用IP安全（IPsec）服务，例如Internet密钥交换（IKE）、身份验证头（AH）或封装安全有效负载（ESP）[RFC4306、RFC4302、RFC4303]，而无需“IKE中NAT遍历的协商”[RFC3947]中仍然存在的配置限制。因此，我们可以说该服务对网络安全有积极的影响。但是，安全分析还必须考虑Teredo服务的负面影响，我们可以将其分为四类：直接将节点连接到IPv6 Internet的安全风险、欺骗Teredo服务器以实现中间人攻击、旨在拒绝Teredo客户端使用Teredo服务的潜在攻击、，以及针对Teredo服务启用的非Teredo参与节点的拒绝服务攻击。
In the following, we review in detail these four types of issues, and we present mitigating strategies for each of them.
在下文中，我们将详细回顾这四种类型的问题，并针对每种问题提出缓解策略。
The very purpose of the Teredo service is to make a machine reachable through IPv6. By definition, the machine using the service will give up whatever firewall service was available in the NAT box, however limited this service may be [RFC2993]. The services that listen to the Teredo IPv6 address will become the potential target of attacks from the entire IPv6 Internet. This may sound scary, but there are three mitigating factors.
Teredo服务的真正目的是使机器可以通过IPv6访问。根据定义，使用该服务的机器将放弃NAT盒中可用的任何防火墙服务，无论该服务多么有限[RFC2993]。侦听Teredo IPv6地址的服务将成为整个IPv6 Internet的潜在攻击目标。这听起来可能很可怕，但有三个缓解因素。
The first mitigating factor is the possibility to restrict some services to only accept traffic from local neighbors, e.g., using link-local addresses. Teredo does not support communication using link-local addresses. This implies that link-local services will not be accessed through Teredo, and will be restricted to whatever other IPv6 connectivity may be available, e.g., direct traffic with neighbors on the local link, behind the NAT.
第一个缓解因素是可能限制某些服务仅接受来自本地邻居的流量，例如使用链路本地地址。Teredo不支持使用链接本地地址进行通信。这意味着链路本地服务将不会通过Teredo访问，并且将被限制为任何其他可用的IPv6连接，例如，与NAT后面本地链路上的邻居直接通信。
The second mitigating factor is the possible use of a "local firewall" solution, i.e., a piece of software that performs locally the kind of inspection and filtering that is otherwise performed in a perimeter firewall. Using such software is recommended.
第二个缓解因素是可能使用“本地防火墙”解决方案，即在本地执行在外围防火墙中执行的检查和过滤的软件。建议使用此类软件。
The third mitigating factor is the availability of IP security (IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303]. Using these services in conjunction with Teredo is a good policy, as it will protect the client from possible attacks in intermediate servers such as the NAT, the Teredo server, or the Teredo relay. (However, these services can be used only if the parties in the communication can negotiate a key, which requires agreeing on some credentials; this is known to be a hard problem.)
第三个缓解因素是IP安全（IPsec）服务的可用性，如IKE、AH或ESP[RFC4306、RFC4302、RFC4303]。将这些服务与Teredo结合使用是一个很好的策略，因为它可以保护客户端免受中间服务器（如NAT、Teredo服务器或Teredo中继）中可能的攻击。（但是，只有当通信双方可以协商密钥时，才能使用这些服务，这需要就某些凭据达成一致；这是一个众所周知的难题。）
The goal of the Teredo service is to provide hosts located behind a NAT with a globally reachable IPv6 address. There is a possible class of attacks against this service in which an attacker somehow intercepts the router solicitation, responds with a spoofed router advertisement, and provides a Teredo client with an incorrect address. The attacker may have one of two objectives: it may try to deny service to the Teredo client by providing it with an address that is in fact unreachable, or it may try to insert itself as a relay for all client communications, effectively enabling a variety of "man-in-the-middle" attack.
Teredo服务的目标是为位于NAT后面的主机提供一个全局可访问的IPv6地址。此服务可能受到一类攻击，其中攻击者以某种方式拦截路由器请求，以伪造的路由器广告进行响应，并向Teredo客户端提供不正确的地址。攻击者可能有两个目标之一：它可能试图通过向Teredo客户端提供实际上无法访问的地址来拒绝向其提供服务，或者它可能试图将自身插入所有客户端通信的中继，从而有效地启用各种“中间人”攻击。
The simple nonce verification procedure described in Section 5.2.2 provides a first level of protection against attacks in which a third party tries to spoof the server. In practice, the nonce procedure can be defeated only if the attacker is "on path".
第5.2.2节中描述的简单的nonce验证过程提供了一级保护，防止第三方试图欺骗服务器的攻击。实际上，只有当攻击者“在路径上”时，nonce过程才能失败。
If client and server share a secret and agree on an authentication algorithm, the secure qualification procedure described in Section 5.2.2 provides further protection. To defeat this protection, the attacker could try to obtain a copy of the secret shared between client and server. The most likely way to obtain the shared secret is to listen to the traffic and mount an offline dictionary attack; to protect against this attack, the secret shared between client and server should contain sufficient entropy. (This probably requires some automated procedure for provisioning the shared secret and the algorithm.)
如果客户机和服务器共享一个秘密并就认证算法达成一致，则第5.2.2节所述的安全鉴定程序将提供进一步的保护。若要破坏此保护，攻击者可以尝试获取客户端和服务器之间共享的机密副本。获取共享秘密的最有可能的方法是监听流量并发起脱机字典攻击；为了防止这种攻击，客户端和服务器之间共享的秘密应该包含足够的熵。（这可能需要一些自动过程来提供共享机密和算法。）
If the shared secret contains sufficient entropy, the attacker would have to defeat the one-way function used to compute the authentication value. This specification suggests a default
如果共享秘密包含足够的熵，则攻击者必须击败用于计算身份验证值的单向函数。此规范建议使用默认值
algorithm combining HMAC and MD5. If the protection afforded by MD5 was not deemed sufficient, clients and servers can agree to use a different algorithm, e.g., SHA1.
结合HMAC和MD5的算法。如果MD5提供的保护不充分，客户机和服务器可以同意使用不同的算法，例如SHA1。
Another way to defeat the protection afforded by the authentication procedure is to mount a complex attack, as follows:
另一种破坏身份验证过程提供的保护的方法是发起复杂的攻击，如下所示：
1) Client prepares router solicitation, including authentication encapsulation.
1) 客户端准备路由器请求，包括身份验证封装。
2) Attacker intercepts the solicitation, and somehow manages to prevent it from reaching the server, for example, by mounting a short-duration DoS attack against the server.
2) 攻击者截获请求，并以某种方式设法阻止其到达服务器，例如，通过对服务器发起短时间的DoS攻击。
3) Attacker replaces the source IPv4 address and source UDP port of the request by one of its own addresses and port, and forwards the modified request to the server.
3) 攻击者将请求的源IPv4地址和源UDP端口替换为自己的地址和端口之一，并将修改后的请求转发给服务器。
4) Server dutifully notes the IPv4 address from which the packet is received, verifies that the Authentication encapsulation is correct, prepares a router advertisement, signs it, and sends it back to the incoming address, i.e., the attacker.
4) 服务器尽职尽责地记录从中接收数据包的IPv4地址，验证身份验证封装是否正确，准备路由器公告，对其签名，并将其发送回传入地址，即攻击者。
5) Attacker receives the advertisement, takes note of the mapping, replaces the IPv4 address and UDP port by the original values in the intercepted message, and sends the response to the client.
5) 攻击者接收广告，注意映射，用截获消息中的原始值替换IPv4地址和UDP端口，并将响应发送给客户端。
6) Client receives the advertisement, notes that the authentication header is present and is correct, and uses the proposed prefix and the mapped addresses in the origin indication encapsulation.
6) 客户端接收广告，注意到身份验证标头存在且正确，并在源指示封装中使用建议的前缀和映射的地址。
The root cause of the problem is that the NAT is, in itself, a man-in-the-middle attack. The Authentication encapsulation covers the encapsulated IPv6 packet, but does not cover the encapsulating IPv4 header and UDP header. It is very hard to devise an effective authentication scheme, since the attacker does not do anything else than what the NAT legally does!
问题的根本原因是NAT本身就是一个中间人攻击。身份验证封装包括封装的IPv6数据包，但不包括封装的IPv4报头和UDP报头。设计一个有效的身份验证方案是非常困难的，因为攻击者除了NAT合法地做什么之外，什么都不做！
However, there are several mitigating factors that lead us to avoid worrying too much about this attack. In practice, the gain from the attack is either to deny service to the client or to obtain a "man-in-the-middle" position. However, in order to mount the attack, the attacker must be able to suppress traffic originating from the client, i.e., have denial of service capability; the attacker must also be able to observe the traffic exchanged between client and inject its own traffic in the mix, i.e., have man-in-the-middle capacity. In summary, the attack is very hard to mount, and the gain for the attacker in terms of "elevation of privilege" is minimal.
然而，有几个缓解因素使我们避免过度担心这次袭击。实际上，攻击的好处要么是拒绝向客户提供服务，要么是获得一个“中间人”的位置。但是，为了发起攻击，攻击者必须能够抑制来自客户端的流量，即具有拒绝服务能力；攻击者还必须能够观察客户端之间交换的流量，并在混合中注入自己的流量，即具有中间人容量。总之，攻击很难发动，攻击者在“提升权限”方面的收益很小。
A similar attack is described in detail in the security section of [RFC3489].
[RFC3489]的安全部分详细描述了类似的攻击。
An attacker may try to use Teredo either to pass itself for another IPv6 host or to place itself as a man-in-the-middle between a Teredo host and a native IPv6 host. The attacker will mount such attacks by spoofing a Teredo relay, i.e., by convincing the Teredo host that packets bound to the native IPv6 host should be relayed to the IPv4 address of the attacker.
攻击者可能试图使用Teredo将自己传递给另一台IPv6主机，或将自己作为介于Teredo主机和本机IPv6主机之间的中间人。攻击者将通过欺骗Teredo中继（即，通过说服Teredo主机绑定到本机IPv6主机的数据包应中继到攻击者的IPv4地址）来发起此类攻击。
The possibility of the attack derives from the lack of any algorithmic relation between the IPv4 address of a relay and the native IPv6 addresses served by these relay. A Teredo host cannot decide just by looking at the encapsulating IPv4 and UDP header whether or not a relay is legitimate. If a Teredo host decided to simply trust the incoming traffic, it would easily fall prey to a relay-spoofing attack.
攻击的可能性源于中继的IPv4地址与这些中继所服务的本机IPv6地址之间缺乏任何算法关系。Teredo主机不能仅仅通过查看封装的IPv4和UDP报头来决定中继是否合法。如果Teredo主机决定只信任传入的流量，它很容易成为中继欺骗攻击的牺牲品。
The attack is mitigated by the "direct IPv6 connectivity test" specified in Section 5.2.9. The test specifies a relay discovery procedure secured by a nonce. The nonce is transmitted from the Teredo host to the destination through Teredo server, which the client normally trusts. The response arrives through the "natural" relay, i.e., the relay closest to the IPv6 destination. Sending traffic to this relay will place it out of reach of attackers that are not on the direct path between the Teredo host and its IPv6 peer.
通过第5.2.9节中指定的“直接IPv6连接测试”，可以减轻攻击。该测试指定了由nonce保护的中继发现过程。nonce通过客户机通常信任的Teredo服务器从Teredo主机传输到目标。响应通过“自然”中继到达，即距离IPv6目标最近的中继。将流量发送到此中继将使Teredo主机与其IPv6对等方之间不在直接路径上的攻击者无法访问该中继。
End-to-end security protections are required to defend against spoofing attacks if the attacker is on the direct path between the Teredo host and its peer.
如果攻击者位于Teredo主机与其对等机之间的直接路径上，则需要端到端安全保护来抵御欺骗攻击。
The most effective line of defense of a Teredo client is probably not to try to secure the Teredo service itself: even if the mapping can be securely obtained, the attacker would still be able to listen to the traffic and send spoofed packets. Rather, the Teredo client should realize that, because it is located behind a NAT, it is in a
Teredo客户端最有效的防线可能是不要尝试保护Teredo服务本身：即使可以安全地获得映射，攻击者仍然能够侦听流量并发送伪造的数据包。相反，Teredo客户机应该意识到，因为它位于NAT后面，所以它位于
situation of vulnerability; it should systematically try to encrypt its IPv6 traffic, using IPsec. Even if the IPv4 and UDP headers are vulnerable, the use of IPsec will effectively prevent spoofing and listening of the IPv6 packets by third parties. By providing each client with a global IPv6 address, Teredo enables the use of IPsec
脆弱性状况；它应该系统地尝试使用IPsec加密其IPv6流量。即使IPv4和UDP报头易受攻击，IPsec的使用也将有效防止第三方欺骗和侦听IPv6数据包。通过为每个客户端提供全局IPv6地址，Teredo支持使用IPsec
without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the security of these clients.
没有“IKE中NAT遍历的协商”[RFC3947]中仍然存在的配置限制，并最终增强了这些客户端的安全性。
Our analysis outlines five ways to attack the Teredo service. There are countermeasures for each of these attacks.
我们的分析概述了攻击Teredo服务的五种方法。每种攻击都有相应的对策。
An attack can be mounted on the IPv6 side of the service by setting up a rogue relay and letting that relay advertise a route to the Teredo IPv6 prefix. This is an attack against IPv6 routing, which can also be mitigated by the same kind of procedures used to eliminate spurious route advertisements. Dual-stack nodes that implement "host local" Teredo relays are impervious to this attack.
通过设置恶意中继并让该中继公布到Teredo IPv6前缀的路由，可以在服务的IPv6端发起攻击。这是一种针对IPv6路由的攻击，也可以通过用于消除虚假路由广告的相同过程来减轻这种攻击。实现“主机本地”Teredo中继的双堆栈节点不受此攻击的影响。
In Section 7.2, we discussed the use of spoofed router advertisements to insert an attacker in the middle of a Teredo conversation. The spoofed router advertisements can also be used to provision a client with an incorrect address, pointing to either a non-existing IPv4 address or the IPv4 address of a third party.
在第7.2节中，我们讨论了使用欺骗路由器广告插入攻击者在TeleDo会话的中间。伪造的路由器广告还可用于向客户端提供不正确的地址，指向不存在的IPv4地址或第三方的IPv4地址。
The Teredo client will detect the attack when it fails to receive traffic through the newly acquired IPv6 address. The attack can be mitigated by using the authentication encapsulation.
Teredo客户端将在无法通过新获取的IPv6地址接收流量时检测到攻击。可以通过使用身份验证封装来减轻攻击。
A Teredo client manages a cache of recently used peers, which makes it stateful. It is possible to mount an attack against the client by provoking it to respond to packets that appear to come from a large number of Teredo peers, thus trashing the cache and effectively denying the use of direct communication between peers. The effect will last only as long as the attack is sustained.
Teredo客户端管理最近使用的对等点的缓存，这使其具有状态。通过激发客户端响应似乎来自大量Teredo对等方的数据包，可以对客户端发起攻击，从而破坏缓存并有效地拒绝使用对等方之间的直接通信。只要攻击持续，效果就会持续。
There is a possible denial of service attack against the local peer discovery procedure, if attackers can manage to send spoofed local discovery bubbles to a Teredo client. The checks described in Section 5.2.8 mitigate this attack. Clients who are more interested in security than in performance could decide to disable the local discovery procedure; however, if local discovery is disabled, traffic between local nodes will end up being relayed through a server
如果攻击者能够设法向Teredo客户端发送伪造的本地发现气泡，则可能存在针对本地对等发现过程的拒绝服务攻击。第5.2.8节中所述的检查可缓解此攻击。对安全性比对性能更感兴趣的客户端可以决定禁用本地发现过程；但是，如果禁用本地发现，本地节点之间的通信将最终通过服务器中继
external to the local network, which has questionable security implications.
本地网络外部，具有可疑的安全影响。
It is possible to mount a brute force denial of service attack against the Teredo servers by sending them a very large number of packets. This attack will have to be brute force, since the servers are stateless, and can be designed to process all the packets that are sent on their access line.
通过向Teredo服务器发送大量数据包，可以对其发起暴力拒绝服务攻击。由于服务器是无状态的，并且可以设计为处理在其访问线路上发送的所有数据包，因此这种攻击必须是暴力攻击。
The brute force attack against the Teredo servers is mitigated if clients are ready to "failover" to another server. Bringing down the servers will, however, force the clients that change servers to renumber their Teredo address.
如果客户端准备好“故障切换”到另一台服务器，则可以减轻对Teredo服务器的暴力攻击。然而，关闭服务器将迫使更改服务器的客户端重新编号其Teredo地址。
It is also possible to mount a brute force attack against a Teredo relay. This attack is mitigated if the relay under attack stops announcing the reachability of the Teredo service prefix to the IPv6 network: the traffic will be picked up by the next relay.
也有可能对Teredo中继发动暴力攻击。如果受攻击的中继停止向IPv6网络宣布Teredo服务前缀的可达性，则此攻击将得到缓解：流量将由下一个中继接收。
An attack similar to that described in Section 7.3.2 can be mounted against a relay. An IPv6 host can send IPv6 packets to a large number of Teredo destinations, forcing the relay to establish state for each of these destinations. Teredo relays can obtain some protection by limiting the range of IPv6 clients that they serve, and by limiting the amount of state used for "new" peers.
可针对继电器进行类似于第7.3.2节所述的攻击。IPv6主机可以向大量Teredo目的地发送IPv6数据包，迫使中继为每个目的地建立状态。Teredo中继可以通过限制其服务的IPv6客户端的范围以及限制用于“新”对等方的状态量来获得一些保护。
There is a widely expressed concern that transition mechanisms such as Teredo can be used to mount denial of service attacks, by injecting traffic at locations where it is not expected. These attacks fall in three categories: using the Teredo servers as a reflector in a denial of service attack, using the Teredo server to carry a denial of service attack against IPv6 nodes, and using the Teredo relays to carry a denial of service attack against IPv4 nodes. The analysis of these attacks follows. A common mitigating factor in all cases is the "regularity" of the Teredo traffic, which contains highly specific patterns such as the Teredo UDP port, or the Teredo IPv6 prefix. In case of attacks, these patterns can be used to quickly install filters and remove the offending traffic.
人们普遍担心，Teredo等过渡机制可以通过在预期不到的位置注入流量来发动拒绝服务攻击。这些攻击分为三类：使用Teredo服务器作为拒绝服务攻击的反射器，使用Teredo服务器对IPv6节点进行拒绝服务攻击，以及使用Teredo中继对IPv4节点进行拒绝服务攻击。对这些攻击的分析如下。在所有情况下，一个常见的缓解因素是Teredo流量的“规律性”，它包含高度特定的模式，如Teredo UDP端口或Teredo IPv6前缀。在发生攻击的情况下，可以使用这些模式快速安装过滤器并删除违规流量。
We should also note that none of the listed possibilities offer any noticeable amplification.
我们还应该注意到，列出的所有可能性都没有提供任何明显的放大效果。
An attacker can use the Teredo servers as reflectors in a denial of service attack aimed at an IPv4 target. The attacker can do this in one of two ways. The first way is to construct a Router Solicitation
攻击者可以使用Teredo服务器作为针对IPv4目标的拒绝服务攻击的反射器。攻击者可以通过以下两种方式之一执行此操作。第一种方法是构造路由器请求
message and post it to a Teredo server, using as IPv4 source address the spoofed address of the target; the Teredo server will then send a Router advertisement message to the target. The second way is to construct a Teredo IPv6 address using the Teredo prefix, the address of a selected server, the IPv4 of the target, and an arbitrary UDP port, and to then send packets bound to that address to the selected Teredo server.
消息并将其发布到Teredo服务器，将目标的伪造地址用作IPv4源地址；Teredo服务器随后将向目标发送路由器广告消息。第二种方法是使用Teredo前缀、选定服务器的地址、目标的IPv4和任意UDP端口构造Teredo IPv6地址，然后将绑定到该地址的数据包发送到选定Teredo服务器。
Reflector attacks are discussed in [REFLECT], which outlines various mitigating techniques against such attacks. One of these mitigations is to observe that "the traffic generated by the reflectors [has] sufficient regularity and semantics that it can be filtered out near the victim without the filtering itself constituting a denial-of-service to the victim ('collateral damage')". The traffic reflected by the Teredo servers meets this condition: it is clearly recognizable, since it originates from the Teredo UDP port; it can be filtered out safely if the target itself is not a Teredo user. In addition, the packets relayed by servers will carry an Origin indication encapsulation, which will help determine the source of the attack.
[REFLECT]中讨论了反射器攻击，概述了针对此类攻击的各种缓解技术。这些缓解措施之一是观察到“反射器产生的流量[具有]足够的规律性和语义，可以在受害者附近过滤掉，而过滤本身不会构成对受害者的拒绝服务（“附带损害”）。Teredo服务器反映的流量满足以下条件：由于它来自Teredo UDP端口，因此可以清楚地识别；如果目标本身不是Teredo用户，则可以安全地将其过滤掉。此外，服务器转发的数据包将带有一个来源指示封装，这将有助于确定攻击的来源。
An attacker may use the Teredo servers to launch a denial of service attack against an arbitrary IPv6 destination. The attacker will build an IPv6 packet bound for the target and will send that packet to the IPv4 address and UDP port of a Teredo server, to be relayed from there to the target over IPv6.
攻击者可以使用Teredo服务器对任意IPv6目标发起拒绝服务攻击。攻击者将为目标构建绑定的IPv6数据包，并将该数据包发送到Teredo服务器的IPv4地址和UDP端口，然后通过IPv6从该服务器中继到目标。
The address checks specified in Section 5.3.1 provide some protection against this attack, as they ensure that the IPv6 source address will be consistent with the IPv4 source address and UDP source port used by the attacker: if the attacker cannot spoof the IPv4 source address, the target will be able to determine the origin of the attack.
第5.3.1节中指定的地址检查提供了一些针对此攻击的保护，因为它们确保IPv6源地址与攻击者使用的IPv4源地址和UDP源端口一致：如果攻击者无法欺骗IPv4源地址，目标将能够确定攻击的来源。
The address checks ensure that the IPv6 source address of packets forwarded by servers will start with the IPv6 Teredo prefix. This is a mitigating factor, as sites under attack could use this to filter out all packets sourced from that prefix during an attack. This will result in a partial loss of service, as the target will not be able to communicate with legitimate Teredo hosts that use the same prefix.
地址检查确保服务器转发的数据包的IPv6源地址以IPv6 Teredo前缀开头。这是一个缓解因素，因为受到攻击的站点可以在攻击期间使用它过滤来自该前缀的所有数据包。这将导致部分服务丢失，因为目标将无法与使用相同前缀的合法Teredo主机通信。
However, the communication with other IPv6 hosts will remain unaffected, and the communication with Teredo hosts will be able to resume when the attack has ceased.
但是，与其他IPv6主机的通信将不受影响，并且在攻击停止后，与Teredo主机的通信将能够恢复。
An attacker with IPv6 connectivity may use the Teredo relays to launch a denial of service attack against an arbitrary IPv4 destination. The attacker will compose a Teredo IPv6 address using the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the target, and an arbitrary UDP port.
具有IPv6连接的攻击者可以使用Teredo中继对任意IPv4目标发起拒绝服务攻击。攻击者将使用Teredo前缀、设置为1的“cone”标志、目标的IPv4地址和任意UDP端口组成Teredo IPv6地址。
In the simplest variation of this attack, the attacker sends IPv6 packets to the Teredo destination using regular IPv6 routing. The packets are picked by the nearest relay, which will forward them to the IPv4 address of the target. In a more elaborate variant, the attacker tricks a Teredo into sending packets to the target, either by sending a first packet with a spoofed IPv6 address and letting the Teredo host reply or by publishing a spoofed IPv6 address in a name service.
在这种攻击的最简单变体中，攻击者使用常规IPv6路由将IPv6数据包发送到Teredo目标。数据包由最近的中继器拾取，中继器将数据包转发到目标的IPv4地址。在更复杂的变体中，攻击者诱使Teredo向目标发送数据包，方法是发送带有伪造IPv6地址的第一个数据包并让Teredo主机应答，或者在名称服务中发布伪造IPv6地址。
There are three types of IPv4 addresses that an attacker may embed in the spoofed Teredo address. It may embed a multicast or broadcast address, an local unicast address, or a global unicast address.
攻击者可以在伪造的Teredo地址中嵌入三种类型的IPv4地址。它可以嵌入多播或广播地址、本地单播地址或全局单播地址。
With multicast or broadcast addresses, the attacker can use the multiplying effect of multicast routing. By sending a single packet, it can affect a large number of hosts, in a way reminiscent of the "smurf" attack.
对于多播或广播地址，攻击者可以利用多播路由的倍增效应。通过发送单个数据包，它可以影响大量主机，这让人想起“蓝精灵”攻击。
By using local addresses, the attacker can reach hosts that are not normally reachable from the Internet, for example, hosts connected to the a Teredo relay by a private subnet. This creates an exposure for, at a minimum, a denial of service attack against these otherwise protected hosts. This is similar to attack variants using source routing to breach a perimeter.
通过使用本地地址，攻击者可以访问通常无法从Internet访问的主机，例如通过专用子网连接到Teredo中继的主机。这至少会造成针对这些受保护主机的拒绝服务攻击。这类似于使用源路由突破周界的攻击变体。
The address checks specified in Section 5.2.4, 5.3.1, and 5.4.1 verify that packets are relayed only to a global IPv4 address. They are designed to eliminate the possibility of using broadcast, multicast or local addresses in denial of service or other attacks. In what follows, we will only consider attacks targeting globally reachable unicast addresses.
第5.2.4节、第5.3.1节和第5.4.1节中规定的地址检查验证数据包是否仅中继到全局IPv4地址。它们旨在消除在拒绝服务或其他攻击中使用广播、多播或本地地址的可能性。在下文中，我们将只考虑针对全局可达单播地址的攻击。
The attacks can be targeted at arbitrary UDP ports, such as, for example, the DNS port of a server. The UDP payload must be a well-formed IPv6 packet, and is thus unlikely to be accepted by any well-written UDP service; in most case, the only effect of the attack will be to overload the target with random traffic.
攻击可以针对任意UDP端口，例如服务器的DNS端口。UDP有效负载必须是格式良好的IPv6数据包，因此不可能被任何编写良好的UDP服务接受；在大多数情况下，攻击的唯一效果是使用随机流量使目标过载。
A special case occurs if the attack is directed to an echo service. The service will echo the packets. Since the echo service sees the request coming from the IPv4 address of the relay, the echo replies will be sent back to the same relay. According to the rules specified in Section 5.4, these packets will be discarded by the Teredo relay. This is not a very efficient attack against the Teredo relays -- establishing a legitimate session with an actual Teredo host would create more traffic.
如果攻击指向回显服务，则会发生特殊情况。服务将回显数据包。由于回显服务看到来自中继IPv4地址的请求，因此回显回复将发送回同一中继。根据第5.4节规定的规则，Teredo中继将丢弃这些数据包。这不是针对Teredo中继的非常有效的攻击——与实际Teredo主机建立合法会话将产生更多流量。
The IPv6 packets sent to the target contain the IPv6 address used by the attacker. If ingress filtering is used in the IPv6 network, this
发送到目标的IPv6数据包包含攻击者使用的IPv6地址。如果IPv6网络中使用了入口过滤，则
address will be hard to spoof. If ingress filtering is not used, the attacker can be traced if the IPv6 routers use a mechanism similar to ICMP Traceback. The ICMP messages will normally be collected by the same relays that forward the traffic from the attacker; the relays can use these messages to identify the source of an ongoing attack. The details of this solution will have to be developed in further research.
地址很难伪造。如果未使用入口过滤，则如果IPv6路由器使用类似于ICMP回溯的机制，则可以跟踪攻击者。ICMP消息通常由转发攻击者流量的相同中继收集；中继可以使用这些消息来识别正在进行的攻击的来源。该解决方案的细节有待进一步研究。
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]. Teredo 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]。Teredo是执行此类功能的协议的一个示例。IAB已授权为此目的制定的任何协议都应记录一组特定的考虑因素。本节满足这些要求。
From [RFC3424], any UNSAF proposal must provide a 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".
根据[RFC3424]，任何UNSAF提案都必须对UNSAF提案要解决的特定、有限范围的问题提供精确的定义。短期解决方案不应泛化为解决其他问题；这就是为什么“短期修复通常不是”。
The specific problem being solved by Teredo is the provision of IPv6 connectivity for hosts that cannot obtain IPv6 connectivity natively and cannot make use of 6to4 because of the presence of a NAT between them and the 6to4 relays.
Teredo正在解决的具体问题是为无法以本机方式获得IPv6连接且无法使用6to4的主机提供IPv6连接，因为它们与6to4中继之间存在NAT。
From [RFC3424], any UNSAF proposal must provide the 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.
根据[RFC3424]，任何UNSAF提案必须提供退出战略/过渡计划的说明。更好的短期修复方法是，随着适当技术的部署，自然会看到越来越少的使用。
Teredo comes with its own built-in exit strategy: as soon as a client obtains IPv6 connectivity by other means, either 6to4 or native IPv6, it can cease using the Teredo service. In particular, we expect that the next generation of home routers will provide an IPv6 service in complement to the current IPv4 NAT service, e.g., by relaying connectivity obtained from the ISP, or by using a configured or automatic tunnel service.
Teredo有自己的内置退出策略：一旦客户端通过其他方式（6to4或本机IPv6）获得IPv6连接，它就可以停止使用Teredo服务。特别是，我们预计下一代家庭路由器将提供IPv6服务，以补充当前的IPv4 NAT服务，例如，通过中继从ISP获得的连接，或通过使用配置的或自动的隧道服务。
As long as Teredo is used, there will be a need to support Teredo relays so that the remaining Teredo hosts can communicate with native IPv6 hosts. As Teredo usage declines, the traffic load on the relays will decline. Over time, managers will observe a reduced traffic load on their relays and will turn them off, effectively increasing the pressure on the remaining Teredo hosts to upgrade to another form of connectivity.
只要使用Teredo，就需要支持Teredo中继，以便其余Teredo主机可以与本机IPv6主机通信。随着Teredo使用率的下降，继电器上的流量负载将下降。随着时间的推移，管理者将观察到其中继上的流量负载减少，并将其关闭，从而有效地增加剩余Teredo主机升级到另一种连接形式的压力。
The exit strategy is facilitated by the nature of Teredo, which provides an IP-level solution. IPv6-aware applications do not have to be updated to use or not use Teredo. The absence of impact on the applications makes it easier to migrate out of Teredo: network connectivity suffices.
Teredo的特性促进了退出策略，它提供了IP级别的解决方案。支持IPv6的应用程序无需更新即可使用或不使用Teredo。对应用程序没有影响使迁移出Teredo变得更容易：网络连接就足够了。
There would appear to be reasons why a Teredo implementation might decide to continue usage of the Teredo service even if it already has obtained connectivity by some other means, for example:
Teredo实现可能会决定继续使用Teredo服务，即使它已经通过其他方式获得连接，这似乎是有原因的，例如：
1. When a client is dual homed, and it wishes to improve the service when communicating with other Teredo hosts that are "nearby" on the IPv4 network. If the client only used its native IPv6 service, the Teredo hosts would be reached only through the relay. By maintaining Teredo, the Teredo hosts can be reached by direct transmission over IPv4.
1. 当客户机是双主机，并且希望在与IPv4网络上“附近”的其他Teredo主机通信时改进服务时。如果客户端仅使用其本机IPv6服务，则只能通过中继到达Teredo主机。通过维护Teredo，可以通过IPv4直接传输到达Teredo主机。
2. If, for some reason, the Teredo link is providing the client with better service than the native IPv6 link, in terms of bandwidth, packet loss, etc.
2. 如果由于某种原因，Teredo链路在带宽、数据包丢失等方面为客户端提供了比本机IPv6链路更好的服务。
The design of Teredo mitigates the dual-homing reason. A host that wishes to communicate with Teredo peers can implement a "host-based relay", which is effectively an unnumbered Teredo interface. As such, the dual-homed host will obtain Teredo connectivity with those
Teredo的设计缓解了双重归巢的原因。希望与Teredo对等方通信的主机可以实现“基于主机的中继”，这实际上是一个无编号的Teredo接口。因此，双宿主主机将获得与这些主机的Teredo连接
hosts that must use Teredo, but will not inadvertently encourage other dual-homed hosts to keep using the Teredo service.
必须使用Teredo但不会无意中鼓励其他双宿主主机继续使用Teredo服务的主机。
The bubbles and the UDP encapsulation used by Teredo introduce a significant overhead. It would take exceptional circumstances for native technologies to provide a lesser service than Teredo. These exceptional circumstances, or other unforeseen reasons, may induce hosts to keep using the Teredo service despite the availability of native IPv6 connectivity. However, these circumstances are likely to be rare and transient. Moreover, if the primary reason to use Teredo fades away, one can expect that Teredo relays will be progressively turned off and that the quality of the Teredo service will progressively degrade, reducing the motivation to use the Teredo service.
Teredo使用的气泡和UDP封装带来了巨大的开销。在特殊情况下，本地技术提供的服务要比Teredo少。这些异常情况或其他不可预见的原因可能会导致主机继续使用Teredo服务，尽管本机IPv6连接可用。然而，这些情况可能是罕见和短暂的。此外，如果使用Teredo的主要原因消失，可以预期Teredo继电器将逐渐关闭，Teredo服务的质量将逐渐降低，从而降低使用Teredo服务的动机。
From [RFC3424], any UNSAF proposal must provide a 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.
根据[RFC3424]，UNSAF的任何提案都必须对可能使系统更“脆弱”的具体问题进行讨论。例如，涉及在多个网络层使用数据的方法会产生更多的依赖性，增加调试挑战，并使转换更加困难。
Teredo introduces brittleness into the system in several ways: the discovery process assumes a certain classification of devices based on their treatment of UDP; the mappings need to be continuously refreshed; and addressing structure may cause some hosts located behind a common NAT to be unreachable from each other.
Teredo以几种方式将脆弱性引入系统：发现过程假设设备根据其UDP处理方式进行某种分类；映射需要不断刷新；寻址结构可能导致位于公共NAT后面的一些主机彼此无法访问。
There are many similarities between these points and those introduced by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489]; however, Teredo is probably somewhat less brittle than STUN. The reason is that all Teredo packets are sent from the local IPv4 Teredo service port, including discovery, bubbles, and actual encapsulated packets. This is different from STUN, where NAT type detection and binding allocation use different local ports (ephemeral, in both cases).
这些要点与通过NAT（STUN）[RFC3489]简单遍历UDP协议引入的要点有许多相似之处；然而，泰瑞多可能比斯泰恩更不脆弱。原因是所有Teredo数据包都是从本地IPv4 Teredo服务端口发送的，包括发现、气泡和实际封装的数据包。这与STUN不同，在STUN中，NAT类型检测和绑定分配使用不同的本地端口（在这两种情况下都是短暂的）。
Teredo assumes a certain classification of devices based on their treatment of UDP (e.g., cone, protected cone and symmetric). There could be devices that would not fit into one of these molds, and hence would be improperly classified by Teredo.
Teredo根据设备对UDP的处理（例如锥体、受保护锥体和对称）对设备进行了一定的分类。可能有一些设备不适合这些模具中的一个，因此Teredo会对其进行不正确的分类。
The bindings allocated from the NAT need to be continuously refreshed. Since the timeouts for these bindings are very implementation specific, the refresh interval cannot easily be
从NAT分配的绑定需要不断刷新。由于这些绑定的超时是非常特定于实现的，因此刷新间隔不容易确定
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.
决心当绑定不是主动用于接收流量，而是用于等待传入消息时，绑定刷新将不必要地消耗网络带宽。
The use of the Teredo server as an additional network element introduces another point of potential security attack. These attacks are largely prevented by the security measures provided by Teredo, but not entirely.
将Teredo服务器用作附加网络元素会引入另一个潜在的安全攻击点。Teredo提供的安全措施在很大程度上阻止了这些攻击，但并非完全阻止。
The use of the Teredo server as an additional network element introduces another point of failure. If the client cannot locate a Teredo server, or if the server should be unavailable due to failure, the Teredo client will not be able to obtain IPv6 connectivity.
将Teredo服务器用作附加网元会导致另一个故障点。如果客户端找不到Teredo服务器，或者服务器因故障而不可用，Teredo客户端将无法获得IPv6连接。
The communication with non-Teredo hosts relies on the availability of Teredo relays. The Teredo design assumes that there are multiple Teredo relays; the Teredo service will discover the relay closest to the non-Teredo peer. If that relay becomes unavailable, or is misbehaving, communication between the Teredo hosts and the peers close to that relay will fail. This reliability issue is somewhat mitigated by the possibility to deploy many relays, arbitrarily close from the native IPv6 hosts that require connectivity with Teredo peers.
与非Teredo主机的通信依赖于Teredo中继的可用性。Teredo设计假设存在多个Teredo继电器；Teredo服务将发现距离非Teredo对等点最近的中继。如果该中继变得不可用或行为异常，Teredo主机与该中继附近的对等方之间的通信将失败。这种可靠性问题在某种程度上可以通过部署许多中继来缓解，这些中继任意靠近需要与Teredo对等点连接的本机IPv6主机。
Teredo imposes some restrictions on the network topologies for proper operation. In particular, if the same NAT is on the path between two clients and the Teredo server, these clients will only be able to interoperate if they are connected to the same link, or if the common NAT is capable of "hairpinning", i.e., "looping" packets sent by one client to another.
Teredo对网络拓扑施加了一些限制，以确保正常运行。特别是，如果相同的NAT位于两个客户机和Teredo服务器之间的路径上，则这些客户机只有在连接到同一链路时，或者如果公共NAT能够“发夹”，即，将一个客户机发送的数据包“循环”到另一个客户机时，才能进行互操作。
There are also additional points of brittleness that are worth mentioning:
另外还有一些脆性点值得一提：
- Teredo service will not work through NATs of the symmetric variety.
- Teredo服务无法通过对称类型的NAT工作。
- Teredo service depends on the Teredo server running on a network that is a common ancestor to all Teredo clients; typically, this is the public Internet. If the Teredo server is itself behind a NAT, Teredo service will not work to certain peers.
- Teredo服务依赖于运行在网络上的Teredo服务器，该网络是所有Teredo客户端的共同祖先；通常，这是公共互联网。如果Teredo服务器本身位于NAT后面，Teredo服务将无法对某些对等方工作。
- Teredo introduces jitter into the IPv6 service it provides, due to the queuing of packets while bubble exchanges take place. This jitter can negatively impact applications, particularly latency sensitive ones, such as Voice over IP (VoIP).
- Teredo在其提供的IPv6服务中引入了抖动，这是因为在气泡交换发生时，数据包会排队。这种抖动会对应用程序产生负面影响，特别是对延迟敏感的应用程序，如IP语音（VoIP）。
From [RFC3424], any UNSAF proposal must identify requirements for longer-term, sound technical solutions -- contribute to the process of finding the right longer-term solution.
根据[RFC3424]，UNSAF的任何提案都必须确定长期、合理的技术解决方案的要求——为找到正确的长期解决方案的过程做出贡献。
Our experience with Teredo has led to the following requirements for a long-term solution to the NAT problem: the devices that implement the IPv4 NAT services should in the future also become IPv6 routers.
我们在Teredo方面的经验导致了长期解决NAT问题的以下要求：实现IPv4 NAT服务的设备将来也应该成为IPv6路由器。
This memo documents a request to IANA to allocate a 32-bit Teredo IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4 multicast address, as specified in Section 2.17.
本备忘录记录了对IANA的请求，请求分配第2.6节规定的32位Teredo IPv6服务前缀和第2.17节规定的Teredo IPv4多播地址。
Many of the ideas in this memo are the result of discussions between the author and Microsoft colleagues, notably Brian Zill, John Miller, Mohit Talwar, Joseph Davies, and Rick Rashid. Several encapsulation details are inspired from earlier work by Keith Moore. The example in Section 5.1 and a number of security precautions were suggested by Pekka Savola. The local discovery procedure was suggested by Richard Draves and Dave Thaler. The document was reviewed by members of the NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng Soo Guan, and Eiffel Wu. Eric Klein, Karen Nielsen, Francis Dupont, Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg provided detailed reviews during the IETF last call.
本备忘录中的许多想法都是作者与微软同事讨论的结果，特别是Brian Zill、John Miller、Mohit Talwar、Joseph Davies和Rick Rashid。一些封装细节灵感来自Keith Moore的早期作品。Pekka Savola提出了第5.1节中的示例和一些安全预防措施。当地的发现程序是由理查德·德拉维斯和戴夫·泰勒提出的。NGTRANS和V6OPS工作组成员审查了该文件，包括Brian Carpenter、Cyndi Jung、Keith Moore、Thomas Narten、Anssi Porttikivi、Pekka Savola、Eng-Soo Guan和Eiffel Wu。Eric Klein、Karen Nielsen、Francis Dupont、Markku Ala Vanneslooma、Henrik Levkowetz和Jonathan Rosenberg在IETF上次通话中提供了详细的评论。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[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月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3566]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, National Institute of Standards and Technology, U.S. Department Of Commerce, May 1993.
[FIPS-180]“安全哈希标准”，美国商务部国家标准与技术研究所计算机系统实验室，1993年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[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]罗森伯格，J.，温伯格，J.，惠特马，C.，和R.马伊。“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[RFC3904]Huitema，C.，Austein，R.，Satapati，S.，和R.van der Pol，“非托管网络IPv6过渡机制的评估”，RFC 3904，2004年9月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[REFLECT] V. Paxson, "An analysis of using reflectors for distributed denial of service attacks", Computer Communication Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47.
[REFLECT]V.Paxson，“使用反射器进行分布式拒绝服务攻击的分析”，《计算机通信评论》，ACM SIGCOMM，第31卷，第3期，2001年7月，第38-47页。
Author's Address
作者地址
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。