RFC 4361

Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)

📅 published February 2006, from ietf

RFC 4361 glow-up era 💖

Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) 🎀

  • Network Working Group 🌸
  • Request for Comments: 4361 📜
  • Authors: T. Lemon (Nominum) and B. Sommerfield (Sun Microsystems) 👯‍♀️
  • Category: Standards Track ✨
  • Date: February 2006 📅
  • Updates: 2131, 2132, 3315 🔧
  • Obsoletes: nothing listed in the title block 🙅‍♀️

Status of This Memo ✨

Okay so this is an Internet standards track protocol doc for the Internet community, and it's literally asking everyone to chime in with discussion and suggestions 🗣️. For the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006).

Abstract 🦋

Bestie, this doc lays out the format that DHCPv4 client identifiers should be encoded in 🧚, so those identifiers can be swapped with the ones used in DHCPv6. It also tackles and fixes some problems in RFC 2131 and RFC 2132 around how DHCP client identifiers get handled 🔥.

Table of Contents 🍓

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Applicability ...................................................2
   4. Problem Statement ...............................................3
      4.1. Client identities are ephemeral. ...........................3
      4.2. Clients can accidentally present multiple identities. ......3
      4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
      4.4. RFC 2131 does not require the use of a client identifier. ..4
   5. Requirements ....................................................4
   6. Implementation ..................................................6
      6.1. DHCPv4 Client Behavior .....................................6
      6.2. DHCPv6 Client Behavior .....................................7
      6.3. DHCPv4 Server Behavior .....................................7
      6.4. Changes from RFC 2131 ......................................8
      6.5. Changes from RFC 2132 ......................................9

   7. Notes on DHCP Clients in Multi-stage Network Booting ............9
   8. Security Considerations ........................................10
   9. References .....................................................10
      9.1. Normative References ......................................10
      9.2. Informative References ....................................10

1. Introduction 🌸

Okay so this doc is all about how Dynamic Host Configuration Protocol Version 4 [RFC2131] clients should identify themselves 🪪. DHCPv4 client implementations that follow this spec use a DHCP Unique Identifier (DUID) as specified in Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] ✨. The DUID gets wrapped up inside a DHCPv4 client identifier option, as described in "DHCP Options and BOOTP Vendor Extensions" [RFC2132] 🎁. The behaviour described here supersedes the behavior specified in RFC2131 and RFC2132 💜.

So why change anything? As we transition from IPv4 to IPv6, there are going to be network devices that need both DHCPv4 and DHCPv6 🔁. Users of those devices get a much smoother experience if the devices identify themselves consistently, no matter which version of DHCP they're using at any given moment 🫶. The most obvious win is that DNS updates the DHCP server makes on behalf of the client get handled more correctly 🌐. This change also fixes certain limitations in how RFC 2131/2132-style DHCP client identifiers work 🔧.

The doc goes in order: first it describes the problem, then the new technique to fix it 🦋. Last, it spells out the specific changes you'd have to make to RFC 2131 and RFC 2132 so those docs don't contradict what's written here 👑.

2. Terminology 📖

So the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💅.

3. Applicability 🧚

This doc updates RFC 2131 and RFC 2132 🔄. It also specifies behavior that is required of DHCPv4 and DHCPv6 clients that are meant to run in a dual-stack configuration 🌈. And finally, it recommends behavior for host configurations where more than one DHCP client has to run in sequence to fully configure the client (for example, a network boot loader and the operating system it loads) 🥾.

DHCPv4 clients and servers built according to this doc should be implemented as if the changes in sections 6.3 and 6.4 have been made to RFC 2131 and RFC 2132 ✨. DHCPv4 clients should, in addition, follow the behavior in section 6.1 💖. DHCPv6 clients should follow the behavior in section 6.2 🎀. DHCPv4 servers should additionally follow the behavior in section 6.3 🫶.

4. Problem Statement 🔥

4.1. Client identities are ephemeral. 🫠

RFC 2132 recommends that client identifiers be generated using the permanent link-layer address of the network interface the client is trying to configure 🔌. The catch is that when the network interface hardware on a client gets replaced, the client's identity changes too 💀. The client loses its IP address and any other resources tied to its old identifier, like its domain name as published through the DHCPv4 server 😭.

4.2. Clients can accidentally present multiple identities. 👯

Picture a DHCPv4 client with two network interfaces, one wired and one wireless 🦋. It might successfully configure zero, one, or two of those interfaces 🤷‍♀️. Under the current spec, each interface gets its own IP address, and the DHCPv4 server treats each interface as a totally independent DHCPv4 client on a totally independent host 🙈.

So when the client sends info to be updated in a network directory service like DNS, the name is the same on both interfaces, but the identity presented is different 🌀. What happens is one of the two interfaces gets the name and keeps it for as long as it has a valid lease, even if it loses its connection to the network 🔒. The other interface never gets the name 💔. Sometimes this works out fine, like when only one interface is connected and its IP address is the one published ✅. But sometimes the connected interface's IP address isn't the one that gets published 😬. With two interfaces, the correct one might get published, or it might not 🎲.

This is likely to be a real problem with modern laptops, which usually have built-in wireless ethernet and wired ethernet 💻. Say the user is near a wired outlet and wants the extra speed and privacy of a wired connection 🔐. That same user might unplug and wander around, still connected through wireless 🚶‍♀️. When that switch happens under the current scheme, if the wired interface's address is the one that gets published, hosts trying to connect to this client will think it has intermittent connectivity 📉. Even though it actually has continuous connectivity through the wireless port 📶. Total mess 💅.

Another common case of duplicate identities happens when a boot monitor, like a Pre-Boot Execution Environment (PXE) loader, specifies one DHCP client identifier, and then the operating system the boot loader loads specifies a different one 🥴.

4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. 🙅‍♀️

The 'client identifier' option is how DHCPv4 clients and servers identify clients 🪪. Sometimes the value of that option is used to mediate access to resources, like the client's domain name as published through the DHCPv4 server 🌐. RFC 2132 and RFC 3315 have different methods for deriving client identifiers 🧩. Those methods guarantee that the DHCPv4 and DHCPv6 identifiers will be different ⚡. So mediating access to resources with these identifiers won't work right when a node gets configured with DHCPv4 in some cases and DHCPv6 in others 💔.

4.4. RFC 2131 does not require the use of a client identifier. 🫥

RFC 2131 lets the DHCPv4 server identify clients either by the client identifier option the client sent or, if the client didn't send one, by the client's link-layer address 🔍. Like the client identifier format RFC 2131 recommends, this one suffers from the problems described in sections 4.2 and 4.3 😩.

5. Requirements ✨

okay so, to fix the problems from section 4, DHCPv4 client identifiers must have these vibes 💅:

  • They must be persistent, in the sense that a particular host's client identifier must not change simply because a piece of network hardware is added or removed. 🔒
  • It must be possible for the client to represent itself as having more than one network identity, for example, so that a client with two network interfaces can express to the DHCPv4 server that these two network interfaces are to receive different IP addresses, even if they happen to be connected to the same link. 🦋
  • In cases where the DHCPv4 client is expressing more than one network identity at the same time, it must nevertheless be possible for the DHCPv4 server to determine that the two network identities belong to the same host. 👑
  • In some cases it may be desirable for a DHCP client to present the same identity on two interfaces, so that if they both happen to be connected to the same network, they will both receive the same IP address. In such cases, it must be possible for the client to use exactly the same identifier for each interface. 🫶
  • DHCPv4 servers that do not conform to this specification, but that are compliant with the older client identifier specification, must correctly handle client identifiers sent by clients that conform to this specification. 🌸
  • DHCPv4 servers that do conform to this specification must interoperate correctly with DHCPv4 clients that do not conform to this specification, except that when configuring such clients, behaviors such as those described in section 2 may occur. 🧚
  • The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet as an identifier must be deprecated. 🍓
  • DHCPv4 client identifiers used by dual-stack hosts that also use DHCPv6 must use the same host identification string for both DHCPv4 and DHCPv6. For example, a DHCPv4 server that uses the client's identity to update the DNS on behalf of a DHCPv4 client must register the same client identity in the DNS that would be registered by the DHCPv6 server on behalf of the DHCPv6 client running on that host, and vice versa. 💜

so for all but the last of these requirements, we need to build a DHCPv4 client identifier out of two parts. One part must be unique to the host the client is running on. The other must be unique to the network identity being presented. The DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) specified in RFC 3315 check both boxes 🎀.

for that last requirement, we have to use the DUID to identify the DHCPv4 client. So, taking all the requirements together, the DUID and IAID described in RFC 3315 are the only possible solution. It's giving main character energy 👑.

by following these rules, a compliant DHCPv4 client will interoperate correctly with both compliant and non-compliant DHCPv4 servers. A non-compliant DHCPv4 client will also interoperate correctly with a compliant DHCPv4 server. If either server or client is not compliant, the goals stated in the document are not met, but there is no loss of functionality. no drama, just less magic ✨.

6. Implementation 🌈

here we spell out the changes to how DHCPv4 clients and servers behave. We also spell out changes to the wording in RFC 2131 and RFC 2132. DHCPv4 clients, servers, and relay agents that conform to this specification must implement RFC 2131 and RFC 2132 with the wording changes specified in sections 6.3 and 6.4.

6.1. DHCPv4 Client Behavior 💖

DHCPv4 clients conforming to this specification MUST use stable DHCPv4 node identifiers in the dhcp-client-identifier option. DHCPv4 clients MUST NOT use client identifiers based solely on layer two addresses that are hard-wired to the layer two device (e.g., the ethernet MAC address) as suggested in RFC 2131, except as allowed in section 9.2 of RFC 3315. DHCPv4 clients MUST send a 'client identifier' option containing an Identity Association Unique Identifier, as defined in section 10 of RFC 3315, and a DHCP Unique Identifier, as defined in section 9 of RFC 3315. These together constitute an RFC 3315-style binding identifier. 🧩

the general format of the DHCPv4 'client identifier' option is defined in section 9.14 of RFC 2132.

to send an RFC 3315-style binding identifier in a DHCPv4 'client identifier' option, the type of the 'client identifier' option is set to 255. The type field is immediately followed by the IAID, which is an opaque 32-bit quantity. The IAID is immediately followed by the DUID, which consumes the remaining contents of the 'client identifier' option. the format of the 'client identifier' option is as follows:

       Code  Len  Type  IAID                DUID
       +----+----+-----+----+----+----+----+----+----+---
       | 61 | n  | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
       +----+----+-----+----+----+----+----+----+----+---

any DHCPv4 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured by both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention. 🎀

DHCPv4 clients that support more than one network interface SHOULD use the same DUID on every interface. DHCPv4 clients that support more than one network interface SHOULD use a different IAID on each interface. 🦋

a DHCPv4 client that generates a DUID and that has stable storage MUST retain this DUID for use in subsequent DHCPv4 messages, even after an operating system reboot. no forgetting your identity after a restart, bestie 🫶.

6.2. DHCPv6 Client Behavior 🌸

any DHCPv6 client that conforms to this specification SHOULD provide a means by which an operator can learn what DUID the client has chosen. Such clients SHOULD also provide a means by which the operator can configure the DUID. A device that is normally configured by both a DHCPv4 and DHCPv6 client SHOULD automatically use the same DUID for DHCPv4 and DHCPv6 without any operator intervention.

6.3. DHCPv4 Server Behavior 🧚

this document does not require any change to DHCPv4 or DHCPv6 servers that follow RFC 2131 and RFC 2132. However, some DHCPv4 servers can be configured not to conform to RFC 2131 and RFC 2132, in the sense that they ignore the 'client identifier' option and use the client's hardware address instead.

DHCPv4 servers that conform to this specification MUST use the 'client identifier' option to identify the client if the client sends it.

DHCPv4 servers MAY use administrator-supplied values for chaddr and htype to identify the client in the case where the administrator is assigning a fixed IP address to the client, even if the client sends a client identifier option. This is ONLY permitted in the case where the DHCPv4 server administrator has provided the values for chaddr and htype, because in this case if it causes a problem, the administrator can correct the problem by removing the offending configuration information. 🍓

the ONLY part is serious business: admins can fix it by just removing the config they added 🙈

6.4. Changes from RFC 2131 🍑

in section 2 of RFC 2131, on page 9, the text that reads "; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name" is deleted. 💅

in section 4.2 of RFC 2131, the text "The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client." is replaced by the text "The client MUST explicitly provide a client identifier through the 'client identifier' option. The client MUST use the same 'client identifier' option for all messages."

in the same section, the text "Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a client's network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box." is replaced by the text "The DHCP client MUST NOT rely on the 'chaddr' field to identify it." 🙅‍♀️

in section 4.4.1 of RFC 2131, the text "The client MAY include a different unique identifier" is replaced with "The client MUST include a unique identifier".

in section 3.1, items 4 and 6; section 3.2 item 3 and 4; and section 4.3.1, where RFC 2131 says that 'chaddr' may be used instead of the 'client identifier' option, the text "or 'chaddr'" and "'chaddr' or" is deleted.

note that these changes do not relieve the DHCPv4 server of the obligation to use 'chaddr' as an identifier if the client does not send a 'client identifier' option. Rather, they oblige clients that conform with this document to send a 'client identifier' option, and not rely on 'chaddr' for identification. DHCPv4 servers MUST use 'chaddr' as an identifier in cases where 'client identifier' is not sent, in order to support old clients that do not conform with this document. this part is the glue that keeps old devices working 🫶.

6.5. Changes from RFC 2132 🌟

the text in section 9.14, beginning with "The client identifier MAY consist of" through "that meet this requirement for uniqueness." is replaced with "the client identifier consists of a type field whose value is normally 255, followed by a four-byte IA_ID field, followed by the DUID for the client as defined in RFC 3315, section 9." The text "its minimum length is 2" in the following paragraph is deleted. ✨

7. Notes on DHCP Clients in Multi-stage Network Booting ✨

okay so bestie, sometimes one device runs more than one DHCP client back to back while it's loading an operating system over the network 💻🌐 The first-stage boot might use a different client identifier than the later stage(s), or maybe no client identifier at all. It's giving plot twist 🧚

Under DHCPv4, that means the two (sometimes more than two!) boot stages show up with different identities 🫣 So the DHCPv4 server hands out two different IP addresses to them. Not iconic for the IP pool 🙈

Some DHCP servers have a little workaround for the common version of this. The boot PROM (Programmable Read Only Memory) sends no client identifier, and the operating system's DHCP client sends one built from the MAC (Message Authentication Code) address of the network interface. The server treats both as the same identifier, so no extra IP address gets eaten 🍓 Clever, right?

BUT here's the tea ☕ A compliant DHCPv4 client does not use a client identifier built from the MAC address of the network interface, because network interfaces are not stable 😬 So a compliant DHCPv4 client can't be supported by that simple hack, and this may have some significant impact at some sites 💀

We can't write the solution to this as a set of requirements, because the situations where this happens vary way too much 🌈 But we can give some suggestions, and I've got them for you 💅

The first suggestion is that DHCP clients in network boot loaders request short lease times, so their IP addresses don't stick around. These clients should send a DHCPRELEASE message to the DHCP server before moving on to the next stage of the boot process 🦋 They should also provide a way for the operating system's DHCP client to configure a DUID to use on subsequent boots. And DHCP clients in the final stage should, where possible, configure the DUID used by the boot PROM to be the same as the DUID used by the operating system 🫶

The second suggestion is for implementors of DHCPv4 clients that are only expected to be used in a multi-stage network boot setup, are never expected to network boot using DHCPv6, and have a MAC address that can't be easily changed. They may not need to implement the changes described in this specification 🌸 There is some danger in assuming that, though. The first solution suggested is definitely better 👑 A compromise could be to have the final-stage DHCP client detect whether it's running on legacy hardware. If it is, it uses the old identifier. If it isn't, it follows the scheme described in the previous paragraph ✨

8. Security Considerations 🔐

Okay, serious moment, but make it cute 🎀 This document raises no new security issues. Potential exposure to attack in the DHCPv4 protocol is discussed in section 7 of the DHCP protocol specification [RFC2131] and in Authentication for DHCP messages [RFC3118]. Potential exposure to attack in the DHCPv6 protocol is discussed in section 23 of RFC 3315.

Go read those sections before you ship anything, periodt 😭

9. References 📚

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          March 1997.

[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.

9.2. Informative References

[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
          Messages", RFC 3118, June 2001.

Authors' Addresses 🦋

Meet the authors, they're literally the reason this exists 🧚

Ted Lemon
Nominum
2385 Bay Road
Redwood City, CA 94063 USA

Phone: +1 650 381 6000
EMail: mellon@nominum.com


Bill Sommerfeld
Sun Microsystems
1 Network Drive
Burlington, MA 01824

Phone: +1 781 442 3458
EMail: sommerfeld@sun.com

The Internet Society holds the copyright for this one, dated 2006 🌈 The document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 💜

The legal fine print, word for word, because it matters:

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed for this technology are valid or how far they go, or whether a license would be available 🙈 It also doesn't say it has searched for those rights itself. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79 📖

Copies of IPR disclosures made to the IETF Secretariat, assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF online IPR repository at http://www.ietf.org/ipr. The IETF also invites anyone to bring to its attention any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 💌

Acknowledgement 🌸

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖

📦 where this page comes from