Summary

  • RFC 7844 defines a DHCP anonymity profile, not an anonymous address. DUID, IAID, previous-address hints, server identifiers, FQDN and class options can reconnect a supposedly fresh attachment to an older one.
  • Option choice and order can fingerprint an implementation even when explicit names are absent. The profile minimizes requests and varies their order so privacy implementations do not advertise themselves through a common mistake.
  • Coordinated forgetting has costs: servers may retain unused state, address pools and binding tables may work harder, and networks that require preregistered devices may refuse access. It reduces selected DHCP correlations; it does not promise invisibility.

The address changed; the client did not

Address randomization is visually persuasive. One value disappears, another replaces it, and a packet trace appears to show two different devices. RFC 7824, the analysis that preceded the solution, asks what else crossed the boundary unchanged.

DHCP carries more than an address request. In DHCPv6, a DUID identifies the client to the server. An IAID distinguishes identity associations within that client. A Client FQDN may name the host. User Class and Vendor Class options can describe its role or implementation. The Option Request Option records what information the client wants, and its ordering may be characteristic. A requested old address can disclose where the same client was attached before.

The problem is not that every one of these fields is always globally unique. Correlation needs less. A stable DUID plus a rare option pattern may be enough to join two observations with high confidence. A DUID type that contains a link-layer address can undo the protection of a newly randomized wireless address directly. The observer does not need to learn the owner's civil identity to learn that the two visits likely came from the same device.

Huitema, Tomek Mrugalski and Suresh Krishnan answered with RFC 7844 in 2016. Their object was deliberately narrower than invisibility. They defined a common client profile for reducing DHCP disclosures when a user chooses anonymity. The shared profile matters because nine different attempts at privacy can create nine new fingerprints.

DUID and IAID need a boundary, not a myth

Ordinary DHCPv6 behavior values stable identifiers. Stability helps a server recognize a returning client, renew state and offer continuity. Privacy changes the purpose of the transaction. If a client adopts a new link-layer identity yet retains the old DUID, the stable value becomes a bridge between the two appearances.

RFC 7844 therefore ties identifier treatment to the link transition. With randomized link-layer addresses, the DHCP identity must not silently outlive the identity it was meant to accompany. The profile also specifies randomized DUID behavior for relevant cases without link-layer randomization. The current DHCPv6 base specification, RFC 9915, preserves the general expectation of DUID stability while explicitly recognizing the RFC 7844 exception. There is no contradiction: identifiers are stable within one operating contract and deliberately replaced under another.

IAID has a smaller scope but the same evidentiary risk. It must not be constructed as a permanent machine signature. Its useful stability belongs to the current link-layer association. Calling either field “just a number” hides the operational question: stable for whom, across which change, and for what service?

Old addresses and server identifiers require the same discipline. Asking for a previously held address can reduce disruption, but it supplies a direct continuity hint. Reusing cached server state from another link can reveal the older context. In the anonymity profile, stored addresses are cleared when the link-layer address changes. The client trades a convenient reunion for a cleaner break.

A list can identify without naming

The most interesting fingerprint may contain no identifier at all. DHCP clients ask for different combinations of configuration options. Their implementations may put those requests in a stable order. RFC 7824 explains how the set and sequence can disclose an operating-system family or client implementation.

RFC 7844's response is restrained. Ask for a minimal subset. Avoid replaying cached option values. Vary the order. Do not send User Class, Vendor Class, vendor-specific information or Client FQDN merely out of habit. A narrowly local FQDN can be useful, but it must not become a portable name that defeats the mode.

This is a form of minimum specification. The standard does not ask every client to emit a grand declaration of privacy. It reduces the amount and regularity of what they emit. Huitema and his coauthors specifically reject a dedicated anonymity flag: the client that announces “I want anonymity” may become the easiest client to single out, block or watch.

The same caution explains their treatment of temporary-address machinery. An uncommon option can expose the privacy intent through sparse deployment or uneven implementation. A feature with a privacy-shaped name is not automatically the most private signal on the wire.

What the profile cannot erase

RFC 7844 leaves radio fingerprinting outside its scope. Hardware behavior, traffic timing, application accounts and other protocols can preserve correlation. That admission strengthens the standard. It names the boundary rather than converting one protocol improvement into a total claim about the user.

The operational costs are equally real. A server that cannot recognize the returning client may keep the old allocation until its lease expires and create new state for the fresh identity. Frequent changes can increase consumption of addresses or binding-table entries. A network that only admits preregistered link-layer addresses may deny connectivity. Stateful services that relied on client recognition can lose continuity.

These outcomes do not prove the profile is broken. They reveal competing purposes. The server wants economical state and predictable return. An admission system wants a stable handle. The user may want two visits not to be joined. RFC 7844 assigns the choice to the user and describes the consequences instead of pretending that one identifier policy satisfies every party.

Huitema's contribution was a profile of restraint

The IETF's profile for Christian Huitema records decades of standards work and identifies privacy and QUIC among his later interests. His own account describes a career across transport, naming and security, with the free flow of information as a recurring concern. RFC 7844, however, is not a solitary invention. Mrugalski and Krishnan are coauthors, and its analysis rests on the wider DHCP community's work in RFC 7824.

The useful historical point is a method. A protocol can disclose identity through the conjunction of modest fields. Repair therefore begins by inventorying every observation surface, defining a synchronized boundary and refusing to promise more than the running mechanism can deliver.

A field is not a person, and a stable identifier is not ownership. It is a receipt emitted under a particular policy. Huitema's anonymity profile asks operators to read that receipt at the right scope—and asks clients to stop carrying it across a boundary where it no longer serves the user's purpose.

Sources