Anonymity Profiles for DHCP Clients
Extracted elements (27)
IA_TA (temporary addresses) is not recommended despite being designed for privacy, because it is not widely supported, lacks defined renewal semantics, and signals a desire for privacy that could invite countermeasures. IA_NA addresses under the anonymity profile are discarded on link-layer address change, fulfilling the same purpose.
The anonymity profiles deliberately avoid including any option that would explicitly identify a client as 'using the anonymity option'. Declaring a preference for privacy is analogous to 'walking around with a Guy Fawkes mask' — it makes the client stand out and could trigger additional surveillance.
The anonymity profiles mandate client identifiers based on the link-layer address (contradicting RFC 4361), because hardware-independent stable identifiers enable efficient cross-network tracking of mobile clients, negating the benefit of MAC address randomization.
The profiles derive DHCP identifiers from the current link-layer address so that DHCP identifiers evolve in synchrony with MAC address randomization. If DHCP identifiers remained stable while the link-layer address changed, the old and new addresses could be trivially correlated.
Clients using the anonymity profile may consume more server resources because old IP addresses remain leased after a link-layer address change and a new address is requested. Some DHCP servers only give addresses to pre-registered MAC addresses, forcing clients to choose between anonymity and connectivity.
Requesting Prefix Delegation (DHCPv6 PD) via IA_PD is a form of fingerprinting until its use becomes widespread; the IAID could identify the client and a prefix hint could reveal previous location. Clients desiring anonymity that request only one prefix SHOULD set IAID to zero and SHOULD NOT include a previously assigned prefix hint.
Clients interested in protecting their privacy MUST ensure that the IAID in the IA_NA option does not enable client identification, and it MUST be constant for the association as long as the link-layer address remains constant.
Clients interested in protecting their privacy SHOULD NOT send Confirm messages and SHOULD instead directly try to acquire addresses on the new link, to avoid revealing previous attachment points via addresses in the Confirm message.
Clients interested in their privacy SHOULD NOT use IA_TA (temporary addresses option, code 4), as it reveals the desire for privacy and may trigger countermeasures, is not widely supported, and addresses obtained via IA_NA under the anonymity profile already serve as de facto temporary addresses.
Clients using the anonymity profile MUST NOT include in the message a Client IP address (ciaddr) that has been obtained with a different link-layer address, to prevent tying two network locations together.
Clients using the anonymity profile SHOULD NOT send the Host Name option; if they do, they MUST send a non-qualified host name (never an FQDN) and MUST obfuscate the host name value.
DHCPv6 clients using the anonymity profile MUST only include server identifier values that were received with the current link-layer address, because the reuse of old values discloses identifying information.
DHCPv6 clients using the anonymity profile SHOULD NOT use the Authentication option (code 11), as it can be used to identify the client and is incompatible with client anonymity.
Nodes visiting untrusted networks MUST NOT send or use the PXE options including the UUID/GUID-Based Client Machine Identifier option (code 97), which carries a 16-octet GUID uniquely identifying the device.
The client intending to protect its privacy SHOULD randomize the ordering of options before sending any DHCPv4 or DHCPv6 message; if random ordering cannot be implemented, the client MAY order options by option code number (lowest to highest).
When stateless address configuration is enabled by Router Advertisement flags, hosts using the anonymity profile SHOULD use stateless address configuration instead of stateful, because it requires fewer information disclosures.
When using stateless DHCPv6, clients wanting to protect their privacy SHOULD NOT include client identifiers in their Information-request messages.
When using the anonymity profile, clients SHOULD NOT use the Requested IP Address option in DHCPDISCOVER messages, to avoid disclosing an IP address used at a previous location or with a different link-layer address.
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, contradicting RFC 4361's recommendation against MAC-based identifiers.
When using the anonymity profile, DHCP clients SHOULD NOT include the Client FQDN option (code 81) in their DHCP requests, as it uniquely identifies the client and may expose location via DNS updates.
When using the anonymity profile, DHCPv4 clients SHOULD NOT use Vendor-Specific Information (code 43), Vendor Class Identifier (code 60), V-I Vendor Class (code 124), or V-I Vendor-Specific Information (code 125) options.
When using the anonymity profile, DHCPv6 clients SHOULD NOT use the User Class option (code 15) or the Vendor Class option (code 16), as these potentially reveal identifying information.
When using the anonymity profile with randomized link-layer addresses, DHCPv6 clients MUST use DUID format number 3 (link-layer address), set to the value currently assigned to the interface.
DHCP options such as Client Identifier, Host Name, Client FQDN, and vendor class options carry unique or quasi-unique identifiers that enable device tracking even when link-layer addresses are randomized. The anonymity profiles minimize disclosure of these identifiers.
Operating system fingerprinting via DHCP option sets, option ordering, and option values can reveal device type, vendor, and OS version, potentially identifying the device or revealing that the anonymity profile is in use. Clients should randomize option ordering and limit the options sent.
The DHCPv6 Confirm message includes previously assigned addresses, allowing an observer to trivially identify a client's previous points of attachment. Clients interested in privacy SHOULD NOT send Confirm messages.
The use of the anonymity profiles does not change the security considerations of the DHCPv4 or DHCPv6 protocols as defined in RFC 2131 and RFC 3315.