Internet Engineering Task Force (IETF) D. Thaler
Request for Comments: 5991 Microsoft
Updates: 4380 S. Krishnan
Category: Standards Track Ericsson
ISSN: 2070-1721 J. Hoagland
Symantec
September 2010
Internet Engineering Task Force (IETF) D. Thaler
Request for Comments: 5991 Microsoft
Updates: 4380 S. Krishnan
Category: Standards Track Ericsson
ISSN: 2070-1721 J. Hoagland
Symantec
September 2010
Teredo Security Updates
Teredo安全更新
Abstract
摘要
The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible.
Teredo协议定义了嵌入在每个Teredo IPv6地址中的一组标志。此文档指定一组安全更新，这些更新修改此标志字段的使用，但向后兼容。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5991.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5991.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Specification ...................................................4
3.1. Random Address Flags .......................................4
3.2. Deprecation of Cone Bit ....................................6
4. Security Considerations .........................................7
5. Acknowledgments .................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Implementation Status .................................9
Appendix B. Resistance to Address Prediction ......................9
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Specification ...................................................4
3.1. Random Address Flags .......................................4
3.2. Deprecation of Cone Bit ....................................6
4. Security Considerations .........................................7
5. Acknowledgments .................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Implementation Status .................................9
Appendix B. Resistance to Address Prediction ......................9
Teredo [RFC4380] defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backwards compatible. This document updates RFC 4380.
Teredo[RFC4380]定义了嵌入在每个Teredo IPv6地址中的一组标志。此文档指定一组安全更新，这些更新修改此标志字段的使用，但向后兼容。本文档更新了RFC 4380。
The Flags field in a Teredo IPv6 address has 13 unused bits out of a total of 16 bits. To guard against address-scanning risks [RFC5157] from malicious users, this update randomizes 12 of the 13 unused bits when configuring the Teredo IPv6 address. Even if an attacker were able to determine the external (mapped) IPv4 address and port assigned by a NAT to the Teredo client, the attacker would still need to attack a range of 4,096 IPv6 addresses to determine the actual Teredo IPv6 address of the client.
Teredo IPv6地址中的标志字段在总共16位中有13位未使用。为了防止恶意用户的地址扫描风险[RFC5157]，在配置Teredo IPv6地址时，此更新将13个未使用位中的12个随机化。即使攻击者能够确定NAT分配给Teredo客户端的外部（映射的）IPv4地址和端口，攻击者仍需要攻击4096个IPv6地址来确定客户端的实际Teredo IPv6地址。
The cone bit in a Teredo IPv6 address indicates whether a peer needs to send Teredo control messages before communicating with a Teredo IPv6 address. Unfortunately, it may also have some value in terms of profiling to the extent that it reveals the security posture of the network. If the cone bit is set, an attacker may decide it is
Teredo IPv6地址中的锥形位指示对等方在与Teredo IPv6地址通信之前是否需要发送Teredo控制消息。不幸的是，它在分析方面也可能有一些价值，因为它揭示了网络的安全态势。如果设置了牙轮钻头，攻击者可能会认为它是正确的
fruitful to port-scan the embedded external IPv4 address and others associated with the same organization, looking for open ports. Deprecating the cone bit prevents the a priori revelation of the security posture of the NAT.
端口扫描嵌入的外部IPv4地址和与同一组织关联的其他地址，查找打开的端口。弃用牙轮钻头可防止NAT安全态势的先验暴露。
This document uses the following terminology, for consistency with [RFC4380].
为了与[RFC4380]保持一致，本文件使用以下术语。
Cone NAT: A NAT that maps all requests from the same internal IP address and port to the same external IP address and port. Furthermore, any external host can send a packet to the internal host by sending a packet to the mapped external address and port.
Cone NAT：将来自相同内部IP地址和端口的所有请求映射到相同外部IP地址和端口的NAT。此外，任何外部主机都可以通过向映射的外部地址和端口发送数据包来向内部主机发送数据包。
Indirect Bubble: A Teredo control message that is sent to another Teredo client via the destination's Teredo server, as specified in [RFC4380], Section 5.2.4.
间接气泡：根据[RFC4380]第5.2.4节的规定，通过目的地的Teredo服务器发送给另一个Teredo客户端的Teredo控制消息。
Local Address/Port: The IPv4 address and UDP port from which a Teredo client sends Teredo packets. The local port is referred to as the Teredo service port in [RFC4380]. The local address of a node may or may not be globally routable because the node can be located behind one or more NATs.
本地地址/端口：Teredo客户端从中发送Teredo数据包的IPv4地址和UDP端口。本地端口在[RFC4380]中称为Teredo服务端口。节点的本地地址可能是全局可路由的，也可能不是全局可路由的，因为节点可以位于一个或多个NAT后面。
Mapped Address/Port: A global IPv4 address and a UDP port that results from the translation of a node's own local address/port by one or more NATs. The node learns these values through the Teredo protocol specified in [RFC4380]. The mapped address/port can be different for every peer with which a node tries to communicate.
映射地址/端口：全局IPv4地址和UDP端口，由一个或多个NAT转换节点自身的本地地址/端口而产生。节点通过[RFC4380]中指定的Teredo协议学习这些值。对于节点尝试与之通信的每个对等方，映射的地址/端口可能不同。
Network Address Translation (NAT): The process of converting between IP addresses used within an intranet or other private network and Internet IP addresses.
网络地址转换（NAT）：在内部网或其他专用网络中使用的IP地址与Internet IP地址之间进行转换的过程。
Peer: A Teredo client with which another Teredo client needs to communicate.
对等方：另一个Teredo客户端需要与之通信的Teredo客户端。
Port-Preserving NAT: A NAT that translates a local address/port to a mapped address/port such that the mapped port has the same value as the local port, as long as that same mapped address/port has not already been used for a different local address/port.
端口保留NAT：将本地地址/端口转换为映射地址/端口的NAT，只要相同的映射地址/端口尚未用于不同的本地地址/端口，则映射端口与本地端口具有相同的值。
Public Address: An external global address used by a NAT.
公共地址：NAT使用的外部全局地址。
Restricted NAT: A NAT where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike the cone NAT, an external host can send packets to
受限NAT：来自相同内部IP地址和端口的所有请求都映射到相同外部IP地址和端口的NAT。与cone NAT不同，外部主机可以向服务器发送数据包
an internal host (by sending a packet to the external mapped address and port) only if the internal host has first sent a packet to the external host.
仅当内部主机已首先向外部主机发送数据包时，内部主机（通过向外部映射地址和端口发送数据包）。
Teredo Client: A node that implements the client parts of [RFC4380], has access to the IPv4 Internet, and wants to gain access to the IPv6 Internet.
Teredo客户端：实现[RFC4380]客户端部分的节点，可以访问IPv4 Internet，并希望访问IPv6 Internet。
Teredo IPv6 Address: An IPv6 address that starts with the prefix 2001:0000:/32 and is formed as specified in Section 4 of [RFC4380].
Teredo IPv6地址：以前缀2001:0000:/32开头并按照[RFC4380]第4节的规定形成的IPv6地址。
Teredo Server: A node that has a globally routable address on the IPv4 Internet, and is used as a helper to provide IPv6 connectivity to Teredo clients.
Teredo服务器：在IPv4 Internet上具有全局可路由地址的节点，用作向Teredo客户端提供IPv6连接的帮助器。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Teredo addresses are structured, and some of the fields contained in them are fairly predictable. This makes the addresses themselves easier to predict and opens up a vulnerability.
Teredo地址是结构化的，其中包含的一些字段是可预测的。这使得地址本身更容易预测，并打开了一个漏洞。
Teredo prefix: This field is 32 bits and has a single IANA-assigned value.
Teredo前缀：此字段为32位，具有单个IANA赋值。
Server: This field is 32 bits and is set to the server in use. The server to use is generally statically configured on the client. This means that overall entropy of the server field will be low, i.e., that the server will not be hard to predict. Attackers could confine their guessing to the most popular server IP addresses.
服务器：此字段为32位，设置为正在使用的服务器。要使用的服务器通常在客户端上进行静态配置。这意味着服务器字段的总体熵将较低，即服务器不难预测。攻击者可以将猜测限制在最流行的服务器IP地址上。
Flags: The Flags field is 16 bits in length, but [RFC4380] provides for only one of these bits (the cone bit) to vary.
标志：标志字段的长度为16位，但[RFC4380]只提供其中一位（锥形位）的变化。
Client port: This 16-bit field corresponds to the external port number assigned to the client's Teredo service port. Thus, the value of this field depends on two factors (the chosen Teredo
客户端端口：此16位字段对应于分配给客户端Teredo服务端口的外部端口号。因此，该字段的值取决于两个因素（所选的Teredo
service port and the NAT port assignment behavior), and it therefore is harder to predict the entropy this field will have. If clients tend to use a predictable port number and NATs are often port-preserving, then the port number can be rather predictable.
服务端口和NAT端口分配行为），因此很难预测此字段的熵。如果客户端倾向于使用可预测的端口号，而NAT通常保留端口，那么端口号可以相当可预测。
Client IPv4 address: This 32-bit field corresponds to the external IPv4 address the NAT has assigned for the client port. In principle, this can be any address in the assigned part of the IPv4 unicast address space. However, if an attacker is looking for the address of a specific Teredo client, they will have to have the external IPv4 address pretty well narrowed down. Certain IPv4 address ranges could also become well known for having a higher concentration of Teredo clients, making it easier to find an arbitrary Teredo client. These addresses could correspond to large organizations that allow Teredo, such as a university or enterprise, or to Internet Service Providers that only provide their customers with RFC 1918 addresses.
客户端IPv4地址：此32位字段对应于NAT为客户端端口分配的外部IPv4地址。原则上，这可以是IPv4单播地址空间指定部分中的任何地址。但是，如果攻击者正在查找特定Teredo客户端的地址，那么他们必须将外部IPv4地址缩小。某些IPv4地址范围还可能因Teredo客户端的集中度较高而广为人知，从而更容易找到任意Teredo客户端。这些地址可以对应于允许Teredo的大型组织，如大学或企业，或者对应于仅向其客户提供RFC1918地址的互联网服务提供商。
Optimizations in scanning can also reduce the number of addresses that need to be checked. For example, for addresses behind a cone NAT, it would likely be easy to probe if a specific port number is open on an IPv4 address, prior to trying to form a Teredo address for that address and port.
扫描中的优化还可以减少需要检查的地址数。例如，对于cone NAT后面的地址，在尝试为该地址和端口形成Teredo地址之前，可能很容易探测IPv4地址上是否打开了特定的端口号。
Hence, the Flags field specified in [RFC4380], Section 4 is updated as follows:
因此，[RFC4380]第4节中规定的标志字段更新如下：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|z|Random1|U|G| Random2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|z|Random1|U|G| Random2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: This flag is specified in [RFC4380], and its use is modified in Section 3.2 below.
C:[RFC4380]中规定了该标志，其使用在下面第3.2节中进行了修改。
z: This flag is reserved. It MUST be set to zero when the address is constructed, as specified in [RFC4380].
z:这面旗是保留的。按照[RFC4380]中的规定，构造地址时必须将其设置为零。
Random1: MUST be set to a random value.
Random1:必须设置为随机值。
U: This flag is specified in [RFC4380].
U:此标志在[RFC4380]中指定。
G: This flag is specified in [RFC4380].
G:该标志在[RFC4380]中有规定。
Random2: MUST be set to a random value.
Random2:必须设置为随机值。
The qualification procedure is specified in [RFC4380], Section 5.2.1, and is modified as follows. Teredo clients SHOULD completely skip the first phase of the qualification procedure and implement only the second phase where it uses the Teredo link-local address with the cone bit set to zero. Consequently, a distinction between cone and restricted NATs can no longer be made. Teredo communication will still succeed, but at the expense of forcing peers to skip case 4 of the sending details specified in [RFC4380], Section 5.2.4. This will result in the same number of indirect bubbles being sent as if the other end were a peer behind a restricted NAT. Even though the peer behind the cone NAT does not need these indirect bubbles, it replies to these indirect bubbles just like it would to any other indirect bubbles. Skipping case 4 is already allowed for reliability reasons (as also specified in [RFC4380], Section 5.2.4), and hence this does not break interoperability, but the result of skipping the first phase of qualification is to force that behavior (which is less efficient, but potentially more reliable) to be taken by peers.
[RFC4380]第5.2.1节规定了鉴定程序，并对其进行了如下修改。Teredo客户机应完全跳过鉴定程序的第一阶段，仅执行第二阶段，即使用Teredo链路本地地址，并将锥形位设置为零。因此，不能再区分锥形和受限NAT。Teredo通信仍将成功，但代价是迫使对等方跳过[RFC4380]第5.2.4节中规定的发送细节的情况4。这将导致发送相同数量的间接气泡，就像另一端是受限NAT后面的对等方一样。即使cone NAT后面的对等方不需要这些间接气泡，它对这些间接气泡的响应与对任何其他间接气泡的响应一样。出于可靠性原因（如[RFC4380]第5.2.4节所述），已允许跳过案例4，因此这不会破坏互操作性，但跳过鉴定第一阶段的结果是迫使对等方采取该行为（效率较低，但可能更可靠）。
In addition, clients and relays SHOULD ignore the cone bit in the address of a Teredo peer and treat it as if it were always clear, as specified in [RFC4380], Section 5.2.4 (last paragraph).
此外，客户机和继电器应忽略Teredo对等机地址中的锥形位，并将其视为始终清晰，如[RFC4380]第5.2.4节（最后一段）所述。
Teredo servers MUST NOT ignore the cone bit for the following reasons.
Teredo服务器不得出于以下原因忽略锥形位。
o The cone bit in the IPv6 source address of a Router Solicitation (RS) from a client controls what IPv4 source address the server should use when sending a Router Advertisement (RA). If this behavior is not preserved, legacy clients will conclude that they are behind a cone NAT even when they are not (because the client WILL receive the RA where previously it would not, since a cone bit set to 1 requires the server to respond from another IP address). They will then set their cone bit and lose connectivity.
o 来自客户端的路由器请求（RS）的IPv6源地址中的锥形位控制服务器在发送路由器公告（RA）时应使用的IPv4源地址。如果不保留此行为，则旧客户端将得出结论，即使它们不在cone NAT之后，它们也在cone NAT之后（因为客户端将接收RA，而以前它不会接收RA，因为cone位设置为1需要服务器从另一个IP地址响应）。然后，它们将设置锥位并失去连接。
o When the Teredo server sends RAs (or bubbles if it's also a relay), the cone bit in its own Teredo address is set, indicating that it doesn't require bubbles to reach it.
o 当Teredo服务器发送RAs（或气泡，如果它也是一个中继）时，它自己的Teredo地址中的锥形位被设置，表明它不需要气泡来到达它。
The basic threat model for Teredo is described in detail in [RFC4380], Section 7, but briefly, the goal is that a Teredo client should be as secure as if a host were directly attached to an untrusted Internet link. This document specifies updates to [RFC4380] that improve the security of the base Teredo mechanism regarding specific threats.
Teredo的基本威胁模型在[RFC4380]第7节中有详细描述，但简单地说，目标是Teredo客户端应该像主机直接连接到不受信任的Internet链路一样安全。本文件规定了对[RFC4380]的更新，以提高基本Teredo机制在特定威胁方面的安全性。
IPv6 address scanning [RFC5157] by off-path attackers: The Teredo IPv6 Address format defined in [RFC4380], Section 4 makes it relatively easy for a malicious user to conduct an address-scan to determine IPv6 addresses by guessing the external (mapped) IPv4 address and port assigned to the Teredo client. The random address bits guard against address-scanning risks by providing a range of 4,096 IPv6 addresses per external IPv4 address/port. As a result, even if a malicious user were able to determine the external (mapped) IPv4 address and port assigned to the Teredo client, the malicious user would still need to attack a range of 4,096 IPv6 addresses to determine the actual Teredo IPv6 address of the client. Appendix B compares the address prediction resistance of a Teredo address following this specification to that of an address formed using standard IPv6 stateless address autoconfiguration [RFC4862].
非路径攻击者的IPv6地址扫描[RFC5157]：第4节[RFC4380]中定义的Teredo IPv6地址格式使得恶意用户通过猜测外部（映射）IPv4地址和分配给Teredo客户端的端口来执行地址扫描以确定IPv6地址相对容易。随机地址位通过为每个外部IPv4地址/端口提供4096个IPv6地址的范围来防范地址扫描风险。因此，即使恶意用户能够确定分配给Teredo客户端的外部（映射）IPv4地址和端口，恶意用户仍需要攻击4096个IPv6地址范围，以确定客户端的实际Teredo IPv6地址。附录B比较了遵循本规范的Teredo地址与使用标准IPv6无状态地址自动配置形成的地址的地址预测阻力[RFC4862]。
In order to prevent adversaries from easily guessing the values of the random bits and hence the address, the Random1 and Random2 bits in the Teredo Flags field MUST be constructed following the recommendations for random number generation as specified in [NIST-RANDOM] and [RFC4086].
为了防止对手轻易猜测随机位的值以及地址，Teredo Flags字段中的Random1和Random2位必须按照[NIST-random]和[RFC4086]中规定的随机数生成建议进行构造。
Opening a hole in an enterprise firewall [TUNNEL-SEC]: Teredo is NOT RECOMMENDED as a solution for networks that wish to implement strict controls for what traffic passes to and from the Internet. Administrators of such networks may wish to filter all Teredo traffic at the boundaries of their networks.
在企业防火墙上打开一个洞[TUNNEL-SEC]：对于那些希望对进出互联网的流量实施严格控制的网络，不建议将Teredo作为解决方案。此类网络的管理员可能希望过滤其网络边界处的所有Teredo流量。
The authors would like to thank Remi Denis-Courmont, Fred Templin, Jordi Palet Martinez, James Woodyatt, Christian Huitema, Tom Yu, Jari Arkko, David Black, Tim Polk, and Sean Turner for reviewing earlier versions of this document and providing comments to make this document better. The authors would also like to thank Alfred Hoenes for a careful review of this document.
作者要感谢雷米·丹尼斯·库尔蒙、弗雷德·坦普林、乔迪·帕莱特·马丁内斯、詹姆斯·伍迪亚特、克里斯蒂安·惠特马、汤姆·余、贾里·阿尔科、大卫·布莱克、蒂姆·波尔克和肖恩·特纳对本文件早期版本进行了审查，并为改进本文件提供了意见。作者还要感谢Alfred Hoenes对本文件的仔细审查。
[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月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[NIST-RANDOM] "NIST SP 800-90, Recommendation for Random Number Generation Using Deterministic Random Bit Generators", March 2007, <http://csrc.nist.gov/publications/ nistpubs/800-90/SP800-90revised_March2007.pdf>.
[NIST-RANDOM]“NIST SP 800-90，使用确定性随机位生成器生成随机数的建议”，2007年3月<http://csrc.nist.gov/publications/ nistpubs/800-90/SP800-90修订版\u 2007年3月2日.pdf>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157]Chown，T.，“IPv6对网络扫描的影响”，RFC 5157，2008年3月。
[TUNNEL-SEC] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", Work in Progress, March 2010.
[TUNNEL-SEC]Hoagland，J.，Krishnan，S.，和D.Thaler，“IP隧道的安全问题”，正在进行的工作，2010年3月。
Deprecation of the cone bit as specified in this document is implemented in Windows Vista and Windows Server 2008.
在Windows Vista和Windows Server 2008中实现了对本文档中指定的锥形钻头的弃用。
The random flags specified in this document are implemented in Windows Vista SP1 and Windows Server 2008.
本文档中指定的随机标志在Windows Vista SP1和Windows Server 2008中实现。
All Windows implementations automatically disable Teredo if they detect that they are on a managed network with a domain controller.
如果所有Windows实现检测到它们位于具有域控制器的托管网络上，则会自动禁用Teredo。
This section compares the address prediction resistance of a Teredo address as compared to an address formed using IPv6 stateless address autoconfiguration (SLAAC) [RFC4862].
本节比较Teredo地址与使用IPv6无状态地址自动配置（SLAAC）形成的地址的地址预测阻力[RFC4862]。
Let's assume that the attacker knows a Teredo client's external IPv4 address and Ethernet card's vendor. Since the attacker knows the client's external IPv4 address, he does not have to search this space. The attacker does not know the external port (16 bits) and the value of the random bits (12 bits), and he has to search this space. This gives the attacker a total search space of 28 bits (16+12). This compares very favorably with the 24 bits of search space required to find an address configured using SLAAC (when the Ethernet card's vendor is known) as described in Section 2.3 of [RFC5157]. Without the 12 random bits, the search space is limited to only 16 bits, and this is significantly worse than the 24 bits of search space provided by SLAAC.
假设攻击者知道Teredo客户端的外部IPv4地址和以太网卡的供应商。由于攻击者知道客户端的外部IPv4地址，因此不必搜索此空间。攻击者不知道外部端口（16位）和随机位（12位）的值，他必须搜索该空间。这使攻击者的总搜索空间为28位（16+12）。这与[RFC5157]第2.3节中描述的使用SLAAC（当知道以太网卡的供应商时）配置的地址所需的24位搜索空间相比非常有利。如果没有12个随机位，搜索空间仅限于16位，这明显比SLAAC提供的24位搜索空间差。
As the knowledge of the attacker decreases, the number of bits of search space in both cases is likely to increase in a relatively similar fashion. The predictability of Teredo addresses will stay comparable to that of SLAAC addresses with the added 12 bits of search space, but will be significantly worse without the random bits.
随着攻击者知识的减少，两种情况下的搜索空间位数可能会以相对相似的方式增加。Teredo地址的可预测性将与添加了12位搜索空间的SLAAC地址的可预测性相当，但如果没有随机位，则可预测性将显著降低。
Authors' Addresses
作者地址
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
James Hoagland Symantec Corporation 350 Ellis St. Mountain View, CA 94043 USA
詹姆斯·霍格兰·赛门铁克公司美国加利福尼亚州埃利斯圣山景城350号，邮编94043
EMail: Jim_Hoagland@symantec.com
URI: http://symantec.com/
EMail: Jim_Hoagland@symantec.com
URI: http://symantec.com/