Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7707 Huawei Technologies
Obsoletes: 5157 T. Chown
Category: Informational Jisc
ISSN: 2070-1721 March 2016
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7707 Huawei Technologies
Obsoletes: 5157 T. Chown
Category: Informational Jisc
ISSN: 2070-1721 March 2016
Network Reconnaissance in IPv6 Networks
IPv6网络中的网络侦察
Abstract
摘要
IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.
IPv6提供了比IPv4更大的地址空间。大小为/64的IPv6子网（理论上）可以容纳大约1.844*10^19个主机，从而导致主机密度（主机/地址）比IPv4网络中的主机密度低得多，IPv4网络中的站点通常具有65000个或更少的唯一地址。因此，人们普遍认为对IPv6网络进行地址扫描攻击需要付出巨大的努力；因此，IPv6地址扫描攻击被认为是不可行的。本文件通过进一步分析传统地址扫描技术如何应用于IPv6网络并探索可用于IPv6网络侦察的其他技术，正式废除了RFC 5157，RFC 5157首先讨论了这一假设。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7707.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7707.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for the Applicability of Network Reconnaissance
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 6
4.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
4.1.1. Stateless Address Autoconfiguration (SLAAC) . . . . . 6
4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 11
4.1.3. Manually Configured Addresses . . . . . . . . . . . . 12
4.1.4. IPv6 Addresses Corresponding to
Transition/Coexistence Technologies . . . . . . . . . 14
4.1.5. IPv6 Address Assignment in Real-World Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
4.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17
4.2.1. Reducing the Subnet ID Search Space . . . . . . . . . 18
4.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 19
4.4. Existing IPv6 Address-Scanning Tools . . . . . . . . . . 20
4.4.1. Remote IPv6 Network Address Scanners . . . . . . . . 20
4.4.2. Local IPv6 Network Address Scanners . . . . . . . . . 21
4.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22
5. Alternative Methods to Glean IPv6 Addresses . . . . . . . . . 23
5.1. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . 23
5.1.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . 23
5.1.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . 23
5.1.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . 24
5.2. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Public Archives . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements for the Applicability of Network Reconnaissance
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv6 Address Scanning . . . . . . . . . . . . . . . . . . . . 6
4.1. Address Configuration in IPv6 . . . . . . . . . . . . . . 6
4.1.1. Stateless Address Autoconfiguration (SLAAC) . . . . . 6
4.1.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 11
4.1.3. Manually Configured Addresses . . . . . . . . . . . . 12
4.1.4. IPv6 Addresses Corresponding to
Transition/Coexistence Technologies . . . . . . . . . 14
4.1.5. IPv6 Address Assignment in Real-World Network
Scenarios . . . . . . . . . . . . . . . . . . . . . . 14
4.2. IPv6 Address Scanning of Remote Networks . . . . . . . . 17
4.2.1. Reducing the Subnet ID Search Space . . . . . . . . . 18
4.3. IPv6 Address Scanning of Local Networks . . . . . . . . . 19
4.4. Existing IPv6 Address-Scanning Tools . . . . . . . . . . 20
4.4.1. Remote IPv6 Network Address Scanners . . . . . . . . 20
4.4.2. Local IPv6 Network Address Scanners . . . . . . . . . 21
4.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 21
4.6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 22
5. Alternative Methods to Glean IPv6 Addresses . . . . . . . . . 23
5.1. Leveraging the Domain Name System (DNS) for Network
Reconnaissance . . . . . . . . . . . . . . . . . . . . . 23
5.1.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . 23
5.1.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . 23
5.1.3. DNS Brute Forcing . . . . . . . . . . . . . . . . . . 23
5.1.4. DNS Reverse Mappings . . . . . . . . . . . . . . . . 24
5.2. Leveraging Local Name Resolution and Service Discovery
Services . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Public Archives . . . . . . . . . . . . . . . . . . . . . 25
5.4. Application Participation . . . . . . . . . . . . . . . . 25
5.5. Inspection of the IPv6 Neighbor Cache and Routing Table . 25
5.6. Inspection of System Configuration and Log Files . . . . 26
5.7. Gleaning Information from Routing Protocols . . . . . . . 26
5.8. Gleaning Information from IP Flow Information Export
(IPFIX) . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9. Obtaining Network Information with traceroute6 . . . . . 26
5.10. Gleaning Information from Network Devices Using SNMP . . 27
5.11. Obtaining Network Information via Traffic Snooping . . . 27
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation of a Full-Fledged IPv6 Address-
Scanning Tool . . . . . . . . . . . . . . . . . . . 34
A.1. Host-Probing Considerations . . . . . . . . . . . . . . . 34
A.2. Implementation of an IPv6 Local Address-Scanning Tool . . 35
A.3. Implementation of an IPv6 Remote Address-Scanning Tool . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
5.4. Application Participation . . . . . . . . . . . . . . . . 25
5.5. Inspection of the IPv6 Neighbor Cache and Routing Table . 25
5.6. Inspection of System Configuration and Log Files . . . . 26
5.7. Gleaning Information from Routing Protocols . . . . . . . 26
5.8. Gleaning Information from IP Flow Information Export
(IPFIX) . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9. Obtaining Network Information with traceroute6 . . . . . 26
5.10. Gleaning Information from Network Devices Using SNMP . . 27
5.11. Obtaining Network Information via Traffic Snooping . . . 27
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation of a Full-Fledged IPv6 Address-
Scanning Tool . . . . . . . . . . . . . . . . . . . 34
A.1. Host-Probing Considerations . . . . . . . . . . . . . . . 34
A.2. Implementation of an IPv6 Local Address-Scanning Tool . . 35
A.3. Implementation of an IPv6 Remote Address-Scanning Tool . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
The main driver for IPv6 [RFC2460] deployment is its larger address space [CPNI-IPv6]. This larger address space not only allows for an increased number of connected devices but also introduces a number of subtle changes in several aspects of the resulting networks. One of these changes is the reduced host density (the number of hosts divided by the number of addresses) of typical IPv6 subnetworks, when compared to their IPv4 counterparts. [RFC5157] describes how this significantly lower IPv6 host density is likely to make classic network address-scanning attacks less feasible, since even by applying various heuristics, the address space to be scanned remains very large. RFC 5157 goes on to describe some alternative methods for attackers to glean active IPv6 addresses and provides some guidance for administrators and implementors, e.g., not using sequential addresses with DHCPv6.
IPv6[RFC2460]部署的主要驱动因素是其更大的地址空间[CPNI-IPv6]。这种更大的地址空间不仅允许增加连接设备的数量，而且在产生的网络的几个方面引入了一些微妙的变化。其中一个变化是，与IPv4子网相比，典型IPv6子网的主机密度降低（主机数量除以地址数量）。[RFC5157]描述了IPv6主机密度显著降低可能会降低传统网络地址扫描攻击的可行性，因为即使应用各种启发式方法，要扫描的地址空间仍然非常大。RFC 5157接着描述了攻击者收集活动IPv6地址的一些替代方法，并为管理员和实施者提供了一些指导，例如，不在DHCPv6中使用顺序地址。
With the benefit of more than five years of additional IPv6 deployment experience, this document formally obsoletes RFC 5157. It emphasizes that while address-scanning attacks are less feasible, they may, with appropriate heuristics, remain possible. At the time that RFC 5157 was written, observed address-scanning attacks were typically across ports on the addresses of discovered servers; since then, evidence that some classic address scanning is occurring is being witnessed. This text thus updates the analysis on the feasibility of address-scanning attacks in IPv6 networks, and it
得益于五年多的IPv6部署经验，本文档正式淘汰了RFC 5157。它强调，虽然地址扫描攻击不太可行，但通过适当的启发式，它们仍然是可能的。在编写RFC 5157时，观察到的地址扫描攻击通常跨越发现的服务器地址上的端口；从那时起，一些经典地址扫描正在发生的证据正在被证实。因此，本文更新了对IPv6网络中地址扫描攻击可行性的分析，并
explores a number of additional techniques that can be employed for IPv6 network reconnaissance. Practical examples and guidance are also included in the appendices.
探索可用于IPv6网络侦察的许多其他技术。附录中还包括了实际示例和指南。
On one hand, raising awareness about IPv6 network reconnaissance techniques may allow (in some cases) network and security administrators to prevent or detect such attempts. On the other hand, network reconnaissance is essential for the so-called "penetration tests" typically performed to assess the security of production networks. As a result, we believe the benefits of a thorough discussion of IPv6 network reconnaissance are twofold.
一方面，提高对IPv6网络侦察技术的认识可能（在某些情况下）允许网络和安全管理员阻止或检测此类尝试。另一方面，网络侦察对于通常用于评估生产网络安全性的所谓“渗透测试”至关重要。因此，我们认为深入讨论IPv6网络侦察的好处是双重的。
Section 4 analyzes the feasibility of address-scanning attacks (e.g., ping sweeps) in IPv6 networks and explores a number of possible improvements to such techniques. Appendix A describes how the aforementioned analysis can be leveraged to produce address-scanning tools (e.g., for penetration testing purposes). Finally, the rest of this document discusses a number of miscellaneous techniques that could be leveraged for IPv6 network reconnaissance.
第4节分析了IPv6网络中地址扫描攻击（如ping扫描）的可行性，并探讨了对此类技术的一些可能改进。附录A描述了如何利用上述分析生成地址扫描工具（例如，用于渗透测试）。最后，本文档的其余部分将讨论可用于IPv6网络侦察的多种技术。
Throughout this document, we consider that bits are numbered from left to right, starting at 0, and that bytes are numbered from left to right, starting at 0.
在整个文档中，我们认为从左到右编号从0开始，字节从左到右编号，从0开始。
3. Requirements for the Applicability of Network Reconnaissance Techniques
3. 网络侦察技术的适用性要求
Throughout this document, a number of network reconnaissance techniques are discussed. Each of these techniques has different requirements on the side of the practitioner, with respect to whether they require local access to the target network and whether they require login access (or similar access credentials) to the system on which the technique is applied.
在本文件中，讨论了许多网络侦察技术。这些技术中的每一种对于从业者来说都有不同的要求，关于它们是否需要对目标网络的本地访问，以及它们是否需要对应用该技术的系统的登录访问（或类似的访问凭证）。
The following table tries to summarize the aforementioned requirements and serves as a cross index to the corresponding sections.
下表试图总结上述要求，并作为相应章节的交叉索引。
+---------------------------------------------+----------+----------+
| Technique | Local | Login |
| | access | access |
+---------------------------------------------+----------+----------+
| Remote Address Scanning (Section 4.2) | No | No |
+---------------------------------------------+----------+----------+
| Local Address Scanning (Section 4.3) | Yes | No |
+---------------------------------------------+----------+----------+
| DNS Advertised Hosts (Section 5.1.1) | No | No |
+---------------------------------------------+----------+----------+
| DNS Zone Transfers (Section 5.1.2) | No | No |
+---------------------------------------------+----------+----------+
| DNS Brute Forcing (Section 5.1.3) | No | No |
+---------------------------------------------+----------+----------+
| DNS Reverse Mappings (Section 5.1.4) | No | No |
+---------------------------------------------+----------+----------+
| Leveraging Local Name Resolution and | Yes | No |
| Service Discovery Services (Section 5.2) | | |
+---------------------------------------------+----------+----------+
| Public Archives (Section 5.3) | No | No |
+---------------------------------------------+----------+----------+
| Application Participation (Section 5.4) | No | No |
+---------------------------------------------+----------+----------+
| Inspection of the IPv6 Neighbor Cache and | No | Yes |
| Routing Table (Section 5.5) | | |
+---------------------------------------------+----------+----------+
| Inspecting System Configuration and Log | No | Yes |
| Files (Section 5.6) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from Routing Protocols | Yes | No |
| (Section 5.7) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from IP Flow | No | Yes |
| Information Export (IPFIX) (Section 5.8) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information with | No | No |
| traceroute6 (Section 5.9) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from Network Devices | No | Yes |
| Using SNMP (Section 5.10) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information via Traffic | Yes | No |
| Snooping (Section 5.11) | | |
+---------------------------------------------+----------+----------+
+---------------------------------------------+----------+----------+
| Technique | Local | Login |
| | access | access |
+---------------------------------------------+----------+----------+
| Remote Address Scanning (Section 4.2) | No | No |
+---------------------------------------------+----------+----------+
| Local Address Scanning (Section 4.3) | Yes | No |
+---------------------------------------------+----------+----------+
| DNS Advertised Hosts (Section 5.1.1) | No | No |
+---------------------------------------------+----------+----------+
| DNS Zone Transfers (Section 5.1.2) | No | No |
+---------------------------------------------+----------+----------+
| DNS Brute Forcing (Section 5.1.3) | No | No |
+---------------------------------------------+----------+----------+
| DNS Reverse Mappings (Section 5.1.4) | No | No |
+---------------------------------------------+----------+----------+
| Leveraging Local Name Resolution and | Yes | No |
| Service Discovery Services (Section 5.2) | | |
+---------------------------------------------+----------+----------+
| Public Archives (Section 5.3) | No | No |
+---------------------------------------------+----------+----------+
| Application Participation (Section 5.4) | No | No |
+---------------------------------------------+----------+----------+
| Inspection of the IPv6 Neighbor Cache and | No | Yes |
| Routing Table (Section 5.5) | | |
+---------------------------------------------+----------+----------+
| Inspecting System Configuration and Log | No | Yes |
| Files (Section 5.6) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from Routing Protocols | Yes | No |
| (Section 5.7) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from IP Flow | No | Yes |
| Information Export (IPFIX) (Section 5.8) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information with | No | No |
| traceroute6 (Section 5.9) | | |
+---------------------------------------------+----------+----------+
| Gleaning Information from Network Devices | No | Yes |
| Using SNMP (Section 5.10) | | |
+---------------------------------------------+----------+----------+
| Obtaining Network Information via Traffic | Yes | No |
| Snooping (Section 5.11) | | |
+---------------------------------------------+----------+----------+
Table 1: Requirements for the Applicability of Network Reconnaissance Techniques
表1：网络侦察技术的适用性要求
This section discusses how traditional address-scanning techniques (e.g., "ping sweeps") apply to IPv6 networks. Section 4.1 provides an essential analysis of how address configuration is performed in IPv6, identifying patterns in IPv6 addresses that can be leveraged to reduce the IPv6 address search space when performing IPv6 address-scanning attacks. Section 4.2 discusses IPv6 address scanning of remote networks. Section 4.3 discusses IPv6 address scanning of local networks. Section 4.4 discusses existing IPv6 address-scanning tools. Section 4.5 provides advice on how to mitigate IPv6 address-scanning attacks. Finally, Appendix A discusses how the insights obtained in the following subsections can be incorporated into a fully fledged IPv6 address-scanning tool.
本节讨论传统地址扫描技术（例如，“ping扫描”）如何应用于IPv6网络。第4.1节提供了对IPv6中如何执行地址配置的基本分析，确定了在执行IPv6地址扫描攻击时可用于减少IPv6地址搜索空间的IPv6地址中的模式。第4.2节讨论远程网络的IPv6地址扫描。第4.3节讨论本地网络的IPv6地址扫描。第4.4节讨论了现有的IPv6地址扫描工具。第4.5节提供了有关如何减轻IPv6地址扫描攻击的建议。最后，附录A讨论了如何将在以下小节中获得的见解整合到一个成熟的IPv6地址扫描工具中。
IPv6 incorporates two automatic address-configuration mechanisms: Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Support for SLAAC for automatic address configuration is mandatory, while support for DHCPv6 is optional -- however, most current versions of general-purpose operating systems support both. In addition to automatic address configuration, hosts, typically servers, may employ manual configuration, in which all the necessary information is manually entered by the host or network administrator into configuration files at the host.
IPv6包含两种自动地址配置机制：无状态地址自动配置（SLAAC）[RFC4862]和IPv6动态主机配置协议（DHCPv6）[RFC3315]。对SLAAC的自动地址配置支持是强制性的，而对DHCPv6的支持是可选的——然而，大多数通用操作系统的当前版本都支持这两种功能。除了自动地址配置之外，主机（通常是服务器）还可以采用手动配置，其中所有必要的信息都由主机或网络管理员手动输入到主机的配置文件中。
The following subsections describe each of the possible configuration mechanisms/approaches in more detail.
以下小节更详细地描述了每种可能的配置机制/方法。
The basic idea behind SLAAC is that every host joining a network will send a multicasted solicitation requesting network configuration information, and local routers will respond to the request providing the necessary information. SLAAC employs two different ICMPv6 message types: ICMPv6 Router Solicitation and ICMPv6 Router Advertisement messages. Router Solicitation messages are employed by hosts to query local routers for configuration information, while Router Advertisement messages are employed by local routers to convey the requested information.
SLAAC背后的基本思想是，每个加入网络的主机将发送一个多播请求，请求网络配置信息，本地路由器将响应请求，提供必要的信息。SLAAC使用两种不同的ICMPv6消息类型：ICMPv6路由器请求和ICMPv6路由器广告消息。主机使用路由器请求消息来查询本地路由器的配置信息，而本地路由器使用路由器广告消息来传递请求的信息。
Router Advertisement messages convey a plethora of network configuration information, including the IPv6 prefix that should be used for configuring IPv6 addresses on the local network. For each local prefix learned from a Router Advertisement message, an IPv6 address is configured by appending a locally generated Interface Identifier (IID) to the corresponding IPv6 prefix.
路由器广告消息传递大量网络配置信息，包括用于在本地网络上配置IPv6地址的IPv6前缀。对于从路由器广告消息学习到的每个本地前缀，通过将本地生成的接口标识符（IID）附加到相应的IPv6前缀来配置IPv6地址。
The following subsections describe currently deployed policies for generating the IIDs used with SLAAC.
以下小节描述了用于生成SLAAC使用的IID的当前部署的策略。
The traditional SLAAC IIDs are based on the link-layer address of the corresponding network interface card. For example, in the case of Ethernet addresses, the IIDs are constructed as follows:
传统的SLAAC IID基于相应网络接口卡的链路层地址。例如，在以太网地址的情况下，IID的构造如下：
1. The "Universal" bit (bit 6, from left to right) of the address is set to 1.
1. 地址的“通用”位（从左到右的第6位）设置为1。
2. The word 0xfffe is inserted between the Organizationally Unique Identifier (OUI) and the rest of the Ethernet address.
2. 字0xfffe插入到组织唯一标识符（OUI）和以太网地址的其余部分之间。
For example, the Media Access Control (MAC) address 00:1b:38:83:88:3c would lead to the IID 021b:38ff:fe83:883c.
例如，媒体访问控制（MAC）地址00:1b:38:83:88:3c将导致IID 021b:38ff:fe83:883c。
A number of considerations should be made about these identifiers. Firstly, one 16-bit word (bytes 3-4) of the resulting address always has a fixed value (0xfffe), thus reducing the search space for the IID. Secondly, the high-order three bytes of the IID correspond to the OUI of the network interface card vendor. Since not all possible OUIs have been assigned, this further reduces the IID search space. Furthermore, of the assigned OUIs, many could be regarded as corresponding to legacy devices and thus are unlikely to be used for Internet-connected IPv6-enabled systems, yet further reducing the IID search space. Finally, in some scenarios, it could be possible to infer the OUI in use by the target network devices, yet narrowing down the possible IIDs even more.
对于这些标识符，应考虑一些因素。首先，结果地址的一个16位字（字节3-4）始终具有固定值（0xfffe），从而减少IID的搜索空间。其次，IID的高阶三个字节对应于网络接口卡供应商的OUI。由于没有分配所有可能的OUI，这进一步减少了IID搜索空间。此外，在分配的OUI中，许多OUI可被视为与遗留设备相对应，因此不太可能用于支持IPv6的互联网连接系统，但进一步减少了IID搜索空间。最后，在某些场景中，可以推断目标网络设备正在使用的OUI，但可以进一步缩小可能的IID。
NOTE: For example, an organization known for being provisioned by vendor X is likely to have most of the nodes in its organizational network with OUIs corresponding to vendor X.
注意：例如，已知由供应商X提供的组织可能在其组织网络中具有与供应商X对应的OUI的大多数节点。
These considerations mean that in some scenarios, the original IID search space of 64 bits may be effectively reduced to 2^24 or n * 2^24 (where "n" is the number of different OUIs assigned to the target vendor).
这些考虑意味着，在某些情况下，64位的原始IID搜索空间可以有效地减少到2^24或n*2^24（其中“n”是分配给目标供应商的不同OUI的数量）。
Furthermore, if just one host address is detected or known within a subnet, it is not unlikely that, if systems were ordered in a batch, they may have sequential MAC addresses. Additionally, given a MAC address observed in one subnet, sequential or nearby MAC addresses may be seen in other subnets in the same site.
此外，如果在一个子网中只检测到或知道一个主机地址，则如果系统是批量订购的，则它们可能具有顺序MAC地址。此外，给定在一个子网中观察到的MAC地址，在同一站点的其他子网中可能会看到顺序或附近的MAC地址。
NOTE: [RFC7136] notes that all bits of an IID should be treated as "opaque" bits. Furthermore, [DEFAULT-IIDS] is currently in the process of changing the default IID generation scheme to align with [RFC7217] (as described below in Section 4.1.1.5), such that IIDs are semantically opaque and do not follow any patterns. Therefore, the traditional IIDs based on link-layer addresses are expected to become less common over time.
注：[RFC7136]注意IID的所有位都应被视为“不透明”位。此外，[DEFAULT-IID]目前正在更改默认IID生成方案，以与[RFC7217]保持一致（如下文第4.1.1.5节所述），从而使IID在语义上不透明，不遵循任何模式。因此，随着时间的推移，基于链路层地址的传统IID预计将变得越来越不常见。
IIDs resulting from virtualization technologies can be considered a specific subcase of IIDs embedding IEEE identifiers (please see Section 4.1.1.1): they employ IEEE identifiers, but part of the IID has specific patterns. The following subsections describe IIDs of some popular virtualization technologies.
虚拟化技术产生的IID可被视为嵌入IEEE标识符的IID的特定子类别（请参见第4.1.1.1节）：它们使用IEEE标识符，但IID的一部分具有特定模式。以下小节介绍了一些流行虚拟化技术的IID。
All automatically generated MAC addresses in VirtualBox virtual machines employ the OUI 08:00:27 [VBox2011]. This means that all addresses resulting from traditional SLAAC will have an IID of the form a00:27ff:feXX:XXXX, thus effectively reducing the IID search space from 64 bits to 24 bits.
VirtualBox虚拟机中所有自动生成的MAC地址都采用OUI 08:00:27[VBox2011]。这意味着由传统SLAAC生成的所有地址都将具有a00:27ff:feXX:XXXX形式的IID，从而有效地将IID搜索空间从64位减少到24位。
The VMware ESX server (versions 1.0 to 2.5) provides yet a more interesting example. Automatically generated MAC addresses have the following pattern [vmesx2011]:
VMware ESX server（版本1.0到2.5）提供了一个更有趣的示例。自动生成的MAC地址具有以下模式[vmesx2011]：
1. The OUI is set to 00:05:69.
1. OUI设置为00:05:69。
2. The next 16 bits of the MAC address are set to the same value as the last 16 bits of the console operating system's primary IPv4 address.
2. MAC地址的下16位设置为与控制台操作系统主IPv4地址的最后16位相同的值。
3. The final 8 bits of the MAC address are set to a hash value based on the name of the virtual machine's configuration file.
3. MAC地址的最后8位根据虚拟机配置文件的名称设置为哈希值。
This means that, assuming the console operating system's primary IPv4 address is known, the IID search space is reduced from 64 bits to 8 bits.
这意味着，假设控制台操作系统的主IPv4地址已知，IID搜索空间将从64位减少到8位。
On the other hand, manually configured MAC addresses in the VMware ESX server employ the OUI 00:50:56, with the low-order three bytes of the MAC address being in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products). Therefore, even in the case of manually configured MAC addresses, the IID search space is reduced from 64 bits to 22 bits.
另一方面，VMware ESX server中手动配置的MAC地址采用OUI 00:50:56，MAC地址的低三个字节在00:00:00-3F:FF:FF范围内（以避免与其他VMware产品发生冲突）。因此，即使在手动配置MAC地址的情况下，IID搜索空间也从64位减少到22位。
VMware vSphere [vSphere] supports these default MAC address generation algorithms:
VMware vSphere[vSphere]支持以下默认MAC地址生成算法：
o Generated addresses
o 生成地址
* Assigned by the vCenter server
* 由vCenter服务器分配
* Assigned by the ESXi host
* 由ESXi主机分配
o Manually configured addresses
o 手动配置的地址
By default, MAC addresses assigned by the vCenter server use the OUI 00:50:56 and have the format 00:50:56:XX:YY:ZZ, where XX is calculated as (0x80 + vCenter Server ID (in the range 0x00-0x3F)), and XX and YY are random two-digit hexadecimal numbers. Thus, the possible IID range is 00:50:56:80:00:00-00:50:56:BF:FF:FF; therefore, the search space for the resulting SLAAC addresses will be 22 bits.
默认情况下，vCenter server分配的MAC地址使用OUI 00:50:56，格式为00:50:56:XX:YY:ZZ，其中XX计算为（0x80+vCenter server ID（范围0x00-0x3F）），XX和YY为随机两位十六进制数。因此，可能的IID范围是00:50:56:80:00:00-00:50:56:BF:FF:FF；因此，结果SLAAC地址的搜索空间将为22位。
MAC addresses generated by the ESXi host use the OUI 00:0C:29 and have the format 00:0C:29:XX:YY:ZZ, where XX, YY, and ZZ are the last three octets in hexadecimal format of the virtual machine Universally Unique Identifier (UUID) (based on a hash calculated with the UUID of the ESXi physical machine and the path to a configuration file). Thus, the MAC addresses will be in the range 00:0C:29:00:00:00-00:0C:29:FF:FF:FF; therefore, the search space for the resulting SLAAC addresses will be 24 bits.
ESXi主机生成的MAC地址使用OUI 00:0C:29，格式为00:0C:29:XX:YY:ZZ，其中XX、YY和ZZ是虚拟机通用唯一标识符（UUID）的十六进制格式的最后三个八位字节（基于使用ESXi物理机的UUID和配置文件路径计算的哈希）。因此，MAC地址将在范围00:0C:29:00:00-00:0C:29:FF:FF；因此，结果SLAAC地址的搜索空间将为24位。
Finally, manually configured MAC addresses employ the OUI 00:50:56, with the low-order three bytes being in the range 00:00:00-3F:FF:FF (to avoid conflicts with other VMware products). Therefore, the resulting MAC addresses will be in the range 00:50:56:00:00:00-00:50:56:3F:FF:FF, and the search space for the corresponding SLAAC addresses will be 22 bits.
最后，手动配置的MAC地址使用OUI 00:50:56，低阶三个字节的范围为00:00:00-3F:FF:FF（以避免与其他VMware产品发生冲突）。因此，生成的MAC地址将在00:50:56:00:00-00:50:56:3F:FF:FF范围内，相应SLAAC地址的搜索空间将为22位。
Privacy concerns [Gont-DEEPSEC2011] [RFC7721] regarding IIDs embedding IEEE identifiers led to the introduction of "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941], also known as "temporary addresses" or "privacy addresses". Essentially, "temporary addresses" produce random addresses by concatenating a random identifier to the autoconfiguration IPv6 prefix advertised in a Router Advertisement message.
关于嵌入IEEE标识符的IID的隐私问题[Gont-DEEPSEC2011][RFC7721]导致了“IPv6中无状态地址自动配置的隐私扩展”[RFC4941]，也称为“临时地址”或“隐私地址”。本质上，“临时地址”通过将随机标识符连接到路由器广告消息中广告的自动配置IPv6前缀来生成随机地址。
NOTE: In addition to their unpredictability, these addresses are typically short-lived, such that even if an attacker were to learn of one of these addresses, they would be of use for a limited period of time. A typical implementation may keep a temporary address preferred for 24 hours, and configured but deprecated for seven days.
注意：除了它们的不可预测性之外，这些地址通常是短暂的，因此即使攻击者知道其中一个地址，它们也会在有限的时间内有用。典型的实现可能会将临时地址首选保留24小时，并将其配置但不推荐保留7天。
It is important to note that "temporary addresses" are generated in addition to the stable addresses [RFC7721] (such as the traditional SLAAC addresses based on IEEE identifiers): stable SLAAC addresses are meant to be employed for "server-like" inbound communications, while "temporary addresses" are meant to be employed for "client-like" outbound communications. This means that implementation/use of "temporary addresses" does not prevent an attacker from leveraging the predictability of stable SLAAC addresses, since "temporary addresses" are generated in addition to (rather than as a replacement of) the stable SLAAC addresses (such as those derived from IEEE identifiers).
需要注意的是，“临时地址”是在稳定地址[RFC7721]（例如基于IEEE标识符的传统SLAAC地址）之外生成的：稳定SLAAC地址用于“服务器式”入站通信，而“临时地址”用于“客户端式”入站通信对外通信。这意味着“临时地址”的实现/使用并不能阻止攻击者利用稳定SLAAC地址的可预测性，因为“临时地址”是在稳定SLAAC地址（例如从IEEE标识符派生的地址）之外生成的（而不是替换）。
The benefit that temporary addresses offer in this context is that they reduce the exposure of the host addresses to any third parties that may observe traffic sent from a host where temporary addresses are enabled and used by default. But, in the absence of firewall protection for the host, its stable SLAAC address remains liable to be scanned from off-site.
在此上下文中，临时地址提供的好处是，它们减少了主机地址对任何第三方的暴露，这些第三方可能会观察到从默认启用和使用临时地址的主机发送的通信量。但是，在主机没有防火墙保护的情况下，其稳定的SLAAC地址仍然容易从非现场进行扫描。
In order to mitigate the security implications arising from the predictable IPv6 addresses derived from IEEE identifiers, Microsoft Windows produced an alternative scheme for generating "stable addresses" (in replacement of the ones embedding IEEE identifiers). The aforementioned scheme is believed to be an implementation of RFC 4941 [RFC4941], but without regenerating the addresses over time. The resulting IIDs are constant across system bootstraps, and also constant across networks.
为了减轻由IEEE标识符派生的可预测IPv6地址所带来的安全影响，Microsoft Windows提供了一种生成“稳定地址”的替代方案（替代嵌入IEEE标识符的方案）。上述方案被认为是RFC4941[RFC4941]的实现，但是没有随着时间的推移重新生成地址。由此产生的IID在系统引导过程中是恒定的，在网络中也是恒定的。
Assuming no flaws in the aforementioned algorithm, this scheme would remove any patterns from the SLAAC addresses.
假设上述算法没有缺陷，该方案将从SLAAC地址中删除任何模式。
NOTE: However, since the resulting IIDs are constant across networks, these addresses may still be leveraged for host-tracking purposes [RFC7217] [RFC7721].
注意：但是，由于产生的IID在网络中是恒定的，因此这些地址仍然可以用于主机跟踪目的[RFC7217][RFC7721]。
The benefit of this scheme is thus that the host may be less readily detected by applying heuristics to an address-scanning attack, but, in the absence of concurrent use of temporary addresses, the host is liable to be tracked across visited networks.
因此，该方案的优点是，通过将启发式应用于地址扫描攻击，主机可能不太容易被检测到，但是，在没有同时使用临时地址的情况下，主机容易在访问的网络中被跟踪。
In response to the predictability issues discussed in Section 4.1.1.1 and the privacy issues discussed in [RFC7721], the IETF has standardized (in [RFC7217]) a method for generating IPv6 IIDs to be used with IPv6 SLAAC, such that addresses configured using this method are stable within each subnet, but the IIDs change when hosts move from one subnet to another. The aforementioned method is meant to be an alternative to generating IIDs based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users.
为了响应第4.1.1.1节中讨论的可预测性问题和[RFC7721]中讨论的隐私问题，IETF（在[RFC7217]中）标准化了一种生成IPv6 IID的方法，该方法将与IPv6 SLAAC一起使用，以便使用该方法配置的地址在每个子网中都是稳定的，但当主机从一个子网移动到另一个子网时，IID会发生变化。上述方法是基于IEEE标识符生成IID的替代方法，这样可以在不牺牲用户隐私的情况下实现稳定地址的好处。
Implementation of this method (in replacement of IIDs based on IEEE identifiers) eliminates any patterns from the IID, thus benefiting user privacy and reducing the ease with which addresses can be scanned.
此方法的实现（替换基于IEEE标识符的IID）消除了IID中的任何模式，从而有利于用户隐私并降低了地址扫描的难度。
DHCPv6 can be employed as a stateful address configuration mechanism, in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 hosts. As with the IPv4 counterpart, addresses are assigned according to a configuration-defined address range and policy, with some DHCPv6 servers assigning addresses sequentially, from a specific range. In such cases, addresses tend to be predictable.
DHCPv6可以用作有状态地址配置机制，其中服务器（DHCPv6服务器）将IPv6地址出租给IPv6主机。与IPv4对应方一样，地址是根据配置定义的地址范围和策略分配的，一些DHCPv6服务器从特定范围按顺序分配地址。在这种情况下，地址往往是可预测的。
NOTE: For example, if the prefix 2001:db8::/64 is used for assigning addresses on the local network, the DHCPv6 server might (sequentially) assign addresses from the range 2001:db8::1 - 2001:db8::100.
注意：例如，如果前缀2001:db8:：/64用于分配本地网络上的地址，DHCPv6服务器可能（顺序）分配范围为2001:db8:：1-2001:db8:：100的地址。
In most common scenarios, this means that the IID search space will be reduced from the original 64 bits to 8 or 16 bits. [RFC5157] recommended that DHCPv6 instead issue addresses randomly from a large
在大多数常见情况下，这意味着IID搜索空间将从原来的64位减少到8或16位。[RFC5157]建议DHCPv6改为从大型数据库中随机发布地址
pool; that advice is repeated here. [IIDS-DHCPv6] specifies an algorithm that can be employed by DHCPv6 servers to produce stable addresses that do not follow any specific pattern, thus resulting in an IID search space of 64 bits.
水塘这里重复这一建议。[IIDS-DHCPv6]指定一种算法，DHCPv6服务器可以使用该算法生成不遵循任何特定模式的稳定地址，从而产生64位的IID搜索空间。
In some scenarios, node addresses may be manually configured. This is typically the case for IPv6 addresses assigned to routers (since routers do not employ automatic address configuration) but also for servers (since having a stable address that does not depend on the underlying link-layer address is generally desirable).
在某些情况下，可以手动配置节点地址。这通常适用于分配给路由器的IPv6地址（因为路由器不采用自动地址配置），也适用于服务器（因为通常需要具有不依赖于底层链路层地址的稳定地址）。
While network administrators are mostly free to select the IID from any value in the range 1 - 2^64, for the sake of simplicity (i.e., ease of remembering), they tend to select addresses with one of the following patterns:
虽然网络管理员通常可以从1-2^64范围内的任何值中自由选择IID，但为了简单起见（即易于记忆），他们倾向于使用以下模式之一选择地址：
o low-byte addresses: in which most of the bytes of the IID are set to 0 (except for the least significant byte)
o 低字节地址：其中IID的大部分字节设置为0（最低有效字节除外）
o IPv4-based addresses: in which the IID embeds the IPv4 address of the network interface (as in 2001:db8::192.0.2.1)
o 基于IPv4的地址：IID将网络接口的IPv4地址嵌入其中（如2001年：db8:：192.0.2.1）
o service port addresses: in which the IID embeds the TCP/UDP service port of the main service running on that node (as in 2001:db8::80 or 2001:db8::25)
o 服务端口地址：IID在其中嵌入在该节点上运行的主服务的TCP/UDP服务端口（如2001年：db8:：80或2001年：db8:：25）
o wordy addresses: which encode words (as in 2001:db8::bad:cafe)
o wordy地址：对单词进行编码的地址（如2001:db8:：bad:cafe）
Each of these patterns is discussed in detail in the following subsections.
以下小节将详细讨论这些模式中的每一种。
The most common form of low-byte addresses is that in which all the
bytes of the IID (except the least significant bytes) are set to zero
(as in 2001:db8::1, 2001:db8::2, etc.). However, it is also common
to find similar addresses in which the two lowest-order 16-bit words
(from the right to left) are set to small numbers (as in
2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to
find IPv6 addresses in which the second lowest-order 16-bit word
(from right to left) is set to a small value in the range
0x0000:0x00ff, while the lowest-order 16-bit word (from right to
left) varies in the range 0x0000:0xffff. It should be noted that all
of these address patterns are generally referred to as "low-byte
The most common form of low-byte addresses is that in which all the
bytes of the IID (except the least significant bytes) are set to zero
(as in 2001:db8::1, 2001:db8::2, etc.). However, it is also common
to find similar addresses in which the two lowest-order 16-bit words
(from the right to left) are set to small numbers (as in
2001::db8::1:10, 2001:db8::2:10, etc.). Yet it is not uncommon to
find IPv6 addresses in which the second lowest-order 16-bit word
(from right to left) is set to a small value in the range
0x0000:0x00ff, while the lowest-order 16-bit word (from right to
left) varies in the range 0x0000:0xffff. It should be noted that all
of these address patterns are generally referred to as "low-byte
addresses", even when, strictly speaking, it is not only the lowest-order byte of the IPv6 address that varies from one address to another.
“地址”，即使严格来说，IPv6地址的最低顺序字节在不同的地址之间也不尽相同。
In the worst-case scenario, the search space for this pattern is 2^24 (although most systems can be found by searching 2^16 or even 2^8 addresses).
在最坏的情况下，此模式的搜索空间为2^24（尽管大多数系统可以通过搜索2^16甚至2^8个地址找到）。
The most common form of these addresses is that in which an IPv4 address is encoded in the lowest-order 32 bits of the IPv6 address (usually as a result of the address notation of the form 2001:db8::192.0.2.1). However, it is also common for administrators to encode each of the bytes of the IPv4 address in each of the 16-bit words of the IID (as in, e.g., 2001:db8::192:0:2:1).
这些地址最常见的形式是IPv4地址以IPv6地址的最低32位进行编码（通常是2001:db8:：192.0.2.1形式的地址表示法的结果）。然而，管理员在IID的每个16位字中对IPv4地址的每个字节进行编码也是很常见的（例如，在2001:db8:：192:0:2:1中）。
Therefore, the search space for addresses following this pattern is that of the corresponding IPv4 prefix (or twice the size of that search space if both forms of "IPv4-based addresses" are to be searched).
因此，遵循此模式的地址的搜索空间是相应IPv4前缀的搜索空间（如果要搜索两种形式的“基于IPv4的地址”，则是该搜索空间大小的两倍）。
Addresses following this pattern include the service port (e.g., 80 for HTTP) in the lowest-order byte of the IID and have the rest of the bytes of the IID set to zero. There are a number of variants for this address pattern:
遵循此模式的地址包括IID最低顺序字节中的服务端口（例如，HTTP为80），并将IID的其余字节设置为零。此地址模式有多种变体：
o The lowest-order 16-bit word (from right to left) may contain the service port, and the second lowest-order 16-bit word (from right to left) may be set to a number in the range 0x0000-0x00ff (as in, e.g., 2001:db8::1:80).
o 最低阶16位字（从右到左）可以包含服务端口，第二个最低阶16位字（从右到左）可以设置为0x0000-0x00ff范围内的数字（例如，2001:db8:：1:80）。
o The lowest-order 16-bit word (from right to left) may be set to a value in the range 0x0000-0x00ff, while the second lowest-order 16-bit word (from right to left) may contain the service port (as in, e.g., 2001:db8::80:1).
o 最低阶16位字（从右到左）可以设置为0x0000-0x00ff范围内的值，而第二个最低阶16位字（从右到左）可以包含服务端口（例如，如2001:db8:：80:1）。
o The service port itself might be encoded in decimal or in hexadecimal notation (e.g., an address embedding the HTTP port might be 2001:db8::80 or 2001:db8::50) -- with addresses encoding the service port as a decimal number being more common.
o 服务端口本身可能以十进制或十六进制表示法进行编码（例如，嵌入HTTP端口的地址可能是2001:db8:：80或2001:db8:：50）——将服务端口编码为十进制数的地址更常见。
Considering a maximum of 20 popular service ports, the search space for addresses following this pattern is, in the worst-case scenario, 10 * 2^11.
考虑到最多20个常用服务端口，在最坏的情况下，遵循此模式的地址的搜索空间为10*2^11。
Since the IPv6 address notation allows for a number of hexadecimal digits, it is not difficult to encode words into IPv6 addresses (as in, e.g., 2001:db8::bad:cafe).
由于IPv6地址表示法允许许多十六进制数字，因此将单词编码到IPv6地址并不困难（例如，2001:db8:：bad:cafe）。
Addresses following this pattern are likely to be explored by means of "dictionary attacks"; therefore, computing the corresponding search space is not straightforward.
遵循此模式的地址可能会通过“字典攻击”进行探测；因此，计算相应的搜索空间并不简单。
4.1.4. IPv6 Addresses Corresponding to Transition/Coexistence Technologies
4.1.4. 与转换/共存技术相对应的IPv6地址
Some transition/coexistence technologies might be leveraged to reduce the target search space of remote address-scanning attacks, since they specify how the corresponding IPv6 address must be generated. For example, in the case of Teredo [RFC4380], the 64-bit IID is generated from the IPv4 address observed at a Teredo server along with a UDP port number.
可能会利用一些转换/共存技术来减少远程地址扫描攻击的目标搜索空间，因为它们指定了必须如何生成相应的IPv6地址。例如，在Teredo[RFC4380]的情况下，64位IID是从Teredo服务器上观察到的IPv4地址以及UDP端口号生成的。
For obvious reasons, the search space for these addresses will depend on the specific transition/coexistence technology being employed.
出于显而易见的原因，这些地址的搜索空间将取决于所采用的特定转换/共存技术。
Figures 1, 2, and 3 provide a summary of the results obtained by [Gont-LACSEC2013] when measuring the address patterns employed by web servers, name servers, and mail servers, respectively. Figure 4 provides a rough summary of the results obtained by [Malone2008] for IPv6 routers. Figure 5 provides a summary of the results obtained by [Ford2013] for clients.
图1、图2和图3总结了[Gont-LACSEC2013]分别测量web服务器、名称服务器和邮件服务器使用的地址模式时获得的结果。图4提供了[Malone2008]对IPv6路由器获得的结果的粗略总结。图5总结了[Ford2013]为客户提供的结果。
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 1.44% |
+---------------+------------+
| Embedded-IPv4 | 25.41% |
+---------------+------------+
| Embedded-Port | 3.06% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 56.88% |
+---------------+------------+
| Byte-pattern | 6.97% |
+---------------+------------+
| Randomized | 6.24% |
+---------------+------------+
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 1.44% |
+---------------+------------+
| Embedded-IPv4 | 25.41% |
+---------------+------------+
| Embedded-Port | 3.06% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 56.88% |
+---------------+------------+
| Byte-pattern | 6.97% |
+---------------+------------+
| Randomized | 6.24% |
+---------------+------------+
Figure 1: Measured Web Server Addresses
图1：测量的Web服务器地址
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.67% |
+---------------+------------+
| Embedded-IPv4 | 22.11% |
+---------------+------------+
| Embedded-Port | 6.48% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 56.58% |
+---------------+------------+
| Byte-pattern | 11.07% |
+---------------+------------+
| Randomized | 3.09% |
+---------------+------------+
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.67% |
+---------------+------------+
| Embedded-IPv4 | 22.11% |
+---------------+------------+
| Embedded-Port | 6.48% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 56.58% |
+---------------+------------+
| Byte-pattern | 11.07% |
+---------------+------------+
| Randomized | 3.09% |
+---------------+------------+
Figure 2: Measured Name Server Addresses
图2：测量的名称服务器地址
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.48% |
+---------------+------------+
| Embedded-IPv4 | 4.02% |
+---------------+------------+
| Embedded-Port | 1.07% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 92.65% |
+---------------+------------+
| Byte-pattern | 1.20% |
+---------------+------------+
| Randomized | 0.59% |
+---------------+------------+
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 0.48% |
+---------------+------------+
| Embedded-IPv4 | 4.02% |
+---------------+------------+
| Embedded-Port | 1.07% |
+---------------+------------+
| ISATAP | 0.00% |
+---------------+------------+
| Low-byte | 92.65% |
+---------------+------------+
| Byte-pattern | 1.20% |
+---------------+------------+
| Randomized | 0.59% |
+---------------+------------+
Figure 3: Measured Mail Server Addresses
图3：测量的邮件服务器地址
+--------------+------------+
| Address type | Percentage |
+--------------+------------+
| Low-byte | 70.00% |
+--------------+------------+
| IPv4-based | 5.00% |
+--------------+------------+
| SLAAC | 1.00% |
+--------------+------------+
| Wordy | <1.00% |
+--------------+------------+
| Randomized | <1.00% |
+--------------+------------+
| Teredo | <1.00% |
+--------------+------------+
| Other | <1.00% |
+--------------+------------+
+--------------+------------+
| Address type | Percentage |
+--------------+------------+
| Low-byte | 70.00% |
+--------------+------------+
| IPv4-based | 5.00% |
+--------------+------------+
| SLAAC | 1.00% |
+--------------+------------+
| Wordy | <1.00% |
+--------------+------------+
| Randomized | <1.00% |
+--------------+------------+
| Teredo | <1.00% |
+--------------+------------+
| Other | <1.00% |
+--------------+------------+
Figure 4: Measured Router Addresses
图4：测量的路由器地址
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 7.72% |
+---------------+------------+
| Embedded-IPv4 | 14.31% |
+---------------+------------+
| Embedded-Port | 0.21% |
+---------------+------------+
| ISATAP | 1.06% |
+---------------+------------+
| Randomized | 69.73% |
+---------------+------------+
| Low-byte | 6.23% |
+---------------+------------+
| Byte-pattern | 0.74% |
+---------------+------------+
+---------------+------------+
| Address type | Percentage |
+---------------+------------+
| IEEE-based | 7.72% |
+---------------+------------+
| Embedded-IPv4 | 14.31% |
+---------------+------------+
| Embedded-Port | 0.21% |
+---------------+------------+
| ISATAP | 1.06% |
+---------------+------------+
| Randomized | 69.73% |
+---------------+------------+
| Low-byte | 6.23% |
+---------------+------------+
| Byte-pattern | 0.74% |
+---------------+------------+
Figure 5: Measured Client Addresses
图5：测量的客户端地址
NOTE: "ISATAP" stands for "Intra-Site Automatic Tunnel Addressing Protocol" [RFC5214].
注：“ISATAP”代表“站点内自动隧道寻址协议”[RFC5214]。
It should be clear from these measurements that a very high percentage of host and router addresses follow very specific patterns.
从这些测量结果可以清楚地看出，主机和路由器地址中有很高比例遵循非常特定的模式。
Figure 5 shows that while around 70% of clients observed in this measurement appear to be using temporary addresses, a significant number of clients still expose IEEE-based addresses and addresses using embedded IPv4 (thus also revealing IPv4 addresses). Besides, as noted in Section 4.1.1.3, temporary addresses are employed along with stable IPv6 addresses; thus, hosts employing a temporary address may still be the subject of address-scanning attacks that target their stable address(es).
图5显示，虽然在该测量中观察到大约70%的客户机似乎使用临时地址，但仍有相当数量的客户机公开了基于IEEE的地址和使用嵌入式IPv4的地址（因此也公开了IPv4地址）。此外，如第4.1.1.3节所述，临时地址与稳定的IPv6地址一起使用；因此，使用临时地址的主机可能仍然是针对其稳定地址的地址扫描攻击的目标。
[ADDR-ANALYSIS] contains a spatial and temporal analysis of IPv6 addresses corresponding to clients and routers.
[ADDR-ANALYSIS]包含与客户端和路由器相对应的IPv6地址的空间和时间分析。
Although attackers have been able to get away with "brute-force" address-scanning attacks in IPv4 networks (thanks to the lesser search space), successfully performing a brute-force address-scanning attack of an entire /64 network would be infeasible. As a result, it is expected that attackers will leverage the IPv6 address patterns discussed in Section 4.1 to reduce the IPv6 address search space.
尽管攻击者能够在IPv4网络中逃脱“暴力”地址扫描攻击（由于搜索空间较小），但成功执行整个/64网络的暴力地址扫描攻击是不可行的。因此，预计攻击者将利用第4.1节中讨论的IPv6地址模式来减少IPv6地址搜索空间。
IPv6 address scanning of remote networks should consider an additional factor not present for the IPv4 case: since the typical IPv6 subnet is a /64, scanning an entire /64 could, in theory, lead to the creation of 2^64 entries in the Neighbor Cache of the last-hop router. Unfortunately, a number of IPv6 implementations have been found to be unable to properly handle a large number of entries in the Neighbor Cache; hence, these address-scanning attacks may have the side effect of resulting in a Denial-of-Service (DoS) attack [CPNI-IPv6] [RFC6583].
远程网络的IPv6地址扫描应该考虑IPv4情况下不存在的附加因素：因为典型的IPv6子网是A/64，所以扫描整个/ 64可以在理论上导致在最后一跳路由器的邻居高速缓存中创建2 ^ 64个条目。不幸的是，许多IPv6实现无法正确处理邻居缓存中的大量条目；因此，这些地址扫描攻击的副作用可能导致拒绝服务（DoS）攻击[CPNI-IPv6][RFC6583]。
[RFC7421] discusses the "default" /64 boundary for host subnets and the assumptions surrounding it. While there are reports of sites implementing IPv6 subnets of size /112 or smaller to reduce concerns about the above attack, such smaller subnets are likely to make address-scanning attacks more feasible, in addition to encountering the issues with non-/64 host subnets discussed in [RFC7421].
[RFC7421]讨论了主机子网的“默认”//64边界及其相关假设。虽然有报告称，站点实施了大小为/112或更小的IPv6子网，以减少对上述攻击的担忧，但这种更小的子网除了遇到[RFC7421]中讨论的非/64主机子网的问题外，还可能使地址扫描攻击更具可行性。
When address scanning a remote network, consideration is required to select which subnet IDs to choose. A typical site might have a /48 allocation, which would mean up to 65,000 or so IPv6 /64 subnets to be scanned.
当地址扫描远程网络时，需要考虑选择要选择的子网ID。一个典型的站点可能有A/48分配，这意味着最多要扫描65000个左右的IPv6/64子网。
However, in the same way the search space for the IID can be reduced, we may also be able to reduce the subnet ID search space in a number of ways, by guessing likely address plan schemes or using any complementary clues that might exist from other sources or observations. For example, there are a number of documents available online (e.g., [RFC5375]) that provide recommendations for the allocation of address space, which address various operational considerations, including Regional Internet Registry (RIR) assignment policy, ability to delegate reverse DNS zones to different servers, ability to aggregate routes efficiently, address space preservation, ability to delegate address assignment within the organization, ability to add/allocate new sites/prefixes to existing entities without updating Access Control Lists (ACLs), and ability to de-aggregate and advertise subspaces via various Autonomous System (AS) interfaces.
然而，与减少IID搜索空间的方法相同，我们也可以通过猜测可能的地址计划方案或使用其他来源或观察中可能存在的任何补充线索，以多种方式减少子网ID搜索空间。例如，有许多在线可用的文档（例如，[RFC5375]）为地址空间的分配提供了建议，解决了各种操作问题，包括区域互联网注册（RIR）分配策略、将反向DNS区域委托给不同服务器的能力，高效聚合路由的能力、地址空间保留、在组织内委派地址分配的能力、在不更新访问控制列表（ACL）的情况下向现有实体添加/分配新站点/前缀的能力，以及通过各种自治系统（AS）接口取消聚合和公布子空间的能力。
Address plans might include use of subnets that:
地址计划可能包括使用以下子网：
o Run from low ID upwards, e.g., 2001:db8:0::/64, 2001:db8:1::/64, etc.
o 从低ID向上运行，例如，2001:db8:0:：/64、2001:db8:1:：/64等。
o Use building numbers, in hexadecimal or decimal form.
o 使用十六进制或十进制形式的建筑编号。
o Use Virtual Local Area Network (VLAN) numbers.
o 使用虚拟局域网（VLAN）号码。
o Use an IPv4 subnet number in a dual-stack target, e.g., a site with a /16 for IPv4 might use /24 subnets, and the IPv6 address plan may reuse the third byte of the IPv4 address as the IPv6 subnet ID.
o 在双堆栈目标中使用IPv4子网编号，例如，对于IPv4使用/16的站点可能使用/24子网，IPv6地址计划可能会将IPv4地址的第三个字节重新用作IPv6子网ID。
o Use the service "color", as defined for service-based prefix coloring, or semantic prefixes. For example, a site using a specific coloring for a specific service such as Voice over IP (VoIP) may reduce the subnet ID search space for those devices.
o 使用为基于服务的前缀着色或语义前缀定义的服务“颜色”。例如，对特定服务（如IP语音（VoIP））使用特定颜色的站点可能会减少这些设备的子网ID搜索空间。
The net effect is that the address space of an organization may be highly structured, and allocations of individual elements within this structure may be predictable once other elements are known.
最终的效果是，一个组织的地址空间可能是高度结构化的，一旦其他元素已知，该结构中各个元素的分配可能是可预测的。
In general, any subnet ID address plan may convey information, or be based on known information, which may in turn be of advantage to an attacker.
通常，任何子网ID地址计划都可能传递信息，或基于已知信息，这反过来可能对攻击者有利。
IPv6 address scanning in Local Area Networks (LANs) could be considered, to some extent, a completely different problem than that of scanning a remote IPv6 network. The main difference is that use of link-local multicast addresses can relieve the attacker of searching for unicast addresses in a large IPv6 address space.
局域网（LAN）中的IPv6地址扫描在某种程度上可以被认为是一个与远程IPv6网络扫描完全不同的问题。主要区别在于，使用链路本地多播地址可以减轻攻击者在大型IPv6地址空间中搜索单播地址的负担。
NOTE: While a number of other network reconnaissance vectors (such as network snooping, leveraging Neighbor Discovery traffic, etc.) are available when scanning a local network, this section focuses only on address-scanning attacks (a la "ping sweep").
注意：虽然扫描本地网络时有许多其他网络侦察向量（如网络窥探、利用邻居发现流量等）可用，但本节仅关注地址扫描攻击（“ping扫描”）。
An attacker can simply send probe packets to the all-nodes link-local multicast address (ff02::1), such that responses are elicited from all local nodes.
攻击者只需将探测数据包发送到所有节点链接本地多播地址（ff02:：1），即可从所有本地节点获取响应。
Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo Request messages sent to multicast addresses, IPv6 address-scanning tools typically employ a number of additional probe packets to elicit responses from all the local nodes. For example, unrecognized IPv6 options of type 10xxxxxx elicit Internet Control Message Protocol version 6 (ICMPv6) Parameter Problem, code 2, error messages.
由于Windows系统（Vista、7等）不响应发送到多播地址的ICMPv6回显请求消息，IPv6地址扫描工具通常会使用大量额外的探测数据包来获取所有本地节点的响应。例如，类型为10xxxxxx的无法识别的IPv6选项会引发Internet控制消息协议版本6（ICMPv6）参数问题、代码2、错误消息。
Many address-scanning tools discover only IPv6 link-local addresses (rather than, e.g., the global addresses of the target systems): since the probe packets are typically sent with the attacker's IPv6 link-local address, the "victim" nodes send the response packets using the IPv6 link-local address of the corresponding network
许多地址扫描工具仅发现IPv6链路本地地址（而不是目标系统的全局地址）：由于探测数据包通常与攻击者的IPv6链路本地地址一起发送，“受害者”节点使用相应网络的IPv6链路本地地址发送响应数据包
interface (as specified by the IPv6 address-selection rules [RFC6724]). However, sending multiple probe packets, with each packet employing source addresses from different prefixes, typically helps to overcome this limitation.
接口（由IPv6地址选择规则[RFC6724]指定）。然而，发送多个探测包，每个包使用来自不同前缀的源地址，通常有助于克服此限制。
IPv4 address-scanning tools have traditionally carried out their task by probing an entire address range (usually the entire address range comprised by the target subnetwork). One might argue that the reason for which they have been able to get away with such somewhat "rudimentary" techniques is that the scale or challenge of the task is so small in the IPv4 world that a "brute-force" attack is "good enough". However, the scale of the "address-scanning" task is so large in IPv6 that attackers must be very creative to be "good enough". Simply sweeping an entire /64 IPv6 subnet would just not be feasible.
IPv4地址扫描工具通常通过探测整个地址范围（通常是由目标子网组成的整个地址范围）来执行其任务。有人可能会说，他们之所以能够使用这些“基本”技术，是因为在IPv4世界中，任务的规模或挑战太小，以至于“蛮力”攻击“足够好”。然而，IPv6中“地址扫描”任务的规模如此之大，以至于攻击者必须非常有创造力才能“足够好”。简单地扫描整个/64 IPv6子网是不可行的。
Many address-scanning tools do not even support sweeping an IPv6 address range. On the other hand, the alive6 tool from [THC-IPV6] supports sweeping address ranges, thus being able to leverage some patterns found in IPv6 addresses, such as the incremental addresses resulting from some DHCPv6 setups. Finally, the scan6 tool from [IPv6-Toolkit] supports sweeping address ranges and can also leverage all the address patterns described in Section 4.1 of this document.
许多地址扫描工具甚至不支持扫描IPv6地址范围。另一方面，[THC-IPV6]的alive6工具支持广泛的地址范围，因此能够利用IPV6地址中的一些模式，例如一些DHCPv6设置产生的增量地址。最后，[IPv6 Toolkit]中的scan6工具支持广泛的地址范围，还可以利用本文档第4.1节中描述的所有地址模式。
Clearly, a limitation of many of the currently available tools for IPv6 address scanning is that they lack an appropriately tuned "heuristics engine" that can help reduce the search space, such that the problem of IPv6 address scanning becomes tractable.
显然，许多目前可用的IPv6地址扫描工具的一个局限性是，它们缺乏经过适当调整的“启发式引擎”，这有助于减少搜索空间，因此IPv6地址扫描问题变得容易处理。
It should be noted that IPv6 network monitoring and management tools also need to build and maintain information about the hosts in their network. Such systems can no longer scan internal systems in a reasonable time to build a database of connected systems. Rather, such systems will need more efficient approaches, e.g., by polling network devices for data held about observed IP addresses, MAC addresses, physical ports used, etc. Such an approach can also enhance address accountability, by mapping IPv4 and IPv6 addresses to observed MAC addresses. This of course implies that any access control mechanisms for querying such network devices, e.g., community strings for SNMP, should be set appropriately to avoid an attacker being able to gather address information remotely.
需要注意的是，IPv6网络监视和管理工具还需要构建和维护其网络中主机的相关信息。这样的系统无法再在合理的时间内扫描内部系统以建立连接系统的数据库。相反，此类系统将需要更有效的方法，例如，通过轮询网络设备以获取有关观察到的IP地址、MAC地址、使用的物理端口等的数据。这种方法还可以通过将IPv4和IPv6地址映射到观察到的MAC地址来增强地址的可问责性。当然，这意味着查询此类网络设备的任何访问控制机制（例如SNMP的社区字符串）都应适当设置，以避免攻击者能够远程收集地址信息。
There are a variety of publicly available local IPv6 network address-scanners:
有多种公开可用的本地IPv6网络地址扫描器：
o Current versions of nmap [nmap2015] implement this functionality.
o nmap[nmap2015]的当前版本实现了此功能。
o The Hacker's Choice (THC) IPv6 Attack Toolkit [THC-IPV6] includes a tool (alive6) that implements this functionality.
o 黑客选择（THC）IPv6攻击工具包[THC-IPv6]包括一个实现此功能的工具（alive6）。
o SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) that implements this functionality.
o SI6 Network的IPv6 Toolkit[IPv6 Toolkit]包括一个实现此功能的工具（scan6）。
IPv6 address-scanning attacks can be mitigated in a number of ways. A non-exhaustive list of the possible mitigations includes:
IPv6地址扫描攻击可以通过多种方式缓解。可能缓解措施的非详尽列表包括：
o Employing [RFC7217] (stable, semantically opaque IIDs) in replacement of addresses based on IEEE identifiers, such that any address patterns are eliminated.
o 使用[RFC7217]（稳定、语义不透明的IID）替换基于IEEE标识符的地址，从而消除任何地址模式。
o Employing Intrusion Prevention Systems (IPSs) at the perimeter.
o 在周边使用入侵防御系统（IPSs）。
o Enforcing IPv6 packet filtering where applicable (see, e.g., [RFC4890]).
o 在适用的情况下实施IPv6数据包过滤（例如，参见[RFC4890]）。
o Employing manually configured MAC addresses if virtual machines are employed and "resistance" to address-scanning attacks is deemed desirable, such that even if the virtual machines employ IEEE-derived IIDs, they are generated from non-predictable MAC addresses.
o 如果使用了虚拟机，并且认为需要“抵抗”地址扫描攻击，则使用手动配置的MAC地址，这样即使虚拟机使用IEEE派生的IID，它们也是从不可预测的MAC地址生成的。
o Avoiding use of sequential addresses when using DHCPv6. Ideally, the DHCPv6 server would allocate random addresses from a large pool (see, e.g., [IIDS-DHCPv6]).
o 使用DHCPv6时避免使用顺序地址。理想情况下，DHCPv6服务器将从大型池中分配随机地址（例如，请参见[IIDS-DHCPv6]）。
o Using the "default" /64 size IPv6 subnet prefixes.
o 使用“默认”//64大小的IPv6子网前缀。
o In general, avoiding being predictable in the way addresses are assigned.
o 通常，避免地址分配方式的可预测性。
It should be noted that some of the aforementioned mitigations are operational, while others depend on the availability of specific protocol features (such as [RFC7217]) on the corresponding nodes.
应注意，上述缓解措施中的一些是可操作的，而其他缓解措施则取决于相应节点上特定协议功能（如[RFC7217]）的可用性。
Additionally, while some resistance to address-scanning attacks is generally desirable (particularly when lightweight mitigations are available), there are scenarios in which mitigation of some address-scanning vectors is unlikely to be a high priority (if at all possible). And one should always remember that security by obscurity is not a reasonable defense in itself; it may only be one (relatively small) layer in a broader security environment.
此外，虽然通常需要对地址扫描攻击进行一些抵抗（特别是在轻量级缓解措施可用时），但在某些情况下，某些地址扫描向量的缓解不太可能是高优先级的（如果可能的话）。人们应该永远记住，默默无闻的安全本身并不是一种合理的防御；在更广泛的安全环境中，它可能只是一个（相对较小的）层。
Two of the techniques discussed in this document for local address-scanning attacks are those that employ multicasted ICMPv6 Echo Requests and multicasted IPv6 packets containing unsupported options of type 10xxxxxx. These two vectors could be easily mitigated by configuring nodes to not respond to multicasted ICMPv6 Echo Requests (default on Windows systems) and by updating the IPv6 specifications (and/or possibly configuring local nodes) such that multicasted packets never elicit ICMPv6 error messages (even if they contain unsupported options of type 10xxxxxx).
本文档中讨论的用于本地地址扫描攻击的两种技术是使用多播ICMPv6回显请求和包含10xxxxxx类型的不受支持选项的多播IPv6数据包的技术。通过将节点配置为不响应多播ICMPv6回显请求（Windows系统上默认），以及更新IPv6规范（和/或可能配置本地节点），使多播数据包永远不会引发ICMPv6错误消息，可以轻松缓解这两个向量（即使它们包含10xxxxxx类型的不受支持的选项）。
NOTE: [SMURF-AMPLIFIER] proposed such an update to the IPv6 specifications.
注：[SMURF-Amplier]建议对IPv6规范进行此类更新。
In any case, when it comes to local networks, there are a variety of network reconnaissance vectors. Therefore, even if address-scanning vectors were mitigated, an attacker could still rely on, e.g., protocols employed for the so-called "service discovery protocols" (see Section 5.2) or eventually rely on network snooping as a last resort for network reconnaissance. There is ongoing work in the IETF on extending mDNS, or at least DNS-based service discovery, to work across a whole site, rather than in just a single subnet, which will have associated security implications.
在任何情况下，当涉及到本地网络时，存在各种各样的网络侦察向量。因此，即使减少了地址扫描向量，攻击者仍然可以依赖于，例如，用于所谓“服务发现协议”（见第5.2节）的协议，或者最终依赖网络窥探作为网络侦察的最后手段。IETF正在进行扩展MDN或至少基于DNS的服务发现的工作，以在整个站点上工作，而不仅仅是在单个子网中，这将产生相关的安全影响。
In the previous subsections, we have shown why a /64 host subnet may be more vulnerable to address-based scanning than might intuitively be thought and how an attacker might reduce the target search space when performing an address-scanning attack.
在前面的小节中，我们已经说明了为什么/64主机子网可能比直觉上认为的更容易受到基于地址的扫描的攻击，以及攻击者在执行地址扫描攻击时如何减少目标搜索空间。
We have described a number of mitigations against address-scanning attacks, including the replacement of traditional SLAAC with stable semantically opaque IIDs (which requires support from system vendors). We have also offered some practical guidance in regard to the principle of avoiding predictability in host addressing schemes. Finally, examples of address-scanning approaches and tools are discussed in the appendices.
我们已经描述了一些针对地址扫描攻击的缓解措施，包括用稳定的语义不透明IID（需要系统供应商的支持）替换传统的SLAAC。我们还就主机寻址方案中避免可预测性的原则提供了一些实际指导。最后，附录中讨论了地址扫描方法和工具的示例。
While most early IPv6-enabled networks remain dual stack, they are more likely to be scanned and attacked over IPv4 transport, and one may argue that the IPv6-specific considerations discussed here are not of an immediate concern. However, an early IPv6 deployment within a dual-stack network may be seen by an attacker as a potentially "easier" target if the implementation of security policies is not as strict for IPv6 (for whatever reason). As IPv6-only networks become more common, the above considerations will be of much greater importance.
虽然大多数早期支持IPv6的网络仍然是双栈的，但它们更有可能通过IPv4传输受到扫描和攻击，有人可能会认为，此处讨论的IPv6特定注意事项并不是立即需要考虑的问题。但是，如果安全策略的实施对IPv6不那么严格（无论出于何种原因），攻击者可能会将双堆栈网络中的早期IPv6部署视为潜在的“更容易”目标。随着纯IPv6网络变得越来越普遍，上述考虑因素将变得更加重要。
The following subsections describe alternative methods by which an attacker might attempt to glean IPv6 addresses for subsequent probing.
以下小节描述了攻击者可能试图收集IPv6地址以进行后续探测的替代方法。
Any systems that are "published" in the DNS, e.g., Mail Exchange (MX) relays or web servers, will remain open to probing from the very fact that their IPv6 addresses are publicly available. It is worth noting that where the addresses used at a site follow specific patterns, publishing just one address may lead to an attack upon the other nodes.
任何在DNS中“发布”的系统，例如邮件交换（MX）中继或web服务器，都将保持开放状态，以便从其IPv6地址公开这一事实进行探测。值得注意的是，如果站点上使用的地址遵循特定模式，则仅发布一个地址可能会导致对其他节点的攻击。
Additionally, we note that publication of IPv6 addresses in the DNS should not discourage the elimination of IPv6 address patterns: if any address patterns are eliminated from addresses published in the DNS, an attacker may have to rely on performing dictionary-based DNS lookups in order to find all systems in a target network (which is generally less reliable and more time/traffic consuming than mapping nodes with predictable IPv6 addresses).
此外，我们注意到，在DNS中发布IPv6地址不应妨碍消除IPv6地址模式：如果从DNS中发布的地址中消除任何地址模式，攻击者可能必须依靠执行基于词典的DNS查找来查找目标网络中的所有系统（与使用可预测的IPv6地址映射节点相比，这通常不太可靠，且更耗费时间/流量）。
A DNS zone transfer (DNS query type "AXFR") [RFC1034] [RFC1035] can readily provide information about potential attack targets. Restricting zone transfers is thus probably more important for IPv6, even if it is already good practice to restrict them in the IPv4 world.
DNS区域传输（DNS查询类型“AXFR”）[RFC1034][RFC1035]可以随时提供有关潜在攻击目标的信息。因此，限制区域传输对于IPv6来说可能更为重要，即使在IPv4世界中限制区域传输已经是一种很好的做法。
Attackers may employ DNS brute-forcing techniques by testing for the presence of DNS AAAA records against commonly used host names.
攻击者可以通过测试DNS AAAA记录是否与常用主机名相符，从而使用DNS暴力强制技术。
[van-Dijk] describes an interesting technique that employs DNS reverse mappings for network reconnaissance. Essentially, the attacker walks through the "ip6.arpa" zone looking up PTR records, in the hopes of learning the IPv6 addresses of hosts in a given target network (assuming that the reverse mappings have been configured, of course). What is most interesting about this technique is that it can greatly reduce the IPv6 address search space.
[van Dijk]介绍了一种有趣的技术，它使用DNS反向映射进行网络侦察。本质上，攻击者通过“ip6.arpa”区域查找PTR记录，希望了解给定目标网络中主机的IPv6地址（当然，假设已配置反向映射）。这项技术最有趣的是，它可以大大减少IPv6地址搜索空间。
Basically, an attacker would walk the ip6.arpa zone corresponding to a target network (e.g., "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for "2001:db8:80::/48"), issuing queries for PTR records corresponding to the domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR records for any hosts "starting" with the domain name "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name corresponding to the IPv6 address 2001:db8:80::1), the response would contain an RCODE of 0 (no error). Otherwise, the response would contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this technique allows for a tremendous reduction in the "IPv6 address" search space.
基本上，攻击者会在与目标网络相对应的ip6.arpa区域（例如，“0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.”针对“2001:db8:80:：/48”）发出与域名“0.0.8.0.0.8.b.d.0.1.0.2.ip6.arpa.”和“1.0.8.0.0.8.b.d.0.1.0.0.0.2.ip6.arpa.”相对应的PTR记录查询。如果有任何主机的记录，比如说以域名“0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa”开头（例如，与IPv6地址2001:db8:80:：1对应的ip6.arpa域名），响应将包含0的RCODE（无错误）。否则，响应将包含4的RCODE（NXDOMAIN）。如[van Dijk]中所述，这种技术可以极大地减少“IPv6地址”搜索空间。
NOTE: Some name servers, incorrectly implementing the DNS protocol, reply NXDOMAIN instead of NODATA (NOERROR=0 and ANSWER=0) when encountering a domain without any resource records but that has child domains, something that is very common in ip6.arpa (these domains are called ENT for Empty Non-Terminals; see [RFC7719]). When scanning ip6.arpa, this behavior may slow down or completely prevent the exploration of ip6.arpa. Nevertheless, since such behavior is wrong (see [NXDOMAIN-DEF]), one cannot rely on it to "secure" ip6.arpa against tree walking.
注意：当遇到没有任何资源记录但有子域的域时，一些名称服务器错误地实现了DNS协议，会回复NXDOMAIN而不是NODATA（NOERROR=0和ANSWER=0），这在ip6.arpa中非常常见（这些域称为ENT表示空的非终端；请参阅[RFC7719]）。扫描ip6.arpa时，此行为可能会减慢或完全阻止对ip6.arpa的探测。尽管如此，由于这种行为是错误的（参见[NXDOMAIN-DEF]），因此不能依靠它来“保护”ip6.arpa以防止树遍历。
[IPv6-RDNS] analyzes different approaches and considerations for ISPs in managing the ip6.arpa zone for IPv6 address space assigned to many customers, which may affect the technique described in this section.
[IPv6 RDN]分析了ISP管理分配给许多客户的IPv6地址空间的ip6.arpa区域的不同方法和注意事项，这可能会影响本节中描述的技术。
A number of protocols allow for unmanaged local name resolution and service. For example, mDNS [RFC6762] and DNS Service Discovery (DNS-SD) [RFC6763], or Link-Local Multicast Name Resolution (LLMNR) [RFC4795], are examples of such protocols.
许多协议允许非托管本地名称解析和服务。例如，MDN[RFC6762]和DNS服务发现（DNS-SD）[RFC6763]或链路本地多播名称解析（LLMNR）[RFC4795]是此类协议的示例。
NOTE: Besides the Graphical User Interfaces (GUIs) included in products supporting such protocols, command-line tools such as mdns-scan [mdns-scan] and mzclient [mzclient] can help discover IPv6 hosts employing mDNS/DNS-SD.
注意：除了支持此类协议的产品中包含的图形用户界面（GUI）之外，命令行工具（如mdns scan[mdns scan]和mzclient[mzclient]可以帮助发现使用mdns/DNS-SD的IPv6主机。
Public mailing-list archives or Usenet news messages archives may prove to be a useful channel for an attacker, since hostnames and/or IPv6 addresses could be easily obtained by inspection of the (many) "Received from:" or other header lines in the archived email or Usenet news messages.
公共邮件列表存档或Usenet新闻消息存档可能被证明是攻击者的有用渠道，因为通过检查存档电子邮件或Usenet新闻消息中的（多个）“接收自：”或其他标题行，可以轻松获取主机名和/或IPv6地址。
Peer-to-peer applications often include some centralized server that coordinates the transfer of data between peers. For example, BitTorrent [BitTorrent] builds swarms of nodes that exchange chunks of files, with a tracker passing information about peers with available chunks of data between the peers. Such applications may offer an attacker a source of peer addresses to probe.
对等应用程序通常包括一些集中式服务器，用于协调对等机之间的数据传输。例如，BitTorrent[BitTorrent]构建了大量节点，这些节点交换文件块，跟踪器通过对等节点之间可用的数据块传递对等节点的信息。此类应用程序可能会为攻击者提供一个对等地址源进行探测。
Information about other systems connected to the local network might be readily available from the Neighbor Cache [RFC4861] and/or the routing table of any system connected to such network. Source Address Validation Improvement (SAVI) [RFC6620] also builds a cache of IPv6 and link-layer addresses (without actively participating in the Neighbor Discovery packet exchange) and hence is another source of similar information.
关于连接到本地网络的其他系统的信息可以从邻居缓存[RFC4861]和/或连接到该网络的任何系统的路由表中随时可用。源地址验证改进（SAVI）[RFC6620]还构建了IPv6和链路层地址的缓存（无需积极参与邻居发现数据包交换），因此也是类似信息的另一个来源。
These data structures could be inspected via either "login" access or SNMP. While this requirement may limit the applicability of this technique, there are a number of scenarios in which this technique might be of use. For example, security audit tools might be provided with the necessary credentials such that the Neighbor Cache and the routing table of all systems for which the tool has "login" or SNMP access can be automatically gleaned. On the other hand, IPv6 worms [V6-WORMS] could leverage this technique for the purpose of spreading on the local network, since they will typically have access to the Neighbor Cache and routing table of an infected system.
这些数据结构可以通过“登录”访问或SNMP进行检查。虽然此要求可能会限制此技术的适用性，但在许多情况下，此技术可能会被使用。例如，可以为安全审计工具提供必要的凭据，以便可以自动收集该工具具有“登录”或SNMP访问权限的所有系统的邻居缓存和路由表。另一方面，IPv6蠕虫[V6-worms]可以利用这种技术在本地网络上传播，因为它们通常可以访问受感染系统的邻居缓存和路由表。
Section 2.5.1.4 of [OPSEC-IPv6] discusses additional considerations for the inspection of the IPv6 Neighbor Cache.
[OPSEC-IPv6]的第2.5.1.4节讨论了检查IPv6邻居缓存的其他注意事项。
Nodes are generally configured with the addresses of other important local computers, such as email servers, local file servers, web proxy servers, recursive DNS servers, etc. The /etc/hosts file in UNIX-like systems, Secure Shell (SSH) known_hosts files, or the Microsoft Windows registry are just some examples of places where interesting information about such systems might be found.
节点通常配置有其他重要本地计算机的地址，如电子邮件服务器、本地文件服务器、web代理服务器、递归DNS服务器等。类UNIX系统中的/etc/hosts文件、Secure Shell（SSH）已知的\u hosts文件、，或者MicrosoftWindows注册表只是一些可以找到有关此类系统的有趣信息的地方的例子。
Additionally, system log files (including web server logs, etc.) may also prove to be a useful source for an attacker.
此外，系统日志文件（包括web服务器日志等）也可能被证明是攻击者的有用来源。
While the required credentials to access the aforementioned configuration and log files may limit the applicability of this technique, there are a number of scenarios in which this technique might be of use. For example, security audit tools might be provided with the necessary credentials such that these files can be automatically accessed. On the other hand, IPv6 worms could leverage this technique for the purpose of spreading on the local network, since they will typically have access to these files on an infected system [V6-WORMS].
虽然访问上述配置和日志文件所需的凭据可能会限制此技术的适用性，但在许多情况下，此技术可能会被使用。例如，可以为安全审计工具提供必要的凭据，以便可以自动访问这些文件。另一方面，IPv6蠕虫可以利用这种技术在本地网络上传播，因为它们通常可以在受感染的系统上访问这些文件[V6-WORM]。
Some organizational IPv6 networks employ routing protocols to dynamically maintain routing information. In such an environment, a local attacker could become a passive listener of the routing protocol, to determine other valid subnets/prefixes and some router addresses within that organization [V6-WORMS].
一些有组织的IPv6网络使用路由协议来动态维护路由信息。在这种环境中，本地攻击者可能成为路由协议的被动侦听器，以确定该组织内的其他有效子网/前缀和某些路由器地址[V6-WORM]。
IPFIX [RFC7012] can aggregate the flows by source addresses and hence may be leveraged for obtaining a list of "active" IPv6 addresses. Additional discussion of IPFIX can be found in Section 2.5.1.2 of [OPSEC-IPv6].
IPFIX[RFC7012]可以按源地址聚合流，因此可以用于获取“活动”IPv6地址列表。有关IPFIX的更多讨论，请参见[OPSEC-IPv6]的第2.5.1.2节。
IPv6 traceroute [traceroute6] and similar tools (such as path6 from [IPv6-Toolkit]) can be employed to find router addresses and valid network prefixes.
IPv6跟踪路由[traceroute6]和类似工具（如[IPv6 Toolkit]中的path6）可用于查找路由器地址和有效的网络前缀。
SNMP can be leveraged to obtain information from a number of data structures such as the Neighbor Cache [RFC4861], the routing table, and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP access should be secured, such that unauthorized access to the aforementioned information is prevented.
可以利用SNMP从许多数据结构中获取信息，例如IPv6和链路层地址的邻居缓存[RFC4861]、路由表和SAVI[RFC6620]缓存。应保护SNMP访问，以防止未经授权访问上述信息。
Snooping network traffic can help in discovering active nodes in a number of ways. Firstly, each captured packet will reveal the source and destination of the packet. Secondly, the captured traffic may correspond to network protocols that transfer information such as host or router addresses, network topology information, etc.
窥探网络流量有助于以多种方式发现活动节点。首先，每个捕获的数据包将显示数据包的来源和目的地。其次，捕获的流量可能对应于传输诸如主机或路由器地址、网络拓扑信息等信息的网络协议。
This document explores the topic of network reconnaissance in IPv6 networks. It analyzes the feasibility of address-scanning attacks in IPv6 networks and shows that the search space for such attacks is typically much smaller than the one traditionally assumed (64 bits).
本文档探讨IPv6网络中的网络侦察主题。它分析了IPv6网络中地址扫描攻击的可行性，并表明此类攻击的搜索空间通常比传统假设的搜索空间（64位）小得多。
Additionally, this document explores a plethora of other network reconnaissance techniques, ranging from inspecting the IPv6 Network Cache of an attacker-controlled system to gleaning information about IPv6 addresses from public mailing-list archives or Peer-to-Peer (P2P) protocols.
此外，本文档还探讨了大量其他网络侦察技术，从检查攻击者控制系统的IPv6网络缓存到从公共邮件列表存档或对等（P2P）协议中收集有关IPv6地址的信息。
We expect traditional address-scanning attacks to become more and more elaborated (i.e., less "brute force"), and other network reconnaissance techniques to be actively explored, as global deployment of IPv6 increases and, more specifically, as more IPv6-only devices are deployed.
我们预计，随着IPv6全球部署的增加，更具体地说，随着仅部署IPv6的设备的增加，传统的地址扫描攻击将变得越来越复杂（即“暴力攻击”将减少），其他网络侦察技术将得到积极探索。
This document reviews methods by which addresses of hosts within IPv6 subnets can be determined. As such, it raises no new security concerns.
本文档回顾了确定IPv6子网内主机地址的方法。因此，它不会引起新的安全问题。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 4380，DOI 10.17487/RFC4380，2006年2月<http://www.rfc-editor.org/info/rfc4380>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 5214，DOI 10.17487/RFC5214，2008年3月<http://www.rfc-editor.org/info/rfc5214>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, <http://www.rfc-editor.org/info/rfc6620>.
[RFC6620]Nordmark，E.，Bagnulo，M.和E.Levy Abegnoli，“FCFS SAVI：本地分配IPv6地址的先到先得源地址验证改进”，RFC 6620，DOI 10.17487/RFC6620，2012年5月<http://www.rfc-editor.org/info/rfc6620>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <http://www.rfc-editor.org/info/rfc7012>.
[RFC7012]Claise，B.，Ed.和B.Trammell，Ed.，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，DOI 10.17487/RFC7012，2013年9月<http://www.rfc-editor.org/info/rfc7012>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
[ADDR-ANALYSIS] Plonka, D. and A. Berger, "Temporal and Spatial Classification of Active IPv6 Addresses", ACM Internet Measurement Conference (IMC), Tokyo, Japan, Pages 509-522, DOI 10.1145/2815675.2815678, October 2015, <http://conferences2.sigcomm.org/imc/2015/papers/ p509.pdf>.
[ADDR-ANALYSIS]Plonka，D.和A.Berger，“活动IPv6地址的时空分类”，ACM互联网测量会议（IMC），日本东京，第509-522页，DOI 10.1145/2815675.2815678，2015年10月<http://conferences2.sigcomm.org/imc/2015/papers/ p509.pdf>。
[BitTorrent] Wikipedia, "BitTorrent", November 2015, <https://en.wikipedia.org/w/ index.php?title=BitTorrent&oldid=690381343>.
[BitTorrent]维基百科，“BitTorrent”，2015年11月<https://en.wikipedia.org/w/ index.php？title=BitTorrent&oldid=690381343>。
[CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request).
[CPNI-IPv6]Gont，F.，“互联网协议第6版（IPv6）的安全评估”，英国国家基础设施保护中心（可根据要求提供）。
[DEFAULT-IIDS] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", Work in Progress, draft-ietf-6man-default-iids-10, February 2016.
[DEFAULT-IIDS]Gont，F.，Cooper，A.，Thaler，D.，和W.Liu，“关于稳定IPv6接口标识符的建议”，正在进行的工作，草案-ietf-6man-DEFAULT-IIDS-10，2016年2月。
[Ford2013] Ford, M., "IPv6 Address Analysis - Privacy In, Transition Out", May 2013, <http://www.internetsociety.org/blog/2013/05/ ipv6-address-analysis-privacy-transition-out>.
[Ford2013]Ford，M.，“IPv6地址分析-隐私输入、转换输出”，2013年5月<http://www.internetsociety.org/blog/2013/05/ ipv6地址分析隐私转换输出>。
[Gont-DEEPSEC2011] Gont, F., "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC Conference, Vienna, Austria, November 2011, <http://www.si6networks.com/presentations/deepsec2011/ fgont-deepsec2011-ipv6-security.pdf>.
[Gont-DEEPSEC2011]Gont，F.“互联网协议版本6（IPv6）的安全评估结果”，DEEPSEC会议，奥地利维也纳，2011年11月<http://www.si6networks.com/presentations/deepsec2011/ fgont-deepsec2011-ipv6-security.pdf>。
[Gont-LACSEC2013] Gont, F., "IPv6 Network Reconnaissance: Theory & Practice", LACSEC Conference, Medellin, Colombia, May 2013, <http://www.si6networks.com/presentations/lacnic19/ lacsec2013-fgont-ipv6-network-reconnaissance.pdf>.
[Gont-LACSEC2013]Gont，F.，“IPv6网络侦察：理论与实践”，LACSEC会议，哥伦比亚麦德林，2013年5月<http://www.si6networks.com/presentations/lacnic19/ lacsec2013-fgont-ipv6-network-conservation.pdf>。
[IIDS-DHCPv6] Gont, F. and W. Liu, "A Method for Generating Semantically Opaque Interface Identifiers with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress, draft-ietf-dhc-stable-privacy-addresses-02, April 2015.
[IIDS-DHCPv6]Gont，F.和W.Liu，“使用IPv6动态主机配置协议（DHCPv6）生成语义不透明接口标识符的方法”，正在进行的工作，草稿-ietf-dhc-stable-privacy-addresses-022015年4月。
[IPV6-EXT-HEADERS] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", Work in Progress, draft-ietf-v6ops-ipv6-ehs-in-real-world-02, December 2015.
[IPV6-EXT-HEADERS]Gont，F.，Linkova，J.，Chown，T.，和W.Liu，“关于在现实世界中使用IPV6扩展头丢弃数据包的观察”，正在进行的工作，草稿-ietf-v6ops-IPV6-ehs-in-Real-World-022015年12月。
[IPv6-RDNS] Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", Work in Progress, draft-ietf-dnsop-isp-ip6rdns-00, October 2015.
[IPv6 RDNS]Howard，L.，“互联网服务提供商IPv6中的反向DNS”，正在进行的工作，草稿-ietf-dnsop-isp-ip6rdns-00，2015年10月。
[IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.
[IPv6工具包]SI6网络，“SI6网络的IPv6工具包”<http://www.si6networks.com/tools/ipv6toolkit>.
[Malone2008] Malone, D., "Observations of IPv6 Addresses", Passive and Active Network Measurement (PAM 2008, LNCS 4979), DOI 10.1007/978-3-540-79232-1_3, April 2008, <http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.
[Malone2008]Malone，D.，“IPv6地址的观测”，被动和主动网络测量（PAM 2008，LNCS 4979），内政部10.1007/978-3-540-79232-1_3，2008年4月<http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>。
[mdns-scan] Poettering, L., "mdns-scan(1) Manual Page", <http://manpages.ubuntu.com/manpages/precise/man1/ mdns-scan.1.html>.
[mdns扫描]Poettering，L.，“mdns扫描（1）手册页”<http://manpages.ubuntu.com/manpages/precise/man1/ mdns scan.1.html>。
[mzclient] Bockover, A., "Mono Zeroconf Project -- mzclient command-line tool", <http://www.mono-project.com/archived/monozeroconf/>.
[mzclient]Bockover，A.，“Mono Zeroconf项目——mzclient命令行工具”<http://www.mono-project.com/archived/monozeroconf/>.
[nmap2015] Lyon, Gordon "Fyodor", "Nmap 7.00", November 2015, <http://insecure.org>.
[nmap2015]里昂，戈登“Fyodor”，“Nmap 7.00”，2015年11月<http://insecure.org>.
[NXDOMAIN-DEF] Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there is nothing underneath", Work in Progress, draft-ietf-dnsop-nxdomain-cut-00, December 2015.
[NXDOMAIN-DEF]Bortzmeyer，S.和S.Huque，“NXDOMAIN实际上意味着下面什么都没有”，正在进行的工作，草稿-ietf-dnsop-NXDOMAIN-cut-00，2015年12月。
[OPSEC-IPv6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-07, September 2015.
[OPSEC-IPv6]Chittimaneni，K.，Kaeo，M.，和E.Vyncke，“IPv6网络的运营安全考虑”，正在进行的工作，草案-ietf-OPSEC-v6-07，2015年9月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, DOI 10.17487/RFC4795, January 2007, <http://www.rfc-editor.org/info/rfc4795>.
[RFC4795]Aboba，B.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 4795，DOI 10.17487/RFC4795，2007年1月<http://www.rfc-editor.org/info/rfc4795>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <http://www.rfc-editor.org/info/rfc4890>.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 4890，DOI 10.17487/RFC4890，2007年5月<http://www.rfc-editor.org/info/rfc4890>.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, DOI 10.17487/RFC5157, March 2008, <http://www.rfc-editor.org/info/rfc5157>.
[RFC5157]Chown，T，“IPv6对网络扫描的影响”，RFC 5157，DOI 10.17487/RFC5157，2008年3月<http://www.rfc-editor.org/info/rfc5157>.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., and C. Hahn, "IPv6 Unicast Address Assignment Considerations", RFC 5375, DOI 10.17487/RFC5375, December 2008, <http://www.rfc-editor.org/info/rfc5375>.
[RFC5375]Van de Velde，G.，Popoviciu，C.，Chown，T.，Bonness，O.，和C.Hahn，“IPv6单播地址分配注意事项”，RFC 5375，DOI 10.17487/RFC5375，2008年12月<http://www.rfc-editor.org/info/rfc5375>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>.
[RFC6583]Gashinsky，I.，Jaeggli，J.，和W.Kumari，“操作邻居发现问题”，RFC 6583，DOI 10.17487/RFC6583，2012年3月<http://www.rfc-editor.org/info/rfc6583>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<http://www.rfc-editor.org/info/rfc6763>.
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <http://www.rfc-editor.org/info/rfc7421>.
[RFC7421]Carpenter，B.，Ed.，Chown，T.，Gont，F.，Jiang，S.，Petrescu，A.，和A.Yourtchenko，“IPv6寻址中64位边界的分析”，RFC 7421，DOI 10.17487/RFC7421，2015年1月<http://www.rfc-editor.org/info/rfc7421>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<http://www.rfc-editor.org/info/rfc7719>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.
[RFC7721]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的安全和隐私考虑”，RFC 7721，DOI 10.17487/RFC7721，2016年3月<http://www.rfc-editor.org/info/rfc7721>.
[SMURF-AMPLIFIER] Gont, F. and W. Liu, "Security Implications of IPv6 Options of Type 10xxxxxx", Work in Progress, draft-gont-6man-ipv6-smurf-amplifier-03, March 2013.
[SMURF-Amplier]Gont，F.和W.Liu，“10xxxxxx型IPv6选项的安全影响”，正在进行的工作，草稿-Gont-6man-IPv6-SMURF-Amplier-032013年3月。
[THC-IPV6] "THC-IPV6", <http://www.thc.org/thc-ipv6/>.
[THC-IPV6]“THC-IPV6”<http://www.thc.org/thc-ipv6/>.
[traceroute6] FreeBSD, "FreeBSD System Manager's Manual: traceroute6(8) manual page", August 2009, <https://www.freebsd.org/cgi/ man.cgi?query=traceroute6>.
[traceroute6]FreeBSD，“FreeBSD系统管理器手册：traceroute6（8）手册页”，2009年8月<https://www.freebsd.org/cgi/ man.cgi？query=traceroute6>。
[V6-WORMS] Bellovin, S., Cheswick, B., and A. Keromytis, "Worm propagation strategies in an IPv6 Internet", Vol. 31, No. 1, pp. 70-76, February 2006, <https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>.
[V6-WORMS]Bellovin，S.，Cheswick，B.，和A.Keromytis，“IPv6互联网中的蠕虫传播策略”，第31卷，第1期，第70-76页，2006年2月<https://www.cs.columbia.edu/~smb/papers/v6worms.pdf>。
[van-Dijk] van Dijk, P., "Finding v6 hosts by efficiently mapping ip6.arpa", March 2012, <http://7bits.nl/blog/2012/03/26/ finding-v6-hosts-by-efficiently-mapping-ip6-arpa>.
[van Dijk]van Dijk，P.，“通过有效映射ip6.arpa来查找v6主机”，2012年3月<http://7bits.nl/blog/2012/03/26/ finding-v6-hosts-by-mapping-ip6-arpa>。
[VBox2011] VirtualBox, "Oracle VM VirtualBox User Manual", Version 4.1.2, August 2011, <http://www.virtualbox.org>.
[VBox2011]VirtualBox，“Oracle VM VirtualBox用户手册”，版本4.1.2，2011年8月<http://www.virtualbox.org>.
[vmesx2011] VMware, "Setting a static MAC address for a virtual NIC (219)", VMware Knowledge Base, August 2011, <http://kb.vmware.com/selfservice/microsites/ search.do?language=en_US&cmd=displayKC&externalId=219>.
[vmesx2011]VMware，“为虚拟NIC设置静态MAC地址（219）”，VMware知识库，2011年8月<http://kb.vmware.com/selfservice/microsites/ search.do？language=en_US&cmd=displayKC&externalId=219>。
[vSphere] VMware, "vSphere Networking", vSphere 5.5, Update 2, September 2014, <http://pubs.vmware.com/ vsphere-55/topic/com.vmware.ICbase/PDF/ vsphere-esxi-vcenter-server-552-networking-guide.pdf>.
[vSphere]VMware，“vSphere网络”，vSphere 5.5，更新版本2，2014年9月<http://pubs.vmware.com/ vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-552-networking-guide.PDF>。
This section describes the implementation of a full-fledged IPv6 address-scanning tool. Appendix A.1 discusses the selection of host probes. Appendix A.2 describes the implementation of an IPv6 address scanner for local area networks. Appendix A.3 outlines the implementation of a general (i.e., non-local) IPv6 address scanner.
本节介绍一个成熟的IPv6地址扫描工具的实现。附录A.1讨论了主机探头的选择。附录A.2描述了局域网IPv6地址扫描程序的实现。附录A.3概述了通用（即非本地）IPv6地址扫描器的实现。
A number of factors should be considered when selecting the probe packet types and the probing rate for an IPv6 address-scanning tool.
在为IPv6地址扫描工具选择探测数据包类型和探测速率时，应考虑多个因素。
Firstly, some hosts (or border firewalls) might be configured to block or rate limit some specific packet types. For example, it is usual for host and router implementations to rate-limit ICMPv6 error traffic. Additionally, some firewalls might be configured to block or rate limit incoming ICMPv6 echo request packets (see, e.g., [RFC4890]).
首先，一些主机（或边界防火墙）可能被配置为阻止或限制某些特定的数据包类型。例如，主机和路由器实现通常会对ICMPv6错误流量进行速率限制。此外，一些防火墙可能被配置为阻止或限制传入的ICMPv6回显请求数据包（例如，请参阅[RFC4890]）。
NOTE: As noted earlier in this document, Windows systems simply do not respond to ICMPv6 echo requests sent to multicast IPv6 addresses.
注意：如本文档前面所述，Windows系统不响应发送到多播IPv6地址的ICMPv6回显请求。
Among the possible probe types are:
可能的探头类型包括：
o ICMPv6 Echo Request packets (meant to elicit ICMPv6 Echo Replies),
o ICMPv6回显请求数据包（用于获取ICMPv6回显回复），
o TCP SYN segments (meant to elicit SYN/ACK or RST segments),
o TCP SYN段（用于引出SYN/ACK或RST段），
o TCP segments that do not contain the ACK bit set (meant to elicit RST segments),
o 不包含ACK位集的TCP段（用于引出RST段），
o UDP datagrams (meant to elicit a UDP application response or an ICMPv6 Port Unreachable),
o UDP数据报（旨在引发UDP应用程序响应或ICMPv6端口不可访问），
o IPv6 packets containing any suitable payload and an unrecognized extension header (meant to elicit ICMPv6 Parameter Problem error messages), or
o 包含任何适当负载和无法识别的扩展标头的IPv6数据包（旨在引发ICMPv6参数问题错误消息），或
o IPv6 packets containing any suitable payload and an unrecognized option of type 10xxxxxx (meant to elicit an ICMPv6 Parameter Problem error message).
o IPv6数据包包含任何合适的负载和类型为10xxxxxx的无法识别的选项（旨在引发ICMPv6参数问题错误消息）。
Selecting an appropriate probe packet might help conceal the ongoing attack, but it may also be actually necessary if host or network configuration causes certain probe packets to be dropped.
选择适当的探测数据包可能有助于隐藏正在进行的攻击，但如果主机或网络配置导致某些探测数据包被丢弃，则实际上也可能需要这样做。
Some address-scanning tools (such as scan6 of [IPv6-Toolkit]) incorporate support for IPv6 extension headers. In some cases, inserting some IPv6 extension headers in the probe packet may allow some filtering policies or monitoring devices to be circumvented. However, it may also result in the probe packets being dropped, as a result of the widespread dropping of IPv6 packets that employ IPv6 extension headers (see [IPV6-EXT-HEADERS]).
一些地址扫描工具（如[IPv6 Toolkit]的scan6）包含对IPv6扩展头的支持。在某些情况下，在探测数据包中插入一些IPv6扩展头可能允许绕过某些过滤策略或监视设备。但是，由于采用IPv6扩展头的IPv6数据包的广泛丢弃（请参阅[IPv6-EXT-headers]），这也可能导致探测数据包被丢弃。
Another factor to consider is the address-probing rate. Clearly, the higher the rate, the smaller the amount of time required to perform the attack. However, the probing rate should not be too high, or else:
另一个要考虑的因素是地址探测率。显然，速率越高，执行攻击所需的时间越短。但是，探测率不应过高，否则：
1. the attack might cause network congestion, thus resulting in packet loss.
1. 该攻击可能导致网络拥塞，从而导致数据包丢失。
2. the attack might hit rate limiting, thus resulting in packet loss.
2. 攻击可能会达到速率限制，从而导致数据包丢失。
3. the attack might reveal underlying problems in Neighbor Discovery implementations, thus leading to packet loss and possibly even Denial of Service.
3. 该攻击可能揭示邻居发现实现中的潜在问题，从而导致数据包丢失，甚至可能导致拒绝服务。
Packet loss is undesirable, since it would mean that an "alive" node might remain undetected as a result of a lost probe or response. Such losses could be the result of congestion (in case the attacker is scanning a target network at a rate higher than the target network can handle) or may be the result of rate limiting (as it would be typically the case if ICMPv6 is employed for the probe packets). Finally, as discussed in [CPNI-IPv6] and [RFC6583], some IPv6 router implementations have been found to be unable to perform decent resource management when faced with Neighbor Discovery traffic involving a large number of local nodes. This essentially means that regardless of the type of probe packets, an address-scanning attack might result in a DoS of the target network, with the same (or worse) effects as that of network congestion or rate limiting.
数据包丢失是不可取的，因为它意味着“活动”节点可能由于丢失的探测或响应而未被检测到。此类丢失可能是拥塞的结果（如果攻击者以高于目标网络可处理的速率扫描目标网络），也可能是速率限制的结果（如果探测数据包使用ICMPv6，则通常会出现这种情况）。最后，如[CPNI-IPv6]和[RFC6583]中所述，一些IPv6路由器实现在面临涉及大量本地节点的邻居发现流量时无法执行适当的资源管理。这本质上意味着，无论探测数据包的类型如何，地址扫描攻击都可能导致目标网络的拒绝服务，其影响与网络拥塞或速率限制的影响相同（或更糟）。
The specific rates at which each of these issues may come into play vary from one scenario to another and depend on the type of deployed routers/firewalls, configuration parameters, etc.
这些问题的具体发生率因场景而异，取决于部署的路由器/防火墙类型、配置参数等。
scan6 [IPv6-Toolkit] is a full-fledged IPv6 local address-scanning tool, which has proven to be effective and efficient for the discovery of IPv6 hosts on a local network.
scan6[IPv6 Toolkit]是一个成熟的IPv6本地地址扫描工具，已证明它对于在本地网络上发现IPv6主机是有效的。
The scan6 tool operates (roughly) as follows:
scan6工具的操作（大致）如下所示：
1. The tool learns the local prefixes used for autoconfiguration and generates/configures one address for each local prefix (in addition to a link-local address).
1. 该工具学习用于自动配置的本地前缀，并为每个本地前缀生成/配置一个地址（除了链接本地地址）。
2. An ICMPv6 Echo Request message destined to the all-nodes on-link multicast address (ff02::1) is sent from each of the addresses "configured" in the previous step. Because of the different source addresses, each probe packet causes the victim nodes to use different source addresses for the response packets (this allows the tool to learn virtually all the addresses in use in the local network segment).
2. 从上一步中“配置”的每个地址发送一条发送到链路上所有节点多播地址（ff02:：1）的ICMPv6回显请求消息。由于源地址不同，每个探测数据包都会导致受害节点对响应数据包使用不同的源地址（这允许工具了解本地网段中使用的几乎所有地址）。
3. The same procedure of the previous bullet is performed, but this time with ICMPv6 packets that contain an unrecognized option of type 10xxxxxx, such that ICMPv6 Parameter Problem error messages are elicited. This allows the tool to discover, e.g., Windows nodes, which otherwise do not respond to multicasted ICMPv6 Echo Request messages.
3. 执行与上一个项目符号相同的过程，但这次使用的ICMPv6数据包包含类型为10xxxxxx的无法识别的选项，因此会引发ICMPv6参数问题错误消息。这允许工具发现，例如，Windows节点，否则不会响应多播ICMPv6回显请求消息。
4. Each time a new "alive" address is discovered, the corresponding IID is combined with all the local prefixes, and the resulting addresses are probed (with unicasted packets). This can help to discover other addresses in use on the local network segment, since the same IID is typically used with all the available prefixes for the local network.
4. 每次发现一个新的“活动”地址时，相应的IID与所有本地前缀组合，并探测得到的地址（使用单播数据包）。这有助于发现本地网段上使用的其他地址，因为同一IID通常与本地网络的所有可用前缀一起使用。
NOTE: The aforementioned scheme can fail to discover some addresses for some implementations. For example, Mac OS X employs IPv6 addresses embedding IEEE identifiers (rather than "temporary addresses") when responding to packets destined to a link-local multicast address, sourced from an on-link prefix.
注意：上述方案可能无法发现某些实现的某些地址。例如，Mac OS X在响应发送到链路本地多播地址（来源于链路前缀）的数据包时，使用嵌入IEEE标识符（而不是“临时地址”）的IPv6地址。
An IPv6 remote address-scanning tool could be implemented with the following features:
IPv6远程地址扫描工具可以实现以下功能：
o The tool can be instructed to target specific address ranges (e.g., 2001:db8::0-10:0-1000).
o 可以指示该工具以特定的地址范围为目标（例如，2001:db8:：0-10:0-1000）。
o The tool can be instructed to scan for SLAAC addresses of a specific vendor, such that only addresses embedding the corresponding IEEE OUIs are probed.
o 可以指示该工具扫描特定供应商的SLAAC地址，以便只探测嵌入相应IEEE OUI的地址。
o The tool can be instructed to scan for SLAAC addresses that employ a specific IEEE OUI or set of OUIs corresponding to a specific vector.
o 可以指示该工具扫描使用特定IEEE OUI或与特定向量对应的OUI集的SLAAC地址。
o The tool can be instructed to discover virtual machines, such that a given IPv6 prefix is only scanned for the address patterns resulting from virtual machines.
o 可以指示该工具发现虚拟机，以便只扫描给定IPv6前缀以查找虚拟机产生的地址模式。
o The tool can be instructed to scan for low-byte addresses.
o 可以指示该工具扫描低字节地址。
o The tool can be instructed to scan for wordy addresses, in which case the tool selects addresses based on a local dictionary.
o 可以指示工具扫描冗长的地址，在这种情况下，工具根据本地字典选择地址。
o The tool can be instructed to scan for IPv6 addresses embedding TCP/UDP service ports, in which case the tool selects addresses based on a list of well-known service ports.
o 可以指示工具扫描嵌入TCP/UDP服务端口的IPv6地址，在这种情况下，工具会根据已知服务端口列表选择地址。
o The tool can be specified to scan an IPv4 address range in use at the target network, such that only IPv4-based IPv6 addresses are scanned.
o 可以指定该工具来扫描目标网络上正在使用的IPv4地址范围，以便只扫描基于IPv4的IPv6地址。
The scan6 tool of [IPv6-Toolkit] implements all these techniques/ features. Furthermore, when given a target domain name or sample IPv6 address for a given prefix, the tool will try to infer the address pattern in use at the target network, and reduce the address search space accordingly.
[IPv6 Toolkit]的scan6工具实现了所有这些技术/功能。此外，当给定给定前缀的目标域名或示例IPv6地址时，该工具将尝试推断目标网络中使用的地址模式，并相应地减少地址搜索空间。
Acknowledgements
致谢
The authors would like to thank Ray Hunter, who provided valuable text that was readily incorporated into Section 4.2.1 of this document.
作者要感谢Ray Hunter，他提供了有价值的文本，这些文本很容易被纳入本文件第4.2.1节。
The authors would like to thank (in alphabetical order) Ivan Arce, Alissa Cooper, Spencer Dawkins, Stephen Farrell, Wesley George, Marc Heuse, Ray Hunter, Barry Leiba, Libor Polcak, Alvaro Retana, Tomoyuki Sahara, Jan Schaumann, Arturo Servin, and Eric Vyncke for providing valuable comments on earlier draft versions of this document.
作者要感谢（按字母顺序排列）伊万·阿尔奇、艾莉莎·库珀、斯宾塞·道金斯、斯蒂芬·法雷尔、韦斯利·乔治、马克·豪斯、雷·亨特、巴里·莱巴、利博·波尔卡、阿尔瓦罗·雷塔纳、托莫尤基·撒哈拉、扬·肖曼、阿图罗·塞文和埃里克·温克对本文件早期草稿提出了宝贵意见。
Fernando Gont would like to thank Jan Zorz of Go6 Lab <http://go6lab.si/> and Jared Mauch of NTT America for providing access to systems and networks that were employed to perform experiments and measurements that helped to improve this document. Additionally, he would like to thank SixXS <https://www.sixxs.net> for providing IPv6 connectivity.
费尔南多·冈特要感谢Go6实验室的扬·佐尔兹<http://go6lab.si/>以及NTT美国公司的贾里德·莫奇，感谢他提供了对系统和网络的访问，这些系统和网络被用来进行有助于改进本文件的实验和测量。此外，他还要感谢SixXS<https://www.sixxs.net>用于提供IPv6连接。
Part of the contents of this document are based on the results of the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI).
本文件的部分内容基于Fernando Gont代表英国国家基础设施保护中心（CPNI）开展的项目“互联网协议第6版（IPv6）的安全评估”[CPNI-IPv6]的结果。
Fernando Gont would like to thank Daniel Bellomo (UNRC) for his continued support.
费尔南多·冈特感谢丹尼尔·贝洛莫（UNRC）的持续支持。
Authors' Addresses
作者地址
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot. OX11 0SG United Kingdom
迪科特牛津哈维尔图书馆大道Tim Chown Jisc Lumen House。OX11 0SG英国
Email: tim.chown@jisc.ac.uk
Email: tim.chown@jisc.ac.uk