Internet Engineering Task Force (IETF) A. Cooper
Request for Comments: 7721 Cisco
Category: Informational F. Gont
ISSN: 2070-1721 Huawei Technologies
D. Thaler
Microsoft
March 2016
Internet Engineering Task Force (IETF) A. Cooper
Request for Comments: 7721 Cisco
Category: Informational F. Gont
ISSN: 2070-1721 Huawei Technologies
D. Thaler
Microsoft
March 2016
Security and Privacy Considerations for IPv6 Address Generation Mechanisms
IPv6地址生成机制的安全和隐私注意事项
Abstract
摘要
This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.
本文档讨论了几种IPv6地址生成机制（标准化和非标准化）的隐私和安全注意事项。它评估了不同的机制如何缓解不同的威胁，以及实现者、开发人员和用户在选择不同的地址或地址生成机制时面临的权衡。
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/rfc7721.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7721.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Weaknesses in IEEE-Identifier-Based IIDs . . . . . . . . . . 5
3.1. Correlation of Activities over Time . . . . . . . . . . . 5
3.2. Location Tracking . . . . . . . . . . . . . . . . . . . . 6
3.3. Address Scanning . . . . . . . . . . . . . . . . . . . . 7
3.4. Device-Specific Vulnerability Exploitation . . . . . . . 7
4. Privacy and Security Properties of Address Generation
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IEEE-Identifier-Based IIDs . . . . . . . . . . . . . . . 10
4.2. Static, Manually Configured IIDs . . . . . . . . . . . . 10
4.3. Constant, Semantically Opaque IIDs . . . . . . . . . . . 10
4.4. Cryptographically Generated IIDs . . . . . . . . . . . . 10
4.5. Stable, Semantically Opaque IIDs . . . . . . . . . . . . 11
4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
4.7. DHCPv6 Generation of IIDs . . . . . . . . . . . . . . . . 12
4.8. Transition and Coexistence Technologies . . . . . . . . . 12
5. Miscellaneous Issues with IPv6 Addressing . . . . . . . . . . 13
5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13
5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Weaknesses in IEEE-Identifier-Based IIDs . . . . . . . . . . 5
3.1. Correlation of Activities over Time . . . . . . . . . . . 5
3.2. Location Tracking . . . . . . . . . . . . . . . . . . . . 6
3.3. Address Scanning . . . . . . . . . . . . . . . . . . . . 7
3.4. Device-Specific Vulnerability Exploitation . . . . . . . 7
4. Privacy and Security Properties of Address Generation
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IEEE-Identifier-Based IIDs . . . . . . . . . . . . . . . 10
4.2. Static, Manually Configured IIDs . . . . . . . . . . . . 10
4.3. Constant, Semantically Opaque IIDs . . . . . . . . . . . 10
4.4. Cryptographically Generated IIDs . . . . . . . . . . . . 10
4.5. Stable, Semantically Opaque IIDs . . . . . . . . . . . . 11
4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
4.7. DHCPv6 Generation of IIDs . . . . . . . . . . . . . . . . 12
4.8. Transition and Coexistence Technologies . . . . . . . . . 12
5. Miscellaneous Issues with IPv6 Addressing . . . . . . . . . . 13
5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13
5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
IPv6 was designed to improve upon IPv4 in many respects, and mechanisms for address assignment were one such area for improvement. In addition to static address assignment and DHCP, stateless autoconfiguration was developed as a less intensive, fate-shared means of performing address assignment. With stateless autoconfiguration, routers advertise on-link prefixes and hosts generate their own Interface Identifiers (IIDs) to complete their addresses. [RFC7136] clarifies that the IID should be treated as an opaque value, while [RFC7421] provides an analysis of the 64-bit boundary in IPv6 addressing (e.g., the implications of the IID length on security and privacy). Over the years, many IID generation techniques have been defined, both standardized and non-standardized:
IPv6的设计目的是在许多方面改进IPv4，地址分配机制就是其中一个需要改进的领域。除了静态地址分配和DHCP之外，无状态自动配置被开发为执行地址分配的一种不太密集、命运共享的方法。通过无状态自动配置，路由器在链路前缀上发布广告，主机生成自己的接口标识符（IID）以完成其地址。[RFC7136]阐明了IID应被视为不透明值，而[RFC7421]提供了IPv6寻址中64位边界的分析（例如，IID长度对安全性和隐私性的影响）。多年来，已经定义了许多IID生成技术，包括标准化和非标准化：
o Manual configuration [RFC7707]
o 手动配置[RFC7707]
* IPv4 address
* IPv4地址
* Service port
* 服务端口
* Wordy
* 罗嗦
* Low-byte
* 低字节
o Stateless Address Autoconfiguration (SLAAC)
o 无状态地址自动配置（SLAAC）
* IEEE 802 48-bit Media Access Control (MAC) or IEEE 64-bit Extended Unique Identifier (EUI-64) [RFC2464]
* IEEE 802 48位媒体访问控制（MAC）或IEEE 64位扩展唯一标识符（EUI-64）[RFC2464]
* Cryptographically generated [RFC3972]
* 加密生成的[RFC3972]
* Temporary (also known as "privacy addresses") [RFC4941]
* 临时（也称为“隐私地址”）[RFC4941]
* Constant, semantically opaque (also known as "random") [Microsoft]
* 常量，语义不透明（也称为“随机”）[Microsoft]
* Stable, semantically opaque [RFC7217]
* 稳定的，语义不透明的[RFC7217]
o DHCPv6 based [RFC3315]
o 基于DHCPv6的[RFC3315]
o Specified by transition/co-existence technologies
o 由过渡/共存技术指定
* Derived from an IPv4 address (e.g., [RFC5214], [RFC6052])
* 从IPv4地址派生（例如，[RFC5214]、[RFC6052]）
* Derived from an IPv4 address and port set ID (e.g., [RFC7596], [RFC7597], [RFC7599])
* 源自IPv4地址和端口集ID（例如，[RFC7596]、[RFC7597]、[RFC7599]）
* Derived from an IPv4 address and port (e.g., [RFC4380])
* 从IPv4地址和端口派生（例如，[RFC4380]）
Deriving the IID from a globally unique IEEE identifier [RFC2464] [RFC4862] was one of the earliest mechanisms developed (and originally specified in [RFC1971] and [RFC1972]). A number of privacy and security issues related to the IIDs derived from IEEE identifiers were discovered after their standardization, and many of the mechanisms developed later aimed to mitigate some or all of these weaknesses. This document identifies four types of attacks against IEEE-identifier-based IIDs and discusses how other existing techniques for generating IIDs do or do not mitigate those attacks.
从全球唯一的IEEE标识符[RFC2464][RFC4862]推导IID是最早开发的机制之一（最初在[RFC1971]和[RFC1972]中规定）。标准化后，发现了许多与IEEE标识符衍生的IID相关的隐私和安全问题，后来开发的许多机制旨在缓解部分或全部这些弱点。本文档确定了针对基于IEEE标识符的IID的四种攻击类型，并讨论了生成IID的其他现有技术如何减轻或不减轻这些攻击。
This section clarifies the terminology used throughout this document.
本节澄清了本文件中使用的术语。
Public address: An address that has been published in a directory or other public location, such as the DNS, a SIP proxy [RFC3261], an application-specific Distributed Hash Table (DHT), or a publicly available URI. A host's public addresses are intended to be discoverable by third parties.
公共地址：已发布在目录或其他公共位置的地址，如DNS、SIP代理[RFC3261]、特定于应用程序的分布式哈希表（DHT）或公共可用URI。主机的公共地址旨在被第三方发现。
Stable address: An address that does not vary over time within the same IPv6 link. Note that [RFC4941] refers to these as "public" addresses, but "stable" is used here for reasons explained in Section 4.
稳定地址：在同一IPv6链路中不随时间变化的地址。请注意，[RFC4941]将这些地址称为“公共”地址，但出于第4节中解释的原因，此处使用“稳定”地址。
Temporary address: An address that varies over time within the same IPv6 link.
临时地址：在同一IPv6链路中随时间变化的地址。
Constant IID: An IPv6 interface identifier that is globally stable. That is, the Interface ID will remain constant even if the node moves from one IPv6 link to another.
常量IID：全局稳定的IPv6接口标识符。也就是说，即使节点从一个IPv6链路移动到另一个IPv6链路，接口ID也将保持不变。
Stable IID: An IPv6 interface identifier that is stable within some specified context. For example, an Interface ID can be globally stable (constant) or could be stable per IPv6 link (meaning that the Interface ID will remain unchanged as long as the node stays on the same IPv6 link but may change when the node moves from one IPv6 link to another).
稳定IID：在某些指定上下文中稳定的IPv6接口标识符。例如，接口ID可以是全局稳定的（常数），也可以是每个IPv6链路稳定的（这意味着只要节点保持在同一IPv6链路上，接口ID将保持不变，但当节点从一个IPv6链路移动到另一个IPv6链路时，接口ID可能会改变）。
Temporary IID: An IPv6 interface identifier that varies over time.
临时IID：随时间变化的IPv6接口标识符。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。这些词只有在全部大写时才具有规范意义。
There are a number of privacy and security implications that exist for hosts that use IEEE-identifier-based IIDs. This section discusses four generic attack types: correlation of activities over time, location tracking, address scanning, and device-specific vulnerability exploitation. The first three of these rely on the attacker first gaining knowledge of the IID of the target host. This could be achieved by a number of different entities: the operator of a server to which the host connects, such as a web server or a peer-to-peer server; an entity that connects to the same IPv6 link as the target (such as a conference network or any public network); a passive observer of traffic that the host broadcasts; or an entity that is on path to the destinations with which the host communicates, such as a network operator.
对于使用基于IEEE标识符的IID的主机，存在许多隐私和安全问题。本节讨论四种常见攻击类型：随时间变化的活动相关性、位置跟踪、地址扫描和特定于设备的漏洞利用。前三种方法依赖于攻击者首先了解目标主机的IID。这可以通过许多不同的实体来实现：主机连接到的服务器的操作员，例如web服务器或对等服务器；与目标连接到同一IPv6链路的实体（如会议网络或任何公共网络）；对主机广播的流量的被动观察者；或位于主机与之通信的目的地路径上的实体，如网络运营商。
As with other identifiers, an IPv6 address can be used to correlate the activities of a host for at least as long as the lifetime of the address. The correlation made possible by IEEE-identifier-based IIDs is of particular concern since they last roughly for the lifetime of a device's network interface, allowing correlation on the order of years.
与其他标识符一样，IPv6地址可用于关联主机的活动，时间至少与地址的生命周期相同。由基于IEEE标识符的IID实现的相关性尤其值得关注，因为它们大致持续设备网络接口的生命周期，允许以年为单位的相关性。
As [RFC4941] explains,
正如[RFC4941]所解释的，
[t]he use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. ... The use of a constant identifier within an address is of special concern because addresses are a fundamental requirement of communication and cannot easily be hidden from eavesdroppers and other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear.
[t] 使用不改变的接口标识符来形成地址是更一般情况下的一个具体实例，在这种情况下，常量标识符在一段较长的时间内以及在多个独立的活动中被重用。只要在多个上下文中使用同一标识符，该标识符就有可能用于关联看似无关的活动。。。在地址中使用常量标识符是一个特别值得关注的问题，因为地址是通信的基本要求，不容易被窃听者和其他方隐藏。即使当更高层加密其有效载荷时，数据包头中的地址也会显示为明文。
IP addresses are just one example of information that can be used to correlate activities over time. DNS names, cookies [RFC6265], browser fingerprints [Panopticlick], and application-layer usernames
IP地址只是一个可以用来随时间关联活动的信息示例。DNS名称、Cookie[RFC6265]、浏览器指纹[Panoptick]和应用层用户名
can all be used to link a host's activities together. Although IEEE-identifier-based IIDs are likely to last at least as long or longer than these other identifiers, IIDs generated in other ways may have shorter or longer lifetimes than these identifiers depending on how they are generated. Therefore, the extent to which a host's activities can be correlated depends on whether the host uses multiple identifiers together and the lifetimes of all of those identifiers. Frequently refreshing an IPv6 address may not mitigate correlation if an attacker has access to other longer-lived identifiers for a particular host. This is an important caveat to keep in mind throughout the discussion of correlation in this document. For further discussion of correlation, see Section 5.2.1 of [RFC6973].
都可用于将主机的活动链接在一起。尽管基于IEEE标识符的IID可能至少与这些其他标识符的寿命相同或更长，但以其他方式生成的IID可能比这些标识符的寿命更短或更长，具体取决于它们的生成方式。因此，主机活动的关联程度取决于主机是否同时使用多个标识符以及所有这些标识符的生存期。如果攻击者能够访问特定主机的其他寿命更长的标识符，则频繁刷新IPv6地址可能不会缓解相关性。在本文档中的相关性讨论过程中，这是一个重要的注意事项。有关相关性的进一步讨论，请参见[RFC6973]第5.2.1节。
As noted in [RFC4941], in some cases correlation is just as feasible for a host using an IPv4 address as for a host using an IEEE identifier to generate its IID in its IPv6 address. Hosts that use static IPv4 addressing or who are consistently allocated the same address via DHCPv4 can be tracked as described above. However, the widespread use of both NAT and DHCPv4 implementations that assign the same host a different address upon lease expiration mitigates this threat in the IPv4 case as compared to the IEEE identifier case in IPv6.
如[RFC4941]所述，在某些情况下，使用IPv4地址的主机与使用IEEE标识符在其IPv6地址中生成IID的主机的相关性同样可行。可以如上所述跟踪使用静态IPv4地址或通过DHCPv4一致分配相同地址的主机。然而，NAT和DHCPv4实现的广泛使用，在租约到期时为同一主机分配不同的地址，与IPv6中的IEEE标识符情况相比，在IPv4情况下缓解了这种威胁。
Because the IPv6 address structure is divided between a topological portion and an interface identifier portion, an interface identifier that remains constant when a host connects to different IPv6 links (as an IEEE-identifier-based IID does) provides a way for observers to track the movements of that host. In a passive attack on a mobile host, a server that receives connections from the same host over time would be able to determine the host's movements as its prefix changes.
由于IPv6地址结构分为拓扑部分和接口标识符部分，因此当主机连接到不同的IPv6链路时保持不变的接口标识符（如基于IEEE标识符的IID）为观察者提供了跟踪该主机移动的方法。在对移动主机的被动攻击中，随着时间的推移，从同一主机接收连接的服务器将能够确定主机在其前缀更改时的移动。
Active attacks are also possible. An attacker that first learns the host's interface identifier by being connected to the same IPv6 link, running a server that the host connects to, or being on path to the host's communications could subsequently probe other networks for the presence of the same interface identifier by sending a probe packet (e.g., ICMPv6 Echo Request, or any other probe packet). Even if the host does not respond, the first-hop router will usually respond with an ICMP Destination Unreachable/Address Unreachable (type 1, code 3) when the host is not present and be silent when the host is present.
主动攻击也是可能的。通过连接到同一IPv6链路、运行主机连接的服务器或在主机通信路径上，首先学习主机接口标识符的攻击者可以通过发送探测数据包探测其他网络是否存在相同的接口标识符（例如，ICMPv6回显请求或任何其他探测数据包）。即使主机没有响应，第一跳路由器通常会在主机不存在时响应ICMP目的地不可访问/地址不可访问（类型1，代码3），并且在主机存在时保持静默。
Location tracking based on IP address is generally not possible in IPv4 since hosts get assigned wholly new addresses when they change networks.
在IPv4中，基于IP地址的位置跟踪通常是不可能的，因为主机在更改网络时会被分配全新的地址。
The structure of IEEE-based identifiers used for address generation can be leveraged by an attacker to reduce the target search space [RFC7707]. The 24-bit Organizationally Unique Identifier (OUI) of MAC addresses, together with the fixed value (0xff, 0xfe) used to form a Modified EUI-64 interface identifier, greatly help to reduce the search space, making it easier for an attacker to scan for individual addresses using widely known popular OUIs. This erases much of the protection against address scanning that the larger IPv6 address space could provide as compared to IPv4.
攻击者可以利用用于地址生成的基于IEEE的标识符的结构来减少目标搜索空间[RFC7707]。MAC地址的24位组织唯一标识符（OUI）以及用于形成修改后的EUI-64接口标识符的固定值（0xff，0xfe），大大有助于减少搜索空间，使攻击者更容易使用广为人知的OUI扫描单个地址。与IPv4相比，更大的IPv6地址空间可以提供许多针对地址扫描的保护，这就消除了这些保护。
IPv6 addresses that embed IEEE identifiers leak information about the device (e.g., Network Interface Card vendor, or even Operating System and/or software type), which could be leveraged by an attacker with knowledge of device- or software-specific vulnerabilities to quickly find possible targets. Attackers can exploit vulnerabilities in hosts whose IIDs they have previously obtained or scan an address space to find potential targets.
嵌入IEEE标识符的IPv6地址泄漏有关设备的信息（例如，网络接口卡供应商，甚至操作系统和/或软件类型），知道设备或软件特定漏洞的攻击者可以利用这些信息快速找到可能的目标。攻击者可以利用其先前获得的IID主机中的漏洞，或扫描地址空间以查找潜在目标。
Analysis of the extent to which a particular host is protected against the attacks described in Section 3 depends on how each of a host's addresses is generated and used. In some scenarios, a host configures a single global address and uses it for all communications. In other scenarios, a host configures multiple addresses using different mechanisms and may use any or all of them.
针对第3节所述攻击对特定主机的保护程度的分析取决于如何生成和使用每个主机的地址。在某些情况下，主机配置单个全局地址并将其用于所有通信。在其他场景中，主机使用不同的机制配置多个地址，并且可以使用其中任何一个或所有地址。
[RFC3041] (later obsoleted by [RFC4941]) sought to address some of the problems described in Section 3 by defining "temporary addresses" for outbound connections. Temporary addresses are meant to supplement the other addresses that a device might use, not to replace them. They use IIDs that are randomly generated and change daily by default. The idea was for temporary addresses to be used for outgoing connections (e.g., web browsing) while maintaining the ability to use a stable address when more address stability is desired (e.g., for IPv6 addresses published in the DNS).
[RFC3041]（后来被[RFC4941]淘汰）试图通过定义出站连接的“临时地址”来解决第3节中描述的一些问题。临时地址用于补充设备可能使用的其他地址，而不是替换它们。他们使用随机生成的IID，默认情况下每天都会更改。这个想法是为了在需要更高的地址稳定性时（例如，对于DNS中发布的IPv6地址），在保持使用稳定地址的能力的同时，将临时地址用于传出连接（例如，web浏览）。
[RFC3484] originally specified that stable addresses be used for outbound connections unless an application explicitly prefers temporary addresses. The default preference for stable addresses was established to avoid applications potentially failing due to the short lifetime of temporary addresses or the possibility of a reverse look-up failure or error. However, [RFC3484] allowed that "implementations for which privacy considerations outweigh these
[RFC3484]最初指定稳定地址用于出站连接，除非应用程序明确首选临时地址。建立稳定地址的默认首选项是为了避免由于临时地址的生存期短或可能出现反向查找失败或错误而导致应用程序可能失败。然而，[RFC3484]允许“隐私考虑超过这些的实现”
application-compatibility concerns MAY reverse the sense of this rule" and instead prefer by default temporary addresses rather than stable addresses. Indeed, most implementations (notably including Windows) chose to default to temporary addresses for outbound connections since privacy was considered more important (and few applications supported IPv6 at the time, so application compatibility concerns were minimal). [RFC6724] then obsoleted [RFC3484] and changed the default to match what implementations actually did.
应用程序兼容性问题可能会改变这一规则的含义”，而是更喜欢默认的临时地址，而不是稳定的地址。事实上，大多数实现（尤其包括Windows）都选择默认为出站连接的临时地址，因为隐私被认为更为重要（当时很少有应用程序支持IPv6，因此应用程序兼容性问题很少）。[RFC6724]随后淘汰了[RFC3484]，并更改了默认设置以匹配实际实现。
The envisioned relationship in [RFC3484] between stability of an address and its use in "public" can be misleading when conducting privacy analysis. The stability of an address and the extent to which it is linkable to some other public identifier are independent of one another. For example, there is nothing that prevents a host from publishing a temporary address in a public place, such as the DNS. Publishing both a stable address and a temporary address in the DNS or elsewhere where they can be linked together by a public identifier allows the host's activities when using either address to be correlated together.
[RFC3484]中设想的地址稳定性与其在“公共”中的使用之间的关系在进行隐私分析时可能会产生误导。地址的稳定性和可链接到其他公共标识符的程度是相互独立的。例如，没有任何东西可以阻止主机在公共场所（如DNS）发布临时地址。在DNS或其他地方发布稳定地址和临时地址（它们可以通过公共标识符链接在一起），允许主机在使用任一地址时将其活动关联在一起。
Moreover, because temporary addresses were designed to supplement other addresses generated by a host, the host may still configure a more stable address even if it only ever intentionally uses temporary addresses (as source addresses) for communication to off-link destinations. An attacker can probe for the stable address even if it is never used as such a source address or advertised outside the link (e.g., in DNS or SIP).
此外，由于临时地址被设计为补充主机生成的其他地址，因此即使主机只是有意使用临时地址（作为源地址）来与断开链路的目的地进行通信，它仍然可以配置更稳定的地址。攻击者可以探测稳定地址，即使该地址从未被用作源地址或在链接外部（例如，在DNS或SIP中）公布。
This section compares the privacy and security properties of a variety of IID generation mechanisms and their possible usage scenarios, including scenarios in which a single mechanism is used to generate all of a host's IIDs and those in which temporary addresses are used together with addresses generated using a different IID generation mechanism. The analysis of the exposure of each IID type to correlation assumes that IPv6 prefixes are shared by a reasonably large number of nodes. As [RFC4941] notes, if a very small number of nodes (say, only one) use a particular prefix for an extended period of time, the prefix itself can be used to correlate the host's activities regardless of how the IID is generated. For example, [RFC3314] recommends that prefixes be uniquely assigned to mobile handsets where IPv6 is used within General Packet Radio Service (GPRS). In cases where this advice is followed and prefixes persist for extended periods of time (or get reassigned to the same handsets whenever those handsets reconnect to the same network router), hosts' activities could be correlatable for longer periods than the analysis below would suggest.
本节比较了各种IID生成机制的隐私和安全属性及其可能的使用场景，包括使用单一机制生成主机所有IID的场景，以及临时地址与使用不同IID生成机制生成的地址一起使用的场景。对每种IID类型暴露于相关性的分析假设IPv6前缀由相当多的节点共享。如[RFC4941]所述，如果极少数节点（例如，只有一个）在较长时间内使用特定前缀，则前缀本身可用于关联主机的活动，而不管IID是如何生成的。例如，[RFC3314]建议在通用分组无线业务（GPRS）中使用IPv6的移动手机上唯一分配前缀。如果遵循此建议且前缀持续较长时间（或在手机重新连接到同一网络路由器时重新分配到同一手机），主机活动的相关时间可能比下面的分析所建议的更长。
The table below provides a summary of the whole analysis. A "No" entry indicates that the attack is prevented from being carried out on the basis of the IID, but the host may still be vulnerable depending on how it employs other protocols.
下表总结了整个分析。“否”条目表示根据IID阻止了攻击的执行，但主机可能仍然易受攻击，这取决于它使用其他协议的方式。
+--------------+-------------+----------+-------------+-------------+
| Mechanism(s) | Correlation | Location | Address | Device |
| | | tracking | scanning | exploits |
+--------------+-------------+----------+-------------+-------------+
| IEEE | For device | For | Possible | Possible |
| identifier | lifetime | device | | |
| | | lifetime | | |
| | | | | |
| Static | For address | For | Depends on | Depends on |
| manual | lifetime | address | generation | generation |
| | | lifetime | mechanism | mechanism |
| | | | | |
| Constant, | For address | For | No | No |
| semantically | lifetime | address | | |
| opaque | | lifetime | | |
| | | | | |
| CGA | For | No | No | No |
| | lifetime of | | | |
| | (modifier | | | |
| | block + | | | |
| | public key) | | | |
| | | | | |
| Stable, | Within | No | No | No |
| semantically | single IPv6 | | | |
| opaque | link | | | |
| | | | | |
| Temporary | For temp | No | No | No |
| | address | | | |
| | lifetime | | | |
| | | | | |
| DHCPv6 | For lease | No | Depends on | No |
| | lifetime | | generation | |
| | | | mechanism | |
+--------------+-------------+----------+-------------+-------------+
+--------------+-------------+----------+-------------+-------------+
| Mechanism(s) | Correlation | Location | Address | Device |
| | | tracking | scanning | exploits |
+--------------+-------------+----------+-------------+-------------+
| IEEE | For device | For | Possible | Possible |
| identifier | lifetime | device | | |
| | | lifetime | | |
| | | | | |
| Static | For address | For | Depends on | Depends on |
| manual | lifetime | address | generation | generation |
| | | lifetime | mechanism | mechanism |
| | | | | |
| Constant, | For address | For | No | No |
| semantically | lifetime | address | | |
| opaque | | lifetime | | |
| | | | | |
| CGA | For | No | No | No |
| | lifetime of | | | |
| | (modifier | | | |
| | block + | | | |
| | public key) | | | |
| | | | | |
| Stable, | Within | No | No | No |
| semantically | single IPv6 | | | |
| opaque | link | | | |
| | | | | |
| Temporary | For temp | No | No | No |
| | address | | | |
| | lifetime | | | |
| | | | | |
| DHCPv6 | For lease | No | Depends on | No |
| | lifetime | | generation | |
| | | | mechanism | |
+--------------+-------------+----------+-------------+-------------+
Table 1: Privacy and Security Properties of IID Generation Mechanisms
表1:IID生成机制的隐私和安全属性
As discussed in Section 3, addresses that use IIDs based on IEEE identifiers are vulnerable to all four attacks. They allow correlation and location tracking for the lifetime of the device since IEEE identifiers last that long and their structure makes address scanning and device exploits possible.
如第3节所述，使用基于IEEE标识符的IID的地址容易受到所有四种攻击。它们允许在设备的生命周期内进行关联和位置跟踪，因为IEEE标识符持续那么长时间，并且它们的结构使地址扫描和设备利用成为可能。
Because static, manually configured IIDs are stable, both correlation and location tracking are possible for the life of the address.
因为静态、手动配置的IID是稳定的，所以在地址的生命周期内，相关和位置跟踪都是可能的。
The extent to which location tracking can be successfully performed depends, to some extent, on the uniqueness of the employed IID. For example, one would expect "low byte" IIDs to be more widely reused than, for example, IIDs where the whole 64 bits follow some pattern that is unique to a specific organization. Widely reused IIDs will typically lead to false positives when performing location tracking.
位置跟踪的成功程度在某种程度上取决于所采用IID的唯一性。例如，人们期望“低字节”IID比整个64位遵循特定组织特有模式的IID得到更广泛的重用。广泛重用的IID在执行位置跟踪时通常会导致误报。
Whether manually configured addresses are vulnerable to address scanning and device exploits depends on the specifics of how the IIDs are generated.
手动配置的地址是否容易受到地址扫描和设备攻击，取决于IID生成的具体方式。
Although a mechanism to generate a constant, semantically opaque IID has not been standardized, it has been in wide use for many years on at least one platform (Windows). Windows uses the random generation mechanism described in [RFC4941] in lieu of generating an IEEE-identifier-based IID. This mitigates the device-specific exploitation and address-scanning attacks but still allows correlation and location tracking because the IID is constant across IPv6 links and time.
尽管生成一个常量、语义不透明的IID的机制尚未标准化，但它已经在至少一个平台（Windows）上广泛使用多年。Windows使用[RFC4941]中描述的随机生成机制来代替基于IEEE标识符的IID生成。这减轻了特定于设备的攻击和地址扫描攻击，但仍然允许关联和位置跟踪，因为IID在IPv6链路和时间上是恒定的。
Cryptographically Generated Addresses (CGAs) [RFC3972] bind a hash of the host's public key to an IPv6 address in the SEcure Neighbor Discovery (SEND) protocol [RFC3971]. CGAs may be regenerated for each subnet prefix, but this is not required given that they are computationally expensive to generate. A host using a CGA can be correlated for as long as the lifetime of the combination of the public key and the chosen modifier block since it is possible to rotate modifier blocks without generating new public keys. Because the cryptographic hash of the host's public key uses the subnet prefix as an input, even if the host does not generate a new public key or modifier block when it moves to a different IPv6 link, its
加密生成地址（CGA）[RFC3972]将主机公钥的哈希绑定到安全邻居发现（SEND）协议[RFC3971]中的IPv6地址。可以为每个子网前缀重新生成CGA，但这不是必需的，因为生成CGA的计算成本很高。使用CGA的主机可以在公钥和所选修改器块组合的生命周期内进行关联，因为可以在不生成新公钥的情况下旋转修改器块。由于主机公钥的加密散列使用子网前缀作为输入，因此即使主机在移动到其他IPv6链路时未生成新公钥或修改器块，其
location cannot be tracked via the IID. CGAs do not allow device-specific exploitation or address-scanning attacks.
无法通过IID跟踪位置。CGA不允许特定于设备的攻击或地址扫描攻击。
[RFC7217] specifies an algorithm that generates, for each network interface, a unique random IID per IPv6 link. The aforementioned algorithm is employed not only for global unicast addresses, but also for unique local unicast addresses and link-local unicast addresses since these addresses may leak out via application protocols (e.g., IPv6 addresses embedded in email headers).
[RFC7217]指定一种算法，该算法为每个网络接口生成每个IPv6链路的唯一随机IID。上述算法不仅适用于全局单播地址，还适用于唯一的本地单播地址和链路本地单播地址，因为这些地址可能通过应用协议泄漏（例如，嵌入电子邮件头中的IPv6地址）。
A host that stays connected to the same IPv6 link could therefore be tracked at length, whereas a mobile host's activities could only be correlated for the duration of each network connection. Location tracking is not possible with these addresses. They also do not allow device-specific exploitation or address-scanning attacks.
因此，可以对保持连接到同一IPv6链路的主机进行长时间跟踪，而移动主机的活动只能在每个网络连接的持续时间内进行关联。使用这些地址无法进行位置跟踪。它们也不允许特定于设备的攻击或地址扫描攻击。
A host that uses only a temporary address mitigates all four threats. Its activities may only be correlated for the lifetime of a single temporary address.
仅使用临时地址的主机可以缓解所有四种威胁。它的活动只能在单个临时地址的生存期内关联。
A host that configures both an IEEE-identifier-based IID and temporary addresses makes the host vulnerable to the same attacks as if temporary addresses were not in use, although the viability of some of them depends on how the host uses each address. An attacker can correlate all of the host's activities for which it uses its IEEE-identifier-based IID. Once an attacker has obtained the IEEE-identifier-based IID, location tracking becomes possible on other IPv6 links even if the host only makes use of temporary addresses on those other IPv6 links; the attacker can actively probe the other IPv6 links for the presence of the IEEE-identifier-based IID. Device-specific vulnerabilities can still be exploited. Address scanning is also still possible because the IEEE-identifier-based address can be probed.
配置基于IEEE标识符的IID和临时地址的主机会使主机容易受到相同的攻击，就像临时地址未被使用一样，尽管其中一些地址的可行性取决于主机如何使用每个地址。攻击者可以关联其使用基于IEEE标识符的IID的主机的所有活动。一旦攻击者获得基于IEEE标识符的IID，即使主机仅使用这些其他IPv6链路上的临时地址，也可以在其他IPv6链路上进行位置跟踪；攻击者可以主动探测其他IPv6链路是否存在基于IEEE标识符的IID。仍然可以利用特定于设备的漏洞。地址扫描也是可能的，因为可以探测基于IEEE标识符的地址。
If the host instead generates a constant, semantically opaque IID to use in a stable address for server-like connections together with temporary addresses for outbound connections (as is the default in Windows), it sees some improvements over the previous scenario. The address-scanning attacks and device-specific exploitation attacks are no longer possible because the OUI is no longer embedded in any of the host's addresses. However, correlation of some activities across time and location tracking are both still possible because the semantically opaque IID is constant. And once an attacker has obtained the host's semantically opaque IID, location tracking is
如果主机生成一个恒定的、语义不透明的IID，用于类似服务器的连接的稳定地址以及出站连接的临时地址（在Windows中是默认的），那么它会看到比前一个场景有所改进。地址扫描攻击和特定于设备的攻击不再可能，因为OUI不再嵌入任何主机地址中。然而，由于语义不透明的IID是常量，所以跨时间和位置跟踪的某些活动的相关性仍然是可能的。一旦攻击者获得了主机的语义不透明的IID，就可以进行位置跟踪
possible on any network by probing for that IID, even if the host only uses temporary addresses on those networks. However, if the host generates but never uses a constant, semantically opaque IID, it mitigates all four threats.
通过探测该IID在任何网络上都是可能的，即使主机仅在这些网络上使用临时地址。但是，如果主机生成但从不使用恒定的、语义不透明的IID，则它可以缓解所有四种威胁。
When used together with temporary addresses, the stable, semantically opaque IID generation mechanism [RFC7217] improves upon the previous scenario by limiting the potential for correlation to the lifetime of the stable address (which may still be lengthy for hosts that are not mobile) and by eliminating the possibility for location tracking (since a different IID is generated for each subnet prefix). As in the previous scenario, a host that configures but does not use a stable, semantically opaque address mitigates all four threats.
当与临时地址一起使用时，稳定的、语义不透明的IID生成机制[RFC7217]通过将关联的可能性限制在稳定地址的生存期内（对于非移动主机来说可能仍然很长）和消除位置跟踪的可能性，改进了前一种情况（因为为每个子网前缀生成不同的IID）。与前面的场景一样，配置但不使用稳定、语义不透明地址的主机可以缓解所有四种威胁。
The security and privacy implications of DHCPv6-based addresses will typically depend on whether the client requests an IA_NA (Identity Association for Non-temporary Addresses) or an IA_TA (Identity Association for Temporary Addresses) [RFC3315] and the specific DHCPv6 server software being employed.
基于DHCPv6的地址的安全和隐私影响通常取决于客户端是请求IA_-NA（非临时地址的身份关联）还是IA_-TA（临时地址的身份关联）[RFC3315]以及所使用的特定DHCPv6服务器软件。
DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses.
DHCPv6临时地址与SLAAC临时地址具有相同的属性（见第4.6节）。另一方面，DHCPv6非临时地址的属性通常取决于所使用的特定DHCPv6服务器软件。最流行的DHCPv6服务器软件的最新版本通常租赁随机地址，租赁时间与IPv4类似。因此，这些地址可以被认为是“稳定的、语义不透明的”。[DHCPv6 IID]指定DHCPv6服务器可用于生成“稳定、语义不透明”地址的算法。
On the other hand, some DHCPv6 software leases sequential addresses (typically low-byte addresses). These addresses can be considered to be stable addresses. The drawback of this address generation scheme compared to "stable, semantically opaque" addresses is that, since they follow specific patterns, they enable IPv6 address scans.
另一方面，一些DHCPv6软件租用顺序地址（通常为低字节地址）。这些地址可以被认为是稳定的地址。与“稳定的、语义不透明的”地址相比，这种地址生成方案的缺点是，由于它们遵循特定的模式，因此能够进行IPv6地址扫描。
Addresses specified based on transition or coexistence technologies that embed an IPv4 address within an IPv6 address are not included in Table 1 because their privacy and security properties are inherited from the embedded address. For example, Teredo [RFC4380] specifies a means to generate an IPv6 address from the underlying IPv4 address and port, leaving many other bits set to zero. This makes it relatively easy for an attacker to scan for IPv6 addresses by guessing the Teredo client's IPv4 address and port (which for many
表1不包括基于在IPv6地址中嵌入IPv4地址的转换或共存技术指定的地址，因为它们的隐私和安全属性是从嵌入地址继承的。例如，Teredo[RFC4380]指定了一种从底层IPv4地址和端口生成IPv6地址的方法，将许多其他位设置为零。这使得攻击者通过猜测Teredo客户端的IPv4地址和端口（对于许多人来说是如此）来扫描IPv6地址相对容易
NATs is not randomized). For this reason, popular implementations (e.g., Windows) began deviating from the standard by including 12 random bits in place of zero bits. This modification was later standardized in [RFC5991].
NATs不是随机的）。因此，流行的实现（如Windows）开始偏离标准，用12个随机位代替零位。该修改后来在[RFC5991]中标准化。
Some other transition technologies (e.g., [RFC5214], [RFC6052]) specify means to generate an IPv6 address from an underlying IPv4 address without a port. Such mechanisms thus make it much easier for an attacker to conduct an address scan than for mechanisms that require finding a port number as well.
其他一些转换技术（例如，[RFC5214]、[RFC6052]）指定了从底层IPv4地址生成IPv6地址的方法，而不需要端口。因此，与需要查找端口号的机制相比，此类机制使攻击者更容易进行地址扫描。
Finally, still other mechanisms (e.g., [RFC7596], [RFC7597], [RFC7599]) are somewhere in between, using an IPv4 address and a port set ID (which for many NATs is not randomized). In general, such mechanisms are thus typically as easy to scan as in the Teredo example above without the 12-bit mitigation.
最后，还有其他机制（例如，[RFC7596]、[RFC7597]、[RFC7599]）介于两者之间，使用IPv4地址和端口集ID（对于许多NAT来说，这不是随机的）。一般来说，这样的机制通常与上面的Teredo示例一样容易扫描，而无需12位缓解。
It is generally agreed that IPv6 addresses that vary over time in a specific IPv6 link tend to increase the complexity of event logging, trouble-shooting, enforcement of access controls and quality of service, etc. As a result, some organizations disable the use of temporary addresses [RFC4941] even at the expense of reduced privacy [Broersma].
人们普遍认为，特定IPv6链路中随时间变化的IPv6地址往往会增加事件记录、故障排除、访问控制实施和服务质量等的复杂性。因此，一些组织甚至以降低隐私为代价禁用临时地址[RFC4941]。
Some IPv6 compliance testing suites required (and might still require) implementations to support IEEE-identifier-based IIDs in order to be approved as compliant. This document recommends that compliance testing suites be relaxed to allow other forms of address generation that are more amenable to privacy.
一些IPv6符合性测试套件需要（并且可能仍然需要）实现来支持基于IEEE标识符的IID，以便被批准为符合性测试套件。本文档建议放宽法规遵从性测试套件，以允许更符合隐私的其他形式的地址生成。
Some IPv6 addressing techniques might be covered by Intellectual Property rights, which might limit their implementation in different operating systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on CGAs.
某些IPv6寻址技术可能受知识产权保护，这可能会限制它们在不同操作系统中的实现。[CGA-IPR]和[KAME-CGA]讨论CGA的知识产权。
This whole document concerns the privacy and security properties of different IPv6 address generation mechanisms.
整个文档涉及不同IPv6地址生成机制的隐私和安全属性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC 2464，DOI 10.17487/RFC2464，1998年12月<http://www.rfc-editor.org/info/rfc2464>.
[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>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 3972，DOI 10.17487/RFC3972，2005年3月<http://www.rfc-editor.org/info/rfc3972>.
[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>.
[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>.
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, DOI 10.17487/RFC5991, September 2010, <http://www.rfc-editor.org/info/rfc5991>.
[RFC5991]Thaler，D.，Krishnan，S.，和J.Hoagland，“Teredo安全更新”，RFC 5991，DOI 10.17487/RFC599119010年9月<http://www.rfc-editor.org/info/rfc5991>.
[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>.
[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>.
[Broersma] Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6-enabled environment", Australian IPv6 Summit 2010, Melbourne, VIC Australia, October 2010, <http://www.ipv6.org.au/10ipv6summit/talks/ Ron_Broersma.pdf>.
[Broersma]Broersma，R.，“无处不在的IPv6：生活在完全支持IPv6的环境中”，2010年澳大利亚IPv6峰会，澳大利亚维多利亚州墨尔本，2010年10月<http://www.ipv6.org.au/10ipv6summit/talks/ Ron_Broersma.pdf>。
[CGA-IPR] IETF, "IPR Details: Microsoft's Statement about IPR claimed in RFC 3972", November 2005, <https://datatracker.ietf.org/ipr/676/>.
[CGA-IPR]IETF，“知识产权详细信息：微软关于RFC 3972中声称的知识产权的声明”，2005年11月<https://datatracker.ietf.org/ipr/676/>.
[DHCPv6-IID] 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.
[DHCPv6 IID]Gont，F.和W.Liu，“使用IPv6动态主机配置协议（DHCPv6）生成语义不透明接口标识符的方法”，正在进行的工作，草稿-ietf-dhc-stable-privacy-addresses-022015年4月。
[KAME-CGA] The KAME Project, "The KAME IPR policy and concerns of some technologies which have IPR claims", November 2005, <http://www.kame.net/newsletter/20040525/>.
[KAME-CGA]KAME项目，“KAME知识产权政策和对某些拥有知识产权权利的技术的关注”，2005年11月<http://www.kame.net/newsletter/20040525/>.
[Microsoft] Microsoft, "IPv6 interface identifiers", 2013, <http://www.microsoft.com/resources/documentation/ windows/xp/all/proddocs/en-us/ sag_ip_v6_imp_addr7.mspx?mfr=true>.
[Microsoft]微软，“IPv6接口标识符”，2013年<http://www.microsoft.com/resources/documentation/ windows/xp/all/proddocs/en-us/sag\u ip\u v6\u imp\u addr7.mspx？mfr=true>。
[Panopticlick] Electronic Frontier Foundation, "Panopticlick", 2011, <http://panopticlick.eff.org>.
[ PopoptLICK]电子前沿基金会，“Panopticlick”，2011，<http://panopticlick.eff.org>.
[RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August 1996, <http://www.rfc-editor.org/info/rfc1971>.
[RFC1971]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 1971，DOI 10.17487/RFC19711996年8月<http://www.rfc-editor.org/info/rfc1971>.
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, DOI 10.17487/RFC1972, August 1996, <http://www.rfc-editor.org/info/rfc1972>.
[RFC1972]克劳福德，M.，“通过以太网传输IPv6数据包的方法”，RFC 1972，DOI 10.17487/RFC1972，1996年8月<http://www.rfc-editor.org/info/rfc1972>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, DOI 10.17487/RFC3041, January 2001, <http://www.rfc-editor.org/info/rfc3041>.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，DOI 10.17487/RFC3041，2001年1月<http://www.rfc-editor.org/info/rfc3041>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, DOI 10.17487/RFC3314, September 2002, <http://www.rfc-editor.org/info/rfc3314>.
[RFC3314]Wasserman，M.，Ed.，“第三代合作伙伴关系项目（3GPP）标准中IPv6的建议”，RFC 3314，DOI 10.17487/RFC3314，2002年9月<http://www.rfc-editor.org/info/rfc3314>.
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/RFC3484, February 2003, <http://www.rfc-editor.org/info/rfc3484>.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，DOI 10.17487/RFC3484，2003年2月<http://www.rfc-editor.org/info/rfc3484>.
[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>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052，DOI 10.17487/RFC6052，2010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[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>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596]Cui，Y.，Sun，Q.，Boucadair，M.，Tsou，T.，Lee，Y.，和I.Farrer，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年7月<http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.
[RFC7597]Troan，O.，Ed.，Dec，W.，Li，X.，Bao，C.，Matsushima，S.，Murakami，T.，和T.Taylor，Ed.，“地址和端口的封装映射（MAP-E）”，RFC 7597，DOI 10.17487/RFC7597，2015年7月<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7599]Li，X.，Bao，C.，Dec，W.，Ed.，Troan，O.，Matsushima，S.，和T.Murakami，“地址和端口映射使用翻译（MAP-T）”，RFC 7599，DOI 10.17487/RFC7599，2015年7月<http://www.rfc-editor.org/info/rfc7599>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <http://www.rfc-editor.org/info/rfc7707>.
[RFC7707]Gont，F.和T.Chown，“IPv6网络中的网络侦察”，RFC 7707，DOI 10.17487/RFC7707，2016年3月<http://www.rfc-editor.org/info/rfc7707>.
Acknowledgements
致谢
The authors would like to thank Bernard Aboba, Brian Carpenter, Tim Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz, Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for providing valuable comments on earlier draft versions of this document.
作者要感谢Bernard Aboba、Brian Carpenter、Tim Chown、Lorenzo Coletti、Rich Draves、Robert Hinden、Robert Moskowitz、Erik Nordmark、Mark Smith、Ole Troan和James Woodyatt对本文件早期草稿提供了宝贵意见。
Authors' Addresses
作者地址
Alissa Cooper Cisco 707 Tasman Drive Milpitas, CA 95035 United States
美国加利福尼亚州米尔皮塔斯塔斯曼大道707号Alissa Cooper Cisco，邮编95035
Phone: +1-408-902-3950
Email: alcoop@cisco.com
URI: https://www.cisco.com/
Phone: +1-408-902-3950
Email: alcoop@cisco.com
URI: https://www.cisco.com/
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
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 United States
Dave Thaler美国华盛顿州雷德蒙微软一路98052
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Phone: +1 425 703 8835
Email: dthaler@microsoft.com