Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
Extracted elements (21)
A multi-interface host (e.g., wired + wireless laptop) presents multiple DHCP identities under RFC 2131/2132, causing inconsistent DNS registration and IP address assignment. A node-level identifier shared across interfaces solves this.
Client identifiers based on link-layer (MAC) addresses are ephemeral: replacing network interface hardware changes the client identity, causing loss of IP address and DNS registrations. This motivated a move to node-stable identifiers.
RFC 2131 permits servers to fall back to chaddr when no client identifier option is present, inheriting all the instability problems of link-layer addresses. This document requires clients to always send a client identifier.
RFC 2132 (DHCPv4) and RFC 3315 (DHCPv6) derive client identifiers by incompatible methods, guaranteeing DHCPv4 and DHCPv6 identifiers for the same host will differ. This breaks resource mediation (e.g., DNS updates) on dual-stack hosts.
The DUID (host-unique) and IAID (interface-unique) from RFC 3315 are the only constructs that simultaneously satisfy all requirements: persistent host identity, per-interface differentiation, and dual-stack DHCPv4/DHCPv6 consistency.
A compliant DHCPv4 client interoperates correctly with both compliant and non-compliant servers. A non-compliant client interoperates correctly with a compliant server. Functionality is not lost if either side is non-compliant, but the node-identity goals are not met.
Multi-stage network booting (e.g., PXE loader followed by OS DHCP client) may present different client identifiers at each stage, causing the DHCPv4 server to allocate separate IP addresses. Boot loaders should request short leases and send DHCPRELEASE before handing off.
The existing server workaround of treating a missing client identifier as equivalent to a MAC-based identifier does not apply to compliant clients, since compliant clients never use MAC-based identifiers; sites must adopt proper multi-stage DUID coordination instead.
A device configured by both DHCPv4 and DHCPv6 clients SHOULD automatically use the same DUID for both protocols without operator intervention, ensuring consistent host identification across address families.
A DHCPv4 client that generates a DUID and has stable storage MUST retain the DUID for use in subsequent DHCPv4 messages, even after an operating system reboot.
Any conforming DHCPv4 or DHCPv6 client SHOULD provide a means for an operator to learn the client's DUID and SHOULD provide a means to configure it.
DHCPv4 clients conforming to this specification MUST use stable DHCPv4 node identifiers in the dhcp-client-identifier option and MUST NOT use client identifiers based solely on layer-two addresses hard-wired to the device.
DHCPv4 clients MUST send a 'client identifier' option (option 61) containing an IAID (as defined in RFC 3315 section 10) immediately followed by a DUID (as defined in RFC 3315 section 9), with the type field set to 255.
DHCPv4 clients supporting more than one network interface SHOULD use the same DUID on every interface and SHOULD use a different IAID on each interface.
DHCPv4 servers conforming to this specification MUST use the 'client identifier' option to identify the client whenever the client sends one; they MUST NOT ignore it in favor of chaddr.
DHCPv4 servers MAY use administrator-supplied chaddr and htype to identify a client for fixed-IP assignment even when a client identifier option is present, but ONLY when the administrator explicitly configured those values.
DHCPv4 servers MUST still use 'chaddr' as the identifier when no 'client identifier' option is sent, in order to support legacy clients that predate this specification.
The DUID (DHCP Unique Identifier), defined in RFC 3315 section 9, is adopted as the node-level stable identifier for DHCPv4 clients. It is embedded in the 'client identifier' option after the type byte and IAID.
The IAID (Identity Association Identifier), defined in RFC 3315 section 10, is a 4-byte opaque quantity that distinguishes per-interface identities within a single host's DUID, allowing multiple IP addresses for the same node.
This document raises no new security issues. Existing DHCPv4 attack exposure is discussed in RFC 2131 section 7 and RFC 3118; DHCPv6 attack exposure is discussed in RFC 3315 section 23.
The DHCPv4 'client identifier' option (code 61) encoding an RFC 3315-style binding identifier has: 1-byte type=255, 4-byte opaque IAID (i1–i4), followed by the variable-length DUID consuming all remaining option bytes.