Internet Engineering Task Force (IETF) T. Narten
Request for Comments: 6355 J. Johnson
Category: Standards Track IBM
ISSN: 2070-1721 August 2011
Internet Engineering Task Force (IETF) T. Narten
Request for Comments: 6355 J. Johnson
Category: Standards Track IBM
ISSN: 2070-1721 August 2011
Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
基于UUID的DHCPv6唯一标识符（DUID-UUID）的定义
Abstract
摘要
This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP.
本文档定义了一个名为DUID-UUID的新DHCPv6唯一标识符（DUID）类型。DUID UUID源自已经标准化的通用唯一标识符（UUID）格式。DUID-UUID使设备可以使用UUID向DHC服务器标识自己，反之亦然。UUID在全球范围内是唯一的，并且在许多系统上都可以随时使用，这使得它们能够方便地在DHCP中利用标识符。
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/rfc6355.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6355.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. UUID Considerations . . . . . . . . . . . . . . . . . . . . . . 3
4. DUID-UUID Format . . . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative Reference . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. UUID Considerations . . . . . . . . . . . . . . . . . . . . . . 3
4. DUID-UUID Format . . . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative Reference . . . . . . . . . . . . . . . . . . . 5
DHCP Unique Identifiers (DUIDs) are used in DHCPv6 to identify clients and servers. This document defines a new DHCP Unique Identifier (DUID) type that embeds a Universally Unique IDentifier (UUID) [RFC4122]. UUIDs are already in widespread use and serve as an existing identifier that could be leveraged by DHCPv6. For example, x86-based systems ship with an embedded UUID in firmware that is readily available to the software running on the device.
DHCP唯一标识符（DUID）在DHCPv6中用于标识客户端和服务器。本文档定义了嵌入通用唯一标识符（UUID）的新DHCP唯一标识符（DUID）类型[RFC4122]。UUID已经被广泛使用，并作为DHCPv6可以利用的现有标识符。例如，基于x86的系统在固件中附带嵌入式UUID，该固件可用于设备上运行的软件。
Although DUIDs are new to DHCPv6, identifying clients in DHCP via a UUID is not. DHCPv4 [RFC2132] defines a Client Machine Identifier Option (option 97) that embeds a UUID (aka a Globally Unique Identifier (GUID)) [RFC4578]. This document extends that capability to DHCPv6.
虽然DUID对于DHCPv6来说是新的，但是通过UUID在DHCP中识别客户端并不重要。DHCPv4[RFC2132]定义了一个嵌入UUID（也称为全局唯一标识符（GUID））[RFC4578]的客户机标识符选项（选项97）。本文档将该功能扩展到DHCPv6。
Terminology specific to IPv6 and DHCPv6 is used as defined in the "Terminology" sections of [RFC3315].
专用于IPv6和DHCPv6的术语如[RFC3315]的“术语”部分所述。
In DHCPv6, clients identify themselves to servers via DHCP Unique Identifiers (DUIDs) [RFC3315]. DUIDs are identifiers that DHCP servers treat as opaque objects with no internal structure. DUIDs are intended to be globally unique, with no two devices using the same DUID. Three DUIDs types have been defined previously:
在DHCPv6中，客户端通过DHCP唯一标识符（DUID）向服务器标识自己[RFC3315]。DUID是DHCP服务器视为不透明对象的标识符，没有内部结构。DUID旨在具有全局唯一性，没有两个设备使用相同的DUID。先前定义了三种DUID类型：
DUID-LLT - the Link-Layer address of one of the device's network interfaces, concatenated with a timestamp
DUID-LLT—设备网络接口之一的链路层地址，与时间戳连接
DUID-EN - an Enterprise Number plus additional information specific to the enterprise
DUID-EN-企业编号以及特定于企业的附加信息
DUID-LL - the Link-Layer address of one of the device's network interfaces
DUID-LL—设备网络接口之一的链路层地址
DUIDs are intended to remain constant over time, so that they can be used as permanent identifiers for a device. In the case of DUID-LLTs, they are intended to be generated once, stored in stable storage, and reused from that point forward.
DUID在一段时间内保持不变，因此可以用作设备的永久标识符。在DUID LLT的情况下，它们打算生成一次，存储在稳定的存储器中，并从那时起重新使用。
One issue that has arisen concerns devices that employ multi-step network boot loading. An initial step (typically run out of firmware) loads a small image that, in turn, loads a second image and so forth until the actual target system is loaded. Each step in the booting process may invoke DHCP. In some operational environments, it is important that each step in the sequence use the same DUID, so that the server knows it is getting requests from the same device and can return the proper configuration information (including the pointer to the correct image to load).
出现的一个问题涉及采用多步骤网络引导加载的设备。初始步骤（通常固件耗尽）加载一个小映像，然后加载第二个映像，依此类推，直到加载实际的目标系统。引导过程中的每个步骤都可以调用DHCP。在某些操作环境中，序列中的每个步骤都必须使用相同的DUID，以便服务器知道它正在从同一设备获取请求，并可以返回正确的配置信息（包括指向要加载的正确映像的指针）。
Unfortunately, none of the previously defined DUIDs are ideal for multi-step network booting. The DUID-LLT and DUID-LL identifiers that a given device may use are not guaranteed to remain constant across each booting step. Even if the different stages used DUID-LL or DUID-LLT, on devices with multiple interfaces, there is no way to guarantee that the same interface (and hence DUID) will be selected. Finally, in the case of DUID-LLT, even if the same interface is chosen, it can be difficult to ensure that each stage uses the same timestamp value. While a DUID-EN could be defined and used, such usage is proprietary by definition.
不幸的是，以前定义的DUID都不适合多步骤网络引导。给定设备可能使用的DUID-LLT和DUID-LL标识符不能保证在每个引导步骤中保持不变。即使不同的阶段在具有多个接口的设备上使用DUID-LL或DUID-LLT，也无法保证选择相同的接口（因此DUID）。最后，在DUID-LLT的情况下，即使选择了相同的接口，也很难确保每个阶段使用相同的时间戳值。虽然可以定义和使用DUID-EN，但根据定义，这种用法是专有的。
This document defines a new DUID type, based on the Universally Unique IDentifier (UUID) [RFC4122]. UUIDs are already used in practice and serve as an existing identifier that could be leveraged by DHCP. In some environments, a UUID-based DUID is preferable to the other existing DUID types.
本文档基于通用唯一标识符（UUID）[RFC4122]定义了一个新的DUID类型。UUID已经在实践中使用，并作为DHCP可以利用的现有标识符。在某些环境中，基于UUID的DUID比其他现有DUID类型更可取。
It should be noted that use of a DUID-UUID will not, by itself, solve all the network boot problems described in this document. Given the availability of a suitable DUID-UUID, implementations will still need to take steps to ensure that all boot stages use the same DUID-UUID as appropriate. Given that DHCP has already defined multiple DUID types, the question of which of several DUIDs to select from already exists, and defining a new DUID type does not, by itself, help. It is believed, however, that network boot services can be configured to use a DUID-UUID and that other software can do so as well. Ensuring this happens in general is beyond the scope of this document.
应该注意的是，使用DUID-UUID本身并不能解决本文档中描述的所有网络引导问题。考虑到合适的DUID-UUID的可用性，实现仍然需要采取步骤确保所有引导阶段都使用相同的DUID-UUID。鉴于DHCP已经定义了多个DUID类型，从多个DUID中选择哪一个的问题已经存在，并且定义一个新的DUID类型本身并没有帮助。然而，人们相信网络引导服务可以配置为使用DUID-UUID，其他软件也可以这样做。一般而言，确保这种情况发生超出了本文件的范围。
Although many UUIDs are in use today, not all UUIDs meet DHCP's requirements (see Section 9 of [RFC3315]). DHCP UUIDs should be persistent across system restarts, system reconfiguration events,
尽管目前使用了许多UUID，但并非所有UUID都满足DHCP的要求（见[RFC3315]第9节）。DHCP UUID应在系统重启、系统重新配置事件、，
system software and operating system upgrades or reinstallation as well as be easily available to any part of the boot process that requires access to the DHCP UUID. For example, UUIDs used in Microsoft's Component Object Module (COM), and for labeling partitions in filesystems, are likely not appropriate as they may not be accessible to firmware boot loaders and can change over time.
系统软件和操作系统的升级或重新安装以及需要访问DHCP UUID的引导过程的任何部分都可以轻松获得。例如，在Microsoft的组件对象模块（COM）中使用的UUID以及在文件系统中标记分区的UUID可能不合适，因为固件引导加载程序可能无法访问这些UUID，并且可能会随着时间的推移而改变。
Implementations of this specification using DUID-UUID must select a UUID that is persistent across system restart and reconfiguration events and that is available to all DHCP protocol agents that may need to identify themselves. For instance, a UUID that is part of the system firmware, or managed by the system firmware, satisfies this requirement.
使用DUID-UUID实现本规范必须选择一个UUID，该UUID在系统重启和重新配置事件中是持久的，并且可用于所有可能需要识别自身的DHCP协议代理。例如，作为系统固件一部分或由系统固件管理的UUID满足此要求。
The DUID-UUID is carried within Client Identifier or Server Identifier options. It has the following format:
DUID-UUID包含在客户端标识符或服务器标识符选项中。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (4) | UUID (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (4) | UUID (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: DUID-UUID Format
图1:DUID-UUID格式
DUID-Type - DUID-UUID (4) - (16 bits)
DUID类型-DUID-UUID（4）-（16位）
UUID - An [RFC4122] UUID (128 bits)
UUID-一个[RFC4122]UUID（128位）
This document was inspired by a discussion on the DHC mailing list in November 2009 on the topic of netboot for IPv6. Specifically, some scenarios were described where it was difficult to do something in DHCPv6 that had worked well in DHCPv4.
本文档的灵感来源于2009年11月DHC邮件列表上关于IPv6的netboot主题的讨论。具体来说，描述了一些场景，其中很难在DHCPv6中执行在DHCPv4中运行良好的操作。
We would like to thank the following individuals in particular for their specific comments and suggestions on this document: Thomas Huth, Andre Kostur, Stephen Jacob, Suresh Krishnan, Ted Lemon, Bernie Volz, and Vincent Zimmer.
我们特别感谢以下人士对本文件提出的具体意见和建议：托马斯·胡特、安德烈·科斯特尔、斯蒂芬·雅各布、苏雷什·克里希南、特德·莱蒙、伯尼·沃尔兹和文森特·齐默。
IANA has assigned the value 4 for use by the DHCPv6 DUID-UUID type.
IANA已为DHCPv6 DUID-UUID类型分配了值4。
DHCP traffic between a client and server is sent in the clear. An eavesdropper residing on the path between the client and server could see DHCP traffic and obtain the UUID for a particular machine. This may raise some privacy issues but is not a new issue brought on by the use of the DUID type defined in this document.
客户端和服务器之间的DHCP通信以明文形式发送。驻留在客户端和服务器之间的路径上的窃听者可以看到DHCP流量并获取特定计算机的UUID。这可能会引起一些隐私问题，但不是由于使用本文档中定义的DUID类型而引起的新问题。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
[RFC4578]Johnston，M.和S.Venaas，“英特尔预引导执行环境（PXE）的动态主机配置协议（DHCP）选项”，RFC 4578，2006年11月。
Authors' Addresses
作者地址
Thomas Narten IBM
托马斯·纳腾IBM
EMail: narten@us.ibm.com
EMail: narten@us.ibm.com
Jarrod B. Johnson IBM
贾罗德·B·约翰逊IBM公司
EMail: jarrod.b.johnson@gmail.com
EMail: jarrod.b.johnson@gmail.com