| RFC 0000 | Randomized and Changing MAC Address | January 2025 |
| Zúñiga, et al. | Informational | [Page] |
Internet users are becoming more aware that their activity over the Internet leaves avast digital footprint, that communications might not always be properlysecured, and that their location and actions can be tracked. One of the mainfactors that eases tracking of Internet users is the wide use of long-lasting, and sometimespersistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses.¶
There have been several initiatives within the IETF and the IEEE 802 standardscommittees to overcome some of the privacy issues involved. This document provides anoverview of these activities to help coordinate standardization activities in these bodies.¶
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 athttps://www.rfc-editor.org/info/rfc0000.¶
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) 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.¶
Privacy is becoming a huge concern, as more and more devices are connecting tothe Internet either directly (e.g., via Wi-Fi) or indirectly (e.g., via asmartphone using Bluetooth). This ubiquitous connectivity, together with thelack of proper education about privacy, makes it very easy to track/monitorthe location of users and/or eavesdrop on their physical and onlineactivities. This is due to many factors, such as the vast digital footprintthat users leave on the Internet with or without their consent and the weak(or even null) authentication and encryption mechanisms used tosecure communications. A digital footprint may includeinformation shared on social networks, cookies used by browsers and serversfor various reasons, connectivity logs that allow tracking of a user's Layer 2(L2) address (i.e, MAC address) or Layer 3 (L3) address, web trackers, etc.¶
Privacy concerns affect all layers of the protocol stack, from the lowerlayers involved in the access to the network (e.g., MAC/L2 and L3addresses can be used to obtain the location of a user) to higher-layer protocolidentifiers and user applications[CSCN2015]. Inparticular, IEEE 802 MAC addresses have historically been an easy target fortracking users[wifi_tracking].¶
There have been several initiatives within the IETF and the IEEE 802 standardscommittees to overcome some of these privacy issues. This document provides anoverview of these activities to help coordinate standardization activitieswithin these bodies.¶
Most mobile devices used today are WLAN enabled (i.e., they are equipped with anIEEE 802.11 wireless local area network interface). Wi-Fi interfaces, like anyother kind of network interface based on IEEE 802 such as Ethernet (i.e., IEEE 802.3), have an L2 address (also referred to as a MAC address) that can be seen byanybody who can receive the radio signal transmitted by the network interface. Theformat of these addresses (for 48-bit MAC addresses) is shown inFigure 1.¶
+--------+--------+---------+--------+--------+---------+ | Organizationally Unique | Network Interface | | Identifier (OUI) | Controller (NIC) Specific | +--------+--------+---------+--------+--------+---------+ / \ / \ / \ b0 (I/G bit): / \ 0: unicast / \ 1: multicast / \ / \ b1 (U/L bit):+--+--+--+--+--+--+--+--+ 0: globally unique (OUI enforced)|b7|b6|b5|b4|b3|b2|b1|b0| 1: locally administered+--+--+--+--+--+--+--+--+
MAC addresses can be either universally or locally administered.Universally and locally administered addresses are distinguished bysetting the second least significant bit of the most significant byte of theaddress (the U/L bit).¶
A universally administered address is uniquely assigned to a device by itsmanufacturer. Most physical devices are provided with a universally administeredaddress, which is composed of two parts:¶
Locally administered addresses override the burned-in address, and they caneither be set up by the network administrator or by the Operating System (OS)of the device to which the address pertains. However, as explained in latersections of this document, there are new initiatives at the IEEE 802 and otherorganizations to specify ways in which these locally administered addressesshould be assigned, depending on the use case.¶
Since universally administered MAC addresses are by definition globally unique,when a device uses this MAC address over a shared medium to transmit data -- especially over the air --it is relatively easy to track this device by simple medium observation. Since adevice is usually directly associated to an individual, this poses a privacyconcern[link_layer_privacy].¶
MAC addresses can be easily observed by a third party, such as a passive devicelistening to communications in the same L2 network. In an 802.11 network, a stationexposes its MAC address in two different situations:¶
While actively scanning for available networks, the MAC address is used in theProbe Request frames sent by the device (also known as IEEE 802.11 STA).¶
Once associated to a given Access Point (AP), the MAC address is used in frametransmission and reception, as one of the addresses used in the unicast address fieldsof an IEEE 802.11 frame.¶
One way to overcome this privacy concern is by using randomly generated MACaddresses. IEEE 802 addressing includes one bit to specify if the hardwareaddress is locally or globally administered. This allows localaddresses to be generated without the need for any global coordination mechanism to ensure thatthe generated address is still unique within the local network. This feature canbe used to generate random addresses, which decouple the globally uniqueidentifier from the device and therefore make it more difficult to track a userdevice from its MAC/L2 address[enhancing_location_privacy].¶
Note that there are reports[contact_tracing_paper] of somemobile OSes reporting persistently (every 20 minutes or so)on MAC addresses (among other information), which would defeat MAC addressrandomization. While these practices might have changed by now, it is importantto highlight that privacy-preserving techniques should be conducted while consideringall layers of the protocol stack.¶
As an outcome to the STRINT W3C/IAB Workshop[strint], atutorial titled "Pervasive Surveillance of the Internet - Designing Privacy intoInternet Protocols"[privacy_tutorial] was given at the IEEE 802 Plenary meeting in San Diego in July of 2014. The tutorial provided an update onthe recent developments regarding Internet privacy, the actions undertaken byother Standards Development Organizations (SDOs) like the IETF, and guidelines that were being followed when developingnew Internet protocol specifications (e.g., the considerations described in[RFC6973]). Thetutorial highlighted some privacy concerns applicable specifically to link-layertechnologies and provided suggestions on how IEEE 802 could help addressthem.¶
Following the discussions and interest within the IEEE 802 community, on 18 July2014, the IEEE 802 Executive Committee (EC) created an IEEE 802 EC PrivacyRecommendation Study Group (SG)[ieee_privacy_ecsg]. The work and discussions from the group have generated multiple outcomes, such as: 802EPAR (Project Authorization Request, this is the means by which standards projects are started within the IEEE. PARs define the scope, purpose, and contact points for a new project): Recommended Practice for Privacy Considerations for IEEE 802 Technologies[IEEE_802E], and the 802c PAR: Standard for Local andMetropolitan Area Networks - Overview and Architecture - Amendment 2: Local MediumAccess Control (MAC) Address Usage[IEEE_802c].¶
In order to test the effects of MAC address randomization, trials were conductedat the IETF and IEEE 802 meetings between November 2014 and March 2015: IETF 91,IETF 92, and IEEE 802 Plenary in Berlin. The purpose of the trials was to evaluatethe use of MAC address randomization from two different perspectives: (i) theeffect on the connectivity experience of the end user, as well as any effect onapplications and OSes, and (ii) the potential impact on thenetwork infrastructure itself. Some of the findings were published in[CSCN2015].¶
During the trials, it was observed that the probability of address duplication ina network is negligible. The trials also revealed that other protocolidentifiers (e.g., the DHCP client identifier) can be correlated and therefore still beused to track an individual. Hence, effective privacy tools should notwork in isolation at a single layer; instead; they should be coordinated with otherprivacy features at higher layers.¶
Since then, MAC randomization has further been implemented by mobile OSes toprovide better privacy for mobile phone users when connecting to public wirelessnetworks[privacy_ios][privacy_windows][privacy_android].¶
Practical experiences with Randomized and Changing MAC addresses (RCM) indevices (some of which are explained inSection 6) helped researchers fine-tune their understanding ofattacks against randomization mechanisms[when_mac_randomization_fails]. Within the IEEE802.11 group, these research experiences eventually formed the basis for aspecified mechanism that randomizes MAC addresses, which was introduced inIEEE Std 802.11aq[IEEE_802.11aq] in 2018.¶
More recent developments include turning on MAC randomization in mobileOSes by default, which has an impact on the ability of networkoperators to customize services[rcm_user_experience_csd]. Therefore, follow-on work in the IEEE802.11 mapped effects of a potentially large uptake of randomized MAC identifierson a number of commonly offered operator services in 2019[rcm_tig_final_report]. In the summer of 2020, this work emanated intwo new standards projects with the purpose of developing mechanisms that do notdecrease user privacy but enable an optimal user experience when the MAC addressof a device in an Extended Service Set (a group of interconnected IEEE 802.11 wireless access points and stations that form a single logical network) is randomized or changes[rcm_user_experience_par] and user privacy solutions applicable toIEEE Std 802.11[rcm_privacy_par].¶
IEEE Std 802[IEEE_802], as of the amendment IEEE 802c-2017[IEEE_802c], specifies a local MAC address space structure knownas the Structured Local Address Plan (SLAP)[RFC8948]. The SLAP designates a range ofExtended Local Identifiers for subassignment within a block of addressesassigned by the IEEE Registration Authority via a Company ID. A range oflocal MAC addresses is designated for Standard Assigned Identifiers to bespecified by IEEE 802 standards. Another range of local MAC addresses isdesignated for Administratively Assigned Identifiers, which are subject to assignmentby a network administrator.¶
IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy Considerations for IEEE 802(R)Technologies")[IEEE_802E] recommends the use of temporary andtransient identifiers if there are no compelling reasons for a newly introducedidentifier to be permanent. This recommendation is part of the basis forthe review of user privacy solutions for IEEE Std 802.11 (a.k.a. Wi-Fi) devices aspart of the RCM[rcm_privacy_csd] efforts. Annex T of IEEE Std802.1AEdk-2023 ("MAC Privacy Protection")[IEEE_802.1AEdk]discusses privacy considerations in bridged networks.¶
As of 2024, two task groups in IEEE 802.11 are dealing with issues related to RCM:¶
The IEEE 802.11bh task group, which is looking at mitigating the repercussions that RCMcreates on 802.11 networks and related services.¶
The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std802.11 medium access control (MAC) specification to specify new mechanisms thataddress and improve user privacy.¶
At the Wireless Broadband Alliance (WBA), the Testing and Interoperability WorkGroup has been looking at the issues related to MAC address randomization andhas identified a list of potential impacts of these changes to existing systemsand solutions, mainly related to Wi-Fi identification.¶
As part of this work, WBA has documented a set of use cases that a Wi-FiIdentification Standard should address in order to scale and achieve longer-termsustainability of deployed services. A first version of this document has beenliaised with the IETF as part of the MAC Address Device Identification forNetwork and Application Services (MADINAS) activities through the "Wi-FiIdentification In a post MAC Randomization Era v1.0" paper[wba_paper].¶
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC)for IPv6, which typically results in hosts configuring one or more "stable"addresses composed of a network prefix advertised by a local router and anInterface Identifier (IID).[RFC8064] formally updated theoriginal IPv6 IID selection mechanism to avoid generating the IID from the MACaddress of the interface (via EUI64), as this potentially allowed for trackingof a device at L3. Additionally, the prefix part of an IP address providesmeaningful insights of the physical location of the device in general, whichtogether with the IID based on the MAC address, made it easier to perform global devicetracking.¶
[RFC8981] identifies and describes the privacy issues associatedwith embedding MAC stable addressing information into IPv6 addresses (aspart of the IID). It describes an extension to IPv6 SLAAC that causes hosts to generate temporary addresses withrandomized IIDs for each prefix advertised withautoconfiguration enabled. Changing addresses over time limits the window oftime during which eavesdroppers and other information collectors may triviallyperform address-based network-activity correlation when the same address isemployed for multiple transactions by the same host. Additionally, it reducesthe window of exposure of a host as being accessible via an address that becomesrevealed as a result of active communication. These temporary addresses aremeant to be used for a short period of time (hours to days) and then deprecated. Deprecated addresses can continue to be used for already-establishedconnections but are not used to initiate new connections. New temporaryaddresses are generated periodically to replace temporary addresses that expire.In order to do so, a node produces a sequence of temporary global scopeaddresses from a sequence of IIDs that appear to be random inthe sense that it is difficult for an outside observer to predict a futureaddress (or identifier) based on a current one and it is difficult to determineprevious addresses (or identifiers) knowing only the present one. Temporaryaddresses should not be used by applications that listen for incomingconnections (as these are supposed to be waiting on permanent/well-knownidentifiers). If a node changes network and comes back to a previously visitedone, the temporary addresses that the node would use will be different, whichmight be an issue in certain networks where addresses are used for operationalpurposes (e.g., filtering or authentication).[RFC7217],summarized next, partially addresses the problems aforementioned.¶
[RFC7217] describes a method to generate IIDsthat are stable for each network interface within each subnet but changeas a host moves from one network to another. This method enables the"stability" properties of the IIDs specified in[RFC4291] to be kept, while still mitigating address-scanning attacks andpreventing correlation of the activities of a host as it moves from one networkto another. The method defined to generate the IPv6 IID is based on computing ahash function that takes the following as input: information that is stable and associated tothe interface (e.g., a local IID), stable informationassociated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 prefix,a secret key, and some other additional information. This basically ensuresthat a different IID is generated when one of the input fields changes (such asthe network or the prefix) but that the IID is the same within each subnet.¶
To mitigate the privacy threats posed by the use of MAC-derivedIIDs,[RFC8064] recommends that nodes implement[RFC7217] as the default scheme for generating stable IPv6 addresseswith SLAAC.¶
In addition to the documents above,[RFC8947] proposes a DHCPv6 extension that:¶
allows a scalable approach to link-layeraddress assignments where preassigned link-layer address assignments (such as bya manufacturer) are not possible or are unnecessary.¶
And[RFC8948] proposes DHCPv6 extensions that:¶
enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAPquadrant to the server so that the server may allocate MAC addresses in thequadrant requested by the relay or client.¶
In addition to MAC and IP addresses, some DHCP options that carry unique identifiers can also be used for tracking purposes. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses.[RFC7844] introduces anonymity profiles that are:¶
designed for clients thatwish to remain anonymous to the visited network¶
and that:¶
provide guidelineson the composition of DHCP or DHCPv6 messages, designed to minimize disclosureof identifying information.¶
[RFC7844] also indicates that thelink-layer address, IP address, and DHCP identifier shall evolve in synchrony.¶
This section documents different policies for MAC address selection. Some OSesmight use a combination of multiple policies.¶
Note about the naming convention used: The "M" in "MAC" is included in theacronym but not the "A" from "Address". This allows one to talk about a PVOMAddress or PNGM Address.¶
This form of MAC address selection is the historical default.¶
The vendor obtains an Organizationally Unique Identifier (OUI) from the IEEE. This is a 24-bit prefix (including two upper bits that are set specifically) that is assigned to the vendor. The vendor generates a unique 24-bit value for the lower 24 bits, forming the 48-bit MAC address. It is not unusual for the 24-bit value to be taken as an incrementing counter, assigned at the factory, and burnt into non-volatile storage.¶
Note that 802.15.4 uses 64-bit MAC addresses, and the IEEE assigns 32-bit prefixes. The IEEE has indicated that there may be a future Ethernet specification that uses 64-bit MAC addresses.¶
This form of MAC address is randomly generated by the device, usually upon first boot. The resulting MAC address is stored in non-volatile storage and is used for the rest of the device lifetime.¶
This form of MAC address is randomly generated by the device each time the device is booted. The resulting MAC address isnot stored in non-volatile storage. It does not persist across power cycles. This case may sometimes be a PDGM where the non-volatile storage is no longer functional (or has failed).¶
This form of MAC address is generated each time a new network attachment is created.¶
This is typically used with Wi-Fi (802.11) networks where the network is identified by an SSID Name. The generated address is stored in non-volatile storage, indexed by the SSID. Each time the device returns to a network with the same SSID, the device uses the saved MAC address.¶
It is possible to use PNGM for wired Ethernet connections through some passive observation of network traffic (such as STP[IEEE_802.1D], the Link Layer Discovery Protocol (LLDP)[IEEE_802.1AB], DHCP, or Router Advertisements) to determine which network has been attached.¶
This form of MAC address is generated periodically, typically around every twelve hours. Like PNGM, it is used primarily with Wi-Fi.¶
When the MAC address changes, the station disconnects from the current session and reconnects using the new MAC address. This will involve a new WPA/802.1x session: new EAP, TLS, etc. negotiations. A new DHCP, SLAAC will be done.¶
If DHCP is used, then a new DHCP Unique Identifier (DUID) is generated so as to not link to the previous connection; this usually results in the allocation of new IP addresses.¶
This form of MAC address is generated on a per-session basis. How a session is defined is implementation-dependent, for example, a session might be defined by logging in to a portal, VPN, etc. Like PNGM, PSGM is used primarily with Wi-Fi.¶
Since the address only changes when a new session is established, there is no disconnection/reconnection involved.¶
By default, most modern OSes (especially mobile ones) do implement some MACaddress randomization policies. Since the mechanism and policies OSes implement can evolve with time, the content is now hosted at[OS_current_practices]. For completeness, a snapshot of the content at the time of publication of this document is included below. Note that the extensive testing reported in this document was conducted in 2021, but no significant changes have been detected at the time of publication of this document.¶
Table 1 summarizes currentpractices for Android and iOS at the time of writing this document (the original source is availableat[private_mac]) and includesupdates based on findings from the authors.¶
| Android 10+ | iOS 14+ |
|---|---|
| The randomized MAC address is bound to the SSID. | The randomized MAC address is bound to the Basic SSID. |
| The randomized MAC address is stable across reconnections for the same network. | The randomized MAC address is stable across reconnections for the same network. |
| The randomized MAC address does not get re-randomized when the device forgets a Wi-Fi network. | The randomized MAC address is reset when the device forgets a Wi-Fi network. |
| MAC address randomization is enabled by default for all the new Wi-Fi networks. But if the device previously connected to a Wi-Fi network identifying itself with the real MAC address, no randomized MAC address will be used (unless manually enabled). | MAC address randomization is enabled by default for all the new Wi-Fi networks. |
In September 2021, we performed some additional tests to evaluate how OSesthat are widely used behave regarding MAC address randomization.Table 2 summarizes our findings;the rows in the table show whether the OS performs address randomization pernetwork (PNGM according to the taxonomy introduced inSection 6), per new connection (PSGM), daily (PPGM with a period of24 hours), supports configuration per SSID, supports address randomization forscanning, and whether it does that by default.¶
| OS | Linux (Debian "bookworm") | Android 10 | Windows 10 | iOS 14+ |
|---|---|---|---|---|
| Random per net. (PNGM) | Y | Y | Y | Y |
| Random per connec. (PSGM) | Y | N | N | N |
| Random daily (PPGM) | N | N | Y | N |
| SSID config. | Y | N | N | N |
| Random. for scan | Y | Y | Y | Y |
| Random. for scan by default | N | Y | N | Y |
According to[privacy_android], starting in Android 12, Androiduses non-persistent randomization in the following situations: (i) a networksuggestion application specifies that non-persistent randomization be used for thenetwork (through an API), or (ii) the network is an open network that hasn'tencountered a captive portal, and an internal config option is set to do so (bydefault, it is not).¶
This document has no IANA actions.¶
Privacy considerations regarding tracking the location of a user through the MACaddress of a device are discussed throughout this document. Given theinformational nature of this document, no protocols/solutions are specified, butthe current state of affairs is documented.¶
Any future specification in this area would need to look into security andprivacy aspects, such as, but not limited to the following: (i) mitigating the problem oflocation privacy while minimizing the impact on upper layers of the protocolstack, (ii) providing the means for network operators to authenticate devicesand authorize network access, despite the MAC addresses changing followingsome pattern, and (iii) providing the means for the device not to use MACaddresses that it is not authorized to use or that are currently in use.¶
A major conclusion of the work in IEEE Std 802E concerned the difficulty ofdefending privacy against adversaries of any sophistication. Individuals can be successfully tracked by fingerprinting,using aspects of their communication other than MAC addresses or other permanentidentifiers.¶
The authors would like to thankGuillermo Sanchez Illan for the extensive testsperformed on different OSes to analyze their behavior regarding addressrandomization.¶
The authors would also like to thankJerome Henry,Hai Shalom,Stephen Farrell,Alan DeKok,Mathieu Cunche,Johanna Ansohn McDougall,Peter Yee,Bob Hinden,Behcet Sarikaya,David Farmer,Mohamed Boucadair,Éric Vyncke,Christian Amsüss,Roman Danyliw,Murray Kucherawy, andPaul Wouters for their reviews and comments onprevious draft versions of this document. In addition, the authors would like to thankMichael Richardson for his contributions on the taxonomy section. Finally, the authors wouldlike to thank the IEEE 802.1 Working Group for its review and comments, performed as part of the "Liaison statement on Randomized and Changing MAC Address" (https://datatracker.ietf.org/liaison/1884/).¶