We discussed this in the context of the DHCP Anonymity profile, which is meant to be used in conjunction with MAC Address Randomization:
http://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-03
That document is currently in last call.
The text on the Client ID says:
In contradiction to [RFC4361], when using the anonymity profile, DHCP
clients MUST use client identifiers based solely on the link layer
address that will be used in the underlying connection. This will
ensure that the DHCP client identifier does not leak any information
that is not already available to entities monitoring the network
connection. It will also ensure that a strategy of randomizing the
link layer address will not be nullified by DHCP options.
From: Daniel Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 3, 2015 10:02 AM
To: STDS-802-PRIVACY@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-Privacy] On the DHCP client identifier
Yesterday during the call there was some discussion on whether the DHCP
client identifier (which we have been using on the trials to ensure the
same IP address is leased to a client even if it changes its MAC
address, just for the sake of having more information about trial
participants) is an optional or mandatory field.
I've checked it and it is optional. RFC 2131 says:
"DHCP defines a new 'client identifier' option that is used to pass an
explicit client identifier to a DHCP server. This change eliminates
the overloading of the 'chaddr' field in BOOTP messages, where
'chaddr' is used both as a hardware address for transmission of BOOTP
reply messages and as a client identifier. The 'client identifier'
is an opaque key, not to be interpreted by the server; 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. The 'client identifier' chosen by a
DHCP client MUST be unique to that client within the subnet to which
the client is attached. If the client uses a 'client identifier' in
one message, it MUST use that same identifier in all subsequent
messages, to ensure that all servers correctly identify the client."
Yes, it appears to be optional but if it’s used it MUST not change in
subsequent messages. Now how to interpret that? If I change my
MAC address am I now a “new” DHCP client and free to decide
whether or not to include a client identifier? And if so, and if I decide
to include it am I free to make it a new opaque string? That is, I am
not bound to use the client identifier I used with my old MAC address?
My feeling is yes to all of those. Because if I choose not to include
the client identifier the server will use the chaddr as the identifier
and if I change MAC addresses I’m going to change chaddrs in
subsequent offers and therefore the server would not associate
me with my previous incarnation. The intent, as I read, it is to
provide continuity across DHCP sessions for a single client on the
network. If you change your MAC address you’re not that client
anymore even if you do include client identifiers in your offers.
If this seems reasonable perhaps an update to RFC 2131 is in order
just to eliminate any potential confusion.
I've also looked at what my Linux box does. Unless I specify a value
for the dhcp-client-identifier, DHCP requests does not include this
option. If I explicitly indicate an identifier, it is included in the