Cisco Systems

United States of America jerhenry@cisco.com

Comcast

1800 Arch Street Philadelphia PA 19103 United States of America yiu_lee@comcast.com

INT madinas RCM Universal MAC address Local MAC address Locally Administered MAC address Personal Device Shared Service Device Network Functional Entities Human-Related Entities Over-the-Air (OTA) observers Wireless access network operators Network access providers Over-the-Wired internal (OTWi) observers Over-the-Wired external (OTWe) observers full trust selective trust zero trust privacy Residential settings Managed residential settings public guest network Enterprises with Bring-Your-Own-Device (BYOD) Managed Enterprises To limit the privacy issues created by the association between a device, its traffic, its location, and its user in IEEE 802 networks, client vendors and client OS vendors have started implementing Media Access Control (MAC) address randomization. This technology is particularly important in Wi-Fi networks (defined in IEEE 802.11) due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the purpose of MAC address randomization. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines some existing frameworks that maintain user privacy while preserving user quality of experience and network operation efficiency.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice 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 () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  MAC Address as Identity: User vs. Device
  • .  Privacy of MAC Addresses
• .  The Actors: Network Functional Entities and Human Entities
  • .  Network Functional Entities
  • .  Human-Related Entities
• .  Degrees of Trust
• .  Environments
• .  Network Services
  • .  Device Identification and Associated Problems
• .  IANA Considerations
• .  Security Considerations
• .  Informative References
• .  Existing Frameworks
  • .  IEEE 802.1X with WPA2 / WPA3
  • .  OpenRoaming
  • .  Proprietary RCM Schemes
• Authors' Addresses

Introduction When the MAC address was first introduced in , it was used in wired Ethernet networks . Due to the nature of wired networks, devices were relatively stationary, and the physical connection imposed a boundary that restricted attackers from easily accessing the network data. However, (Wi-Fi) brought new challenges when it was introduced. The flexibility of Wi-Fi technology has revolutionized communications and become the preferred, and sometimes the only, technology used by devices such as laptops, tablets, and Internet of Things (IoT) devices. Wi-Fi is an over-the-air medium that allows attackers with surveillance equipment to monitor WLAN packets and track the activity of WLAN devices. It is also sometimes possible for attackers to monitor the WLAN packets behind the Wi-Fi Access Point (AP) over the wired Ethernet. Once the association between a device and its user is made, identifying the device and its activity is sufficient to deduce information about what the user is doing, without the user's consent. To reduce the risks of identifying a device only by the MAC address, client OS vendors have started implementing Randomized and Changing MAC addresses (RCM). By randomizing the MAC address, it becomes harder to use the MAC address to construct a persistent association between a flow of data packets and a device, assuming no other visible unique identifiers or stable patterns are in use. When individual devices are no longer easily identifiable, it also becomes difficult to associate a series of network packet flows in a prolonged period with a particular individual using one specific device if the device randomizes the MAC address governed by the OS privacy policies. However, such address changes may affect the user experience and the efficiency of legitimate network operations. For a long time, network designers and implementers relied on the assumption that a given machine, in a network implementing IEEE 802 technologies , would be represented by a unique network MAC address that would not change over time. When this assumption is broken, network communication may be disrupted. For example, sessions established between the end device and the network services may break, and packets in transit may suddenly be lost. If multiple clients implement aggressive (e.g., once an hour or shorter) MAC address randomization without coordination with network services, some network services, such as MAC address caching in the AP and the upstream Layer 2 switch, may not be able to handle the load, which may result in an unexpected network interruption. At the same time, some network services rely on the end station (as defined by ) to provide an identifier, which can be the MAC address or another value. This document also refers to the end station as a "device" or "machine". If the client implements MAC address randomization but continues sending the same static identifier, then the association between a stable identifier and the station continues despite the RCM scheme. There may be environments where such continued association is desirable, but there may be others where user privacy has more value than any continuity of network service state. It is useful for implementations of client and network devices to enumerate services that may be affected by RCM and to evaluate possible frameworks to maintain both the quality of user experience and network efficiency while RCM happens and user privacy is strengthened. This document presents these assessments and recommendations. Although this document mainly discusses MAC address randomization in Wi-Fi networks , the same principles can be easily extended to any IEEE 802 networks . This document is organized as follows:

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

MAC Address as Identity: User vs. Device In IEEE 802 technologies, the Media Access Control (MAC) layer defines rules to control how a device accesses the shared medium. In a network where a machine can communicate with one or more other machines, one such rule is that each 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). Initially intended as a 48-bit (6-octet) value in the first versions of IEEE 802, other standards under the IEEE 802 umbrella allow this address to take an extended format of 64 bits (8 octets), which enabled a larger number of MAC addresses to coexist as IEEE 802 technologies became widely adopted. Regardless of the address length, different networks have different needs, and several bits of the first octet are reserved for specific purposes. In particular, the first bit is used to identify the destination address as an individual (bit set to 0) or a group address (bit set to 1). The second bit, called the Universal/Local (U/L) address bit, indicates whether the address has been assigned by a universal or local administrator. Universally administered addresses have this bit set to 0. If this bit is set to 1, the entire address is considered to be locally administered (see Clause 8.4 of ). Note that universally administered MAC addresses are required to be registered with the IEEE, while locally administered MAC addresses are not. The intent of this provision is important for the present document. recognizes that some devices (e.g., smart thermostats) may never change their attachment network and will not need a globally unique MAC address to prevent address collision against any other device in any other network. The U/L bit can be set to signal to the network that the MAC address is intended to be locally unique (not globally unique). did not initially define the MAC address allocation schema when the U/L bit is set to 1. It states the address must be unique in a given broadcast domain (i.e., the space where the MAC addresses of devices are visible to one another). It is also important to note that the purpose of the universal version of the address was to avoid collisions and confusion, as any machine could connect to any network, and each machine needs to determine if it is the intended destination of a message or its response. Clause 8.4 of reminds network designers and operators that all potential members of a network need to have a unique identifier in that network (if they are going to coexist in the network without confusion on which machine is the source or destination of any message). The advantage of an administrated address is that a node with such an address can be attached to any Local Area Network (LAN) in the world with an assurance that its address is unique in that network. With the rapid development of wireless technologies and mobile devices, this scenario became very common. With a vast majority of networks implementing IEEE 802 radio technologies at the access, the MAC address of a wireless device can appear anywhere on the planet and collisions should still be avoided. However, the same evolution brought the distinction between two types of devices that generally refers to as "nodes in a network" (see Section 6.2 of for definitions of these devices):

Shared Service Device:

A device used by enough people that the device itself, its functions, or its traffic cannot be associated with a single or small group of people. Examples of such devices include switches in a dense network, (WLAN) access points in a crowded airport, and task-specific devices (e.g., barcode scanners).

Personal Device:

A machine or node primarily used by a single person or small group of people, so that any identification of the device or its traffic can also be associated with the identification of the primary user or their online activity.

Identifying the device is trivial if it has a unique MAC address. Once this unique MAC address is established, detecting any elements that directly or indirectly identify the user of the device (i.e., Personally Identifiable Information (PII)) is enough to link the MAC address to that user. Then, any detection of traffic that can be associated with the device will also be linked to the known user of that device (i.e., Personally Correlated Information (PCI)).

Privacy of MAC Addresses The possible identification or association presents a privacy issue, especially with wireless technologies. For most of them ( in particular), the source and destination MAC addresses are not encrypted even in networks that implement encryption. This lack of encryption allows each machine to easily detect if it is the intended target of the message before attempting to decrypt its content and also helps identify the transmitter in order to use the right decryption key when multiple unicast keys are in effect. This identification of the user associated with a node was clearly not the intent of the IEEE 802 MAC address. A logical solution to remove this association is to use a locally administered address instead and change the address in a fashion that prevents a continuous association between one MAC address and some PII. However, other network devices on the same LAN implementing a MAC layer also expect each device to be associated with a MAC address that would persist over time. When a device changes its MAC address, other devices on the same LAN may fail to recognize that the same machine is attempting to communicate with them. This type of MAC address is referred to as 'persistent' MAC address in this document. This assumption sometimes adds to the PII confusion, for example, in the case of Authentication, Authorization, and Accounting (AAA) services authenticating the user of a machine and associating the authenticated user to the device MAC address. Other services solely focus on the machine (e.g., DHCPv4 ) but still expect each device to use a persistent MAC address, for example, to reassign the same IP address to a returning device. Changing the MAC address may disrupt these services.

The Actors: Network Functional Entities and Human Entities The risk of service disruption is weighed against the privacy benefits. However, the plurality of actors involved in the exchanges tends to blur the boundaries of which privacy violations should be protected against. Therefore, it is useful to list the actors associated with the network exchanges because they either actively participate in these exchanges or can observe them. Some actors are functional entities, while others are human (or related) entities.

Network Functional Entities Network communications based on IEEE 802 technologies commonly rely on station identifiers based on a MAC address. This MAC address is utilized by several types of network functional entities 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 participate in IEEE 802 LAN operations. As such, they need to identify each machine as a source or destination to successfully continue exchanging frames. As a device changes its network attachment (roams) from one access point to another, the access points can exchange contextual information (e.g., device MAC address and keying material), allowing the device session to continue seamlessly. These access points can also inform devices further in the wired network about the roam to ensure that Layer 2 frames are redirected to the new device access point.
2. Other network devices operating at the MAC layer: Many wireless network access devices (e.g., access points ) are conceived as Layer 2 devices, and as such, they bridge a frame from one medium (e.g., Wi-Fi ) to another (e.g., Ethernet ). This means that the MAC address of a wireless device often exists on the wire beyond the wireless access device. Devices connected to this wire also implement IEEE 802.3 technologies , and as such, they operate on the expectation that each device is associated with a MAC address that persists for the duration of continuous exchanges. For example, switches and bridges associate MAC addresses to individual ports (so as to know to which port to send a frame intended for a particular MAC address). Similarly, AAA services can validate the identity of a device and use the device MAC address as the first pointer to the device identity (before operating further verification). Similarly, some networking devices offer Layer 2 filtering policies that may rely on the connected MAC addresses. IEEE 802.1X-enabled devices may also selectively put the interface in a blocking state until a 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 is not exhaustive. Multiple services are defined for Ethernet networks , and multiple services defined by the IEEE 802.1 working group are also applicable to Ethernet networks . Wireless access points may also connect using other mediums (e.g., the Data-Over-Cable Service Interface Specification (DOCSIS) ) that implement mechanisms under the umbrella of the general 802 Standard and therefore 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. Some of them also operate a MAC layer function. For example, routers provide IP forwarding services but rely on the device MAC address to create the appropriate frame structure. Other devices and services operate at upper layers but also rely upon the IEEE 802 principles of unique MAC-to-device mapping. For example, the Address Resolution Protocol (ARP) and Neighbor Discovery Protocol (NDP) use a MAC address to create the mapping of 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 is connected to or is the provider of a service that expects a stable MAC-to-device mapping, the provider of the service and traffic forwarding may be disrupted.

Human-Related Entities Humans may actively participate in the network structure and operations or be observers at any point of the network lifecycle. Humans could be users of wireless devices or people operating wireless networks.

1. Over-the-Air (OTA) observers: The transmitting or receiving MAC address is usually not encrypted in wireless exchanges using IEEE 802 technologies, and any protocol-compatible device in range of the signal can read the frame header. As such, OTA observers are able to read the MAC addresses of individual transmissions. Some wireless technologies also support techniques to establish distances or positions, allowing the observer, in some cases, to uniquely associate the MAC address with a physical device and its associated location. An OTA observer may have a legitimate reason to monitor a particular device, for example, for IT support operations. However, another actor might also monitor the same device to obtain PII or PCI.
2. Wireless access network operators: Some wireless access networks host devices that meet specific requirements, such as device type (e.g., IoT-only networks and factory operational networks). Therefore, operators can attempt 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 the 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, the operators may use the MAC address to identify the devices and the users of their networks.
4. Over-the-Wired internal (OTWi) observers: Because the device wireless MAC address continues to be present over the wire if the infrastructure connection device (e.g., access point) functions as a Layer 2 bridge, observers may be positioned over the wire and may read transmission MAC addresses. Such capability supposes that 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, such capability requires physical access to an infrastructure wired device in the broadcast domain (e.g., switch closet) and is therefore not accessible to all.
5. Over-the-Wired external (OTWe) observers: Beyond the broadcast domain, frame headers are removed by a routing device, and a new Layer 2 header is added before the frame is transmitted to the next segment. The device MAC address is not 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 and ). Therefore, unless this last condition exists, OTWe observers are not able to see the device MAC address.

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 the environment, and (3) the type of network the device is communicating through. Consequently, a device can use an identifier (such as a MAC address) that can persist over time if trust with the environment is established, or it can use an identifier that is temporary if an identifier is required for a service in an environment where trust has not been established. Note that trust is not binary. It is useful to distinguish what 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 necessary security measures to prevent observers or network actors from accessing PII. The device (or its user) also has confidence that its MAC address is not 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 a set of network elements and another pseudo-persistent MAC address for another set of network elements. 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 to each of them. That temporary MAC address may or may not be the same for different services.

Environments The trust relationship depends on the relationship between the user of a personal device and the operator of a network service that the personal device may use. It is useful to observe the typical trust structure of common environments:

1. 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 does not expose the MAC address of the internal device if it is not copied to another field before routing happens. The wire segment within the broadcast domain is under the control of the user 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" in this context is referring to the MAC address persistency. It does not 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 is no guarantee that an eavesdropper will not observe the communications. As such, even in this environment, it is common to assume that attackers may still be able to monitor unencrypted information such as MAC addresses. If a device decides to not 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.
2. Managed residential settings: Examples of this type of environment 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 requested to provide IT support to the 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); residents may connect to the network from different locations. For example, they may regularly connect to the network from their own apartments and occasionally connect from common areas. The device may decide to use different pseudo-persistent MAC addresses as described in . 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; thus, network support will be slightly (but not significantly) more complicated than in (A).
3. Public guest networks: Public hotspots in shopping malls, hotels, stores, train stations, and airports are typical examples of this environment. In this environment, trust is commonly not established with any element of the Layer 2 broadcast domain. Users do not anticipate a public guest network using the MAC address information to identify their location and network activity. They do not trust the network and do not want the network to memorize 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 abide to identify devices. They should not use the MAC address for such a 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.
4. Enterprises with Bring-Your-Own-Device (BYOD): This type of network is similar to (B) except that the onboarding devices are subjected to 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 network services including, but not limited to, application-based and identity-based network policies. Changing the MAC address may interrupt network services if the services are based on that MAC address. Thus, network operations will be more complex, so the network support level is high.
5. 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).

summarizes the environments described above. Use Cases

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

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

Network Services Different network environments provide different levels of network services, from simple to complex. At its simplest level, a network can provide a wireless connecting device with basic IP communication service (e.g., DHCPv4 or Stateless Address Autoconfiguration (SLAAC) ) and an 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 service, file storage, printing, and/or local web service. Larger and more complex networks can also incorporate more advanced services, from AAA to Augmented Reality (AR) or Virtual Reality (VR) applications. To the network, its top priority is to provide the best quality of experience to its users. Often the network contains policies that help to make a forwarding decision based on the network conditions, the device, and the user identity associated to the device. For example, in a hospital private network, the network may contain a policy to give highest priority to doctors' Voice-Over-IP packets. In another example, an enterprise network may contain a policy to allow applications from a group of authenticated devices to use Explicit Congestion Notification (ECN) for congestion and/or Differentiated Services Code Point (DSCP) for classification to signal the network for a specific network policy. In this configuration, the network is required to associate the data packets to an identity to validate the legitimacy of the marking. Before RCM, many network systems used a MAC address as a persistent identity to create an association between user and device. After implementing RCM, the association is broken.

Device Identification and Associated Problems Wireless access points and controllers use the MAC address to validate the device connection context, including protocol capabilities, confirmation that authentication was completed, quality of service or security profiles, and encryption keying material. Some advanced access points and controllers also include upper layer functions whose purpose is covered below. A device changing its MAC address, without another recorded device identity, would cause the access point and the controller to lose the relation between a connection context and the corresponding device. As such, the Layer 2 infrastructure does not know that the device (with its new MAC address) is authorized to communicate through the network. The encryption keying material is not identified anymore (causing the access point to fail to decrypt the device packets and fail to select the right key to send encrypted packets to the device). In short, the entire context needs to be rebuilt, and a new session restarted. The time consumed by this procedure breaks any flow that needs continuity or short delay between packets on the device (e.g., real-time audio, video, AR/VR, etc.). For example, recognizes that a device may leave and rejoin the network after a short time window. As such, the standard suggests that the infrastructure should keep the context for a device for a while after the device was last seen. The device should maintain the same MAC address in such a scenario. Some network equipment such as multi-layer routers and Wi-Fi access points, which serve both Layer 2 and Layer 3 in the same device, rely on ARP and NDP to build the MAC-to-IP table for packet forwarding. The size of the MAC address cache in the Layer 2 switch is finite. If new entries are created faster than the old entries are flushed by the idle timer, it is possible to cause an unintentional denial-of-service attack. For example, the default timeout of the MAC address cache in Linux is set to 300 seconds. Aggressive MAC randomization from many devices in a short time interval (e.g., less than 300 seconds) may cause the Layer 2 switch to exhaust its resources, holding in memory traffic for a device whose entry can no longer be found. For the RCM device, these effects translate into session discontinuity and disrupt the active sessions. The discontinuity impact may vary. Real-time applications such as video conference may experience short interruption while non-real-time applications such as video streaming may experience minimal or no impact. The device should carefully balance when to change the MAC address after analyzing the nature of the running applications and its privacy policy. In wireless contexts, IEEE 802.1X authenticators rely on the device and user identity validation provided by a AAA server to change the interface from a blocking state to a forwarding state. The MAC address is used to verify that the device is in the authorized list and to retrieve the associated key used to decrypt the device traffic. A change in MAC address causes the port to be closed to the device data traffic until the AAA server confirms the validity of the new MAC address. Consequently, MAC address randomization can disrupt the device traffic and strain the AAA server. Without a unique identification of the device, DHCPv4 servers lose track of which IP address is validly assigned. Unless the RCM device releases the IP address before changing its MAC address, DHCPv4 servers are at risk of scope exhaustion, causing new devices (and RCM devices) to fail to obtain a new IP address. Even if the RCM device releases the IP address before changing the MAC address, the DHCPv4 server typically holds the released IP address for a certain duration, in case the leaving MAC returns. As the DHCPv4 server cannot know if the release is due to a temporary disconnection or a MAC randomization, the risk of scope address exhaustion exists even in cases where the IP address is released. Network devices with self-assigned IPv6 addresses (e.g., with SLAAC ) and devices using static IP addresses rely on mechanisms like Optimistic Duplicate Address Detection (DAD) and NDP for peer devices to establish the association between the target IP address and a MAC address, and these peers may cache this association in memory. Changing the MAC address, even at the disconnection-reconnection phase, without changing the IP address may disrupt the stability of these mappings for these peers if the change occurs within the caching period. Note that 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 that 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 but also the need for frequent Address Resolution Protocol (ARP) , Reverse Address Resolution Protocol (RARP) , and Neighbor Solicitation and Neighbor Advertisement exchanges. In residential settings (environment type A in ), policies can be in place to control the traffic of some devices (e.g., parental control or blocklist filters). These policies are often based on the device MAC address. MAC address randomization removes the possibility for such 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 functionalities (e.g., door unlock, preferred light and temperature configuration, etc.) These functions often rely on the detection of the device wireless MAC address. MAC address randomization breaks the services based on such models. In managed residential settings (environment type B) and in enterprises (environment types D and E), the network operator is often requested 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 is not possible if the MAC address that the device had at the time of the reported issue (in the past) is not known at the time the issue is reported. In managed enterprise environments, policies are associated with each group of objects, including IoT devices. MAC address randomization may prevent an IoT device from being identified properly and thus lead to network quarantine and disruption of operations.

IANA Considerations This document has no IANA actions.

Security Considerations Privacy considerations are discussed throughout this document.

Informative References CableLabs Data-Over-Cable Service Interface Specifications, DOCSIS 4.0, Version I06 IEEE IEEE IEEE IEEE IEEE IEEE IEEE InkBridge Networks RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The recent publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give recommendations for practices which increase both security and privacy. Work in Progress The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK] Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK] This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK] This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK] This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses). The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-Time Communication (WebRTC) traffic. This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements. Wireless Broadband Alliance, Inc. Cisco Systems Intel Corporation SingleDigits Cisco Systems This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architectures enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. Work in Progress

Existing Frameworks

IEEE 802.1X with WPA2 / WPA3 In a typical enterprise Wi-Fi environment, IEEE 802.1X authentication coupled with WPA2 or WPA3 encryption schemes are commonly used for onboarding a Wi-Fi device. This allows the mutual identification of the client device or the user of the device and an authentication authority. The authentication exchange does not occur in clear text, and the user or device identity can be concealed from unauthorized observers. However, in most cases, the authentication authority is under the control of the same entity as the network access provider. This may lead to exposing the user or device identity to the network owner. This scheme is well-adapted to an enterprise environment, where a level of trust is established between the user and the enterprise network operator. In this scheme, MAC address randomization can occur through brief disconnections and reconnections (under the rules of ). Authentication may then need to reoccur, with an associated cost of service disruption, an additional load on the enterprise infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address to external observers. The adoption of this scheme is limited outside of the enterprise environment by the requirement to install an authentication profile on the end device, which would be recognized and accepted by a local authentication authority and its authentication server. Such a server is uncommon in a home environment, and the procedure to install 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. This may restrict the adoption of this scheme for public Wi-Fi as well. Similar limitations are found 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.

OpenRoaming In order to alleviate some of the limitations listed above, 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 . The federation structure extends the type of authorities that can be used as identity sources (compared to the typical enterprise-based IEEE 802.1X scheme for Wi-Fi ) and facilitates the establishment of trust between local networks and an identity provider. Such a procedure increases the likelihood that one or more identity profiles for the user or the device will be recognized by a local network. At the same time, authentication does not occur to the local network. This may offer the possibility for the user or the device 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 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 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 , authentication allows for the establishment of WPA2 or WPA3 keys that 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 occur through brief disconnections and reconnections (under the rules of ). Authentication may then need to reoccur, with an associated cost of service disruption, an additional load on the venue and identity provider infrastructure, and an associated benefit of limiting the exposure of a continuous MAC address 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 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, describes good practices in the use of Chargeable-User-Identity (CUI) between different visited networks, making it better suited for public Wi-Fi and hospitality use cases.

Proprietary RCM Schemes Most client OS vendors offer RCM schemes that are enabled by default (or easy to enable) on client devices. With these schemes, the device changes its MAC address, when not associated, after having used a given MAC address for a semi-random duration window. These schemes also allow for the device to manifest a different MAC address in different SSIDs. Such a randomization scheme enables the device to limit the duration of exposure of a single MAC address to observers. In , MAC address randomization is not allowed during a given association session, and MAC address randomization can only occur through disconnection and reconnection. Authentication may then need to reoccur, with an associated cost of service disruption and additional load on the venue and identity provider infrastructure, directly proportional to the frequency of the randomization. The scheme is also not intended to protect from the exposure of other identifiers to the venue network (e.g., DHCP option 012 [host name] visible to the network between the AP and the DHCPv4 server).

Authors' Addresses Cisco Systems

United States of America jerhenry@cisco.com

Comcast

1800 Arch Street Philadelphia PA 19103 United States of America yiu_lee@comcast.com