MAC address randomization
Juan Carlos Zuniga
CISCO
Montreal
QC
Canada
juzuniga@cisco.com
Carlos J. Bernardos, Ed.
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid
28911
Spain
+34 91624 6236
cjbc@it.uc3m.es
http://www.it.uc3m.es/cjbc/
Amelia Andersdotter
Sky UK Group, Sky Labs
Chatham Way
Brentwood
CM14 4DZ
UK
amelia.ietf@andersdotter.cc
Internet
MADINAS
Internet privacy has become a major concern over the past few years. Users are becoming more aware that their online activity leaves a vast digital footprint, that communications are not always properly secured, and that their location and actions can be easily tracked. One of the main factors for the location tracking issue is the wide use of long-lasting identifiers, such as MAC addresses.
There have been several initiatives at the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities, with the intention to inform the technical community about them, and help coordinate between present and future standardization activities.

Introduction
Internet privacy is becoming a huge concern, as more and more mobile devices are getting directly (e.g., via cellular or Wi-Fi) or indirectly (e.g., via a smartphone using Bluetooth) connected to the Internet. This ubiquitous connectivity, together with not very secure protocol stacks and the lack of proper education about privacy make it very easy to track/monitor the location of users and/or eavesdrop their physical and online activities. This is due to many factors, such as the vast digital footprint that users leave on the Internet, for instance sharing information on social networks, cookies used by browsers and servers to provide a better navigation experience, connectivity logs that allow tracking of a user’s Layer-2 (L2/MAC) or Layer-3 (L3) address, web trackers, etc.; and/or the weak (or even null in some cases) authentication and encryption mechanisms used to secure communications.
This privacy concern affects all layers of the protocol stack, from the lower layers involved in the actual access to the network (e.g., the MAC/Layer-2 and Layer-3 addresses can be used to obtain the location of a user) to higher layer protocol identifiers and user applications [wifi_internet_privacy]. In particular, IEEE 802 MAC addresses have historically been an easy target for tracking users [wifi_tracking].
There have been several initiatives at the IETF and the IEEE 802 standards committees to overcome some of these privacy issues. This document provides an overview of these activities, with the intention to inform the community and help coordinate between present and futures standardization activities.

Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The following terms are used in this document:
MAC: Medium Access Control

Background

MAC address usage
Most mobile devices used today are Wi-Fi enabled (i.e. they are equipped with an IEEE 802.11 wireless local area network interface). Wi-Fi interfaces, as any other kind of IEEE 802-based network interface, like Ethernet (i.e. IEEE 802.3) have a Layer-2 address also referred to as MAC address, which can be seen by anybody who can receive the signal transmitted by the network interface. The format of these addresses is shown in Figure 1.

IEEE 802 MAC Address Format

        +--------+--------+---------+--------+--------+---------+
        |  Organizationally Unique  |     Network Interface     |
        |     Identifier (OUI)      | Controller (NIC) Specific |
        +--------+--------+---------+--------+--------+---------+
       /          \
      /            \
     /              \          b0 (U/L bit):
    /                \             0: unicast
   /                  \            1: multicast
  /                    \
 /                      \      b1:
+--+--+--+--+--+--+--+--+          0: globally unique (OUI enforced)
|b7|b6|b5|b4|b3|b2|b1|b0|          1: locally administered
+--+--+--+--+--+--+--+--+

MAC addresses can either be universally administered or locally administered. Universally administered and locally administered addresses are distinguished by setting the second-least-significant bit of the most significant byte of the address (the U/L bit).
A universally administered address is uniquely assigned to a device by its manufacturer. Most physical devices are provided with a universally administered address, which is composed of two parts: (i) the Organizationally Unique Identifier (OUI), which are the first three octets in transmission order and identify the organization that issued the identifier, and (ii) Network Interface Controller (NIC) Specific, which are the following three octets, assigned by the organization that manufactured the NIC, in such a way that the resulting MAC address is globally unique.
Locally administered addresses override the burned-in address, and they can either 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 further sections of this document, there are new initiatives at the IEEE 802 and other organizations to specify ways in which these locally administered addresses should be assigned, depending on the use case.

MAC address randomization
Since universally administered MAC addresses are by definition globally-unique, when a device uses this MAC address to transmit data -especially over the air- it is relatively easy to track this device by simple medium observation. Since a device is usually directly associated to an individual, this poses a privacy concern [link_layer_privacy].
MAC addresses can be easily observed by a third party, such as a passive device listening to communications in the same network. In an 802.11 network, a station exposes its MAC address in two different situations:
- While actively scanning for available networks, the MAC address is used in the Probe Request frames sent by the device (aka IEEE 802.11 STA).
- Once associated to a given Access Point (AP), the MAC address is used in frame transmission and reception, as one of the addresses used in the address fields of an IEEE 802.11 frame.
One way to overcome this privacy concern is by using randomly generated MAC addresses. As described in the previous section, the IEEE 802 addressing includes one bit to specify if the hardware address is locally or globally administered. This allows generating local addresses without the need of any global coordination mechanism to ensure that the generated address is still unique within the local network. This feature can be used to generate random addresses, which decouple the globally-unique identifier from the device and therefore make it more difficult to track a user device from its MAC/L2 address [enhancing_location_privacy].

Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802 meetings
As an outcome to the STRINT W3C/IAB Workshop [strint], on July 2014 a Tutorial on Pervasive Surveillance of the Internet - Designing Privacy into Internet Protocols was given at the IEEE 802 Plenary meeting in San Diego [privacy_tutorial]. The Tutorial provided an update on the recent developments regarding Internet privacy, the actions that other SDOs such as IETF were taking, and guidelines that were being followed when developing new Internet protocol specifications (e.g. [RFC6973]). The Tutorial highlighted some Privacy concerns applicable specifically to Link Layer technologies and provided suggestions on how IEEE 802 could help addressing them.
Following the discussions and interest within the IEEE 802 community, on 18 July 2014 the IEEE 802 Executive Committee (EC) created an IEEE 802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. The work and discussions from the group have generated multiple outcomes, such as: 802E PAR: Recommended Practice for Privacy Considerations for IEEE 802 Technologies [IEEE_802E], and the 802c PAR: Standard for Local and Metropolitan Area Networks - Overview and Architecture Amendment - Local Medium Access Control (MAC) Address Usage [IEEE_802c].
In order to test the effects of MAC address randomization, major trials were conducted at the IETF and IEEE 802 meetings between November 2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in Berlin. The purpose of the experiments was to evaluate the use of MAC address randomization from two different perspectives: (i) the effect on the connectivity experience of the end-user, also checking if applications and operating systems (OSs) were affected; and (ii) the potential impact on the network infrastructure itself. Some of the findings were published in [wifi_internet_privacy].
During the experiments it was observed that the probability of address duplication in a network with this characteristics is negligible. The experiments also showed that other protocol identifiers can be correlated and therefore be used to still track an individual. Hence, effective privacy tools should not work in isolation at a single layer, but they should be coordinated with other privacy features at higher layers.
Since then, MAC randomization has further been implemented by mobile operating systems to provide better privacy for mobile phone users when connecting to public wireless networks [privacy_ios], [privacy_windows], [privacy_android].

Recent RCM activities at the IEEE 802
Practical experiences of Randomized And Changing MAC Addresses (RCM) in live devices helped researchers fine-tune their understanding of attacks against randomization mechanisms [when_mac_randomization_fails]. At IEEE 802.11 these research experiences eventually formed the basis for a specified mechanism introduced in the IEEE 802.11aq in 2018 which randomize MAC addresses that recommends mechanisms to avoid pitfalls [IEEE_802_11_aq].
More recent developments include turning on MAC randomization in mobile operating systems by default, which has an impact on the ability of network operators to personalize or customize services [rcm_user_experience_csd]. Therefore, follow-on work in the IEEE 802.11 mapped effects of potentially large uptake of randomized MAC identifiers on a number of commonly offered operator services in 2019[rcm_tig_final_report]. In the summer of 2020 this work emanated in two new standards projects with the purpose of developing mechanisms that do not decrease user privacy and enable an optimal user experience when the MAC address of a device in an Extended Service Set is randomized or changes [rcm_user_experience_par] and user privacy solutions applicable to IEEE Std 802.11 [rcm_privacy_par].
The IEEE 802.1 working group has also published a specification that defines a local MAC address space structure, known as the Structured Local Address Plan (SLAP). This structure designates a range of local MAC addresses for protocols using a Company ID (CID) assigned by the IEEE Registration Authority. Another range of local MAC addresses is designated for assignment by administrators. The specification recommends a range of local MAC addresses for use by IEEE 802 protocols [IEEE_802c].
Work within the IEEE 802.1 Security task group on privacy recommendations for all IEEE 802 network technologies has also looked into general recommendations on identifiers, reaching the conclusion that temporary and transient identifiers are preferably in network technology design if there are no compelling reasons of service quality for a newly introduced identifier to be permanent. This work has been specified in the recently published IEEE P802E: Recommended Practice for Privacy Considerations for IEEE 802 Technologies [IEEE_802E]. The IEEE P802E specification will form part of the basis for the review of user privacy solutions applicable to IEEE Std 802.11 (aka Wi-Fi) devices as part of the RCM [rcm_privacy_csd] efforts.
Currently, two task groups in IEEE 802.11 are dealing with issues related to RCM:
- The IEEE 802.11bh task group, looking at mitigating the repercussions that RCM creates on 802.11 networks and related services, and
- The IEEE 802.11bi task group, which will define modifications to the IEEE Std 802.11 medium access control (MAC) specification to specify new mechanisms that address and improve user privacy.

Recent MAC randomization-related activities at the WBA
At the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work Group has been looking at the issues related to MAC address randomization and has identified a list of potential impacts of these changes to existing systems and solutions, mainly related to Wi-Fi identification.
As part of this work, WBA has documented a set of use cases that a Wi-Fi Identification Standard should address in order to scale and achieve longer term sustainability of deployed services. A first version of this document has been liaised with the IETF as part of the MAC Address Device Identification for Network and Application Services (MADINAS) activities through the "Wi-Fi Identification In a post MAC Randomization Era v1.0" paper [wba_paper].

MAC randomization-related activities at the IETF
Several IP address assignment mechanisms such as the IPv6 stateless autoconfiguration techniques (SLAAC) [RFC4862] generate the Interface Identifier (IID) of the address from its MAC address (via EUI64), which then becomes visible to all IPv6 communication peers. This potentially allows for global tracking of a device at L3 from any point on the Internet. Besides, the prefix part of the address provides meaningful insights of the physical location of the device in general, which together with the MAC address-based IID, makes it easier to perform global device tracking.
There are some solutions that might mitigate this privacy threat, such as the use of temporary addresses [RFC4191], the use of opaque IIDs [RFC7217], [I-D.gont-6man-deprecate-eui64-based-addresses]. Next, we briefly describe how these solutions work.
[RFC4191] identifies and describes the privacy issues associated with embedding MAC stable addressing information into the IPv6 addresses (as part of the IID) and describes some mechanisms to mitigate the associated problems. The specification is meant for IPv6 nodes that auto-configure IPv6 addresses based on the MAC address (EUI-64 mechanism). It defines how to create additional addresses (generally known as "temporary addresses") based on a random interface identifier for the purpose of initiating outgoing sessions. These "random" or temporary addresses are meant to be used for a short period of time (hours to days) and would then be deprecated. Deprecated addresses can continue to be used for already established connections, but are not used to initiate new connections. New temporary addresses are generated periodically to replace temporary addresses that expire. In order to do so, a node produces a sequence of temporary global scope addresses from a sequence of interface identifiers that appear to be random in the sense that it is difficult for an outside observer to predict a future address (or identifier) based on a current one, and it is difficult to determine previous addresses (or identifiers) knowing only the present one. The main problem with the temporary addresses is that they should not be used by applications that listen for incoming connections (as these are supposed to be waiting on permanent/well-known identifiers). Besides, if a node changes network and comes back to a previously visited one, the temporary addresses that the node would use will be different, and this might be an issue in certain networks where addresses are used for operational purposes (e.g., filtering or authentication). [RFC7217], summarized next, partially addresses the problems aforementioned.
[RFC7217] defines a method for generating IPv6 IIDs 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 IID changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on MAC addresses, such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method defined to generate the IPv6 IID is based on computing a hash function which takes as input information that is stable and associated to the interface (e.g., MAC address or local interface identifier), stable information associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 prefix, and a secret key, plus some other additional information. This basically ensures that a different IID is generated when any of the input fields changes (such as the network or the prefix), but that the IID is the same within each subnet.
In addition to the former documents, [RFC8947] proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or unnecessary. [RFC8948] proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server may allocate MAC addresses in the quadrant requested by the relay or client.
Not only MAC and IP addresses can be used for tracking purposes. Some DHCP options carry unique identifiers. 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, designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information. [RFC7844] also indicates that the link-layer address, IP address, and DHCP identifier shall evolve in synchrony.

OS current practices
Since this content can evolve with time, it is now hosted at https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-practices.md

IANA Considerations
N/A.

Security Considerations
TBD.

Acknowledgments
Authors would like to thank Guillermo Sanchez Illan for the extensive tests performed on different OSes to analyze their behavior regarding address randomization.
Authors would like to thank Jerome Henry and Hai Shalom for their review and comments on previous versions of this document.

Normative References

Informative References
[wifi_internet_privacy]

Wi-Fi Internet Connectivity and Privacy: Hiding your tracks on the wireless Internet
Carlos J. Bernardos
Juan C. Zúñiga
Piers O'Hanlon
October 2015
Standards for Communications and Networking (CSCN), 2015 IEEE Conference on
[link_layer_privacy]

Privacy at the link layer
Piers O'Hanlon
J. Wright
Ian Brown
February 2014
Contribution at W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)
[enhancing_location_privacy]

Enhancing location privacy in wireless LAN through disposable interface identifiers: a quantitative analysis
M. Gruteser
D. Grunwald
2005
Mobile Networks and Applications, vol. 10, no. 3, pp. 315–325
[privacy_ios]

Use private Wi-Fi addresses in iOS 14, iPadOS 14, and watchOS 7
Apple
[strint]

A W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)
W3C/IAB
[ieee_privacy_ecsg]

IEEE 802 EC Privacy Recommendation Study Group
IEEE 802 Privacy EC SG
[privacy_tutorial]

Tutorial on Pervasive Surveillance of the Internet - Designing Privacy into Internet Protocols
Alissa Cooper
Ted Hardie
Juan-Carlos Zuniga
Lily Chen
Piers O'Hanlon
[wifi_tracking]

London's bins are tracking your smartphone
The Independent
[privacy_android]

MAC Randomization Behavior
Android Open Source Project
[privacy_windows]

Windows: How to use random hardware addresses
Microsoft
[when_mac_randomization_fails]

A Study of MAC Address Randomization in Mobile Devices and When it Fails
J. Martin
T. Mayberry
C. Donahue
L. Foppe
L. Brown
C. Riggins
E.C. Rye
D. Brown
2017
arXiv:1703.02874v2 [cs.CR]
[IEEE_802E]

IEEE 802E-2020 - IEEE Recommended Practice for Privacy Considerations for IEEE 802 Technologies
802.1 WG - 802 LAN/MAN architecture
2020
IEEE 802E
[IEEE_802c]

IEEE 802c-2017 - IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture--Amendment 2: Local Medium Access Control (MAC) Address Usage
802.1 WG - 802 LAN/MAN architecture
2017
IEEE 802c
[IEEE_802_11_aq]

IEEE 802.11aq-2018 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Preassociation Discovery
802.11 WG - Wireless LAN Working Group
2018
IEEE 802.11
[rcm_user_experience_csd]

IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on user experience mechanisms
802.11 WG RCM SG
2020
doc.:IEEE 802.11-20/1117r3
[rcm_tig_final_report]

IEEE 802.11 Randomized And Changing MAC Addresses Topic Interest Group Report
802.11 WG RCM TIG
2019
doc.:IEEE 802.11-19/1442r9
[rcm_user_experience_par]

IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on user experience mechanisms
802.11 WG RCM SG
2020
doc.:IEEE 802.11-20/742r5
[rcm_privacy_par]

IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on privacy mechanisms
802.11 WG RCM SG
2020
doc.:IEEE 802.11-19/854r7
[rcm_privacy_csd]

IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on user experience mechanisms
802.11 WG RCM SG
2020
doc.:IEEE 802.11-20/1346r1
[wba_paper]

Wi-Fi Identification Scope for Liasing - In a post MAC Randomization Era
Wireless Broadband Alliance
March 2020
doc.:WBA Wi-Fi ID Intro: Post MAC Randomization Era v1.0 - IETF liaison
[RFC2119]
[RFC6973]
[RFC4862]
[RFC4191]
[RFC7217]
[I-D.gont-6man-deprecate-eui64-based-addresses]
[RFC8947]
[RFC8948]
[RFC7844]