ietf-corpus

rfc-6842

Client Identifier Option in DHCP Server Replies

N. Swamy, G. Halwasia, P. Jhingran
date2013-01 streamIETF areaint wgdhc statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc6842 doi10.17487/RFC6842
This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]

updates

Extracted elements (10)

design-rationale §2

The original RFC 2131 prohibition on returning the 'client identifier' option was made purely to conserve the limited space in the DHCP packet. The benefit of including it now outweighs any small risk that legacy clients might drop packets containing this formerly unexpected option.

ip

design-rationale §2

The solution aligns DHCP (DHCPv4) behavior with DHCPv6 (RFC 3315), where the server always includes the Client Identifier option in Reply messages, providing consistency across protocol versions.

ip

interoperability-note §2

DHCP relay agents and servers implementing RFC 2131 MAY drop DHCP packets in the absence of both the 'client identifier' and 'chaddr' option. When a client sets 'chaddr' to all zeroes (e.g., mobile devices) and the server omits 'client identifier' in replies, relay agents may drop valid downstream DHCPOFFER, DHCPACK, and DHCPNAK packets.

ip

interoperability-note §2

The absence of the 'client identifier' option in DHCP reply messages affects scenarios where multiple DHCP clients run on the same host sharing the same 'chaddr', as there is no way to distinguish which client a reply targets.

ip

interoperability-note §2

The 'xid' field alone cannot guarantee that a particular DHCP response is intended for a particular client, because 'xid' values generated by multiple clients within a subnet need not be unique. Without 'client identifier', a client with 'chaddr' set to zero cannot confirm a response is intended for it.

ip

normative-requirement §3 MUST

If the 'client identifier' option is present in a message received from a client, the server MUST return the 'client identifier' option, unaltered, in its response message.

dns, ip

normative-requirement §3 MUST NOT

The server MUST NOT return the 'client identifier' option in DHCPOFFER, DHCPACK, or DHCPNAK messages if the client did not send the option.

ip

normative-requirement §3 MUST

When a client receives a DHCP message containing a 'client identifier' option, the client MUST compare that client identifier to the one it is configured to send. If the two client identifiers do not match, the client MUST silently discard the message.

ip

protocol-element §2

The 'client identifier' option, when sent by the client, serves as a unique identifier for the client's lease in combination with the assigned network address. When 'chaddr' is all zeroes, this option is the sole means of uniquely identifying the client within a subnet.

ip

security-consideration §4

DHCP clients have no a priori knowledge of which network they are connecting to, so the client identifier will routinely be shared with network operators and could be used in ways that violate user privacy. This pre-existing privacy issue from RFC 2131 is not addressed by this document.

security, privacy, ip