diff options
Diffstat (limited to 'doc/rfc/rfc6355.txt')
| -rw-r--r-- | doc/rfc/rfc6355.txt | 283 |
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc6355.txt b/doc/rfc/rfc6355.txt new file mode 100644 index 0000000..8ec4770 --- /dev/null +++ b/doc/rfc/rfc6355.txt @@ -0,0 +1,283 @@ + + + + + + +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. + + 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. + +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 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. + + + + + +Narten & Johnson Standards Track [Page 1] + +RFC 6355 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]. 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] 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. + + 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 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]). 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, 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 + + + + + + +Narten & Johnson Standards Track [Page 5] + |