Summary

  • RFC 9797 explains why randomized or changing MAC addresses can reduce linkability, but cannot guarantee anonymity when accounts, protocol behavior, radio properties or other stable identifiers reconnect the observations.
  • A MAC address is useful for link-layer delivery and may index local state. It is not, by itself, authenticated device or user identity, an authorization credential, or proof that an old policy still applies.
  • A local privacy-continuity receipt should join only the address epoch, trust context, authenticated reference, policy binding, state transition, remaining stable signals, service outcome and expiry needed to explain a decision. This is Daniel Kade’s editorial proposal, not an RFC or IEEE field.

The support ticket says a known laptop returned as a new device. The Wi-Fi controller says the old station disappeared. The DHCP service says it issued a second lease. The access system says the new address has not completed yesterday’s registration. Each statement can be accurate. The mistake begins when any one of them is promoted into an answer to “who is this?”

RFC 9797 is valuable because it refuses that promotion. Published as an Informational RFC from the MADINAS working group, it surveys how randomized and changing MAC addresses affect network operation. The document does not prescribe one rotation timer or one trust model. It describes a tension: persistent link-layer names can expose continuity that a user did not intend, yet networks have accumulated services that quietly depend on that continuity.

That tension is not solved by declaring either permanence or randomization virtuous. It is solved by separating six claims that operational systems often compress into one field: the forwarding name in force on a link, the ability to connect observations over time, the authenticated identity of a device or person, the policy that authorizes an action, the continuity of service state, and the outcome produced by running code.

A forwarding address is a local name, not a biography

A MAC address allows a link to deliver frames to an interface within its local context. ARP for IPv4, Neighbor Discovery for IPv6, DHCP state and switch forwarding all make that address operationally visible. Because many devices historically used stable addresses, operators found it convenient to treat the value as a durable key. A reservation, captive-portal decision, accounting row, quality-of-service class, abuse note or support history could all point to it.

Convenience does not add assurance. The address is normally observed rather than cryptographically proven. It can change because of privacy behavior, interface replacement, virtualization, configuration or software. It can be copied or spoofed. One physical device can present several addresses, and several physical or virtual endpoints can present the same address at different times or, through error or attack, on the same link.

“This address was observed” is therefore a precise claim. “This is the same device” requires more evidence. “This is the same user” requires a different identity chain. “This device may receive this service” requires a current authorization decision. A record system that uses the MAC as its first lookup key may still be well designed, but only if it preserves these boundaries instead of borrowing the confidence of an authentication system it never consulted.

RFC 9797’s governance consequence is subtle. Randomization exposes a pre-existing modeling error; it does not create it. A network that breaks when the index changes had already fused delivery, identity and policy. The change merely makes the fusion visible.

Randomization removes one correlation handle, not every one

Changing a MAC address can make two link observations harder to associate. The benefit is strongest when an address is not reused across unrelated networks or over a long interval, and when the rotation does not carry another equally stable label beside it. An observer that previously joined records on a persistent address loses that particular join.

But the packet does not become context free. A device may expose an account login, certificate, DHCP option, hostname, stable IPv6 identifier, application token, radio characteristic or recognizable traffic pattern. Timing and movement can reconnect sessions. A captive portal can ask the user to identify again. A managed device can deliberately present a credential so the network can apply policy without recovering a permanent link-layer name.

RFC 7217 and RFC 8981 are useful reminders that identifier stability exists above the MAC layer too. Stable, semantically opaque interface identifiers limit some forms of address scanning and correlation; temporary IPv6 addresses change other exposure. Neither means that changing one layer dissolves all continuity. Privacy analysis must inventory every stable signal available to the relevant observer, not celebrate the rotation of the most visible one.

The inverse error is just as serious. A stable MAC does not prove that later traffic belongs to the same physical device, much less the same person. It provides linkability, not authenticity. Linkability can be operationally useful and privacy costly at the same time. Calling it identity conceals both properties.

Trust is contextual, not a setting attached to the radio forever

RFC 9797 discusses different degrees of trust because an address policy that is sensible in one network can be harmful in another. A personal device may disclose more continuity to a managed enterprise network whose security policy it has accepted, less to a venue that needs temporary access, and almost none to a network it has never joined. The device can also distinguish scanning from association and one network profile from another.

These are decisions, not universal states. “Full trust” should not become a demand for permanent correlation outside the purpose that created it. “Zero trust” should not become an excuse to ignore all authenticated evidence and repeatedly challenge a user. Selective trust requires the hardest work: naming which service needs continuity, which credential supplies it, how long the join may last and which observers may see it.

The operator and device also see different risks. A user worries that stable radio identifiers can connect visits and locations. An operator worries that a rotating identifier can evade rate limits, duplicate scarce state, lose a paid entitlement, obscure an abuse investigation or defeat a support workflow. Both risks are real. Neither grants a right to turn a convenient address history into a permanent cross-context dossier.

The defensible unit of policy is an address epoch in a named context. It has a start, an end, a network scope, a stated purpose and an accountable decision. Persistence beyond that boundary needs its own justification.

State continuity must be rebuilt deliberately

Many operational failures attributed to randomization are really failed state transitions. A DHCP server leaves an old lease and allocates another. A switch or wireless controller keeps a stale station record. A captive portal treats the endpoint as unregistered. An accounting system begins a second session. A quality-of-service rule remains tied to the prior address. A help-desk view shows two devices and sends the technician to the wrong history.

None of these outcomes proves that randomization is defective. They show that a service bound continuity to a name whose lifecycle it did not control. The correct repair depends on the service. Some state should expire with the address. Some can be reconstructed from an authenticated credential. Some should be transferred only after a fresh authorization check. Some, such as a short-lived forwarding entry, need no continuity at all.

Resilience work described by RFC 3539 is relevant here: systems should distinguish a transient change in an identifier from loss of the underlying service authority. DHCP, Neighbor Discovery and address resolution have their own clocks and failure modes. Authentication and authorization have others. Merging them into one “known device” bit creates an attractive dashboard and an untestable contract.

A state migration also needs a negative proof. If the new epoch inherits a paid entitlement, quarantine exception or administrative role, what prevents another endpoint from claiming the same transition? The answer cannot be “it had the right old MAC,” because that repeats the original error. The binding must come from an authenticated principal, device credential, possession proof or another assurance mechanism appropriate to the risk.

A privacy-continuity receipt keeps the join small

The editorial proposal here is a privacy-continuity receipt. It is local, short lived and purpose limited. It begins with the address epoch: network context, interface or session reference, observed MAC value, start and end, and the mechanism that caused rotation where known. It records the trust context without pretending that trust is global.

The receipt then keeps identity and authority separate. An authenticated principal or device reference may be present, but the credential itself need not be copied. The record identifies the assurance source, policy version, decision, scope and expiry. If there is no authenticated reference, the receipt says so. Absence is more truthful than upgrading an observed address into identity.

The continuity section names the state that was expired, rebuilt or transferred: lease, portal session, accounting context, rate limit, access role, support record or another bounded object. It records the transition result and the service outcome observed afterward. It also lists only the stable signals material to the privacy decision—for example, whether a persistent higher-layer token made the rotation ineffective—without collecting a general behavioral fingerprint.

Finally, the receipt expires. Its retention follows the service purpose, not the theoretical ability to correlate forever. Access is limited to the teams that own the decision. Aggregated measurements may show how often rotation breaks service, but the local joins should not be exported into a universal identity graph.

This is not a protocol extension, an IETF requirement or an IEEE data structure. It is a discipline for refusing two false verdicts: “new MAC, new person” and “same MAC, same authority.”

The standard is guidance; the outcome belongs to running code

RFC 9797 has no IANA actions and does not prove that a vendor, device class or operator has deployed any particular behavior. IEEE 802.11bh addresses enhanced service with randomized and changing MAC addresses in the IEEE 802.11 family, but a standards amendment is still not evidence of a specific implementation or local policy.

The IETF can describe the problem and the interactions. Device software chooses and executes an address policy. A network chooses what continuity it needs and which credential can supply it. Application and identity systems expose or avoid other stable signals. Operators observe whether access, accounting, troubleshooting and privacy objectives actually hold.

Heng Lu’s distinction between specification, localized decision, voluntary adoption and running code prevents a category error here. A document can make a behavior legible. It cannot establish what happened on one link. A configured policy can express intent. It cannot prove that state migrated, that a user remained unlinkable, or that a service was delivered. Those conclusions need local evidence at the relevant time.

The lasting lesson is not “rotate every address” or “preserve every address.” It is that continuity is an explicit grant. A network should retain exactly the join necessary for a stated service, obtain it from evidence suitable to the decision, measure the outcome, and let it end.

Sources