基于 UUID 的 DHCPv6 唯一标识符（DUID-UUID）定义（RFC 6355） 原文标题：
内容概要总结
本文是 IETF 标准轨道文档 RFC 6355，定义了一种新的 DHCPv6 唯一标识符类型 DUID-UUID，即把已标准化的 UUID（RFC 4122）内嵌进 DHCPv6 的 DUID。文档说明：DHCPv6 用 DUID 标识客户端和服务器，此前已有 DUID-LLT、DUID-EN、DUID-LL 三种类型；但在多步网络引导（固件逐步加载镜像）场景中，这些类型无法保证各引导阶段使用同一 DUID，故引入基于 UUID 的第四种类型（DUID-Type 值为 4，UUID 占 128 位）。文档要求所选 UUID 必须在系统重启、重配置、系统升级/重装之间保持持久，且能被引导过程中所有 DHCP 协议代理访问（例如系统固件中的 UUID）。安全考量指出：DHCP 流量明文传输，路径上的窃听者可获取机器 UUID，但这并非该新 DUID 类型引入的新问题。对设备标识主题而言，本文提供了"用现成 UUID 作为设备标识嵌入网络协议"的标准化范例与持久性要求。
（说明：原引用链接 datatracker.ietf.org/doc/html/rfc6355 直连返回 403，本文取自 rfc-editor.org 的同一 RFC 官方版本。）
翻译内容
原文内容（English）
互联网工程任务组（IETF） T. Narten
请求注释（Request for Comments）：6355 J. Johnson
类别：标准轨道（Standards Track） IBM
ISSN：2070-1721 2011 年 8 月
基于 UUID 的 DHCPv6 唯一标识符（DUID-UUID）定义
摘要
本文定义了一种新的 DHCPv6 唯一标识符（DHCPv6 Unique Identifier，DUID）类型，称为 DUID-UUID。DUID-UUID 派生自已标准化的通用唯一标识符（Universally Unique IDentifier，UUID）格式。DUID-UUID 使设备能够使用 UUID 向 DHCP 服务器标识自身，反之亦然。UUID 是全球唯一的，并且在许多系统上现成可用，因此是在 DHCP 内部加以利用的便捷标识符。
本文档状态
本文档为互联网标准轨道文档。
本文档是互联网工程任务组（IETF）的产物。它代表 IETF 社区的共识。它已经过公开评审，并已获得互联网工程指导组（IESG）批准发布。有关互联网标准的更多信息可在 RFC 5741 第 2 节中找到。
有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc6355 获取。
版权声明
版权所有（c）2011 IETF Trust 及被认定为本文档作者的人员。保留所有权利。
本文档受 BCP 78 及《IETF 文件相关信托法律条款》（http://trustee.ietf.org/license-info）约束，其效力以本文档发布之日为准。请仔细阅读这些文档，因为它们描述了您对本文档的权利与限制。从本文档中提取的代码组件必须包含《信托法律条款》第 4.e 节所述的 Simplified BSD License 文本，并且按《Simplified BSD License》所述不提供任何担保。
目录
- 引言 . . . 2
- 背景 . . . 2
- UUID 考量 . . . 3
- DUID-UUID 格式 . . . 4
- 致谢 . . . 4
- IANA 考量 . . . 5
- 安全考量 . . . 5
- 参考文献 . . . 5
8.1. 规范性参考文献 . . . 5
8.2. 资料性参考文献 . . . 5
1. 引言
DHCP 唯一标识符（DHCP Unique Identifiers，DUID）在 DHCPv6 中用于标识客户端和服务器。本文定义了一种新的 DHCP 唯一标识符（DUID）类型，它内嵌了一个通用唯一标识符（UUID）[RFC4122]。UUID 已被广泛使用，可作为 DHCPv6 可利用的一种既有标识符。例如，基于 x86 的系统在固件中内置了一个 UUID，设备上运行的软件可随时访问它。虽然 DUID 对 DHCPv6 而言是新的，但通过 UUID 在 DHCP 中标识客户端并非新事物。DHCPv4 [RFC2132] 定义了客户端机器标识符选项（Client Machine Identifier Option，选项 97），它内嵌了一个 UUID（又称全局唯一标识符 GUID）[RFC4578]。本文将该能力扩展到 DHCPv6。
本文使用的 IPv6 与 DHCPv6 专用术语，按 [RFC3315] 的“术语（Terminology）”各节所定义。
2. 背景
在 DHCPv6 中，客户端通过 DHCP 唯一标识符（DUID）[RFC3315] 向服务器标识自身。DUID 是 DHCP 服务器视为无内部结构的不透明对象的标识符。DUID 旨在全局唯一，没有任何两台设备使用相同的 DUID。此前已定义了三种 DUID 类型：
- DUID-LLT —— 设备某个网络接口的链路层地址，与一个时间戳拼接
- DUID-EN —— 一个企业编号（Enterprise Number）加上该企业特定的附加信息
- DUID-LL —— 设备某个网络接口的链路层地址
DUID 旨在随时间保持不变，从而可用作设备的永久标识符。对于 DUID-LLT，它们旨在只生成一次，存入稳定存储，并从那一刻起重复使用。
已经出现的一个问题涉及采用多步网络引导加载的设备。初始步骤（通常从固件运行）加载一个小镜像，该镜像又加载第二个镜像，依此类推，直到加载真正的目标系统。引导过程中的每一步都可能调用 DHCP。在某些运行环境中，序列中的每一步都使用相同的 DUID 非常重要，这样服务器就知道它接收到的是来自同一设备的请求，并能返回正确的配置信息（包括指向要加载的正确镜像的指针）。
遗憾的是，此前定义的 DUID 没有一种对多步网络引导是理想的。给定设备可能使用的 DUID-LLT 和 DUID-LL 标识符并不保证在每个引导步骤之间保持恒定。即使不同阶段使用 DUID-LL 或 DUID-LLT，在多接口设备上也无法保证会选择同一个接口（因而同一个 DUID）。最后，对于 DUID-LLT，即使选择了同一个接口，也很难确保每个阶段使用相同的时间戳值。虽然可以定义并使用 DUID-EN，但这种用法按定义就是专有的。
本文定义了一种新的 DUID 类型，它基于通用唯一标识符（UUID）[RFC4122]。UUID 在实践中已被使用，可作为 DHCP 可利用的一种既有标识符。在某些环境中，基于 UUID 的 DUID 优于其他既有 DUID 类型。
应当指出，仅使用 DUID-UUID 本身并不能解决本文所述的所有网络引导问题。即便有了合适的 DUID-UUID，实现者仍需要采取措施，以确保所有引导阶段都酌情使用相同的 DUID-UUID。鉴于 DHCP 已经定义了多种 DUID 类型，从多个 DUID 中选择哪一个的问题本就存在，而定义一种新的 DUID 类型本身并不能帮助解决这一问题。不过，相信网络引导服务可以被配置为使用 DUID-UUID，其他软件也能如此。确保这一点普遍发生超出了本文档的范围。
3. UUID 考量
尽管当今有许多 UUID 在使用，但并非所有 UUID 都满足 DHCP 的要求（见 [RFC3315] 第 9 节）。DHCP 的 UUID 应当在系统重启、系统重配置事件、系统软件与操作系统升级或重装之间保持持久，并且能方便地被引导过程中任何需要访问该 DHCP UUID 的部分获取。例如，Microsoft 的组件对象模型（COM）中使用的 UUID，以及用于标注文件系统分区的 UUID，很可能并不合适，因为它们可能无法被固件引导加载程序访问，并且可能随时间变化。
使用 DUID-UUID 的本规范实现必须选择一个在系统重启与重配置事件之间保持持久、且可被所有可能需要标识自身的 DHCP 协议代理获取的 UUID。例如，作为系统固件一部分、或由系统固件管理的 UUID，满足这一要求。
4. DUID-UUID 格式
DUID-UUID 承载于客户端标识符（Client Identifier）或服务器标识符（Server Identifier）选项内。其格式如下：
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+图 1：DUID-UUID 格式
- DUID-Type —— DUID-UUID（4）——（16 位）
- UUID —— 一个 [RFC4122] UUID（128 位）
5. 致谢
本文档的灵感来自 2009 年 11 月 DHC 邮件列表中关于 IPv6 网络引导（netboot）主题的一次讨论。具体而言，讨论中描述了一些场景，其中在 DHCPv6 中做某件在 DHCPv4 中运作良好的事情变得困难。
我们要特别感谢以下人士就本文档提出的具体评论和建议：Thomas Huth、Andre Kostur、Stephen Jacob、Suresh Krishnan、Ted Lemon、Bernie Volz 和 Vincent Zimmer。
6. IANA 考量
IANA 已分配值 4 供 DHCPv6 DUID-UUID 类型使用。
7. 安全考量
客户端与服务器之间的 DHCP 流量以明文发送。位于客户端与服务器之间路径上的窃听者可以看到 DHCP 流量并获取某台机器的 UUID。这可能引发一些隐私问题，但并非由本文档定义的 DUID 类型的使用所带来的新问题。
8. 参考文献
8.1. 规范性参考文献
- [RFC2132] Alexander, S. 与 R. Droms，"DHCP Options and BOOTP Vendor Extensions"，RFC 2132，1997 年 3 月。
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. 与 M. Carney，"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"，RFC 3315，2003 年 7 月。
- [RFC4122] Leach, P., Mealling, M. 与 R. Salz，"A Universally Unique IDentifier (UUID) URN Namespace"，RFC 4122，2005 年 7 月。
8.2. 资料性参考文献
- [RFC4578] Johnston, M. 与 S. Venaas，"Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)"，RFC 4578，2006 年 11 月。
作者地址
Thomas Narten
IBM
EMail: narten@us.ibm.com
Jarrod B. Johnson
IBM
EMail: jarrod.b.johnson@gmail.com
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)
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.
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](https://www.rfc-editor.org/rfc/rfc5741#section-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.
This document is subject to [BCP 78](https://www.rfc-editor.org/bcp/bcp78) and the IETF Trust's Legal
Provisions Relating to IETF Documents
([http://trustee.ietf.org/license-info](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.
Narten & Johnson Standards Track [Page 1][RFC 6355](https://www.rfc-editor.org/rfc/rfc6355) DUID-UUID August 2011
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
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](https://www.rfc-editor.org/rfc/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.
Although DUIDs are new to DHCPv6, identifying clients in DHCP via a
UUID is not. DHCPv4 [[RFC2132](https://www.rfc-editor.org/rfc/rfc2132)] defines a Client Machine Identifier
Option (option 97) that embeds a UUID (aka a Globally Unique
Identifier (GUID)) [[RFC4578](https://www.rfc-editor.org/rfc/rfc4578)]. This document extends that capability
to DHCPv6.
Terminology specific to IPv6 and DHCPv6 is used as defined in the
"Terminology" sections of [[RFC3315](https://www.rfc-editor.org/rfc/rfc3315)].
2. Background
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:
DUID-LLT - the Link-Layer address of one of the device's network
interfaces, concatenated with a timestamp
DUID-EN - an Enterprise Number plus additional information specific
to the enterprise
DUID-LL - the Link-Layer address of one of the device's network
interfaces
Narten & Johnson Standards Track [Page 2]RFC 6355 DUID-UUID August 2011
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.
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).
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.
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.
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.
3. UUID Considerations
Although many UUIDs are in use today, not all UUIDs meet DHCP's
requirements (see [Section 9 of [RFC3315]](https://www.rfc-editor.org/rfc/rfc3315#section-9)). DHCP UUIDs should be
persistent across system restarts, system reconfiguration events,
Narten & Johnson Standards Track [Page 3]RFC 6355 DUID-UUID August 2011
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.
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.
4. DUID-UUID Format
The DUID-UUID is carried within Client Identifier or Server
Identifier options. It has the following format:
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
DUID-Type - DUID-UUID (4) - (16 bits)
UUID - An [RFC4122] UUID (128 bits)
5. Acknowledgements
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.
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.
Narten & Johnson Standards Track [Page 4]RFC 6355 DUID-UUID August 2011
6. IANA Considerations
IANA has assigned the value 4 for use by the DHCPv6 DUID-UUID type.
7. Security Considerations
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.
8. References
8.1. Normative References
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", [RFC 2132](https://www.rfc-editor.org/rfc/rfc2132), March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", [RFC 3315](https://www.rfc-editor.org/rfc/rfc3315), July 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", [RFC 4122](https://www.rfc-editor.org/rfc/rfc4122),
July 2005.
8.2. Informative Reference
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration
Protocol (DHCP) Options for the Intel Preboot eXecution
Environment (PXE)", [RFC 4578](https://www.rfc-editor.org/rfc/rfc4578), November 2006.
Authors' Addresses
Thomas Narten
IBM
EMail: narten@us.ibm.com
Jarrod B. Johnson
IBM
EMail: jarrod.b.johnson@gmail.com
Narten & Johnson Standards Track [Page 5]