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)




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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

[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:


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.


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).


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.


2. Terminology
2. 术语

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].


3. Relationship to Other Standards
3. 与其他标准的关系

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.


4. Design Goals
4. 设计目标

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


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].


5. Algorithm Specification
5. 算法规范

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.


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: Random (but stable) Identifier


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


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].


Prefix: The prefix to be used for SLAAC, as learned from an ICMPv6 Router Advertisement message, or the link-local IPv6 unicast prefix [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.


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.


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.


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).


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).


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.


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).


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:


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.


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).


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.


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


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.


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:


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.


6. Resolving DAD Conflicts
6. 解决DAD冲突

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:


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.


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).


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.


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.


7. Specified Constants
7. 指定常数

This document specifies the following constant:


IDGEN_RETRIES: defaults to 3.


IDGEN_DELAY: defaults to 1 second.


8. Security Considerations
8. 安全考虑

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:


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.


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:


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.


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地址而产生的一些隐私问题,而不使用临时地址,因此可能为使用临时地址不可行的场景提供了一个有趣的折衷方案。

9. Acknowledgements
9. 致谢

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.


10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[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.


[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月。

10.2. Informative References
10.2. 资料性引用

[ADDR-GEN-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, February 2014.


[BROERSMA] Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6-enabled environment", Australian IPv6 Summit 2010, Melbourne, VIC Australia, October 2010, < Ron_Broersma.pdf>.

[BROERSMA]BROERSMA,R.,“无处不在的IPv6:生活在完全支持IPv6的环境中”,2010年澳大利亚IPv6峰会,澳大利亚维多利亚州墨尔本,2010年10月< 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).


[FIPS-SHS] NIST, "Secure Hash Standard (SHS)", FIPS Publication 180-4, March 2012, < fips/fips180-4/fips-180-4.pdf>.

[FIPS-SHS]NIST,“安全哈希标准(SHS)”,FIPS出版物180-42012年3月< 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, < fgont-deepsec2011-ipv6-security.pdf>.

[GONT-DEEPSEC2011]GONT,F.“互联网协议版本6(IPv6)的安全评估结果”,DEEPSEC 2011年会议,奥地利维也纳,2011年11月< fgont-deepsec2011-ipv6-security.pdf>。

[HD-MOORE] Moore, HD., "The Wild West", Louisville, Kentucky, U.S.A, DerbyCon 2012, September 2012, < hdm/derbycon-2012-the-wild-west>.

[HD-MOORE]摩尔,HD.,“野生西部”,美国肯塔基州路易斯维尔,2012年德比会,2012年9月< hdm/derbycon-2012-the-wild-west>。

[IAB-PRIVACY] IAB, "Privacy and IPv6 Addresses", July 2011, < IPv6-addresses-privacy-review.txt>.

[IAB-隐私]IAB,“隐私和IPv6地址”,2011年7月< IPv6地址privacy review.txt>。

[IANA-RESERVED-IID] IANA, "Reserved IPv6 Interface Identifiers", <>.


[IPV6-RECON] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, January 2014.


[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.


[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.


[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.


[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


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.


A.1. Interface Index
A.1. 界面索引

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).


A.2. Interface Name
A.2. 接口名

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.


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).


A.3. Link-Layer Addresses
A.3. 链路层地址

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


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).


A.4. Logical Network Service Identity
A.4. 逻辑网络服务标识

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.


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
   Phone: +54 11 4650 8472