Internet Engineering Task Force (IETF) T. Narten Request for Comments: 6355 J. Johnson Category: Standards Track IBM ISSN: 2070-1721 August 2011Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)
Narten & Johnson Standards Track [Page 1]
RFC 6355 DUID-UUID August 2011
Table of Contents
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]. 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.
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:
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.
3. UUID Considerations
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, 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.
Narten & Johnson Standards Track [Page 3]
RFC 6355 DUID-UUID August 2011
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 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
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.
Narten & Johnson Standards Track [Page 4]
RFC 6355 DUID-UUID August 2011 6. IANA ConsiderationsIANA 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
8.2. Informative Reference
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration