RFC 6355

Title Block 🎀

RFC 6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) 💖

• Authors: Thomas Narten and Jarrod B. Johnson, both at IBM 🧚
• Category: Standards Track 📜 (ISSN 2070-1721)
• Date: August 2011 🗓️
• Obsoletes or updates: the title block lists neither, so this one doesn't replace or update any earlier RFC 🦋

Abstract 🦋

okay so this doc makes a brand-new DHCPv6 Unique Identifier (DUID) type called DUID-UUID! 💅 It's built on the UUID format that already exists and is already everywhere. With DUID-UUID, devices can use their UUIDs to introduce themselves to DHC servers, and servers can do the same back. UUIDs are globally unique and easy to find on lots of systems, so they're a super convenient ID to borrow for DHCP ✨

Status of This Memo 📝

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF) 🌈 and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 🍓

info about this doc's current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6355 💜

Copyright Notice 💜

© 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🫶

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 📜

if you pull Code Components out of this document, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License describes ⚠️

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 how DHCPv6 tells clients and servers apart 🧚 This doc defines a new DHCP Unique Identifier (DUID) type that embeds a Universally Unique IDentifier (UUID) [RFC4122]. UUIDs are already everywhere and could totally be reused by DHCPv6. For example, x86-based systems ship with a UUID baked into firmware, and the software running on the device can grab it easily 💅

DHCPv4 [RFC2132] already does this. It defines a Client Machine Identifier Option (option 97) that embeds a UUID (aka a Globally Unique Identifier (GUID)) [RFC4578]. This document brings that same capability to DHCPv6 🦋

Terminology specific to IPv6 and DHCPv6 is used as defined in the "Terminology" sections of [RFC3315] 📖

2. Background 🌈

in DHCPv6, clients identify themselves to servers using DHCP Unique Identifiers (DUIDs) [RFC3315] 🎀 DUIDs are opaque to DHCP servers, meaning the servers don't look inside them for any structure. They're meant to be globally unique, so no two devices should ever use the same DUID ✨ Three DUID types have been defined so far:

• DUID-LLT: the Link-Layer address of one of the device's network interfaces, plus a timestamp
• DUID-EN: an Enterprise Number plus extra info specific to that enterprise
• DUID-LL: the Link-Layer address of one of the device's network interfaces

DUIDs are supposed to stay constant over time so they work as permanent identifiers for a device. With DUID-LLTs, the timestamp is generated once, saved to stable storage, and reused from then on 🔥

Here's the problem 😭 Some devices use multi-step network boot loading. A first step (usually run from firmware) loads a small image, which loads a second image, and so on, until the real target system is loaded. Each step in that boot process may invoke DHCP. In some environments, every step needs to use the same DUID so the server knows the requests are coming from the same device and can send back the right config (including the pointer to the correct image to load) 💀

Sadly, none of the existing DUID types are ideal for multi-step network booting. The DUID-LLT and DUID-LL identifiers a device may use aren't guaranteed to stay the same across each boot step. Even if every stage used DUID-LL or DUID-LLT, a device with multiple interfaces has no way to guarantee it picks the same interface (and therefore the same DUID) each time. And with DUID-LLT, even if the same interface is picked, it can be hard to make sure every stage uses the same timestamp. A DUID-EN could be defined and used, but that kind of 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 are an existing identifier DHCP could take advantage of. In some environments, a UUID-based DUID is simply better than the other existing DUID types 👑

Heads up though: using a DUID-UUID won't, on its own, solve all the network boot problems described here. Even with a good DUID-UUID available, implementations will still need to take steps so that all boot stages use the same DUID-UUID where appropriate 🫶 And since DHCP already has several DUID types, the question of which one to pick already exists. Defining one more type doesn't help with that by itself. It's believed, though, that network boot services can be configured to use a DUID-UUID, and other software can too. Making sure this happens in general is beyond the scope of this document 🍓

3. UUID Considerations 🔍

lots of UUIDs are in use today, but not all of them meet DHCP's requirements (see Section 9 of [RFC3315]) 🙈 DHCP UUIDs should stay persistent across system restarts, system reconfiguration events, system software and operating system upgrades or reinstallation. They should also be easy for any part of the boot process that needs the DHCP UUID to access. For example, UUIDs used in Microsoft's Component Object Module (COM), and UUIDs used for labeling partitions in filesystems, are likely not appropriate. They may not be accessible to firmware boot loaders, and they can change over time ⚠️

Implementations of this spec using DUID-UUID must select a UUID that persists across system restart and reconfiguration events, and that's available to every DHCP protocol agent that may need to identify itself. 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 this 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

the fields are:

• DUID-Type: DUID-UUID (4), 16 bits
• UUID: an [RFC4122] UUID, 128 bits

5. Acknowledgements 🫶

this doc was inspired by a discussion on the DHC mailing list in November 2009 about netboot for IPv6. Some scenarios were described where it was hard to do something in DHCPv6 that had worked fine in DHCPv4 💖

big thank you to these people for their specific comments and suggestions: Thomas Huth, Andre Kostur, Stephen Jacob, Suresh Krishnan, Ted Lemon, Bernie Volz, and Vincent Zimmer 🌸

6. IANA Considerations 📋

IANA has assigned the value 4 for the DHCPv6 DUID-UUID type ✨

7. Security Considerations 🚨

⚠️ DHCP traffic between a client and server is sent in the clear. An eavesdropper sitting 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 it 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, 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, July 2003.

[RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
           Unique IDentifier (UUID) URN Namespace", RFC 4122,
           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, November 2006.

Authors' Addresses 🧚

Thomas Narten
IBM

EMail: narten@us.ibm.com


Jarrod B. Johnson
IBM

EMail: jarrod.b.johnson@gmail.com

---

That's the whole thing, bestie! 🌈💅 DUID-UUID = UUID energy for DHCPv6, iconic 👑