Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7136 Univ. of Auckland
Updates: 4291 S. Jiang
Category: Standards Track Huawei Technologies Co., Ltd
ISSN: 2070-1721 February 2014
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7136 Univ. of Auckland
Updates: 4291 S. Jiang
Category: Standards Track Huawei Technologies Co., Ltd
ISSN: 2070-1721 February 2014
Significance of IPv6 Interface Identifiers
IPv6接口标识符的重要性
Abstract
摘要
The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.
IPv6寻址体系结构包括一个单播接口标识符，用于创建多个IPv6地址。接口标识符由多种方法组成。本文档澄清了接口标识符中的位没有任何意义，并且应将整个标识符视为不透明值。具体而言，RFC 4291定义了一种方法，通过该方法，IEEE链路层地址的通用位和组位映射到IPv6单播接口标识符。本文件澄清了这两位仅在从IEEE链路层地址导出接口标识符的过程中有效，并相应地更新了RFC 4291。
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/rfc7136.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7136.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 5
4. The Role of Duplicate Address Detection . . . . . . . . . . . 6
5. Clarification of Specifications . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Usefulness of the U and G Bits . . . . . . . . . . . . . . . 5
4. The Role of Duplicate Address Detection . . . . . . . . . . . 6
5. Clarification of Specifications . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
IPv6 unicast addresses consist of a prefix followed by an Interface Identifier (IID). The IID is supposed to be unique on the links reached by routing to that prefix, giving an IPv6 address that is unique within the applicable scope (link local or global). According to the IPv6 addressing architecture [RFC4291], when a 64-bit IPv6 unicast IID is formed on the basis of an IEEE EUI-64 address, usually itself expanded from a 48-bit MAC address, a particular format must be used:
IPv6单播地址由前缀和接口标识符（IID）组成。IID应该在通过路由到该前缀而到达的链路上是唯一的，从而提供在适用范围内唯一的IPv6地址（链路本地或全局）。根据IPv6寻址体系结构[RFC4291]，当基于IEEE EUI-64地址形成64位IPv6单播IID时，通常其本身从48位MAC地址扩展而来，必须使用特定格式：
For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.
对于所有单播地址（以二进制值000开头的地址除外），接口ID要求为64位长，并以修改的EUI-64格式构造。
Thus, the specification assumes that the normal case is to transform an Ethernet-style address into an IID, but, in practice, there are various methods of forming such an IID.
因此，本规范假设正常情况下是将以太网式地址转换为IID，但在实践中，有各种方法形成这样的IID。
The Modified EUI-64 format preserves the information provided by two particular bits in the MAC address:
修改后的EUI-64格式保留MAC地址中两个特定位提供的信息：
o The "u/l" bit in a MAC address [IEEE802] is set to 0 to indicate universal scope (implying uniqueness) or to 1 to indicate local scope (without implying uniqueness). In an IID formed from a MAC address, this bit is simply known as the "u" bit and its value is inverted, i.e., 1 for universal scope and 0 for local scope. According to [RFC4291] and [RFC7042], the reason for this was to make it easier for network operators to manually configure local-scope IIDs.
o MAC地址[IEEE802]中的“u/l”位设置为0表示通用范围（表示唯一性），或设置为1表示本地范围（不表示唯一性）。在由MAC地址形成的IID中，该位被简单地称为“u”位，其值被反转，即1表示通用范围，0表示本地范围。根据[RFC4291]和[RFC7042]，这样做的原因是使网络运营商更容易手动配置本地范围IID。
In an IID, this bit is in position 6, i.e., position 70 in the complete IPv6 address (when counting from 0).
在IID中，该位位于位置6，即完整IPv6地址中的位置70（从0开始计数时）。
o The "i/g" bit in a MAC address is set to 1 to indicate group addressing (link-layer multicast). The value of this bit is preserved in an IID, where it is known as the "g" bit.
o MAC地址中的“i/g”位设置为1以指示组寻址（链路层多播）。该位的值保存在IID中，称为“g”位。
In an IID, this bit is in position 7, i.e., position 71 in the complete IPv6 address (when counting from 0).
在IID中，该位位于位置7，即完整IPv6地址中的位置71（从0开始计数时）。
This document discusses problems observed with the "u" and "g" bits as a result of the above requirements and the fact that various other methods of forming an IID have been defined independently of the method described in Appendix A of RFC 4291. It then discusses the usefulness of these two bits and the significance of the bits in an IID in general. Finally, it updates RFC 4291 accordingly.
本文件讨论了由于上述要求以及形成IID的各种其他方法已独立于RFC 4291附录a中所述方法的事实而导致的“u”和“g”位出现的问题。然后讨论这两个位的有用性以及这些位在IID中的一般意义。最后，它相应地更新了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]中所述进行解释。
In addition to IIDs formed from IEEE EUI-64 addresses, various new
forms of IIDs have been defined, including temporary addresses
[RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972]
[RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP
addresses [RFC5214]. Other methods have been proposed, such as
stable privacy addresses [IID-SLAAC] and mapped addresses for 4rd
[SOFTWR-4RD]. In each case, the question of how to set the "u" and
"g" bits has to be decided. For example, RFC 3972 specifies that
they are both zero in CGAs, and RFC 4982 describes them as if they
were reserved bits. The same applies to HBAs. On the other hand,
RFC 4941 specifies that "u" must be zero but leaves "g" variable.
In addition to IIDs formed from IEEE EUI-64 addresses, various new
forms of IIDs have been defined, including temporary addresses
[RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972]
[RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP
addresses [RFC5214]. Other methods have been proposed, such as
stable privacy addresses [IID-SLAAC] and mapped addresses for 4rd
[SOFTWR-4RD]. In each case, the question of how to set the "u" and
"g" bits has to be decided. For example, RFC 3972 specifies that
they are both zero in CGAs, and RFC 4982 describes them as if they
were reserved bits. The same applies to HBAs. On the other hand,
RFC 4941 specifies that "u" must be zero but leaves "g" variable.
The NAT64 addressing format [RFC6052] sets the whole byte containing "u" and "g" to zero.
NAT64寻址格式[RFC6052]将包含“u”和“g”的整个字节设置为零。
Another case where the "u" and "g" bits are specified is in the Reserved IPv6 Subnet Anycast Address format [RFC2526], which states that "for interface identifiers in EUI-64 format, the universal/local bit in the interface identifier MUST be set to 0" (i.e., local) and the "g" bit is required to be set to 1. However, the text neither states nor implies any semantics for these bits in anycast addresses.
指定“u”和“g”位的另一种情况是在保留IPv6子网选播地址格式[RFC2526]中，该格式规定“对于EUI-64格式的接口标识符，接口标识符中的通用/本地位必须设置为0”（即本地），并且“g”位必须设置为1。但是，文本既不表示也不暗示选播地址中这些位的任何语义。
A common operational practice for well-known servers is to manually assign a small number as the IID, in which case "u" and "g" are both zero.
知名服务器的常见操作实践是手动分配一个小数字作为IID，在这种情况下，“u”和“g”都是零。
These cases illustrate that the statement quoted above from RFC 4291 requiring "Modified EUI-64 format" is inapplicable when applied to forms of IID that are not in fact based on an underlying EUI-64 address. In practice, the IETF has chosen to assign some 64-bit IIDs that have nothing to do with EUI-64.
这些案例说明，RFC 4291中引用的要求“修改的EUI-64格式”的声明在应用于事实上并非基于基础EUI-64地址的IID格式时不适用。实际上，IETF选择分配一些与EUI-64无关的64位IID。
A particular case is that of /127 prefixes for point-to-point links between routers, as standardised by [RFC6164]. The addresses on these links are undoubtedly global unicast addresses, but they do not have a 64-bit IID. The bits in the positions named "u" and "g" in such an IID have no special significance and their values are not specified.
一种特殊情况是路由器之间点到点链路的/127前缀，由[RFC6164]标准化。这些链路上的地址无疑是全局单播地址，但它们没有64位IID。在这样的IID中，名为“u”和“g”的位置中的位没有特殊意义，并且没有指定它们的值。
Each time a new IID format is proposed, the question arises whether these bits have any meaning. Section 2.2.1 of [RFC7042] discusses the mechanics of the bit allocations but does not explain the purpose or usefulness of these bits in an IID. There is an IANA registry for reserved IID values [RFC5453], but again there is no explanation of the purpose of the "u" and "g" bits.
每次提出新的IID格式时，都会出现这些位是否有任何意义的问题。[RFC7042]第2.2.1节讨论了位分配的机制，但没有解释这些位在IID中的用途。对于保留的IID值[RFC5453]，有一个IANA注册表，但同样没有解释“u”和“g”位的用途。
There was a presumption when IPv6 was designed and the IID format was first specified that a universally unique IID might prove to be very useful, for example to contribute to solving the multihoming problem. Indeed, the addressing architecture [RFC4291] states this explicitly:
在设计IPv6和首次指定IID格式时，有一个假设，即普遍唯一的IID可能非常有用，例如有助于解决多宿问题。实际上，寻址体系结构[RFC4291]明确指出：
The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope.
在修改后的EUI-64格式标识符中使用通用/本地位是为了开发未来技术，该技术可以利用具有通用范围的接口标识符。
However, so far, this has not proved to be the case. Also, there is evidence from the field that MAC addresses with universal scope are sometimes assigned to multiple MAC interfaces. There are recurrent reports of manufacturers assigning the same MAC address to multiple devices, and significant reuse of the same virtual MAC address is
然而，到目前为止，事实证明情况并非如此。此外，有证据表明，具有通用范围的MAC地址有时分配给多个MAC接口。经常有制造商将相同的MAC地址分配给多个设备的报告，并且需要大量重用相同的虚拟MAC地址
reported in virtual machine environments. Once transformed into IID format (with "u" = 1), these identifiers would purport to be universally unique but would in fact be ambiguous. This has no known harmful effect as long as the replicated MAC addresses and IIDs are used on different layer 2 links. If they are used on the same link, of course there will be a problem, very likely interfering with link-layer transmission. If not, the problem will be detected by duplicate address detection [RFC4862] [RFC6775], but such an error can usually only be resolved by human intervention.
在虚拟机环境中报告。一旦转换为IID格式（“u”=1），这些标识符将声称是普遍唯一的，但实际上是不明确的。只要在不同的第2层链路上使用复制的MAC地址和IID，这没有已知的有害影响。如果它们在同一链路上使用，当然会出现问题，很可能干扰链路层传输。如果没有，问题将通过重复地址检测[RFC4862][RFC6775]来检测，但这种错误通常只能通过人工干预来解决。
The conclusion from this is that the "u" bit is not a reliable indicator of universal uniqueness.
由此得出的结论是，“u”位不是普遍唯一性的可靠指标。
We note that Identifier-Locator Network Protocol (ILNP), a multihoming solution that might be expected to benefit from universally unique IIDs in modified EUI-64 format, does not in fact rely on them. ILNP uses its own format defined as a Node Identifier [RFC6741]. ILNP has the constraint that a given Node Identifier must be unique within the context of a given Locator (i.e., within a single given IPv6 subnetwork). As we have just shown, the state of the "u" bit does not in any way guarantee such uniqueness, but duplicate address detection is available.
我们注意到，标识符定位器网络协议（ILNP）实际上并不依赖于它们，ILNP是一种多宿主解决方案，可以从修改后的EUI-64格式的通用唯一IID中获益。ILNP使用自己定义的格式作为节点标识符[RFC6741]。ILNP有一个约束，即给定节点标识符在给定定位器的上下文中必须是唯一的（即，在单个给定IPv6子网中）。正如我们刚才所展示的，“u”位的状态在任何方面都不能保证这种唯一性，但是重复地址检测是可用的。
Thus, we can conclude that the value of the "u" bit in IIDs has no particular meaning. In the case of an IID created from a MAC address according to RFC 4291, its value is determined by the MAC address, but that is all.
因此，我们可以得出结论，IID中“u”位的值没有特殊意义。在根据RFC 4291从MAC地址创建IID的情况下，其值由MAC地址确定，但仅此而已。
An IPv6 IID should not be created from a MAC group address, so the "g" bit will normally be zero. But, this value also has no particular meaning. Additionally, the "u" and the "g" bits are both meaningless in the format of an IPv6 multicast group ID [RFC3306] [RFC3307].
不应从MAC组地址创建IPv6 IID，因此“g”位通常为零。但是，这个值也没有特别的意义。此外，“u”和“g”位在IPv6多播组ID[RFC3306][RFC3307]的格式中都是无意义的。
None of the above implies that there is a problem with using the "u" and "g" bits in MAC addresses as part of the process of generating IIDs from MAC addresses, or with specifying their values in other methods of generating IIDs. What it does imply is that after an IID is generated by any method, no reliable deductions can be made from the state of the "u" and "g" bits; in other words, these bits have no useful semantics in an IID.
以上任何一点都不意味着在从MAC地址生成IID的过程中使用MAC地址中的“u”和“g”位存在问题，或者在生成IID的其他方法中指定它们的值存在问题。它确实意味着，在通过任何方法生成IID后，无法从“u”和“g”位的状态进行可靠的推断；换句话说，这些位在IID中没有有用的语义。
Once this is recognised, we can avoid the problematic confusion caused by these bits each time that a new form of IID is proposed.
一旦认识到这一点，我们就可以避免每次提出新形式的IID时由这些位引起的有问题的混淆。
Given that the "u" and "g" bits do not have a reliable meaning in an IID, it is relevant to consider what usefulness they do have.
考虑到“U”和“G”位在IID中没有可靠的含义，考虑它们所具有的有用性是相关的。
If an IID is known or guessed to have been created according to [RFC4291], it could be transformed back into a MAC address. This can be very helpful during operational fault diagnosis. For that reason, mapping the IEEE "u" and "g" bits into the IID has operational usefulness. However, it should be stressed that an IID with "u" = 1 and "g" = 0 might not be formed from a MAC address; on the contrary, it might equally result from another method. With other methods, there is no reverse transformation available.
如果已知或推测IID是根据[RFC4291]创建的，则可以将其转换回MAC地址。这在运行故障诊断期间非常有用。因此，将IEEE“u”和“g”位映射到IID中具有操作实用性。然而，应当强调的是，“u”=1且“g”=0的IID可能不是由MAC地址形成的；相反，它可能同样来自另一种方法。对于其他方法，没有可用的反向转换。
Given that the values of the "u" and "g" bits in an IID have no particular meaning, new methods of IID formation are at liberty to use them as they wish, for example, as additional pseudo-random bits to reduce the chances of duplicate IIDs.
考虑到IID中“u”和“g”位的值没有特殊意义，IID形成的新方法可以随意使用它们，例如，作为额外的伪随机位，以减少重复IID的机会。
As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is able to detect any case where a collision of two IIDs on the same link leads to a duplicated IPv6 address. The scope of DAD may be extended to a set of links by a DAD proxy [RFC6957] or by Neighbor Discovery Optimization [RFC6775]. Since DAD is mandatory for all nodes, there will be almost no case in which an IID collision, however unlikely it may be, is not detected. It is out of scope of most existing specifications to define the recovery action after a DAD failure, which is an implementation issue. If a manually created IID, or an IID derived from a MAC address according to RFC 4291, leads to a DAD failure, human intervention will most likely be required. However, as mentioned above, some methods of IID formation might produce IID values with "u" = 1 and "g" = 0 that are not based on a MAC address. With very low probability, such a value might collide with an IID based on a MAC address.
如上所述，重复地址检测（DAD）[RFC4862]能够检测相同链路上两个IID的冲突导致重复IPv6地址的任何情况。DAD的范围可以通过DAD代理[RFC6957]或邻居发现优化[RFC6775]扩展到一组链路。由于DAD对所有节点都是强制性的，因此几乎不会出现IID冲突（无论可能性有多大）未被检测到的情况。定义DAD故障后的恢复操作超出了大多数现有规范的范围，这是一个实现问题。如果手动创建的IID或根据RFC 4291从MAC地址派生的IID导致DAD故障，则极有可能需要人工干预。然而，如上所述，一些IID形成方法可能产生不基于MAC地址的“u”=1和“g”=0的IID值。在极低的概率下，该值可能与基于MAC地址的IID冲突。
As stated in RFC 4862:
如RFC 4862所述：
On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued.
另一方面，如果重复链路本地地址不是由基于硬件地址的接口标识符形成的（假定该硬件地址是唯一分配的），则可以继续该接口上的IP操作。
Continued operation is only possible if a new IID is created. The best procedure to follow for this will depend on the IID formation method in use. For example, if an IID is formed by a pseudo-random process, that process could simply be repeated.
只有创建了新的IID，才能继续操作。为此遵循的最佳程序取决于使用的IID形成方法。例如，如果IID是由伪随机过程形成的，则该过程可以简单地重复。
This section describes clarifications to the IPv6 specifications that result from the above discussion.
本节描述了上述讨论对IPv6规范的澄清。
The EUI-64 to IID transformation defined in the IPv6 addressing architecture [RFC4291] MUST be used for all cases where an IPv6 IID is derived from an IEEE MAC or EUI-64 address. With any other form of link-layer address, an equivalent transformation SHOULD be used.
IPv6寻址体系结构[RFC4291]中定义的EUI-64到IID转换必须用于IPv6 IID源自IEEE MAC或EUI-64地址的所有情况。对于任何其他形式的链路层地址，应使用等效转换。
Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set, but a generic semantic meaning for the "u" and "g" bits MUST NOT be defined. However, the method of generating IIDs for specific link types MAY define some local significance for certain bits.
其他形式的64位IID的规范必须指定如何设置所有64位，但不得定义“u”和“g”位的通用语义。然而，为特定链路类型生成IID的方法可能会为某些比特定义一些局部重要性。
In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values. In fact, the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context.
在所有情况下，IID中的位都没有通用语义；换句话说，它们具有不透明的值。事实上，整个IID值必须被第三方视为不透明的位字符串，本地上下文除外。
The following statement in Section 2.5.1 of the IPv6 addressing architecture [RFC4291]:
IPv6寻址体系结构[RFC4291]第2.5.1节中的以下声明：
For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.
对于所有单播地址（以二进制值000开头的地址除外），接口ID要求为64位长，并以修改的EUI-64格式构造。
is replaced by:
替换为：
For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.
对于所有单播地址（以二进制值000开头的地址除外），接口ID的长度要求为64位。如果从IEEE MAC层地址派生，则必须以修改后的EUI-64格式构造。
The following statement in Section 2.5.1 of the IPv6 addressing architecture [RFC4291] is obsoleted:
IPv6寻址体系结构[RFC4291]第2.5.1节中的以下声明已过时：
The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope.
在修改后的EUI-64格式标识符中使用通用/本地位是为了开发未来技术，该技术可以利用具有通用范围的接口标识符。
As far as is known, no existing implementation will be affected by these changes. The benefit is that future design discussions are simplified.
据我们所知，现有的实现不会受到这些更改的影响。其好处是简化了未来的设计讨论。
No new security exposures or issues are raised by this document.
本文件未提出任何新的安全风险或问题。
In some contexts, unpredictable IID values are considered beneficial to enhance privacy and defeat scanning attacks. The recognition that the IID value should be regarded as an opaque bit string is consistent with methods of IID formation that result in unpredictable, pseudo-random values.
在某些情况下，不可预测的IID值被认为有助于增强隐私和抵御扫描攻击。应将IID值视为不透明位字符串的认识与导致不可预测伪随机值的IID形成方法一致。
This document requests no immediate action by IANA. However, the following should be noted when considering any future proposed addition to the registry of reserved IID values, which requires Standards Action [RFC5226] according to [RFC5453].
本文件不要求IANA立即采取行动。但是，在考虑将来向保留IID值注册表中添加任何建议时，应注意以下事项，这需要根据[RFC5453]采取标准行动[RFC5226]。
Full deployment of a new reserved IID value would require updates to IID generation code in every deployed IPv6 stack, so the technical justification for such a Standards Action would need to be extremely strong.
全面部署新的保留IID值将需要更新每个部署的IPv6堆栈中的IID生成代码，因此这种标准操作的技术理由必须非常充分。
The preceding sentence and a reference to this document have been added to the "Reserved IPv6 Interface Identifiers" registry.
“保留IPv6接口标识符”注册表中添加了前面的句子和对本文档的引用。
Valuable comments were received from Ran Atkinson, Remi Despres, Ralph Droms, Fernando Gont, Eric Gray, Brian Haberman, Joel Halpern, Bob Hinden, Christian Huitema, Ray Hunter, Tatuya Jinmei, Roger Jorgensen, Mark Smith, Bernie Volz, and other participants in the 6MAN working group.
Ran Atkinson、Remi Despres、Ralph Droms、Fernando Gont、Eric Gray、Brian Haberman、Joel Halpern、Bob Hinden、Christian Huitema、Ray Hunter、Tatuya Jinmei、Roger Jorgensen、Mark Smith、Bernie Volz以及6MAN工作组的其他参与者提出了宝贵意见。
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work.
布赖恩·卡彭特是剑桥大学计算机实验室的一名访客，他参与了这项工作。
[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月。
[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月。
[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月。
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, February 2009.
[RFC5453]Krishnan，S.，“保留IPv6接口标识符”，RFC 5453，2009年2月。
[RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[RFC7042]Eastlake，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，2013年10月。
[IEEE802] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2001 (R2007), 2007.
[IEEE802]“局域网和城域网的IEEE标准：概述和体系结构”，IEEE标准802-2001（R2007），2007年。
[IID-SLAAC] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, March 2012.
[IID-SLAAC]Gont，F.，“使用IPv6无状态地址自动配置（SLAAC）生成稳定隐私增强地址的方法”，正在进行的工作，2012年3月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307]Haberman，B.，“IPv6多播地址的分配指南”，RFC3307，2002年8月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[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月。
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.
[RFC4982]Bagnulo，M.和J.Arkko，“在加密生成地址（CGA）中支持多散列算法”，RFC 4982，2007年7月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[RFC5535]Bagnulo，M.，“基于哈希的地址（HBA）”，RFC5352009年6月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011.
[RFC6164]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，RFC 61642011年4月。
[RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, November 2012.
[RFC6741]阿特金森，RJ.，“标识符定位器网络协议（ILNP）工程注意事项”，RFC 67412012年11月。
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012.
[RFC6775]Shelby，Z.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 67752012年11月。
[RFC6957] Costa, F., Combes, J-M., Pougnard, X., and H. Li, "Duplicate Address Detection Proxy", RFC 6957, June 2013.
[RFC6957]Costa，F.，Combes，J-M.，Pougnard，X.，和H.Li，“重复地址检测代理”，RFC 69572013年6月。
[SOFTWR-4RD] Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", Work in Progress, October 2013.
[SOFTWR-4RD]Despres，R.，Jiang，S.，Penno，R.，Lee，Y.，Chen，G.，和M.Chen，“通过IPv6的IPv4剩余部署-无状态解决方案（4RD）”，正在进行的工作，2013年10月。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
中国北京海淀区北青路156号华为校区盛江华为技术有限公司Q14，邮编100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com