RFC 9797

Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases

📅 published June 2025, from ietf

RFC 9797: Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases 🦋

Okay bestie, the title block is the vibe check, so here it is first. This is an Informational RFC from the IETF 📚, published June 2025 ✨. It was written by J. Henry (Cisco Systems) 💖 and Y. Lee (Comcast) 🫶. It lives in ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here 🌸.

Abstract ✨

Okay so, devices get tracked by their MAC address, and that's a huge privacy problem in IEEE 802 networks 😭. Like, the link between a device, what it's doing, where it is, and who's using it is a lot. So client vendors and client OS vendors started doing MAC address randomization 🎀 to fix it. It matters most on Wi-Fi (defined in IEEE 802.11) because the air is shared and devices move around all the time 📶. The catch is that when the address changes, some in-network state can break, and that can mess with connectivity and the user experience 💀. Also, devices might keep sending other stable identifiers, which totally defeats the point of randomizing 🙈.

This document lists the network environments and network services that randomization can affect 🧚. Then it looks at the situations where in-network state breaking hurts the user experience 💅. Last, it checks out some existing frameworks that keep users private while still giving them a good experience and keeping the network running efficiently 👑.

Status of This Memo 📜

This document isn't an Internet Standards Track spec. It's published for information, so no pressure 🌈.

This document is a product of the Internet Engineering Task Force (IETF) 💜. It reflects what the IETF community agreed on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🧐.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9797 🔗.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document have to include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Revised BSD License ⚖️.

Table of Contents 📑

   1.  Introduction
   2.  MAC Address as Identity: User vs. Device
     2.1.  Privacy of MAC Addresses
   3.  The Actors: Network Functional Entities and Human Entities
     3.1.  Network Functional Entities
     3.2.  Human-Related Entities
   4.  Degrees of Trust
   5.  Environments
   6.  Network Services
     6.1.  Device Identification and Associated Problems
   7.  IANA Considerations
   8.  Security Considerations
   9.  Informative References
   Appendix A.  Existing Frameworks
     A.1.  IEEE 802.1X with WPA2 / WPA3
     A.2.  OpenRoaming
     A.3.  Proprietary RCM Schemes
   Authors' Addresses

1. Introduction 🌸

Okay so, the MAC address was first made for wired Ethernet networks [IEEE_802.3], back when it was introduced in [IEEE_802] 🔌. Wired devices mostly stayed put, and the physical cable acted like a fence that kept attackers from easily getting at the network data 🚧. Then [IEEE_802.11] (Wi-Fi) showed up and brought a whole new set of problems 😬.

Wi-Fi is seriously the main character now 👑. Laptops, tablets, and Internet of Things (IoT) devices basically run on it, and sometimes it's the only option they've got 📱. But it's an over-the-air medium, so attackers with surveillance gear can watch WLAN packets and track what WLAN devices are doing 👀. Sometimes attackers can also watch the WLAN packets behind the Wi-Fi Access Point (AP) over the wired Ethernet 🔎. Once a device gets linked to its user, figuring out the device and its activity is enough to work out what the user is up to, and they never agreed to that 😤.

To lower the risk of identifying a device just by its MAC address, client OS vendors started using Randomized and Changing MAC addresses (RCM) 🎀. Randomizing the MAC address makes it harder to use it to build a lasting link between a flow of data packets and a device, as long as no other visible unique identifiers or stable patterns are being used 🧩. When devices aren't easy to spot anymore, it's also way harder to tie a bunch of network flows over a long stretch of time to one specific person using one specific device, if the device randomizes its MAC address under the OS privacy policies 🦋.

Real talk though, those address changes can mess with the user experience and with legitimate network operations too 😭. For a long time, network designers and implementers assumed that a given machine on a network using IEEE 802 technologies [IEEE_802] would have one unique network MAC address that never changed 🔒. Once that assumption breaks, network communication can get disrupted 💥. For example, sessions between the end device and network services can break, and packets in transit can suddenly disappear 😱. If lots of clients do aggressive MAC address randomization (e.g., once an hour or even more often) without coordinating with network services, some services, like MAC address caching in the AP and the upstream Layer 2 switch, might not be able to keep up with the load. That can cause an unexpected network interruption 📉.

At the same time, some network services depend on the end station (as defined by [IEEE_802]) to hand over an identifier. That identifier can be the MAC address or something else 🪪. This document also calls the end station a "device" or "machine" 🤖. If a client randomizes its MAC address but keeps sending the same static identifier, then the link between that stable identifier and the station survives even with RCM in place 🙈. Some environments might actually want that continuity, but in others, user privacy is worth more than keeping network service state continuous 💜.

So it's useful for client and network device implementations to list the services RCM might affect, and to evaluate frameworks that keep the user experience and network efficiency good while RCM is happening and privacy gets stronger 🌈. That's what this document does, and it also shares the assessments and recommendations 🫶.

Although this document mainly talks about MAC address randomization in Wi-Fi networks [IEEE_802.11], the same principles can easily carry over to any IEEE 802 network [IEEE_802] 🌍.

This document is organized as follows 📋:

  • Section 2 discusses the current status of using MAC address as identity.
  • Section 3 discusses various actors in the network that will be impacted by MAC address randomization.
  • Section 4 examines the degrees of trust between personal devices and the entities at play in a network domain.
  • Section 5 discusses various network environments that will be impacted.
  • Section 6 analyzes some existing network services that will be impacted.
  • Appendix A includes some existing frameworks.

Part 1 of 7 💖 more parts are coming, bestie 🎀

2. MAC Address as Identity: User vs. Device ✨

okay so bestie, in [IEEE_802] land, the Media Access Control (MAC) layer is the bouncer 💅 It sets the rules for how each device gets to use the shared medium. On a network where a machine can talk to one or more other machines, every machine needs to be identified as either the target destination of a message or the source of a message (and the target destination of the answer). The first versions of IEEE 802 gave each address 48 bits (6 octets). Other standards under the IEEE 802 [IEEE_802] umbrella allow an extended 64-bit (8-octet) format, which made room for way more MAC addresses as IEEE 802 technologies blew up 🚀

Regardless of address length, different networks have different needs, so several bits of the first octet are reserved for specific jobs 🎀 The first bit tells you whether the destination address is an individual (bit set to 0) or a group address (bit set to 1). The second bit is the Universal/Local (U/L) address bit, which says whether the address was handed out by a universal administrator or a local one. Universally administered addresses have this bit set to 0. If the bit is set to 1, the whole address is locally administered (see Clause 8.4 of [IEEE_802]). Universally administered MAC addresses are required to be registered with the IEEE, while locally administered ones are not 🦋

Here's why that bit matters so much for this doc 🫶 [IEEE_802] knows some devices (e.g., smart thermostats) may never change their attachment network, so they won't need a globally unique MAC address to avoid colliding with some other device on some other network. Setting the U/L bit to 1 signals to the network that the MAC address is meant to be locally unique (not globally unique). [IEEE_802] didn't originally define the allocation scheme for when the U/L bit is set to 1. It just says the address has to be unique within a given broadcast domain (i.e., the space where devices' MAC addresses are visible to one another) 🌈

Also, the whole point of the universal version was to avoid collisions and confusion 😭 Any machine can connect to any network, and each machine has to figure out whether it's the intended destination of a message or its response. Clause 8.4 of [IEEE_802] reminds designers and operators that every potential member of a network needs a unique identifier in that network, otherwise they can't coexist without mixing up who's the source or destination of a message. The perk of an administered address is that a node holding one can plug into any Local Area Network (LAN) in the world and be sure its address is unique on that network 💖

Then wireless and mobile devices exploded, and this became super common 📱 Most networks use IEEE 802 radio technologies [IEEE_802] at the access, so a wireless device's MAC address can show up anywhere on the planet, and collisions still need to be avoided. Meanwhile, the same evolution gave us two kinds of devices that [IEEE_802] usually calls "nodes in a network" (see Section 6.2 of [IEEE_802E] for the definitions) 👑

  • Shared Service Device: A device used by so many people that the device itself, its functions, or its traffic can't be tied to one person or a small group 🏢 Examples include switches in a dense network, (WLAN) access points [IEEE_802.11] in a crowded airport, and task-specific devices (e.g., barcode scanners).
  • Personal Device: A machine or node mainly used by one person or a small group, so any identification of the device or its traffic can also be linked to the identity of the primary user or their online activity 🧚

Identifying the device is trivial if it has a unique MAC address 🔍 Once that unique address is established, detecting any elements that directly or indirectly identify the device's user (i.e., Personally Identifiable Information (PII)) is enough to link the MAC address to that user. After that, any traffic detected as coming from the device is also linked to the known user of that device (i.e., Personally Correlated Information (PCI)). Yikes 💀

2.1. Privacy of MAC Addresses

This identification is a privacy problem, especially with wireless tech 🙈 For most of it ([IEEE_802.11] in particular), the source and destination MAC addresses aren't encrypted, even on networks that do encrypt. That lack of encryption lets each machine quickly check whether it's the intended target of a message before it tries to decrypt the content, and it also helps identify the transmitter so the right decryption key gets used when multiple unicast keys are in effect 🔑

Linking a user to a node was never the goal of the IEEE 802 MAC address 😤 The obvious fix is to use a locally administered address instead and change it in a way that stops any continuous association between one MAC address and some PII. The catch is that other network devices on the same LAN that implement a MAC layer also expect each device to keep a MAC address that persists over time 🥺 If a device changes its MAC address, the other devices on the same LAN may not recognize that the same machine is trying to talk to them. This type of address is called a 'persistent' MAC address in this document.

It gets messier 🌀 Authentication, Authorization, and Accounting (AAA) services [RFC3539] authenticate the user of a machine and then tie the authenticated user to the device MAC address. Other services only care about the machine (e.g., DHCPv4 [RFC2131]), but they still expect each device to use a persistent MAC address, for example, to hand the same IP address back to a returning device. Changing the MAC address may disrupt these services 🌸

3. The Actors: Network Functional Entities and Human Entities 🎭

The risk of service disruption has to be weighed against the privacy benefits 🤔 But with so many actors in the exchanges, the lines get super blurry about which privacy violations should be protected against. So it's useful to list the actors involved in these exchanges, because they either actively take part in them or can observe them. Some actors are functional entities, and others are human (or related) entities 💜

3.1. Network Functional Entities

Network communications based on IEEE 802 technologies usually rely on station identifiers based on a MAC address. Several types of network functional entities use this MAC address, such as applications or devices that provide a service related to network operations 🛠️

  1. Wireless access network infrastructure devices (e.g., WLAN access points or controllers): These devices take part in IEEE 802 LAN operations. That means they need to identify each machine as a source or destination to keep exchanging frames successfully 📡 When a device changes its network attachment (roams) from one access point to another, the access points can swap contextual information (e.g., the device MAC address and keying material), so the device's session keeps going seamlessly 🦋 These access points can also tell devices further along in the wired network about the roam, so Layer 2 frames get redirected to the device's new access point.
  2. Other network devices operating at the MAC layer: Lots of wireless network access devices (e.g., access points [IEEE_802.11]) are built as Layer 2 devices, so they bridge a frame from one medium (e.g., Wi-Fi [IEEE_802.11]) to another (e.g., Ethernet [IEEE_802.3]) 🌉 That means a wireless device's MAC address often shows up on the wire beyond the wireless access device. The devices on that wire also implement IEEE 802.3 technologies [IEEE_802.3], so they operate on the expectation that each device has a MAC address that persists for the whole duration of continuous exchanges. For example, switches and bridges tie MAC addresses to individual ports (so they know which port to send a frame to for a particular MAC address) 🔀 Similarly, AAA services can validate a device's identity and use the device MAC address as the first pointer to that identity (before doing further verification). Some networking devices also offer Layer 2 filtering policies that may rely on the connected MAC addresses 🧱 IEEE 802.1X-enabled devices [IEEE_802.1X] may selectively put an interface in a blocking state until the connecting device is authenticated. These services then use the MAC address as the first pointer to the device identity to allow or block data traffic. This list isn't exhaustive 🌟 Multiple services are defined for Ethernet networks [IEEE_802.3], and multiple services defined by the IEEE 802.1 working group also apply to Ethernet networks [IEEE_802.3]. Wireless access points may also connect over other mediums (e.g., the Data-Over-Cable Service Interface Specification (DOCSIS) [DOCSIS]) that use mechanisms under the umbrella of the general 802 Standard, and therefore they expect the unique and persistent association of a MAC address to a device 💅
  3. Network devices operating at upper layers: Some network devices provide functions and services above the MAC layer, and some of them also run a MAC layer function too 🏗️ Routers, for example, provide IP forwarding services but rely on the device MAC address to build the right frame structure. Other devices and services operate at upper layers but still depend on the IEEE 802 principles of unique MAC-to-device mapping. For example, the Address Resolution Protocol (ARP) [RFC826] and Neighbor Discovery Protocol (NDP) [RFC4861] use a MAC address to map an IP address to a MAC address for packet forwarding 🗺️ If a device changes its MAC address without a mechanism to notify the Layer 2 switch it's connected to, or the provider of a service that expects a stable MAC-to-device mapping, then the service provider and the traffic forwarding may be disrupted 😱

Humans can be deeply involved in network structure and operations, or they can just be observers at any point in the network lifecycle 👀 Humans could be users of wireless devices (hi, that's us 💅) or people operating wireless networks.

  1. Over-the-Air (OTA) observers: okay this one is lowkey wild 😭 The transmitting or receiving MAC address is usually not encrypted in wireless exchanges using IEEE 802 technologies, so any protocol-compatible device in range of the signal can read the frame header 🫣 That means OTA observers can read the MAC addresses of individual transmissions. Some wireless technologies also support techniques to establish distances or positions, so the observer can sometimes link a MAC address to a physical device and its location 📍 An OTA observer may have a legitimate reason to monitor a particular device, like for IT support operations 🛠️ However, another actor might also monitor that same device to grab PII or PCI 🚩
  2. Wireless access network operators: some wireless access networks host devices that meet specific requirements, like device type (e.g., IoT-only networks and factory operational networks) ✨ So operators can try to identify the devices (or the users) connecting to the networks under their care 🧐 They often use the MAC address to represent an identified device.
  3. Network access providers: wireless access networks are often considered beyond the first two layers of the OSI model 🌐 For example, a law enforcement agency (e.g., the FBI in the United States) may legally require the network access provider to identify communications from a subject 🕵️‍♀️ In this context, the operating access networks need to identify the devices used by the subjects and cross-reference the data generated by those devices in the network. In other contexts, the operating access networks assign resources based on contractual conditions (e.g., fee and bandwidth fair share) 💸 In these scenarios, operators may use the MAC address to identify the devices and the users of their networks.
  4. Over-the-Wired internal (OTWi) observers: this is giving "the wire is watching" energy 🔌 The device wireless MAC address keeps showing up over the wire if the infrastructure connection device (e.g., access point) works as a Layer 2 bridge, so observers may be positioned over the wire and read transmission MAC addresses 👁️ This only works if the observer has access to the wired segment of the broadcast domain where the frames are exchanged. A broadcast domain is a logical segment of a network in which devices can send, receive, and monitor data frames from all other devices within the same segment 📡 In most networks, this requires physical access to an infrastructure wired device in the broadcast domain (e.g., a switch closet), so it isn't accessible to everyone 🔒
  5. Over-the-Wired external (OTWe) observers: beyond the broadcast domain, frame headers get removed by a routing device, and a new Layer 2 header gets added before the frame is sent to the next segment 🔄 The device MAC address isn't visible anymore, unless a mechanism copies the MAC address into a field that can be read while the packet travels to the next segment (e.g., IPv6 addresses built from the MAC address prior to the use of the methods defined in [RFC8981] and [RFC7217]) 🧩 So unless this last condition exists, OTWe observers can't see the device MAC address 🙌

4. Degrees of Trust 🦋

The surface of PII exposures that can drive MAC address randomization depends on (1) the environment where the device operates, (2) the presence and nature of other devices in that environment, and (3) the type of network the device is communicating through 🌸 So a device can use an identifier (such as a MAC address) that persists over time if trust with the environment is established, or it can use a temporary identifier if an identifier is required for a service in an environment where trust hasn't been established 💜 Note that trust is not binary, bestie! ✨ It's useful to distinguish the trust a personal device may establish with the different entities at play in a network domain where a MAC address may be visible:

  1. Full trust: the device establishes a trust relationship and shares its persistent MAC address with the access network devices (e.g., access point and WLAN controller) 🫶 The network provides the necessary security measures to prevent observers or network actors from accessing PII 🛡️ The device (or its user) also has confidence that its MAC address isn't shared beyond the Layer 2 broadcast domain boundary.
  2. Selective trust: depending on the predefined privacy policies, a device may decide to use one pseudo-persistent MAC address for one set of network elements and another pseudo-persistent MAC address for a different set 🎭 Examples of privacy policies can be a combination of Service Set Identifier (SSID) and Basic Service Set Identifier (BSSID), a particular time of day, or a preset time duration ⏰
  3. Zero trust: a device may randomize its MAC address with any local entity reachable through the AP 🙈 It may generate a temporary MAC address for each of them. That temporary MAC address may or may not be the same for different services 🌈

5. Environments 🏡✨

okay so the trust vibe depends on how the person with a personal device is related to whoever runs the network service they're connecting to 🫶. It helps to look at the trust setups of common environments:

  • (A) Residential settings under the control of the user 🏠: This is a typical home network with Wi-Fi in the LAN and Internet in the WAN. In this environment, traffic over the Internet doesn't expose the MAC address of the internal device if it isn't copied to another field before routing happens. The wire segment inside the broadcast domain is under the user's control and is usually not at risk of hosting an eavesdropper 👀. Full trust is typically established at this level among users and with the network elements. Note that "Full trust" here is about MAC address persistency. It doesn't extend to full trust between applications or devices 🙈. The device trusts the access point and all Layer 2 domain entities beyond the access point, where the Wi-Fi transmissions can be detected, but there's no guarantee that an eavesdropper won't observe the communications. So even in this environment, it's common to assume that attackers may still be able to monitor unencrypted information such as MAC addresses. If a device decides not to fully trust the network, it might apply any necessary policy to protect its identity 🛡️. Most users connecting to a residential network only expect simple Internet connectivity services, so the network services are simple. If users have issues connecting to the network or accessing the Internet, they expect limited to no technical support 💅.
  • (B) Managed residential settings 🏢: Examples include shared living facilities and other collective environments where an operator manages the network for the residents. The OTA exposure is similar to (A). The operator may be asked to provide IT support to residents and may need to identify device activity in real time or analyze logs 📋. The infrastructure is shared and covers a larger area than in (A), so residents may connect from different locations. For example, they may regularly connect from their own apartments and occasionally connect from common areas ☕. The device may decide to use different pseudo-persistent MAC addresses as described in Section 4. As such, the degree of trust is "Selective trust" 💜. In this environment, the network services will be slightly more complex than in (A). The network may be segmented by locations and multiple SSIDs. Users' devices should be able to join the network without pre-certification or pre-approval. In most cases users only need simple connectivity, so network support is slightly (but not significantly) more complicated than in (A).
  • (C) Public guest networks ☕: Public hotspots in shopping malls, hotels, stores, train stations, and airports are typical examples. In this environment, trust is commonly not established with any element of the Layer 2 broadcast domain 🚫. Users don't expect a public guest network to use MAC address information to identify their location and network activity. They don't trust the network and don't want it to remember them permanently 🙅‍♀️. The degree of trust is "Zero trust". Devices in this network should avoid using a long-lived MAC address to prevent fingerprinting. For example, the device may use a different MAC address every time it attaches to a new Wi-Fi access point 🔄. Some guest network operators may legally be required to identify devices. They should not use the MAC address for that function. Most users connecting to a public guest network only expect simple Internet connectivity services, so the network services are simple. If users have issues connecting to the network or accessing the Internet, they expect limited to no technical support. Thus, the network support level is low.
  • (D) Enterprises with Bring-Your-Own-Device (BYOD) 📱: This type of network is similar to (B), except that onboarding devices go through pre-approval and pre-certification. The devices are usually personal devices and are not under the control of the corporate IT team. Compared to residential networks, enterprise networks usually provide more sophisticated services, including, but not limited to, application-based and identity-based network policies 🧠. Changing the MAC address may interrupt network services if those services are based on that MAC address. So network operations are more complex, and the network support level is high 🔧.
  • (E) Managed enterprises 👑: This type of network is similar to (D). The main difference is that the devices are owned and managed by the enterprise. Because both the network and the devices are owned and managed by the enterprise, the degree of trust is "Full trust" 💚. Network services and the network support level are the same as in (D).

Table 1 summarizes the environments above 📊.

   +=======================+===========+=======+========+=============+
   | Use Cases             | Degree of |Network|Network | Network     |
   |                       | Trust     |Admin  |Services| Support     |
   |                       |           |       |        | Expectation |
   +=======================+===========+=======+========+=============+
   | (A) Residential       | Full      |User   |Simple  | Low         |
   | settings under the    | trust     |       |        |             |
   | control of the user   |           |       |        |             |
   +-----------------------+-----------+-------+--------+-------------+
   | (B) Managed           | Selective |IT     |Medium  | Medium      |
   | residential settings  | trust     |       |        |             |
   +-----------------------+-----------+-------+--------+-------------+
   | (C) Public guest      | Zero      |ISP    |Simple  | Low         |
   | networks              | trust     |       |        |             |
   +-----------------------+-----------+-------+--------+-------------+
   | (D) Enterprises with  | Selective |IT     |Complex | High        |
   | Bring-Your-Own-Device | trust     |       |        |             |
   | (BYOD)                |           |       |        |             |
   +-----------------------+-----------+-------+--------+-------------+
   | (E) Managed           | Full      |IT     |Complex | High        |
   | enterprises           | trust     |       |        |             |
   +-----------------------+-----------+-------+--------+-------------+

                            Table 1: Use Cases

Existing technical frameworks that address some of the requirements of the use cases above are discussed in Appendix A 📚.

6. Network Services 🌐

Different network environments provide different levels of network services, from simple to complex 🍓. At its simplest, a network can give a wireless connecting device basic IP communication service (e.g., DHCPv4 [RFC2131] or Stateless Address Autoconfiguration (SLAAC) [RFC4862]) and the ability to connect to the Internet (e.g., DNS service or relay and routing in and out through a local gateway). The network can also offer more advanced services, such as managed instant messaging, file storage, printing, and/or local web service. Larger and more complex networks can incorporate even more advanced services, from AAA to Augmented Reality (AR) or Virtual Reality (VR) applications 🥽. For the network, the top priority is giving its users the best quality of experience ✨. Often the network has policies that help make forwarding decisions based on network conditions, the device, and the user identity associated with the device. For example, in a hospital private network, the network may have a policy to give the highest priority to doctors' Voice-Over-IP packets 🩺. In another example, an enterprise network may have a policy that allows applications from a group of authenticated devices to use Explicit Congestion Notification (ECN) [RFC3168] for congestion and/or Differentiated Services Code Point (DSCP) [RFC8837] for classification, signaling the network for a specific network policy 🚦. In this configuration, the network is required to associate the data packets with an identity to validate the legitimacy of the marking. Before RCM, many network systems used a MAC address as a persistent identity to link user and device. After implementing RCM, that association is broken 💔.

6.1. Device Identification and Associated Problems 🎀

okay bestie, so wireless access points and controllers use the MAC address to check the device's connection context 🧚. That covers protocol capabilities, whether authentication actually finished ✅, QoS or security profiles, and encryption keying material 🔐. Some fancy access points and controllers also have upper layer functions, and we'll get to those below 👀.

Now the drama 😭: if a device changes its MAC address and doesn't have another recorded device identity, the AP and controller totally lose the link between a connection context and the right device. The Layer 2 infrastructure doesn't know the device (with its new MAC) is authorized to be on the network. The keying material isn't identified anymore, so the access point can't decrypt the device's packets or pick the right key to encrypt packets back to it 💀. Basically the whole context has to be rebuilt and a new session restarted from scratch. That takes time, and the delay breaks any flow that needs continuity or short gaps between packets, like real-time audio, video, AR/VR, etc. 🎧

[IEEE_802.11i] knows a device may leave and rejoin the network after a short time window 🦋. So the standard suggests the infrastructure keep a device's context for a while after it was last seen, and the device should keep the same MAC address in that situation.

Some network equipment, like multi-layer routers and Wi-Fi access points that serve both Layer 2 and Layer 3 in the same box, relies on ARP [RFC826] and NDP [RFC4861] to build the MAC-to-IP table for packet forwarding 🗺️. The MAC address cache in a Layer 2 switch is finite 🫠. If new entries get created faster than the idle timer flushes the old ones, you can accidentally cause a denial-of-service attack 🙈. For example, the default timeout of the MAC address cache in Linux is set to 300 seconds. If lots of devices randomize their MACs in a short window (say, less than 300 seconds), the Layer 2 switch can run out of resources while holding traffic for a device whose entry it can no longer find. For the RCM device, that means session discontinuity and disrupted active sessions. The impact varies: a video conference may get a short interruption, while video streaming may barely notice anything ✨. The device should carefully balance when to change its MAC address after looking at the nature of its running applications and its privacy policy 🧠.

In wireless contexts, IEEE 802.1X authenticators [IEEE_802.1X] rely on the device and user identity validation from a AAA server to move the interface from a blocking state to a forwarding state 🚪. The MAC address checks that the device is on the authorized list and fetches the key used to decrypt its traffic. A change in MAC address closes the port to the device's data traffic until the AAA server confirms the new MAC is valid. So MAC address randomization can disrupt device traffic and strain the AAA server 😵.

Without a unique device identification, DHCPv4 servers [RFC2131] lose track of which IP address is validly assigned 📋. Unless the RCM device releases its IP address before changing its MAC address, DHCPv4 servers are at risk of scope exhaustion, which means new devices (including RCM devices) can't get a new IP address 🥲. Even if the RCM device releases the IP address first, the DHCPv4 server typically holds the released address for a certain duration, in case the old MAC comes back. The server can't know whether a release is a temporary disconnection or MAC randomization, so the risk of scope address exhaustion exists even when the IP address is released 😬.

Devices with self-assigned IPv6 addresses (e.g., with SLAAC [RFC4862]) and devices using static IP addresses rely on mechanisms like Optimistic Duplicate Address Detection (DAD) [RFC4429] and NDP [RFC4861] so peers can establish the association between the target IP address and a MAC address, and those peers may cache it in memory 🗂️. Changing the MAC address, even during the disconnection-reconnection phase, without changing the IP address can disrupt the stability of those mappings if the change happens within the caching period. This behavior is against standard operation and existing privacy recommendations 🚫. Implementations must avoid changing the MAC address while maintaining the previously assigned IP address without consulting the network.

Routers keep track of which MAC address is on which interface so they can form the proper Data Link header when forwarding a packet to a segment where MAC addresses are used 🛣️. MAC address randomization can cause MAC address cache exhaustion, and it can also trigger frequent Address Resolution Protocol (ARP) [RFC826], Reverse Address Resolution Protocol (RARP) [RFC903], and Neighbor Solicitation and Neighbor Advertisement [RFC4861] exchanges 🔁.

In residential settings (environment type A in Section 5), policies can control the traffic of some devices (e.g., parental control or blocklist filters) 👀. These policies are often based on the device MAC address, so MAC address randomization removes the possibility for that control 🙅‍♀️.

In residential settings (environment type A) and in enterprises (environment types D and E), device recognition and ranging may be used for IoT-related functionality (e.g., door unlock, preferred light and temperature configuration, etc.) 🔓💡. These functions often rely on detecting the device's wireless MAC address, so MAC address randomization breaks services built on that model.

In managed residential settings (environment type B) and in enterprises (environment types D and E), the network operator is often asked to provide IT support 🛠️. With MAC address randomization, real-time support is only possible if the user can provide the current MAC address. Service improvement support isn't possible if the MAC address the device had at the time of the reported issue isn't known when the issue is reported.

In managed enterprise environments, policies are tied to each group of objects, including IoT devices 🏢. MAC address randomization may stop an IoT device from being identified properly, which can lead to network quarantine and disrupted operations 🚨.

7. IANA Considerations 🌸

This document has no IANA actions. Nothing to register, bestie, so we're all good here ✨.

8. Security Considerations 💜

Privacy considerations are discussed throughout this document 🔒. Seriously, they're everywhere in here, so read the whole thing and don't skip the fine print 🫶.

9. Informative References ✨

Appendix A. Existing Frameworks 🎀

A.1. IEEE 802.1X with WPA2 / WPA3

okay so in a typical enterprise Wi-Fi setup, IEEE 802.1X authentication [IEEE_802.1X] paired with WPA2 or WPA3 [IEEE_802.11i] encryption is what people usually reach for when onboarding a Wi-Fi device 💼✨. It lets the client device, or the user of the device, and an authentication authority mutually identify each other 🤝. The authentication exchange doesn't happen in clear text, and the user or device identity can be hidden from unauthorized observers 🙈. BUT, ngl, in most cases the authentication authority is run by the same entity as the network access provider, which can end up exposing the user or device identity to the network owner 👀.

This scheme is super well-adapted to an enterprise environment, where a level of trust is set up between the user and the enterprise network operator 💅. In this scheme, MAC address randomization can happen through brief disconnections and reconnections (under the rules of [IEEE_802.11bh]) 🦋. Authentication may then need to happen again, which comes with a cost of service disruption and extra load on the enterprise infrastructure, but the upside is limiting how exposed a continuous MAC address is to external observers 🔐. The adoption of this scheme is limited outside of the enterprise environment, because you have to install an authentication profile on the end device that a local authentication authority and its authentication server would recognize and accept 😩. Such a server is uncommon in a home environment, and installing a profile is cumbersome for most untrained users 💀. The likelihood that a user or device profile would match a profile recognized by a public Wi-Fi authentication authority is also fairly limited, so this may restrict the adoption of this scheme for public Wi-Fi as well 🌸. Similar limitations show up in the hospitality environment. The hospitality environment refers to space provided by the hospitality industry, which includes but is not limited to hotels, stadiums, restaurants, concert halls, and hospitals 🍓.

A.2. OpenRoaming

to alleviate some of the limitations we just talked about, the Wireless Broadband Alliance (WBA) OpenRoaming standard introduces an intermediate trusted relay between local venues (places where some public Wi-Fi is available) and sources of identity [WBA-OPENROAMING] 🌈. The federation structure extends the types of authorities that can be used as identity sources (compared to the typical enterprise-based IEEE 802.1X scheme for Wi-Fi [IEEE_802.1X]) and makes it easier to establish trust between local networks and an identity provider 🤝✨. That means one or more identity profiles for the user or the device are more likely to be recognized by a local network 👑. At the same time, authentication does not occur to the local network. This may give the user or the device a way to keep their identity obfuscated from the local network operator, unless that operator specifically expresses the requirement to disclose such identity (in which case the user has the option to accept or decline the connection and the associated identity exposure) 🙈.

The OpenRoaming scheme seems well-adapted to public Wi-Fi and hospitality environments 💖. It defines a framework to protect the identity from unauthorized entities while still permitting mutual authentication between the device or the user and a trusted identity provider 🫶. Just like the standard IEEE 802.1X scheme for Wi-Fi [IEEE_802.1X], authentication allows for the establishment of WPA2 or WPA3 keys [IEEE_802.11i], which can then be used to encrypt the communication between the device and the access point. The encryption adds extra protection to prevent the network traffic from being eavesdropped 🔒.

MAC address randomization can happen through brief disconnections and reconnections (under the rules of [IEEE_802.11bh]) 🦋. Authentication may then need to happen again, which comes with a cost of service disruption and an additional load on the venue and identity provider infrastructure, but the benefit is limiting how exposed a continuous MAC address is to external observers 🧚. Limitations of this scheme include the requirement to first install one or more profiles on the client device 😅. This scheme also requires the local network to support RADSEC [RFC6614] and the relay function, which may not be common in small hotspot networks and home environments 🏠.

It is worth noting that, as part of collaborations between the IETF MADINAS Working Group and WBA around OpenRoaming, some RADIUS privacy enhancements have been proposed in the IETF RADEXT Working Group. For instance, [RADIUS] describes good practices in the use of Chargeable-User-Identity (CUI) between different visited networks, which makes it better suited for public Wi-Fi and hospitality use cases 🌟.

A.3. Proprietary RCM Schemes 💜

Okay bestie, so most client OS vendors ship RCM (random MAC) schemes that are turned on by default or super easy to switch on for client devices 📱✨. How it works: when the device isn't associated, it swaps out its MAC address after using a given one for a semi-random duration window 🦋. These schemes can also let the device show a different MAC address on different SSIDs, which is so iconic 💅.

Here's the tea 🫖: this kind of randomization keeps any single MAC address exposed to observers for a shorter time 🙈. In [IEEE_802.11bh], MAC address randomization is not allowed during a given association session, and it can only happen through disconnection and reconnection 😭. So authentication may need to happen again, which means service disruption and extra load on the venue and identity provider infrastructure, and that load is directly proportional to how often the randomization happens 💀. Also, the scheme is NOT meant to hide other identifiers from the venue network 🚫. For example, DHCP option 012 [host name] is still visible to the network between the AP and the DHCPv4 server 🍓.

Authors' Addresses 🎀

Jerome Henry 🌸

Jerome Henry
Cisco Systems
United States of America
Email: jerhenry@cisco.com

Yiu L. Lee 🦋

Yiu L. Lee
Comcast
1800 Arch Street
Philadelphia, PA 19103
United States of America
Email: yiu_lee@comcast.com
📦 where this page comes from