Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7217 SI6 Networks / UTN-FRH
Category: Standards Track April 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7217 SI6 Networks / UTN-FRH
Category: Standards Track April 2014
ISSN: 2070-1721
A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
一种使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法
Abstract
摘要
This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).
本文档指定了一种生成IPv6接口标识符的方法，该标识符将与IPv6无状态地址自动配置（SLAAC）一起使用，以便使用此方法配置的IPv6地址在每个子网内都是稳定的，但当主机从一个网络移到另一个网络时，相应的接口标识符会发生变化。该方法是基于硬件地址（例如，IEEE LAN媒体访问控制（MAC）地址）生成接口标识符的替代方法，这样可以在不牺牲用户安全性和隐私的情况下实现稳定地址的好处。本文档中指定的方法适用于主机可能使用的所有前缀，包括链接本地、全局和唯一本地前缀（及其相应的地址）。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7217.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7217.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Relationship to Other Standards . . . . . . . . . . . . . . . 5
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Algorithm Specification . . . . . . . . . . . . . . . . . . . 7
6. Resolving DAD Conflicts . . . . . . . . . . . . . . . . . . . 12
7. Specified Constants . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Possible Sources for the Net_Iface Parameter . . . . 19
A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 19
A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . 19
A.3. Link-Layer Addresses . . . . . . . . . . . . . . . . . . 19
A.4. Logical Network Service Identity . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Relationship to Other Standards . . . . . . . . . . . . . . . 5
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Algorithm Specification . . . . . . . . . . . . . . . . . . . 7
6. Resolving DAD Conflicts . . . . . . . . . . . . . . . . . . . 12
7. Specified Constants . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Possible Sources for the Net_Iface Parameter . . . . 19
A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 19
A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . 19
A.3. Link-Layer Addresses . . . . . . . . . . . . . . . . . . 19
A.4. Logical Network Service Identity . . . . . . . . . . . . 20
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460], which typically results in hosts configuring one or more "stable" addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) that typically embeds a hardware address (e.g., an IEEE LAN MAC address) [RFC4291]. Cryptographically Generated Addresses (CGAs) [RFC3972] are yet another method for generating Interface Identifiers; CGAs bind a public signature key to an IPv6 address in the SEcure Neighbor Discovery (SEND) [RFC3971] protocol.
[RFC4862]指定IPv6[RFC2460]的无状态地址自动配置（SLAAC），这通常导致主机配置一个或多个“稳定”地址，这些地址由本地路由器公布的网络前缀和通常嵌入硬件地址（例如IEEE LAN MAC地址）的接口标识符（IID）组成[RFC4291]。加密生成地址（CGA）[RFC3972]是生成接口标识符的另一种方法；CGA将公共签名密钥绑定到安全邻居发现（SEND）[RFC3971]协议中的IPv6地址。
Generally, the traditional SLAAC addresses are thought to simplify network management, since they simplify Access Control Lists (ACLs) and logging. However, they have a number of drawbacks:
一般认为，传统的SLAAC地址可以简化网络管理，因为它们简化了访问控制列表（ACL）和日志记录。但是，它们有一些缺点：
o Since the resulting Interface Identifiers do not vary over time, they allow correlation of host activities within the same network, thus negatively affecting the privacy of users (see [ADDR-GEN-PRIVACY] and [IAB-PRIVACY]).
o 由于生成的接口标识符不会随时间变化，因此它们允许同一网络内主机活动的关联，从而对用户隐私产生负面影响（请参见[ADDR-GEN-privacy]和[IAB-privacy]）。
o Since the resulting Interface Identifiers are constant across networks, the resulting IPv6 addresses can be leveraged to track and correlate the activity of a host across multiple networks (e.g., track and correlate the activities of a typical client connecting to the public Internet from different locations), thus negatively affecting the privacy of users.
o 由于产生的接口标识符在网络中是恒定的，因此可以利用产生的IPv6地址来跟踪和关联多个网络中主机的活动（例如，跟踪和关联从不同位置连接到公共互联网的典型客户端的活动），从而对用户的隐私造成负面影响。
o Since embedding the underlying link-layer address in the Interface Identifier will result in specific address patterns, such patterns may be leveraged by attackers to reduce the search space when performing address-scanning attacks [IPV6-RECON]. For example, the IPv6 addresses of all hosts manufactured by the same vendor (within a given time frame) will likely contain the same IEEE Organizationally Unique Identifier (OUI) in the Interface Identifier.
o 由于在接口标识符中嵌入底层链路层地址将导致特定的地址模式，攻击者在执行地址扫描攻击时可能会利用这些模式来减少搜索空间[IPV6-RECO]。例如，由同一供应商（在给定时间范围内）制造的所有主机的IPv6地址可能在接口标识符中包含相同的IEEE组织唯一标识符（OUI）。
o Embedding the underlying hardware address in the Interface Identifier leaks device-specific information that could be leveraged to launch device-specific attacks.
o 在接口标识符中嵌入底层硬件地址会泄漏特定于设备的信息，这些信息可用于发起特定于设备的攻击。
o Embedding the underlying link-layer address in the Interface Identifier means that replacement of the underlying interface hardware will result in a change of the IPv6 address(es) assigned to that interface.
o 在接口标识符中嵌入底层链路层地址意味着替换底层接口硬件将导致分配给该接口的IPv6地址发生变化。
[ADDR-GEN-PRIVACY] provides additional details regarding how the aforementioned vulnerabilities could be exploited and the extent to which the method discussed in this document mitigates them.
[ADDR-GEN-PRIVACY]提供了关于如何利用上述漏洞以及本文档中讨论的方法缓解这些漏洞的程度的其他详细信息。
The "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] (henceforth referred to as "temporary addresses") were introduced to complicate the task of eavesdroppers and other information collectors (e.g., IPv6 addresses in web server logs or email headers, etc.) to correlate the activities of a host, and basically result in temporary (and random) Interface Identifiers. These temporary addresses are generated in addition to the traditional IPv6 addresses based on IEEE LAN MAC addresses, with the temporary addresses being employed for "outgoing communications", and the traditional SLAAC addresses being employed for "server" functions (i.e., receiving incoming connections).
引入了“IPv6中无状态地址自动配置的隐私扩展”[RFC4941]（以下简称“临时地址”），以使窃听者和其他信息收集器（例如，web服务器日志或电子邮件头中的IPv6地址等）的任务复杂化，从而关联主机的活动，基本上会产生临时（和随机）接口标识符。这些临时地址是在基于IEEE LAN MAC地址的传统IPv6地址之外生成的，临时地址用于“传出通信”，传统SLAAC地址用于“服务器”功能（即接收传入连接）。
It should be noted that temporary addresses can be challenging in a number of areas. For example, from a network-management point of view, they tend to increase the complexity of event logging, troubleshooting, enforcement of access controls, and quality of service, etc. As a result, some organizations disable the use of temporary addresses even at the expense of reduced privacy [BROERSMA]. Temporary addresses may also result in increased implementation complexity, which might not be possible or desirable in some implementations (e.g., some embedded devices).
应该指出的是，临时地址在许多领域都具有挑战性。例如，从网络管理的角度来看，它们往往会增加事件记录、故障排除、访问控制实施和服务质量等的复杂性。因此，一些组织甚至以降低隐私为代价禁用临时地址的使用[BROERSMA]。临时地址还可能导致实现复杂性增加，这在某些实现（例如，某些嵌入式设备）中可能不可能或不可取。
In scenarios in which temporary addresses are deliberately not used (possibly for any of the aforementioned reasons), all a host is left with is the stable addresses that have typically been generated from the underlying hardware addresses. In such scenarios, it may still be desirable to have addresses that mitigate address-scanning attacks and that, at the very least, do not reveal the host's identity when roaming from one network to another -- without complicating the operation of the corresponding networks.
在故意不使用临时地址的情况下（可能出于上述任何原因），主机只剩下通常由底层硬件地址生成的稳定地址。在这种情况下，可能仍然需要具有能够减轻地址扫描攻击的地址，并且至少在从一个网络漫游到另一个网络时不会显示主机的身份，而不会使相应网络的操作复杂化。
However, even with temporary addresses in place, a number of issues remain to be mitigated. Namely,
然而，即使有了临时地址，仍有许多问题有待缓解。即
o since temporary addresses [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only partially mitigate host-tracking and activity correlation across networks (see [ADDR-GEN-PRIVACY] for some example attacks that are still possible with temporary addresses).
o 由于临时地址[RFC4941]不能消除对类似服务器的功能使用固定标识符，因此它们只能部分缓解跨网络的主机跟踪和活动相关性（有关临时地址仍然可能发生的一些示例攻击，请参阅[ADDR-GEN-PRIVACY]）。
o since temporary addresses [RFC4941] do not replace the traditional SLAAC addresses, an attacker can still leverage patterns in SLAAC addresses to greatly reduce the search space for "alive" nodes [GONT-DEEPSEC2011] [CPNI-IPV6] [IPV6-RECON].
o 由于临时地址[RFC4941]不能取代传统的SLAAC地址，攻击者仍然可以利用SLAAC地址中的模式来大大减少“活动”节点的搜索空间[GONT-DEEPSEC2011][CPNI-IPV6][IPV6-RECO]。
Hence, there is a motivation to improve the properties of "stable" addresses regardless of whether or not temporary addresses are employed.
因此，无论是否使用临时地址，都有动机改进“稳定”地址的属性。
This document specifies a method to generate Interface Identifiers that are stable for each network interface within each subnet, but that change as a host moves from one network to another. Thus, this method enables keeping the "stability" properties of the Interface Identifiers specified in [RFC4291], while still mitigating address-scanning attacks and preventing correlation of the activities of a host as it moves from one network to another.
本文档指定了一种生成接口标识符的方法，该标识符对于每个子网中的每个网络接口都是稳定的，但随着主机从一个网络移动到另一个网络，该标识符会发生变化。因此，该方法能够保持[RFC4291]中指定的接口标识符的“稳定性”属性，同时仍然减轻地址扫描攻击，并防止主机从一个网络移动到另一个网络时活动的关联。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The method specified in this document is orthogonal to the use of temporary addresses [RFC4941], since it is meant to improve the security and privacy properties of the stable addresses that are employed along with the aforementioned temporary addresses. In scenarios in which temporary addresses are employed, implementation of the mechanism described in this document (in replacement of stable addresses based on, e.g., IEEE LAN MAC addresses) will mitigate address-scanning attacks and also mitigate the remaining vectors for correlating host activities based on the host's constant (i.e., stable across networks) Interface Identifiers. On the other hand, for hosts that currently disable temporary addresses [RFC4941], implementation of this mechanism would mitigate the host-tracking and address-scanning issues discussed in Section 1.
本文件中规定的方法与临时地址的使用正交[RFC4941]，因为它旨在改善与上述临时地址一起使用的稳定地址的安全性和隐私属性。在使用临时地址的场景中，实施本文档中描述的机制（替换基于例如IEEE LAN MAC地址的稳定地址）将减轻地址扫描攻击，还将减轻基于主机常数的关联主机活动的剩余向量（即，跨网络稳定）接口标识符。另一方面，对于当前禁用临时地址的主机[RFC4941]，此机制的实施将缓解第1节中讨论的主机跟踪和地址扫描问题。
While the method specified in this document is meant to be used with SLAAC, this does not preclude this algorithm from being used with other address configuration mechanisms, such as DHCPv6 [RFC3315] or manual address configuration.
虽然本文档中指定的方法旨在与SLAAC一起使用，但这并不排除该算法与其他地址配置机制（如DHCPv6[RFC3315]或手动地址配置）一起使用。
This document specifies a method for generating Interface Identifiers to be used with IPv6 SLAAC, with the following goals:
本文档指定了一种生成用于IPv6 SLAAC的接口标识符的方法，其目标如下：
o The resulting Interface Identifiers remain stable for each prefix used with SLAAC within each subnet for the same network interface. That is, the algorithm generates the same Interface Identifier when configuring an address (for the same interface) belonging to the same prefix within the same subnet.
o 对于同一网络接口的每个子网内与SLAAC一起使用的每个前缀，生成的接口标识符保持稳定。也就是说，在同一子网中配置属于同一前缀的地址（用于同一接口）时，该算法生成相同的接口标识符。
o The resulting Interface Identifiers must change when addresses are configured for different prefixes. That is, if different autoconfiguration prefixes are used to configure addresses for the same network interface card, the resulting Interface Identifiers must be (statistically) different. This means that, given two addresses produced by the method specified in this document, it must be difficult for an attacker to tell whether the addresses have been generated by the same host.
o 当为不同前缀配置地址时，生成的接口标识符必须更改。也就是说，如果使用不同的自动配置前缀来配置同一网络接口卡的地址，则生成的接口标识符必须（在统计上）不同。这意味着，给定由本文档中指定的方法生成的两个地址，攻击者一定很难判断这些地址是否由同一主机生成。
o It must be difficult for an outsider to predict the Interface Identifiers that will be generated by the algorithm, even with knowledge of the Interface Identifiers generated for configuring other addresses.
o 即使知道为配置其他地址而生成的接口标识符，局外人也很难预测算法将生成的接口标识符。
o Depending on the specific implementation approach (see Section 5 and Appendix A), the resulting Interface Identifiers may be independent of the underlying hardware (e.g., IEEE LAN MAC address). For example, this means that replacing a Network Interface Card (NIC) or adding links dynamically to a Link Aggregation Group (LAG) will not have the (generally undesirable) effect of changing the IPv6 addresses used for that network interface.
o 根据具体的实现方法（见第5节和附录A），产生的接口标识符可能独立于底层硬件（例如，IEEE LAN MAC地址）。例如，这意味着更换网络接口卡（NIC）或向链路聚合组（LAG）动态添加链路不会产生更改用于该网络接口的IPv6地址的效果（通常不需要）。
o The method specified in this document is meant to be an alternative to producing IPv6 addresses based on hardware addresses (e.g., IEEE LAN MAC addresses, as specified in [RFC2464]). That is, this document does not formally obsolete or deprecate any of the existing algorithms to generate Interface Identifiers. It is meant to be employed for all of the stable (i.e., non-temporary) IPv6 addresses configured with SLAAC for a given interface, including global, link-local, and unique-local IPv6 addresses.
o 本文件中规定的方法是基于硬件地址（如[RFC2464]中规定的IEEE LAN MAC地址）生成IPv6地址的替代方法。也就是说，本文档没有正式废弃或弃用任何现有算法来生成接口标识符。它用于为给定接口配置SLAAC的所有稳定（即非临时）IPv6地址，包括全局、链路本地和唯一本地IPv6地址。
We note that this method is incrementally deployable, since it does not pose any interoperability implications when deployed on networks where other nodes do not implement or employ it. Additionally, we note that this document does not update or modify IPv6 Stateless
我们注意到，这种方法是可增量部署的，因为当部署在其他节点没有实现或使用它的网络上时，它不会带来任何互操作性影响。此外，我们注意到，本文档不更新或修改IPv6无状态
Address Autoconfiguration (SLAAC) [RFC4862] itself, but rather it only specifies an alternative algorithm to generate Interface Identifiers. Therefore, the usual address lifetime properties (as specified in the corresponding Prefix Information Options) apply when IPv6 addresses are generated as a result of employing the algorithm specified in this document with SLAAC [RFC4862]. Additionally, from the point of view of renumbering, we note that these addresses behave like the traditional IPv6 addresses (that embed a hardware address) resulting from SLAAC [RFC4862].
地址自动配置（SLAAC）[RFC4862]本身，但它只指定生成接口标识符的替代算法。因此，通常的地址生存期属性（在相应的前缀信息选项中指定）适用于使用本文档中指定的算法与SLAAC[RFC4862]生成IPv6地址的情况。此外，从重新编号的角度来看，我们注意到这些地址的行为类似于SLAAC[RFC4862]产生的传统IPv6地址（嵌入硬件地址）。
IPv6 implementations conforming to this specification MUST generate Interface Identifiers using the algorithm specified in this section as a replacement for any other algorithms for generating "stable" addresses with SLAAC (such as those specified in [RFC2464], [RFC2467], and [RFC2470]). However, implementations conforming to this specification MAY employ the algorithm specified in [RFC4941] to generate temporary addresses in addition to the addresses generated with the algorithm specified in this document. The method specified in this document MUST be employed for generating the Interface Identifiers with SLAAC for all the stable addresses, including IPv6 global, link-local, and unique-local addresses.
符合本规范的IPv6实现必须使用本节中指定的算法生成接口标识符，以替代使用SLAAC生成“稳定”地址的任何其他算法（如[RFC2464]、[RFC2467]和[RFC2470]中指定的算法）。然而，符合本规范的实现可采用[RFC4941]中规定的算法来生成临时地址，以及使用本文件中规定的算法生成的地址。必须使用本文档中指定的方法，为所有稳定地址（包括IPv6全局地址、链路本地地址和唯一本地地址）生成带有SLAAC的接口标识符。
Implementations conforming to this specification SHOULD provide the means for a system administrator to enable or disable the use of this algorithm for generating Interface Identifiers.
符合本规范的实现应为系统管理员提供启用或禁用该算法生成接口标识符的方法。
Unless otherwise noted, all of the parameters included in the expression below MUST be included when generating an Interface Identifier.
除非另有说明，否则在生成接口标识符时，必须包括下面表达式中包含的所有参数。
1. Compute a random (but stable) identifier with the expression:
1. 使用以下表达式计算随机（但稳定）标识符：
RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
RID=F（前缀、网络地址、网络ID、DAD计数器、密钥）
Where:
哪里：
RID: Random (but stable) Identifier
RID：随机（但稳定）标识符
F(): A pseudorandom function (PRF) that MUST NOT be computable from the outside (without knowledge of the secret key). F() MUST also be difficult to reverse, such that it resists attempts to obtain the secret_key, even when given samples of the output of F() and knowledge or control of the other input parameters. F() SHOULD produce an output of at least 64 bits. F() could
F（）：不能从外部计算的伪随机函数（PRF）（不知道密钥）。F（）也必须很难反转，因此即使给定F（）的输出样本和其他输入参数的知识或控制，它也会阻止获取密钥的尝试。F（）应产生至少64位的输出。可以
be implemented as a cryptographic hash of the concatenation of each of the function parameters. SHA-1 [FIPS-SHS] and SHA-256 are two possible options for F(). Note: MD5 [RFC1321] is considered unacceptable for F() [RFC6151].
可以实现为每个函数参数串联的加密哈希。SHA-1[FIPS-SHS]和SHA-256是F（）的两个可能选项。注：对于F（）[RFC6151]，MD5[RFC1321]被认为是不可接受的。
Prefix: The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisement message, or the link-local IPv6 unicast prefix [RFC4291].
前缀：用于SLAAC的前缀，从ICMPv6路由器公告消息或链路本地IPv6单播前缀[RFC4291]得知。
Net_Iface: An implementation-dependent stable identifier associated with the network interface for which the RID is being generated. An implementation MAY provide a configuration option to select the source of the identifier to be used for the Net_Iface parameter. A discussion of possible sources for this value (along with the corresponding trade-offs) can be found in Appendix A.
Net_Iface：与生成RID的网络接口相关联的依赖于实现的稳定标识符。一个实现可以提供一个配置选项，用于选择用于网络参数的标识符的源。关于该值的可能来源（以及相应的权衡）的讨论见附录A。
Network_ID: Some network-specific data that identifies the subnet to which this interface is attached -- for example, the IEEE 802.11 Service Set Identifier (SSID) corresponding to the network to which this interface is associated. Additionally, Simple DNA [RFC6059] describes ideas that could be leveraged to generate a Network_ID parameter. This parameter is OPTIONAL.
Network_ID：一些特定于网络的数据，用于标识此接口连接到的子网——例如，与此接口关联的网络对应的IEEE 802.11服务集标识符（SSID）。此外，Simple DNA[RFC6059]描述了可以用来生成网络ID参数的想法。此参数是可选的。
DAD_Counter: A counter that is employed to resolve Duplicate Address Detection (DAD) conflicts. It MUST be initialized to 0, and incremented by 1 for each new tentative address that is configured as a result of a DAD conflict. Implementations that record DAD_Counter in non-volatile memory for each {Prefix, Net_Iface, Network_ID} tuple MUST initialize DAD_Counter to the recorded value if such an entry exists in non-volatile memory. See Section 6 for additional details.
DAD_计数器：用于解决重复地址检测（DAD）冲突的计数器。必须将其初始化为0，并对由于DAD冲突而配置的每个新临时地址递增1。在非易失性内存中为每个{Prefix，Net_Iface，Network_ID}元组记录DAD_计数器的实现必须将DAD_计数器初始化为记录的值（如果非易失性内存中存在这样的条目）。更多详情见第6节。
secret_key: A secret key that is not known by the attacker. The secret key SHOULD be of at least 128 bits. It MUST be initialized to a pseudo-random number (see [RFC4086] for randomness requirements for security) when the operating system is installed or when the IPv6 protocol stack is "bootstrapped" for the first time. An implementation MAY provide the means for the system administrator to display and change the secret key.
密钥：攻击者不知道的密钥。密钥应至少为128位。在安装操作系统或首次“引导”IPv6协议堆栈时，必须将其初始化为伪随机数（有关安全性的随机性要求，请参见[RFC4086]）。实现可以为系统管理员提供显示和更改密钥的方法。
2. The Interface Identifier is finally obtained by taking as many bits from the RID value (computed in the previous step) as necessary, starting from the least significant bit.
2. 从最低有效位开始，根据需要从RID值（在上一步中计算）中获取尽可能多的位，最终获得接口标识符。
We note that [RFC4291] requires that the Interface IDs of all unicast addresses (except those that start with the binary value 000) be 64 bits long. However, the method discussed in this document could be employed for generating Interface IDs of any arbitrary length, albeit at the expense of reduced entropy (when employing Interface IDs smaller than 64 bits).
我们注意到，[RFC4291]要求所有单播地址（以二进制值000开头的地址除外）的接口ID为64位长。然而，本文中讨论的方法可用于生成任意长度的接口ID，尽管代价是降低熵（当使用小于64位的接口ID时）。
The resulting Interface Identifier SHOULD be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID] and against those Interface Identifiers already employed in an address of the same network interface and the same network prefix. In the event that an unacceptable identifier has been generated, this situation SHOULD be handled in the same way as the case of duplicate addresses (see Section 6).
生成的接口标识符应与保留的IPv6接口标识符[RFC5453][IANA-REFERED-IID]以及已在同一网络接口和同一网络前缀的地址中使用的接口标识符进行比较。如果生成了不可接受的标识符，则应以与地址重复相同的方式处理这种情况（参见第6节）。
This document does not require the use of any specific PRF for the function F() above, since the choice of such PRF is usually a trade-off between a number of properties (processing requirements, ease of implementation, possible intellectual property rights, etc.), and since the best possible choice for F() might be different for different types of devices (e.g., embedded systems vs. regular servers) and might possibly change over time.
本文档不要求对上述函数F（）使用任何特定的PRF，因为这种PRF的选择通常是在多个属性（处理要求、易实现性、可能的知识产权等）之间的权衡，以及F（）的最佳选择对于不同类型的设备（例如嵌入式系统和常规服务器），可能会有所不同，并且可能会随着时间的推移而变化。
Including the SLAAC prefix in the PRF computation causes the Interface Identifier to vary across each prefix (link-local, global, etc.) employed by the host and, consequently, also across networks. This mitigates the correlation of activities of multihomed hosts (since each of the corresponding addresses will typically employ a different prefix), host-tracking (since the network prefix will change as the host moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers (such as IPv6 address-scanning attacks).
在PRF计算中包括SLAAC前缀导致接口标识符在主机使用的每个前缀（链路本地、全局等）之间变化，并且因此也在网络之间变化。这缓解了多宿主主机的活动（因为每个对应的地址通常使用不同的前缀）、主机跟踪（因为随着主机从一个网络移动到另一个网络，网络前缀将发生变化）以及受益于可预测接口标识符的任何其他攻击之间的相关性（如IPv6地址扫描攻击）。
The Net_Iface is a value that identifies the network interface for which an IPv6 address is being generated. The following properties are required for the Net_Iface parameter:
Net_Iface是一个值，用于标识正在为其生成IPv6地址的网络接口。Net_Iface参数需要以下属性：
o It MUST be constant across system bootstrap sequences and other network events (e.g., bringing another interface up or down).
o 它必须在系统引导序列和其他网络事件中保持不变（例如，启动或关闭另一个接口）。
o It MUST be different for each network interface simultaneously in use.
o 同时使用的每个网络接口必须不同。
Since the stability of the addresses generated with this method relies on the stability of all arguments of F(), it is key that the Net_Iface parameter be constant across system bootstrap sequences and other network events. Additionally, the Net_Iface parameter must uniquely identify an interface within the host, such that two interfaces connecting to the same network do not result in duplicate addresses. Different types of operating systems might benefit from different stability properties of the Net_Iface parameter. For example, a client-oriented operating system might want to employ Net_Iface identifiers that are attached to the NIC, such that a removable NIC always gets the same IPv6 address, irrespective of the system communications port to which it is attached. On the other hand, a server-oriented operating system might prefer Net_Iface identifiers that are attached to system slots/ports, such that replacement of a NIC does not result in an IPv6 address change. Appendix A discusses possible sources for the Net_Iface along with their pros and cons.
由于使用此方法生成的地址的稳定性依赖于F（）的所有参数的稳定性，因此在系统引导序列和其他网络事件中，Net_Iface参数保持恒定是关键。此外，Net_Iface参数必须唯一标识主机内的接口，以便连接到同一网络的两个接口不会导致地址重复。不同类型的操作系统可能受益于netiface参数的不同稳定性属性。例如，面向客户端的操作系统可能希望使用连接到NIC的网络标识符，以便可移动NIC始终获得相同的IPv6地址，而不管其连接到哪个系统通信端口。另一方面，面向服务器的操作系统可能更喜欢附加到系统插槽/端口的网络标识符，以便更换NIC不会导致IPv6地址更改。附录A讨论了网络的可能来源及其优缺点。
Including the optional Network_ID parameter when computing the RID value above causes the algorithm to produce a different Interface Identifier when connecting to different networks, even when configuring addresses belonging to the same prefix. This means that a host would employ a different Interface Identifier as it moves from one network to another even for IPv6 link-local addresses or Unique Local Addresses (ULAs) [RFC4193]. In those scenarios where the Network_ID is unknown to the attacker, including this parameter might help mitigate attacks where a victim host connects to the same subnet as the attacker and the attacker tries to learn the Interface Identifier used by the victim host for a remote network (see Section 8 for further details).
在计算上述RID值时包含可选的Network_ID参数会导致算法在连接到不同网络时产生不同的接口标识符，即使在配置属于相同前缀的地址时也是如此。这意味着当主机从一个网络移动到另一个网络时，即使是IPv6链路本地地址或唯一本地地址（ULA）[RFC4193]，它也会使用不同的接口标识符。在攻击者不知道网络ID的情况下，包括此参数可能有助于减轻攻击，其中受害者主机与攻击者连接到同一子网，并且攻击者试图了解受害者主机用于远程网络的接口标识符（有关详细信息，请参阅第8节）。
The DAD_Counter parameter provides the means to intentionally cause this algorithm to produce different IPv6 addresses (all other parameters being the same). This could be necessary to resolve DAD conflicts, as discussed in detail in Section 6.
DAD_计数器参数提供了有意使此算法产生不同IPv6地址（所有其他参数相同）的方法。如第6节详细讨论的，这对于解决DAD冲突可能是必要的。
Note that the result of F() in the algorithm above is no more secure than the secret key. If an attacker is aware of the PRF that is being used by the victim (which we should expect), and the attacker can obtain enough material (i.e., addresses configured by the victim), the attacker may simply search the entire secret-key space to find matches. To protect against this, key lengths of at least 128 bits should be adequate. The secret key is initialized at system installation time to a pseudorandom number, thus allowing this mechanism to be enabled and used automatically, without user intervention. Providing a mechanism to display and change the secret_key would allow an administrator to cause a new/replacement system (with the same implementation of this specification) to
请注意，上述算法中F（）的结果并不比密钥更安全。如果攻击者知道受害者正在使用的PRF（我们应该知道），并且攻击者可以获得足够的资料（即受害者配置的地址），则攻击者只需搜索整个密钥空间即可找到匹配项。为了防止这种情况，至少128位的密钥长度应该足够。密钥在系统安装时初始化为伪随机数，从而允许自动启用和使用此机制，而无需用户干预。提供一种显示和更改密钥的机制将允许管理员使一个新的/替换系统（具有本规范的相同实现）运行
generate the same IPv6 addresses as the system being replaced. We note that since the privacy of the scheme specified in this document relies on the secrecy of the secret_key parameter, implementations should constrain access to the secret_key parameter to the extent practicable (e.g., require superuser privileges to access it). Furthermore, in order to prevent leakages of the secret_key parameter, it should not be used for any purposes other than being a parameter to the scheme specified in this document.
生成与被替换系统相同的IPv6地址。我们注意到，由于本文档中指定的方案的隐私依赖于secret_key参数的保密性，因此实现应在可行的范围内限制对secret_key参数的访问（例如，需要超级用户权限来访问它）。此外，为了防止secret_key参数泄漏，除了作为本文档中指定的方案的参数外，不应将其用于任何其他目的。
We note that all of the bits in the resulting Interface IDs are treated as "opaque" bits [RFC7136]. For example, the universal/local bit of Modified EUI-64 format identifiers is treated as any other bit of such an identifier. In theory, this might result in IPv6 address collisions and DAD failures that would otherwise not be encountered. However, this is not deemed as a likely issue because of the following considerations:
我们注意到，结果接口ID中的所有位都被视为“不透明”位[RFC7136]。例如，修改的EUI-64格式标识符的通用/本地位被视为此类标识符的任何其他位。理论上，这可能会导致IPv6地址冲突和DAD故障，否则将不会遇到这些问题。但是，出于以下考虑，这不被视为可能的问题：
o The interface IDs of all addresses (except those of addresses that start with the binary value 000) are 64 bits long. Since the method specified in this document results in random Interface IDs, the probability of DAD failures is very small.
o 所有地址（以二进制值000开头的地址除外）的接口ID都是64位长。由于本文档中指定的方法会导致随机接口ID，因此DAD故障的概率非常小。
o Real-world data indicates that MAC address reuse is far more common than assumed [HD-MOORE]. This means that even IPv6 addresses that employ (allegedly) unique identifiers (such as IEEE LAN MAC addresses) might result in DAD failures and, hence, implementations should be prepared to gracefully handle such occurrences. Additionally, some virtualization technologies already employ hardware addresses that are randomly selected, and, hence, cannot be guaranteed to be unique [IPV6-RECON].
o 真实世界的数据表明，MAC地址重用比假设的要普遍得多[HD-MOORE]。这意味着，即使使用（据称）唯一标识符（如IEEE LAN MAC地址）的IPv6地址也可能导致DAD故障，因此，实现应准备好妥善处理此类事件。此外，一些虚拟化技术已经使用随机选择的硬件地址，因此无法保证其唯一性[IPV6-RECON]。
o Since some popular and widely deployed operating systems (such as Microsoft Windows) do not embed hardware addresses in the Interface IDs of their stable addresses, reliance on such unique identifiers is reduced in the deployed world (fewer deployed systems rely on them for the avoidance of address collisions).
o 由于一些流行且广泛部署的操作系统（如Microsoft Windows）没有在其稳定地址的接口ID中嵌入硬件地址，因此在部署的世界中，对此类唯一标识符的依赖减少了（较少部署的系统依赖它们以避免地址冲突）。
Finally, we note that since different implementations are likely to use different values for the secret_key parameter, and may also employ different PRFs for F() and different sources for the Net_Iface parameter, the addresses generated by this scheme should not expected to be stable across different operating-system installations. For example, a host that is dual-boot or that is reinstalled may result in different IPv6 addresses for each operating system and/or installation.
最后，我们注意到，由于不同的实现可能会对secret_key参数使用不同的值，并且可能会对F（）使用不同的PRF，对Net_Iface参数使用不同的源，因此该方案生成的地址在不同的操作系统安装中不应是稳定的。例如，双引导或重新安装的主机可能会导致每个操作系统和/或安装的IPv6地址不同。
If, as a result of performing DAD [RFC4862], a host finds that the tentative address generated with the algorithm specified in Section 5 is a duplicate address, it SHOULD resolve the address conflict by trying a new tentative address as follows:
如果由于执行DAD[RFC4862]的结果，主机发现使用第5节中指定的算法生成的暂定地址是重复地址，则应通过尝试新的暂定地址来解决地址冲突，如下所示：
o DAD_Counter is incremented by 1.
o DAD_计数器递增1。
o A new Interface Identifier is generated with the algorithm specified in Section 5, using the incremented DAD_Counter value.
o 使用第5节中指定的算法，使用递增的DAD_计数器值生成新的接口标识符。
Hosts SHOULD introduce a random delay between 0 and IDGEN_DELAY seconds (see Section 7) before trying a new tentative address, to avoid lockstep behavior of multiple hosts.
在尝试新的暂定地址之前，主机应引入0到IDGEN_延迟秒之间的随机延迟（参见第7节），以避免多个主机的锁步行为。
This procedure may be repeated a number of times until the address conflict is resolved. Hosts SHOULD try at least IDGEN_RETRIES (see Section 7) tentative addresses if DAD fails for successive generated addresses, in the hopes of resolving the address conflict. We also note that hosts MUST limit the number of tentative addresses that are tried (rather than indefinitely try a new tentative address until the conflict is resolved).
此过程可能会重复多次，直到解决地址冲突为止。如果DAD连续生成的地址失败，主机应至少尝试IDGEN_重试（参见第7节）暂定地址，以期解决地址冲突。我们还注意到，主机必须限制尝试的临时地址的数量（而不是在冲突解决之前无限期地尝试新的临时地址）。
In those unlikely scenarios in which duplicate addresses are detected and the order in which the conflicting hosts configure their addresses varies (e.g., because they may be bootstrapped in different orders), the algorithm specified in this section for resolving DAD conflicts could lead to addresses that are not stable within the same subnet. In order to mitigate this potential problem, hosts MAY record the DAD_Counter value employed for a specific {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such that the same DAD_Counter value is employed when configuring an address for the same Prefix and subnet at any other point in time. We note that the use of non-volatile memory is OPTIONAL, and hosts that do not implement this feature are still compliant to this protocol specification.
在检测到重复地址且冲突主机配置其地址的顺序不同（例如，因为它们可能以不同的顺序引导）的不太可能的情况下，本节中指定的用于解决DAD冲突的算法可能会导致同一子网中的地址不稳定。为了缓解这一潜在问题，主机可以在非易失性存储器中记录特定{Prefix，Net_Iface，Network_ID}元组使用的DAD_计数器值，以便在任何其他时间点为相同前缀和子网配置地址时使用相同的DAD_计数器值。我们注意到，非易失性内存的使用是可选的，并且未实现此功能的主机仍然符合此协议规范。
In the event that a DAD conflict cannot be solved (possibly after trying a number of different addresses), address configuration would fail. In those scenarios, hosts MUST NOT automatically fall back to employing other algorithms for generating Interface Identifiers.
如果无法解决DAD冲突（可能是在尝试了许多不同的地址之后），地址配置将失败。在这些场景中，主机不能自动退回到使用其他算法来生成接口标识符。
This document specifies the following constant:
本文件规定了以下常数：
IDGEN_RETRIES: defaults to 3.
IDGEN_重试次数：默认为3次。
IDGEN_DELAY: defaults to 1 second.
IDGEN_延迟：默认为1秒。
This document specifies an algorithm for generating Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), as an alternative to e.g., Interface Identifiers that embed hardware addresses (such as those specified in [RFC2464], [RFC2467], and [RFC2470]). When compared to such identifiers, the identifiers specified in this document have a number of advantages:
本文件规定了生成用于IPv6无状态地址自动配置（SLAAC）的接口标识符的算法，作为嵌入硬件地址的接口标识符（如[RFC2464]、[RFC2467]和[RFC2470]中规定的接口标识符）的替代方案。与此类标识符相比，本文件中规定的标识符具有许多优点：
o They prevent trivial host-tracking based on the IPv6 address, since when a host moves from one network to another the network prefix used for autoconfiguration and/or the Network ID (e.g., IEEE 802.11 SSID) will typically change; hence, the resulting Interface Identifier will also change (see [ADDR-GEN-PRIVACY]).
o 它们防止基于IPv6地址的琐碎主机跟踪，因为当主机从一个网络移动到另一个网络时，用于自动配置和/或网络ID（例如IEEE 802.11 SSID）的网络前缀通常会改变；因此，产生的接口标识符也将改变（参见[ADDR-GEN-PRIVACY]）。
o They mitigate address-scanning techniques that leverage predictable Interface Identifiers (e.g., known Organizationally Unique Identifiers) [IPV6-RECON].
o 它们缓解了利用可预测接口标识符（例如，已知的组织唯一标识符）[IPV6-RECO]的地址扫描技术。
o They may result in IPv6 addresses that are independent of the underlying hardware (i.e., the resulting IPv6 addresses do not change if a network interface card is replaced) if an appropriate source for Net_Iface (see Section 5) is employed.
o 如果使用了合适的网络接口源（见第5节），它们可能会导致独立于底层硬件的IPv6地址（即，如果更换了网络接口卡，则产生的IPv6地址不会改变）。
o They prevent the information leakage produced by embedding hardware addresses in the Interface Identifier (which could be exploited to launch device-specific attacks).
o 它们可以防止在接口标识符中嵌入硬件地址所产生的信息泄漏（可以利用硬件地址发动特定于设备的攻击）。
o Since the method specified in this document will result in different Interface Identifiers for each configured address, knowledge or leakage of the Interface Identifier employed for one stable address will not negatively affect the security/privacy of other stable addresses configured for other prefixes (whether at the same time or at some other point in time).
o 由于本文件中规定的方法将导致每个配置地址的不同接口标识符，因此一个稳定地址使用的接口标识符的知识或泄漏不会对为其他前缀配置的其他稳定地址的安全性/隐私性产生负面影响（无论是在同一时间还是在其他时间点）。
We note that while some probing techniques (such as the use of ICMPv6 Echo Request and ICMPv6 Echo Response packets) could be mitigated by a personal firewall at the target host, for other probing vectors,
我们注意到，虽然一些探测技术（如使用ICMPv6 Echo请求和ICMPv6 Echo响应包）可以通过目标主机上的个人防火墙来缓解，但对于其他探测向量，
such as listening to ICMPv6 "Destination Unreachable, Address Unreachable" (Type 1, Code 3) error messages that refer to the target addresses [IPV6-RECON], there is nothing a host can do (e.g., a personal firewall at the target host would not be able to mitigate this probing technique). Hence, the method specified in this document is still of value for hosts that employ personal firewalls.
例如，侦听ICMPv6“目标不可访问，地址不可访问”（类型1，代码3）错误消息（参考目标地址[IPV6-RECON]），主机无法执行任何操作（例如，目标主机上的个人防火墙将无法缓解此探测技术）。因此，本文档中指定的方法对于使用个人防火墙的主机仍然有价值。
In scenarios in which an attacker can connect to the same subnet as a victim host, the attacker might be able to learn the Interface Identifier employed by the victim host for an arbitrary prefix by simply sending a forged Router Advertisement [RFC4861] for that prefix, and subsequently learning the corresponding address configured by the victim host (either listening to the Duplicate Address Detection packets or to any other traffic that employs the newly configured address). We note that a number of factors might limit the ability of an attacker to successfully perform such an attack:
在攻击者可以连接到与受害主机相同的子网的情况下，攻击者可以通过简单地发送伪造的路由器播发[RFC4861]来了解受害主机对任意前缀使用的接口标识符，以及随后学习由受害主机配置的对应地址（侦听重复地址检测分组或使用新配置地址的任何其他通信量）。我们注意到，许多因素可能会限制攻击者成功执行此类攻击的能力：
o First-Hop security mechanisms such as Router Advertisement Guard (RA-Guard) [RFC6105] [RFC7113] could prevent the forged Router Advertisement from reaching the victim host.
o 第一跳安全机制，如路由器广告防护（RA防护）[RFC6105][RFC7113]可以防止伪造的路由器广告到达受害主机。
o If the victim implementation includes the (optional) Network_ID parameter for computing F() (see Section 5), and the Network_ID employed by the victim for a remote network is unknown to the attacker, the Interface Identifier learned by the attacker would differ from the one used by the victim when connecting to the legitimate network.
o 如果受害者实现包含用于计算F（）的（可选）Network_ID参数（请参见第5节），并且攻击者不知道受害者为远程网络使用的Network_ID，则攻击者学习到的接口标识符将与受害者在连接到合法网络时使用的接口标识符不同。
In any case, we note that at the point in which this kind of attack becomes a concern, a host should consider employing SEND [RFC3971] to prevent an attacker from illegitimately claiming authority for a network prefix.
在任何情况下，我们注意到，在这种攻击成为关注点的情况下，主机应该考虑使用发送[RCF971]来防止攻击者非法地请求网络前缀的权限。
We note that this algorithm is meant to be an alternative to Interface Identifiers such as those specified in [RFC2464], but it is not meant as an alternative to temporary Interface Identifiers (such as those specified in [RFC4941]). Clearly, temporary addresses may help to mitigate the correlation of activities of a host within the same network, and they may also reduce the attack exposure window (since temporary addresses are short-lived when compared to the addresses generated with the method specified in this document). We note that the implementation of this specification would still benefit those hosts employing temporary addresses, since it would mitigate host-tracking vectors still present when such addresses are used (see [ADDR-GEN-PRIVACY]) and would also mitigate address-scanning techniques that leverage patterns in IPv6 addresses that embed IEEE LAN MAC addresses. Finally, we note that the method
我们注意到，该算法旨在替代[RFC2464]中规定的接口标识符，但并不意味着替代临时接口标识符（如[RFC4941]中规定的标识符）。显然，临时地址可能有助于缓解同一网络中主机活动的相关性，也可能减少攻击暴露窗口（因为与使用本文档中指定的方法生成的地址相比，临时地址是短暂的）。我们注意到，该规范的实施仍将使使用临时地址的主机受益，因为它将减轻使用此类地址时仍然存在的主机跟踪向量（请参见[ADDR-GEN-PRIVACY]）此外，还将缓解利用嵌入IEEE LAN MAC地址的IPv6地址模式的地址扫描技术。最后，我们注意到该方法
described in this document addresses some of the privacy concerns arising from the use of IPv6 addresses that embed IEEE LAN MAC addresses, without the use of temporary addresses, thus possibly offering an interesting trade-off for those scenarios in which the use of temporary addresses is not feasible.
本文档中描述的解决了由于使用嵌入IEEE LAN MAC地址的IPv6地址而产生的一些隐私问题，而不使用临时地址，因此可能为使用临时地址不可行的场景提供了一个有趣的折衷方案。
The algorithm specified in this document has been inspired by Steven Bellovin's work ([RFC1948]) in the area of TCP sequence numbers.
本文中指定的算法受Steven Bellovin在TCP序列号领域的工作（[RFC1948]）的启发。
The author would like to thank (in alphabetical order) Mikael Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim Chown, Alissa Cooper, Dominik Elsbroek, Stephen Farrell, Eric Gray, Brian Haberman, Bob Hinden, Christian Huitema, Ray Hunter, Jouni Korhonen, Suresh Krishnan, Eliot Lear, Jong-Hyouk Lee, Andrew McGregor, Thomas Narten, Simon Perreault, Tom Petch, Michael Richardson, Vincent Roca, Mark Smith, Hannes Frederic Sowa, Martin Stiemerling, Dave Thaler, Ole Troan, Lloyd Wood, James Woodyatt, and He Xuan, for providing valuable comments on earlier versions of this document.
作者要感谢（按字母顺序排列）米凯尔·阿布拉罕松、冉·阿特金森、卡尔·奥尔、史蒂文·贝洛文、马蒂亚斯·贝特克、本·坎贝尔、布莱恩·卡彭特、塔索斯·查齐托马格鲁、蒂姆·周、艾莉莎·库珀、多米尼克·埃尔斯布鲁克、斯蒂芬·法雷尔、埃里克·格雷、布莱恩·哈伯曼、鲍勃·欣登、克里斯蒂安·惠特马、雷·亨特、乔尼·科霍宁、，Suresh Krishnan、Eliot Lear、Jong Hyuk Lee、Andrew McGregor、Thomas Narten、Simon Perreault、Tom Petch、Michael Richardson、Vincent Roca、Mark Smith、Hannes Frederic Sowa、Martin Stiemering、Dave Thaler、Ole Troan、Lloyd Wood、James Woodyatt和何璇为本文件的早期版本提供了宝贵意见。
Hannes Frederic Sowa produced a reference implementation of this specification for the Linux kernel.
Hannes Frederic Sowa为Linux内核提供了此规范的参考实现。
Finally, the author wishes to thank Nelida Garcia and Guillermo Gont for their love and support.
最后，作者要感谢内丽达·加西亚和吉列尔莫·贡特对我们的爱和支持。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009.
[RFC5453]Krishnan，S.，“保留IPv6接口标识符”，RFC 5453，2009年2月。
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, February 2014.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，2014年2月。
[ADDR-GEN-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, February 2014.
[ADDR-GEN-PRIVACY]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的隐私考虑”，正在进行的工作，2014年2月。
[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>。
[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）的安全评估”，英国国家基础设施保护中心（可根据要求提供）。
[FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, March 2012, <http://csrc.nist.gov/publications/ fips/fips180-4/fips-180-4.pdf>.
[FIPS-SHS]NIST，“安全哈希标准（SHS）”，FIPS出版物180-42012年3月<http://csrc.nist.gov/publications/ fips/fips180-4/fips-180-4.pdf>。
[GONT-DEEPSEC2011] Gont, F., "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, <http://www.si6networks.com/presentations/deepsec2011/ fgont-deepsec2011-ipv6-security.pdf>.
[GONT-DEEPSEC2011]GONT，F.“互联网协议版本6（IPv6）的安全评估结果”，DEEPSEC 2011年会议，奥地利维也纳，2011年11月<http://www.si6networks.com/presentations/deepsec2011/ fgont-deepsec2011-ipv6-security.pdf>。
[HD-MOORE] Moore, HD., "The Wild West", Louisville, Kentucky, U.S.A, DerbyCon 2012, September 2012, <https://speakerdeck.com/ hdm/derbycon-2012-the-wild-west>.
[HD-MOORE]摩尔，HD.，“野生西部”，美国肯塔基州路易斯维尔，2012年德比会，2012年9月<https://speakerdeck.com/ hdm/derbycon-2012-the-wild-west>。
[IAB-PRIVACY] IAB, "Privacy and IPv6 Addresses", July 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/07/ IPv6-addresses-privacy-review.txt>.
[IAB-隐私]IAB，“隐私和IPv6地址”，2011年7月<http://www.iab.org/wp-content/IAB-uploads/2011/07/ IPv6地址privacy review.txt>。
[IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", <http://www.iana.org/assignments/ipv6-interface-ids>.
[IANA-REFERED-IID]IANA，“保留IPv6接口标识符”<http://www.iana.org/assignments/ipv6-interface-ids>.
[IPV6-RECON] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, January 2014.
[IPV6-RECON]Gont，F.和T.Chown，“IPV6网络中的网络侦察”，正在进行的工作，2014年1月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[RFC1948]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[RFC2467]克劳福德，M.，“通过FDDI网络传输IPv6数据包”，RFC2467，1998年12月。
[RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
[RFC2470]Crawford，M.，Narten，T.，和S.Thomas，“通过令牌环网络传输IPv6数据包”，RFC 24701998年12月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542]Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 60592010年11月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014.
[RFC7113]Gont，F.，“IPv6路由器广告防护（RA防护）的实施建议”，RFC 7113，2014年2月。
Appendix A. Possible Sources for the Net_Iface Parameter
附录A.净价格参数的可能来源
The following subsections describe a number of possible sources for the Net_Iface parameter employed by the F() function in Section 5. The choice of a specific source for this value represents a number of trade-offs, which may vary from one implementation to another.
以下小节描述了第5节中F（）函数使用的Net_Iface参数的一些可能来源。为该值选择特定源代表了许多权衡，这些权衡可能因实现而异。
The Interface Index [RFC3493] [RFC3542] of an interface uniquely identifies that interface within the node. However, these identifiers might or might not have the stability properties required for the Net_Iface value employed by this method. For example, the Interface Index might change upon removal or installation of a network interface (typically one with a smaller value for the Interface Index, when such a naming scheme is used) or when network interfaces happen to be initialized in a different order. We note that some implementations are known to provide configuration knobs to set the Interface Index for a given interface. Such configuration knobs could be employed to prevent the Interface Index from changing (e.g., as a result of the removal of a network interface).
接口的接口索引[RFC3493][RFC3542]唯一标识节点内的接口。然而，这些标识符可能具有也可能不具有该方法所采用的净价值所需的稳定性属性。例如，在删除或安装网络接口时（通常是在使用这种命名方案时接口索引值较小的接口），或者网络接口恰好以不同的顺序初始化时，接口索引可能会更改。我们注意到，已知一些实现提供配置旋钮来设置给定接口的接口索引。此类配置旋钮可用于防止接口索引发生变化（例如，由于移除网络接口）。
The Interface Name (e.g., "eth0", "em0", etc.) tends to be more stable than the underlying Interface Index, since such stability is required or desired when interface names are employed in network configuration (firewall rules, etc.). The stability properties of Interface Names depend on implementation details, such as what is the namespace used for Interface Names. For example, "generic" interface names such as "eth0" or "wlan0" will generally be invariant with respect to network interface card replacements. On the other hand, vendor-dependent interface names such as "rtk0" or the like will generally change when a network interface card is replaced with one from a different vendor.
接口名称（例如，“eth0”、“em0”等）往往比底层接口索引更稳定，因为在网络配置（防火墙规则等）中使用接口名称时，需要或需要这种稳定性。接口名称的稳定性属性取决于实现细节，例如接口名称使用的名称空间。例如，“通用”接口名称（如“eth0”或“wlan0”）通常对于网络接口卡的更换是不变的。另一方面，当将网络接口卡替换为来自不同供应商的网络接口卡时，诸如“rtk0”之类的依赖于供应商的接口名称通常会改变。
We note that Interface Names might still change when network interfaces are added or removed once the system has been bootstrapped (for example, consider USB-based network interface cards that might be added or removed once the system has been bootstrapped).
我们注意到，当系统被自举时，网络接口被添加或删除时，接口名称可能仍会发生变化（例如，考虑到一旦系统被自举后可能会添加或删除的基于USB的网络接口卡）。
Link-layer addresses typically provide for unique identifiers for network interfaces; although, for obvious reasons, they generally change when a network interface card is replaced. In scenarios in which neither Interface Indexes nor Interface Names have the stability properties specified in Section 5 for Net_Iface, an
链路层地址通常为网络接口提供唯一标识符；尽管由于明显的原因，它们在更换网络接口卡时通常会发生变化。在接口索引和接口名称都不具有第5节中为Net_Iface指定的稳定性属性的情况下
implementation might want to employ the link-layer address of the interface for the Net_Iface parameter, albeit at the expense of making the corresponding IPv6 addresses dependent on the underlying network interface card (i.e., the corresponding IPv6 addresses would typically change upon replacement of the underlying network interface card).
实现可能希望为Net_Iface参数使用接口的链路层地址，但代价是使相应的IPv6地址依赖于底层网络接口卡（即，在替换底层网络接口卡时，相应的IPv6地址通常会改变）。
Host operating systems with a conception of logical network service identity, distinct from network interface identity or index, may keep a Universally Unique Identifier (UUID) [RFC4122] or similar identifier with the stability properties appropriate for use as the Net_Iface parameter.
具有逻辑网络服务标识（不同于网络接口标识或索引）概念的主机操作系统可保持通用唯一标识符（UUID）[RFC4122]或具有适合用作网络接口参数的稳定性属性的类似标识符。
Author's Address
作者地址
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont SI6 Networks/UTN-FRH 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