Independent Submission F. Gont
Request for Comments: 7943 SI6 Networks / UTN-FRH
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
September 2016
Independent Submission F. Gont
Request for Comments: 7943 SI6 Networks / UTN-FRH
Category: Informational W. Liu
ISSN: 2070-1721 Huawei Technologies
September 2016
A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
一种使用IPv6动态主机配置协议（DHCPv6）生成语义不透明接口标识符（IID）的方法
Abstract
摘要
This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.
本文档描述了一种选择IPv6接口标识符的方法，在将非临时IPv6地址出租给DHCPv6客户端时，IPv6（DHCPv6）服务器的动态主机配置协议可以使用该标识符。此方法是一种DHCPv6服务器端算法，不需要对现有DHCPv6规范进行任何更新。上述方法在每个子网内产生稳定的地址，即使存在多个DHCPv6服务器或DHCPv6服务器重新安装。它是RFC 7217中为IPv6无状态地址自动配置指定的方法的DHCPv6变体。
IESG Note
IESG注释
A predecessor to this document was earlier a working group document in the DHC WG. The WG decided to stop further work in this area because such work was not considered useful.
本文件的前身是DHC工作组先前的一份工作组文件。工作组决定停止这方面的进一步工作，因为这类工作被认为没有用处。
The proposal described in this document has an unaddressed failure case that makes it unsuitable for use as the mechanism to provide the claimed failover features for DHCPv6 servers. Specifically, when a DHCPv6 client DECLINEs a provided address there is no recovery mechanism described that will result in the DHCPv6 client obtaining a working IPv6 address.
本文档中描述的方案有一个未解决的故障案例，因此不适合用作为DHCPv6服务器提供声称的故障切换功能的机制。具体而言，当DHCPv6客户端拒绝提供的地址时，没有描述将导致DHCPv6客户端获得工作IPv6地址的恢复机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第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/rfc7943.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7943.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability and Design Goals . . . . . . . . . . . . . . . 3
3. Method Specification . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability and Design Goals . . . . . . . . . . . . . . . 3
3. Method Specification . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The benefits of stable IPv6 addresses are discussed in [RFC7721]. Providing address stability across server reinstallations or when a database of previous DHCPv6 address leases is unavailable is of use not only when a DHCPv6 server must be reinstalled or the address-lease database becomes corrupted, but is also of use when implementation constraints (e.g., a DHCPv6 server implementation on an embedded device) make it impossible for a DHCPv6 server implementation to maintain a database of previous DHCPv6 address leases. Additionally, [RFC7031] describes scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability in case of server failures.
[RFC7721]中讨论了稳定IPv6地址的好处。提供跨服务器重新安装或以前DHCPv6地址租用的数据库不可用时的地址稳定性不仅在必须重新安装DHCPv6服务器或地址租用数据库损坏时有用，而且在实施约束（例如，嵌入式设备上的DHCPv6服务器实施）时也有用使DHCPv6服务器实现无法维护以前DHCPv6地址租约的数据库。此外，[RFC7031]描述了需要多台DHCPv6服务器以在服务器出现故障时提供更高可用性的方式运行的场景。
This document describes a method for selecting IPv6 Interface Identifiers that can be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients (i.e., to be employed with IA_NA options). This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method has the following properties:
本文档描述了一种选择IPv6接口标识符的方法，DHCPv6服务器在向DHCPv6客户端租用非临时IPv6地址时可以使用这些标识符（即，将与IA_NA选项一起使用）。此方法是一种DHCPv6服务器端算法，不需要对现有DHCPv6规范进行任何更新。上述方法具有以下特性：
o The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client, even when different DHCPv6 servers (implementing this specification) are employed.
o 即使使用了不同的DHCPv6服务器（实现此规范），结果IPv6地址在同一客户端的同一网络接口的每个子网内仍保持稳定。
o Predicting the IPv6 addresses that will be generated by the method specified in this document, even with knowledge of the IPv6 addresses generated for other nodes within the same network, becomes very difficult.
o 即使知道为同一网络中的其他节点生成的IPv6地址，也很难预测将通过本文档中指定的方法生成的IPv6地址。
The method specified in this document achieves the aforementioned properties by means of a calculated technique as opposed to, e.g., state sharing among DHCPv6 servers. This approach has already been suggested in [RFC7031]. We note that the method described in this document is essentially a DHCPv6 version of the "Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].
本文档中指定的方法通过计算技术实现上述属性，而不是DHCPv6服务器之间的状态共享。[RFC7031]中已经提出了这种方法。我们注意到，本文档中描述的方法本质上是[RFC7217]中指定的“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”的DHCPv6版本。
This document simply describes one possible approach for selecting IPv6 Interface Identifiers to be employed by DHCPv6 servers when leasing non-temporary IPv6 addresses to DHCPv6 clients, with the following properties:
本文档简单介绍了一种可能的方法，用于选择DHCPv6服务器在向DHCPv6客户端租用非临时IPv6地址时使用的IPv6接口标识符，该方法具有以下属性：
o The resulting IPv6 addresses remain stable within each subnet for the same network interface of the same client.
o 产生的IPv6地址在同一客户端的同一网络接口的每个子网内保持稳定。
o The resulting IPv6 addresses cannot be predicted by an attacker without knowledge of a secret key.
o 在不知道密钥的情况下，攻击者无法预测生成的IPv6地址。
o The resulting IPv6 addresses remain stable across DHCPv6 server reinstallations, or even if a database of previous DHCPv6 address leases is not available.
o 在重新安装DHCPv6服务器期间，或者即使先前DHCPv6地址租用的数据库不可用，生成的IPv6地址仍然保持稳定。
o The resulting IPv6 addresses remain stable when different DHCPv6 servers (implementing this specification) are employed on the same network.
o 在同一网络上使用不同的DHCPv6服务器（实现此规范）时，生成的IPv6地址保持稳定。
We note that the algorithm specified in this document employs a (lightweight) calculated technique (as opposed to, e.g., state sharing among DHCPv6 servers) to achieve address stability in scenarios where multiple DHCPv6 servers are required to run in such a way as to provide increased availability, without the need of an additional protocol to synchronize the lease databases of DHCPv6 servers.
我们注意到，本文档中指定的算法采用（轻量级）计算技术（与DHCPv6服务器之间的状态共享相反），以在需要多台DHCPv6服务器以提供更高可用性的方式运行的情况下实现地址稳定性，无需附加协议来同步DHCPv6服务器的租约数据库。
Finally, we note that the algorithm in this document is only meant to mitigate IPv6 address-based location tracking, device-specific vulnerability exploitation, and host scanning (please see [RFC7721]). There are a number of ways in which DHCPv6 affects user privacy, which the algorithm specified in this document does not mitigate (and does not intend to). Please see [RFC7844] for a comprehensive discussion of how DHCPv6 may affect user privacy.
最后，我们注意到，本文中的算法仅用于缓解基于IPv6地址的位置跟踪、设备特定漏洞攻击和主机扫描（请参阅[RFC7721]）。DHCPv6影响用户隐私的方式有很多，本文档中指定的算法不会缓解（也不打算缓解）。有关DHCPv6如何影响用户隐私的全面讨论，请参见[RFC7844]。
Implementations should provide the means for a system administrator to enable or disable the use of this algorithm for generating IPv6 addresses.
实现应为系统管理员提供启用或禁用此算法生成IPv6地址的方法。
A DHCPv6 server implementing this specification must select the IPv6 addresses to be leased with the following algorithm:
实现此规范的DHCPv6服务器必须使用以下算法选择要租用的IPv6地址：
1. Compute a random (but stable) identifier with the expression:
1. 使用以下表达式计算随机（但稳定）标识符：
RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
RID=F（前缀|客户端| DUID | IAID |计数器|密钥|）
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 be implemented as a cryptographic hash of the concatenation of each of the function parameters. The default algorithm to be employed for F() should be SHA-256 [FIPS-SHS]. An implementation may provide the means for selecting other algorithms. Note: Message Digest 5 (MD5) [RFC1321] is considered unacceptable for F() [RFC6151].
F（）：不能从外部计算的伪随机函数（PRF）（不知道密钥）。F（）也必须很难反转，这样即使给定了F（）输出的样本和其他输入参数的知识或控制，它也会阻止获取密钥的尝试。F（）应产生至少64位的输出。F（）可以实现为每个函数参数串联的加密哈希。F（）使用的默认算法应为SHA-256[FIPS-SHS]。实现可以提供选择其他算法的方法。注意：消息摘要5（MD5）[RFC1321]对于F（）[RFC6151]是不可接受的。
Prefix: The prefix employed for the local subnet, as a 128-bit unsigned integer in network byte order (with the unused bits set to 0). If multiple servers operate on the same network to provide increased availability, all such DHCPv6 servers must be configured with the same Prefix. It is the administrator's responsibility that the aforementioned requirement is met.
前缀：用于本地子网的前缀，作为网络字节顺序的128位无符号整数（未使用的位设置为0）。如果多台服务器在同一网络上运行以提供更高的可用性，则必须使用相同的前缀配置所有此类DHCPv6服务器。满足上述要求是管理员的责任。
|: An operator representing "concatenation".
|：表示“连接”的运算符。
Client_DUID: The DHCPv6 Unique Identifier (DUID) value contained in the Client Identifier option received in the DHCPv6 client message. The DUID can be treated as an array of 8-bit unsigned integers.
Client_DUID：DHCPv6客户机消息中接收的客户机标识符选项中包含的DHCPv6唯一标识符（DUID）值。DUID可以被视为8位无符号整数的数组。
IAID: The Identity Association Identifier (IAID) value contained in the IA_NA option received in the client message. It must be interpreted as a 32-bit unsigned integer in network byte order.
IAID：在客户端消息中接收的IA_NA选项中包含的标识关联标识符（IAID）值。它必须按网络字节顺序解释为32位无符号整数。
secret_key: A secret key configured by the DHCPv6 server administrator, which must not be known by the attacker. It must be encoded as an array of 8-bit unsigned integers. An implementation of this specification must provide an interface for viewing and changing the secret key. All DHCPv6 servers leasing addresses from the same address range must employ the same secret key.
密钥：由DHCPv6服务器管理员配置的密钥，攻击者不得知道该密钥。它必须编码为8位无符号整数数组。本规范的实现必须提供查看和更改密钥的接口。从同一地址范围租用地址的所有DHCPv6服务器必须使用相同的密钥。
Counter: A 32-bit unsigned integer in network byte order that is employed to resolve address conflicts. It must be initialized to 0.
计数器：网络字节顺序的32位无符号整数，用于解决地址冲突。它必须初始化为0。
2. A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by concatenating as many bits as necessary from the RID value computed in the previous step (starting from the least significant bit) to the Prefix employed in the equation above, as follows:
2. 要租用的候选IPv6地址（IPv6_ADDR）通过将前一步骤中计算的RID值（从最低有效位开始）中的尽可能多的位连接到上述等式中使用的前缀来获得，如下所示：
IPV6_ADDR = IPV6_ADDR_LOW +
RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)
IPV6_ADDR = IPV6_ADDR_LOW +
RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)
where:
哪里：
IPV6_ADDR: The candidate IPv6 address to be leased.
IPV6\u ADDR：要租用的候选IPV6地址。
IPV6_ADDR_HI: An IPv6 address specifying the upper boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_HI must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 1.
IPV6_ADDR_HI：一个IPV6地址，指定DHCPv6服务器从中租用IPV6地址的IPV6地址池的上边界。如果未明确选择地址范围，则必须将IPV6_ADDR_HI设置为接口标识符的所有位都设置为1的前缀（请参见上面的表达式）中的IPV6地址。
IPV6_ADDR_LOW: An IPv6 address specifying the lower boundary of the IPv6 address pool from which the DHCPv6 server leases IPv6 addresses. If an address range is not explicitly selected, IPV6_ADDR_LOW must be set to the IPv6 address from the Prefix (see the expression above) that has all of the bits of the Interface Identifier set to 0.
IPV6_ADDR_LOW：一个IPV6地址，指定DHCPv6服务器从中租用IPV6地址的IPV6地址池的下边界。如果未明确选择地址范围，则必须将IPV6_ADDR_LOW设置为接口标识符的所有位都设置为0的前缀（请参见上面的表达式）中的IPV6地址。
3. The Interface Identifier of the selected IPv6 address must be compared against the reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]. In the event that an unacceptable identifier has been generated, the Counter variable should be incremented by 1, and a new IPv6 address should be computed with the updated Counter value.
3. 必须将所选IPv6地址的接口标识符与保留的IPv6接口标识符[RFC5453][IANA-REFERED-IID]进行比较。如果生成了不可接受的标识符，则计数器变量应递增1，并应使用更新的计数器值计算新的IPv6地址。
4. If the resulting address is not available (e.g., there is a conflicting binding), the DHCPv6 server should increment the Counter variable, and a new Interface Identifier and IPv6 address should be computed with the updated Counter value.
4. 如果生成的地址不可用（例如，存在冲突绑定），DHCPv6服务器应递增计数器变量，并应使用更新的计数器值计算新的接口标识符和IPv6地址。
This document requires that SHA-256 be the default function to be used for F(), such that (all other configuration parameters being the same) different implementations of this specification result in the same IPv6 addresses.
本文档要求SHA-256是F（）使用的默认函数，以便（所有其他配置参数相同）本规范的不同实现会产生相同的IPv6地址。
Including the Prefix in the PRF computation causes the Interface Identifier to be different for each address from a different prefix leased to the same client. This mitigates the correlation of activities of multihomed nodes (since each of the corresponding addresses will employ a different Interface Identifier), host tracking (since the network prefix, and therefore the resulting Interface Identifier, will change as the node moves from one network to another), and any other attacks that benefit from predictable Interface Identifiers [RFC7721].
在PRF计算中包括前缀会导致从租给同一客户机的不同前缀到每个地址的接口标识符不同。这减轻了多宿节点活动的相关性（因为每个对应的地址将使用不同的接口标识符）、主机跟踪（因为网络前缀以及由此产生的接口标识符将随着节点从一个网络移动到另一个网络而改变），以及任何其他得益于可预测接口标识符的攻击[RFC7721]。
As required by [RFC3315], an IAID is associated with each of the client's network interfaces and is consistent across restarts of the DHCPv6 client.
根据[RFC3315]的要求，IAID与每个客户端的网络接口相关联，并且在DHCPv6客户端重新启动时保持一致。
The Counter parameter provides the means to intentionally cause this algorithm to produce different IPv6 addresses (all other parameters being the same). This can be of use to resolve address conflicts (e.g., the resulting address having a conflicting binding).
计数器参数提供了有意使此算法产生不同IPv6地址的方法（所有其他参数相同）。这可用于解决地址冲突（例如，产生的地址具有冲突的绑定）。
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 DHCPv6 server (which we should expect), and the attacker can obtain enough material (i.e., addresses generated by the DHCPv6 server), the attacker may simply search the entire secret-key space to find matches. To protect against this, the secret key should be of at least 128 bits. Key lengths of at least 128 bits should be adequate.
请注意，上述算法中F（）的结果并不比密钥更安全。如果攻击者知道DHCPv6服务器正在使用的PRF（我们应该知道），并且攻击者可以获得足够的资料（即DHCPv6服务器生成的地址），则攻击者可以简单地搜索整个密钥空间以查找匹配项。为了防止出现这种情况，密钥应至少为128位。至少128位的密钥长度应足够。
Providing a mechanism to display and change the secret_key is crucial for having different DHCPv6 servers produce the same IPv6 addresses and for causing a replacement system 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 other purposes than being a parameter to the scheme specified in this document.
提供显示和更改密钥的机制对于让不同的DHCPv6服务器生成相同的IPv6地址以及使替换系统生成与被替换系统相同的IPv6地址至关重要。我们注意到，由于本文档中指定的方案的隐私依赖于secret_key参数的保密性，因此实现应在可行的范围内限制对secret_key参数的访问（例如，需要超级用户权限来访问它）。此外，为了防止secret_key参数泄漏，除了作为本文档中指定的方案的参数外，不应将其用于任何其他目的。
We note that all of the bits in the resulting Interface Identifiers 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 identifier.
我们注意到，结果接口标识符中的所有位都被视为“不透明”位[RFC7136]。例如，修改的EUI-64格式标识符的通用/本地位被视为该标识符的任何其他位。
The method specified in this document results in IPv6 Interface Identifiers (and hence IPv6 addresses) that do not follow any specific pattern. Thus, attacks that rely on predictable Interface Identifiers (such as [RFC7707]) are mitigated.
本文档中指定的方法会产生不遵循任何特定模式的IPv6接口标识符（以及IPv6地址）。因此，可以缓解依赖可预测接口标识符（如[RFC7707]）的攻击。
The method specified in this document neither mitigates nor exacerbates the security considerations for DHCPv6 discussed in [RFC3315] and does not mitigate a range of other privacy implications associated with DHCPv6. Please read [RFC7844] for a comprehensive assessment of the privacy implications of DHCPv6.
本文件中规定的方法既不会减轻也不会加剧[RFC3315]中讨论的DHCPv6的安全注意事项，也不会减轻与DHCPv6相关的一系列其他隐私影响。请阅读[RFC7844]以全面评估DHCPv6的隐私影响。
Finally, we note that an attacker that is able to attach to each of the links to which the victim attaches would still be able to correlate the activities of the victim across networks.
最后，我们注意到，能够连接到受害者连接的每个链接的攻击者仍然能够跨网络关联受害者的活动。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, <http://www.rfc-editor.org/info/rfc5453>.
[RFC5453]Krishnan，S.，“保留IPv6接口标识符”，RFC 5453，DOI 10.17487/RFC5453，2009年2月<http://www.rfc-editor.org/info/rfc5453>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136]Carpenter，B.和S.Jiang，“IPv6接口标识符的重要性”，RFC 7136，DOI 10.17487/RFC7136，2014年2月<http://www.rfc-editor.org/info/rfc7136>.
[FIPS-SHS] Federal Information Processing Standards (FIPS), "Secure Hash Standard (SHS)", FIPS 180-4, August 2015, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[FIPS-SHS]联邦信息处理标准（FIPS），“安全哈希标准（SHS）”，FIPS 180-42015年8月<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>。
[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>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC 1321，DOI 10.17487/RFC1321，1992年4月<http://www.rfc-editor.org/info/rfc1321>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <http://www.rfc-editor.org/info/rfc6151>.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 6151，DOI 10.17487/RFC6151，2011年3月<http://www.rfc-editor.org/info/rfc6151>.
[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Requirements", RFC 7031, DOI 10.17487/RFC7031, September 2013, <http://www.rfc-editor.org/info/rfc7031>.
[RFC7031]Mrugalski，T.和K.Kinnear，“DHCPv6故障切换要求”，RFC 7031，DOI 10.17487/RFC70312013年9月<http://www.rfc-editor.org/info/rfc7031>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <http://www.rfc-editor.org/info/rfc7707>.
[RFC7707]Gont，F.和T.Chown，“IPv6网络中的网络侦察”，RFC 7707，DOI 10.17487/RFC7707，2016年3月<http://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <http://www.rfc-editor.org/info/rfc7721>.
[RFC7721]Cooper，A.，Gont，F.，和D.Thaler，“IPv6地址生成机制的安全和隐私考虑”，RFC 7721，DOI 10.17487/RFC7721，2016年3月<http://www.rfc-editor.org/info/rfc7721>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户端的匿名配置文件”，RFC 7844，DOI 10.17487/RFC7844，2016年5月<http://www.rfc-editor.org/info/rfc7844>.
Acknowledgements
致谢
This document is based on [RFC7217], authored by Fernando Gont.
本文档基于Fernando Gont编写的[RFC7217]。
The authors would like to thank Marc Blanchet, Stephane Bortzmeyer, Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz for providing valuable comments on earlier draft versions of this documents.
作者感谢Marc Blanchet、Stephane Bortzmeyer、Tatuya Jinmei、Andre Kostur、Tomek Mrugalski、Hosnieh Rafie、Jim Schaad、Jean-Francois Tremblay、Tina Tsou和Bernie Volz对本文件的早期草稿提供了宝贵意见。
The authors would like to thank Ted Lemon, who kindly answered some DHCPv6-related questions, and Nevil Brownlee for his guidance while pursuing this document.
作者要感谢泰德·莱蒙（Ted Lemon），他亲切地回答了一些与DHCPv6相关的问题，并感谢内维尔·布朗利（Nevil Brownlee）在撰写本文件时给予的指导。
Fernando Gont would like to thank Nelida Garcia and Guillermo Gont for their love and support, and Diego Armando Maradona for his magic and inspiration.
费尔南多·贡特要感谢内利达·加西亚和吉列尔莫·贡特的爱和支持，感谢迭戈·阿曼多·马拉多纳的魔力和灵感。
Authors' Addresses
作者地址
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
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China
威尔（舒城）刘华威科技有限公司深圳市龙岗区坂田518129
Email: liushucheng@huawei.com
Email: liushucheng@huawei.com