rfc9724.original   rfc9724.txt 
MADINAS JC. Zúñiga Internet Engineering Task Force (IETF) JC. Zúñiga
Internet-Draft CISCO Request for Comments: 9724 Cisco
Intended status: Informational CJ. Bernardos, Ed. Category: Informational CJ. Bernardos, Ed.
Expires: 16 January 2025 UC3M ISSN: 2070-1721 UC3M
A. Andersdotter A. Andersdotter
Safespring AB Safespring AB
15 July 2024 March 2025
Randomized and Changing MAC Address State of Affairs State of Affairs for Randomized and Changing Media Access Control (MAC)
draft-ietf-madinas-mac-address-randomization-15 Addresses
Abstract Abstract
Internet users are becoming more aware that their activity over the Internet users are becoming more aware that their activity over the
Internet leaves a vast digital footprint, that communications might Internet leaves a vast digital footprint, that communications might
not always be properly secured, and that their location and actions not always be properly secured, and that their location and actions
can be tracked. One of the main factors that eases tracking Internet can be tracked. One of the main factors that eases tracking of
users is the wide use of long-lasting, and sometimes persistent, Internet users is the wide use of long-lasting, and sometimes
identifiers at various protocol layers. This document focuses on MAC persistent, identifiers at various protocol layers. This document
addresses. focuses on Media Access Control (MAC) addresses.
There have been several initiatives within the IETF and the IEEE 802 There have been several initiatives within the IETF and the IEEE 802
standards committees to overcome some of these privacy issues. This standards committees to address some of the privacy issues involved.
document provides an overview of these activities to help This document provides an overview of these activities to help
coordinating standardization activities in these bodies. coordinate standardization activities in these bodies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 16 January 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9724.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background
2.1. MAC address usage . . . . . . . . . . . . . . . . . . . . 3 2.1. MAC Address Usage
2.2. MAC address randomization . . . . . . . . . . . . . . . . 4 2.2. MAC Address Randomization
2.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 2.3. Privacy Workshop, Tutorial, and Experiments at IETF and
802 meetings . . . . . . . . . . . . . . . . . . . . . . 5 IEEE 802 Meetings
3. Randomized and Changing MAC addresses activities at the IEEE 3. Activities Relating to Randomized and Changing MAC Addresses in
802 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 the IEEE 802
4. Recent MAC randomization-related activities at the WBA . . . 7 4. Recent Activities Related to MAC Address Randomization in the
5. IPv6 address randomization at the IETF . . . . . . . . . . . 8 WBA
6. A taxonomy of MAC address selection policies . . . . . . . . 9 5. IPv6 Address Randomization in the IETF
6.1. Per-Vendor OUI MAC address (PVOM) . . . . . . . . . . . . 10 6. Taxonomy of MAC Address Selection Policies
6.2. Per-Device Generated MAC address (PDGM) . . . . . . . . . 10 6.1. Per-Vendor OUI MAC Address (PVOM)
6.3. Per-Boot Generated MAC address (PBGM) . . . . . . . . . . 10 6.2. Per-Device Generated MAC Address (PDGM)
6.4. Per-Network Generated MAC address (PNGM) . . . . . . . . 10 6.3. Per-Boot Generated MAC Address (PBGM)
6.5. Per-Period Generated MAC address (PPGM) . . . . . . . . . 11 6.4. Per-Network Generated MAC Address (PNGM)
6.6. Per-Session Generated MAC address (PSGM) . . . . . . . . 11 6.5. Per-Period Generated MAC Address (PPGM)
7. OS current practices . . . . . . . . . . . . . . . . . . . . 11 6.6. Per-Session Generated MAC Address (PSGM)
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. OS Current Practices
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations
11. Informative References . . . . . . . . . . . . . . . . . . . 14 10. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
Privacy is becoming a huge concern, as more and more devices are Privacy is becoming a huge concern, as more and more devices are
getting directly (e.g., via Wi-Fi) or indirectly (e.g., via a connecting to the Internet either directly (e.g., via Wi-Fi) or
smartphone using Bluetooth) connected to the Internet. This indirectly (e.g., via a smartphone using Bluetooth). This ubiquitous
ubiquitous connectivity, together with the lack of proper education connectivity, together with the lack of proper education about
about privacy make it very easy to track/monitor the location of privacy, makes it very easy to track/monitor the location of users
users and/or eavesdrop their physical and online activities. This is and/or eavesdrop on their physical and online activities. This is
due to many factors, such as the vast digital footprint that users due to many factors, such as the vast digital footprint that users
leave on the Internet with or without their consent, for instance leave on the Internet with or without their consent and the weak (or
sharing information on social networks, cookies used by browsers and even null) authentication and encryption mechanisms used to secure
servers for various reasons, connectivity logs that allow tracking of communications. A digital footprint may include information shared
a user's Layer-2 (L2/MAC) or Layer-3 (L3) address, web trackers, on social networks, cookies used by browsers and servers for various
etc.; and/or the weak (or even null in some cases) authentication and reasons, connectivity logs that allow tracking of a user's Layer 2
encryption mechanisms used to secure communications. (L2) address (i.e., MAC address) or Layer 3 (L3) address, web
trackers, etc.
This privacy concern affects all layers of the protocol stack, from Privacy concerns affect all layers of the protocol stack, from the
the lower layers involved in the access to the network (e.g., the lower layers involved in the access to the network (e.g., MAC/L2 and
MAC/Layer-2 and Layer-3 addresses can be used to obtain the location L3 addresses can be used to obtain the location of a user) to higher-
of a user) to higher layer protocol identifiers and user applications layer protocol identifiers and user applications [CSCN2015]. In
[CSCN2015]. In particular, IEEE 802 MAC addresses have historically particular, IEEE 802 MAC addresses have historically been an easy
been an easy target for tracking users [wifi_tracking]. target for tracking users [wifi_tracking].
There have been several initiatives at the IETF and the IEEE 802 There have been several initiatives within the IETF and the IEEE 802
standards committees to overcome some of these privacy issues. This standards committees to address some of these privacy issues. This
document provides an overview of these activities to help document provides an overview of these activities to help coordinate
coordinating standardization activities within these bodies. standardization activities within these bodies.
2. Background 2. Background
2.1. MAC address usage 2.1. MAC Address Usage
Most mobile devices used today are WLAN enabled (i.e., they are Most mobile devices used today are Wi-Fi enabled (i.e., they are
equipped with an IEEE 802.11 wireless local area network interface). equipped with an IEEE 802.11 wireless local area network interface).
Wi-Fi interfaces, as any other kind of IEEE 802-based network Like any other kind of network interface based on IEEE 802 such as
interface, like Ethernet (i.e., IEEE 802.3) have a Layer-2 address Ethernet (i.e., IEEE 802.3), Wi-Fi interfaces have an L2 address
also referred to as MAC address, which can be seen by anybody who can (also referred to as a MAC address) that can be seen by anybody who
receive the radio signal transmitted by the network interface. The can receive the radio signal transmitted by the network interface.
format of these addresses (for 48-bit MAC addresses) is shown in The format of these addresses (for 48-bit MAC addresses) is shown in
Figure 1. Figure 1.
+--------+--------+---------+--------+--------+---------+ +--------+--------+---------+--------+--------+---------+
| Organizationally Unique | Network Interface | | Organizationally Unique | Network Interface |
| Identifier (OUI) | Controller (NIC) Specific | | Identifier (OUI) | Controller (NIC) Specific |
+--------+--------+---------+--------+--------+---------+ +--------+--------+---------+--------+--------+---------+
/ \ / \
/ \ / \
/ \ b0 (I/G bit): / \ b0 (I/G bit):
/ \ 0: unicast / \ 0: unicast
/ \ 1: multicast / \ 1: multicast
/ \ / \
/ \ b1 (U/L bit): / \ b1 (U/L bit):
+--+--+--+--+--+--+--+--+ 0: globally unique (OUI enforced) +--+--+--+--+--+--+--+--+ 0: globally unique (OUI enforced)
|b7|b6|b5|b4|b3|b2|b1|b0| 1: locally administered |b7|b6|b5|b4|b3|b2|b1|b0| 1: locally administered
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
Figure 1: IEEE 802 MAC Address Format (for 48-bit addresses) Figure 1: IEEE 802 MAC Address Format (for 48-Bit Addresses)
MAC addresses can either be universally administered or locally MAC addresses can be either universally or locally administered.
administered. Universally administered and locally administered Universally and locally administered addresses are distinguished by
addresses are distinguished by setting the second-least-significant setting the second least significant bit of the most significant byte
bit of the most significant byte of the address (the U/L bit). of the address (the U/L bit).
A universally administered address is uniquely assigned to a device A universally administered address is uniquely assigned to a device
by its manufacturer. Most physical devices are provided with a by its manufacturer. Most physical devices are provided with a
universally administered address, which is composed of two parts: (i) universally administered address, which is composed of two parts:
the Organizationally Unique Identifier (OUI), which are the first
three octets in transmission order and identify the organization that Organizationally Unique Identifier (OUI): The first three octets in
issued the identifier, and (ii) Network Interface Controller (NIC) transmission order, which identify the organization that issued
Specific, which are the following three octets, assigned by the the identifier.
organization that manufactured the NIC, in such a way that the
resulting MAC address is globally unique. Network Interface Controller (NIC) Specific: The following three
octets, which are 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 Locally administered addresses override the burned-in address, and
they can either be set-up by the network administrator, or by the they can be set up by either the network administrator or the
Operating System (OS) of the device to which the address pertains. Operating System (OS) of the device to which the address pertains.
However, as explained in further sections of this document, there are However, as explained in later sections of this document, there are
new initiatives at the IEEE 802 and other organizations to specify new initiatives in the IEEE 802 and other organizations to specify
ways in which these locally administered addresses should be ways in which these locally administered addresses should be
assigned, depending on the use case. assigned, depending on the use case.
2.2. MAC address randomization 2.2. MAC Address Randomization
Since universally administered MAC addresses are by definition Since universally administered MAC addresses are by definition
globally unique, when a device uses this MAC address over a shared globally unique, when a device uses this MAC address over a shared
medium to transmit data -especially over the air- it is relatively medium to transmit data -- especially over the air -- it is
easy to track this device by simple medium observation. Since a relatively easy to track this device by simple medium observation.
device is usually directly associated to an individual, this poses a Since a device is usually directly associated to an individual, this
privacy concern [link_layer_privacy]. poses a privacy concern [link_layer_privacy].
MAC addresses can be easily observed by a third party, such as a MAC addresses can be easily observed by a third party, such as a
passive device listening to communications in the same layer-2 passive device listening to communications in the same L2 network.
network. In an 802.11 network, a station exposes its MAC address in In an 802.11 network, a device (also known as an IEEE 802.11 station
two different situations: or STA) exposes its MAC address in two different situations:
* While actively scanning for available networks, the MAC address is * While actively scanning for available networks, the MAC address is
used in the Probe Request frames sent by the device (a.k.a. IEEE used in the Probe Request frames sent by the device.
802.11 STA).
* Once associated to a given Access Point (AP), the MAC address is * 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 frame transmission and reception, as one of the addresses
used in the unicast address fields of an IEEE 802.11 frame. used in the unicast address fields of an IEEE 802.11 frame.
One way to overcome this privacy concern is by using randomly One way to address this privacy concern is by using randomly
generated MAC addresses. The IEEE 802 addressing includes one bit to generated MAC addresses. IEEE 802 addressing includes one bit to
specify if the hardware address is locally or globally administered. specify if the hardware address is locally or globally administered.
This allows local addresses to be generated without the need for any
This allows generating local addresses without the need of any global global coordination mechanism to ensure that the generated address is
coordination mechanism to ensure that the generated address is still still unique within the local network. This feature can be used to
unique within the local network. This feature can be used to
generate random addresses, which decouple the globally unique generate random addresses, which decouple the globally unique
identifier from the device and therefore make it more difficult to identifier from the device and therefore make it more difficult to
track a user device from its MAC/L2 address track a user device from its MAC/L2 address
[enhancing_location_privacy]. [enhancing_location_privacy].
Note that there are reports [contact_tracing_paper] of some mobile Note that there are reports [contact_tracing_paper] of some mobile
Operating Systems (OSes) reporting persistently (every 20 minutes or OSes reporting persistently (every 20 minutes or so) on MAC addresses
so) on MAC addresses (among other information), which would defeat (as well as other information), which would defeat MAC address
MAC address randomization. While these practices might have changed randomization. While these practices might have changed by now, it
by now, it is important to highlight that privacy preserving is important to highlight that privacy-preserving techniques should
techniques should be conducted considering all layers of the protocol be conducted while considering all layers of the protocol stack.
stack.
2.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802 2.3. Privacy Workshop, Tutorial, and Experiments at IETF and IEEE 802
meetings Meetings
As an outcome to the STRINT W3C/IAB Workshop [strint], a tutorial on As an outcome to the STRINT W3C/IAB Workshop [strint], a tutorial
"Pervasive Surveillance of the Internet - Designing Privacy into titled "Pervasive Surveillance of the Internet - Designing Privacy
Internet Protocols" was given at the IEEE 802 Plenary meeting in San into Internet Protocols" [privacy_tutorial] was given at the IEEE 802
Diego [privacy_tutorial] in July of 2014. The tutorial provided an Plenary meeting in San Diego in July of 2014. The tutorial provided
update on the recent developments regarding Internet privacy, the an update on the recent developments regarding Internet privacy, the
actions undertaken by other SDOs such as IETF, and guidelines that actions undertaken by other Standards Development Organizations
were being followed when developing new Internet protocol (SDOs) like the IETF, and guidelines that were being followed when
specifications (e.g., [RFC6973]). The tutorial highlighted some developing new Internet protocol specifications (e.g., the
privacy concerns applicable specifically to link-layer technologies considerations described in [RFC6973]). The tutorial highlighted
and provided suggestions on how IEEE 802 could help addressing them. some privacy concerns that apply specifically to link-layer
technologies and provided suggestions on how IEEE 802 could help
address them.
Following the discussions and interest within the IEEE 802 community, Following the discussions and interest within the IEEE 802 community,
on 18 July 2014 the IEEE 802 Executive Committee (EC) created an IEEE on 18 July 2014, the IEEE 802 Executive Committee (EC) created the
802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. IEEE 802 EC Privacy Recommendation Study Group (SG)
The work and discussions from the group have generated multiple [ieee_privacy_ecsg]. The work and discussions from the group have
outcomes, such as: 802E PAR (Project Authorization Request, this is generated multiple outcomes, such Project Authorization Requests
the means by which standards projects are started within the IEEE. (PARs) that resulted in the following documents:
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
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, trials * "IEEE Recommended Practice for Privacy Considerations for IEEE
were conducted at the IETF and IEEE 802 meetings between November 802(R) Technologies" [IEEE_802E]
2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in Berlin.
The purpose of the trials 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 OSes were affected; and (ii) the potential impact on
the network infrastructure itself. Some of the findings were
published in [CSCN2015].
During the trials it was observed that the probability of address * "IEEE Standard for Local and Metropolitan Area Networks: Overview
duplication in a network is negligible. The trials also revealed and Architecture - Amendment 2: Local Medium Access Control (MAC)
that other protocol identifiers (e.g., DHCP client identifier) can be Address Usage" [IEEE_802c]
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 In order to test the effects of MAC address randomization,
OSes to provide better privacy for mobile phone users when connecting experiments were conducted at the IETF and IEEE 802 meetings between
to public wireless networks [privacy_ios], [privacy_windows], November 2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802
[privacy_android]. Plenary in Berlin. The purpose of the experiments was to evaluate
the use of MAC address randomization from two different perspectives:
(1) the effect on the connectivity experience of the end user, as
well as any effect on applications and OSes, and (2) the potential
impact on the network infrastructure itself. Some of the findings
were published in [CSCN2015].
3. Randomized and Changing MAC addresses activities at the IEEE 802 During the experiments, it was observed that the probability of
address duplication in a network is negligible. The experiments also
revealed that other protocol identifiers (e.g., the DHCP client
identifier) can be correlated and can therefore still be used to
track an individual. Hence, effective privacy tools should not work
in isolation at a single layer; instead; they should be coordinated
with other privacy features at higher layers.
Practical experiences of Randomized and Changing MAC addresses (RCM) Since then, MAC address randomization has been further implemented by
in devices (some of them are explained in Section Section 6) helped mobile OSes to provide better privacy for mobile phone users when
connecting to public wireless networks [privacy_ios]
[privacy_windows] [privacy_android].
3. Activities Relating to Randomized and Changing MAC Addresses in the
IEEE 802
Practical experiences with Randomized and Changing MAC addresses
(RCM) in devices (some of which are explained in Section 6) helped
researchers fine-tune their understanding of attacks against researchers fine-tune their understanding of attacks against
randomization mechanisms [when_mac_randomization_fails]. At the IEEE randomization mechanisms [when_mac_randomization_fails]. Within the
802.11 group these research experiences eventually formed the basis IEEE 802.11 group, these research experiences eventually formed the
for a specified mechanism introduced in the IEEE 802.11aq in 2018 basis for a specified mechanism that randomizes MAC addresses, which
which randomize MAC addresses [IEEE_802_11_aq]. was introduced in IEEE Std 802.11aq [IEEE_802.11aq] in 2018.
More recent developments include turning on MAC randomization in More recent developments include turning on MAC address randomization
mobile OSes by default, which has an impact on the ability of network in mobile OSes by default, which has an impact on the ability of
operators to customize services [rcm_user_experience_csd]. network operators to customize services [rcm_user_experience_csd].
Therefore, follow-on work in the IEEE 802.11 mapped effects of Therefore, follow-on work in the IEEE 802.11 mapped effects of a
potentially large uptake of randomized MAC identifiers on a number of potentially large uptake of randomized MAC identifiers on a number of
commonly offered operator services in 2019[rcm_tig_final_report]. In commonly offered operator services in 2019 [rcm_tig_final_report].
the summer of 2020 this work emanated in two new standards projects In the summer of 2020, this work emanated in two new standards
with the purpose of developing mechanisms that do not decrease user projects. The purpose of these projects was to develop mechanisms
privacy but enable an optimal user experience when the MAC address of that do not decrease user privacy but enable an optimal user
a device in an Extended Service Set (a group of interconnected IEEE experience when (1) the MAC address of a device in an Extended
802.11 wireless access points and stations that form a single logical Service Set (a group of interconnected IEEE 802.11 wireless access
network) is randomized or changes [rcm_user_experience_par] and user points and stations that form a single logical network) is randomized
privacy solutions applicable to IEEE Std 802.11 [rcm_privacy_par]. or changes [rcm_user_experience_par] and (2) user privacy solutions
described in IEEE Std 802.11 [rcm_privacy_par] apply.
IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017 IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017
[IEEE_802c], specifies a local MAC address space structure known as [IEEE_802c], specifies a local MAC address space structure known as
the Structured Local Address Plan (SLAP) [RFC8948]. The SLAP the Structured Local Address Plan (SLAP) [RFC8948]. The SLAP
designates a range of Extended Local Identifiers for subassignment designates a range of Extended Local Identifiers for subassignment
within a block of addresses assigned by the IEEE Registration within a block of addresses assigned by the IEEE Registration
Authority via a Company ID. A range of local MAC addresses is Authority via a Company ID. A range of local MAC addresses is
designated for Standard Assigned Identifiers to be specified by IEEE designated for Standard Assigned Identifiers to be specified by IEEE
802 standards. Another range of local MAC addresses is designated 802 standards. Another range of local MAC addresses is designated
for Administratively Assigned Identifiers subject to assignment by a for Administratively Assigned Identifiers, which are subject to
network administrator. assignment by a network administrator.
"IEEE Std 802E-2020: Recommended Practice for Privacy Considerations IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy
for IEEE 802 Technologies" [IEEE_802E] recommends the use of Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends
temporary and transient identifiers if there are no compelling the use of temporary and transient identifiers if there are no
reasons for a newly introduced identifier to be permanent. This compelling reasons for a newly introduced identifier to be permanent.
recommendation is part of the basis for the review of user privacy This recommendation is part of the basis for the review of user
solutions for IEEE Std 802.11 (a.k.a. Wi-Fi) devices as part of the privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi
RCM [rcm_privacy_csd] efforts. Annex T of IEEE Std 802.1AEdk-2023: devices) as part of the RCM efforts [rcm_privacy_csd]. Annex I of
MAC Privacy Protection [IEEE802.1AEdk-2023] discusses privacy IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk]
considerations in bridged networks. discusses privacy considerations in bridged networks.
As per 2024, two task groups in IEEE 802.11 are dealing with issues As of 2024, two task groups in IEEE 802.11 are dealing with issues
related to RCM: related to RCM:
* The IEEE 802.11bh task group, looking at mitigating the * The IEEE 802.11bh task group, which is looking at mitigating the
repercussions that RCM creates on 802.11 networks and related repercussions that RCM creates on 802.11 networks and related
services, and services.
* The IEEE 802.11bi task group, which is chartered to define * The IEEE 802.11bi task group, which is chartered to define
modifications to the IEEE Std 802.11 medium access control (MAC) modifications to the IEEE Std 802.11 MAC specification
specification to specify new mechanisms that address and improve [IEEE_802.11] to specify new mechanisms that address and improve
user privacy. user privacy.
4. Recent MAC randomization-related activities at the WBA 4. Recent Activities Related to MAC Address Randomization in the WBA
At the Wireless Broadband Alliance (WBA), the Testing and In the Wireless Broadband Alliance (WBA), the Testing and
Interoperability Work Group has been looking at the issues related to Interoperability Work Group has been looking at issues related to MAC
MAC address randomization and has identified a list of potential address randomization and has identified a list of potential impacts
impacts of these changes to existing systems and solutions, mainly of these changes to existing systems and solutions, mainly related to
related to Wi-Fi identification. Wi-Fi identification.
As part of this work, WBA has documented a set of use cases that a As part of this work, the WBA has documented a set of use cases that
Wi-Fi Identification Standard should address in order to scale and a Wi-Fi Identification Standard should address in order to scale and
achieve longer term sustainability of deployed services. A first achieve longer-term sustainability of deployed services (see
version of this document has been liaised with the IETF as part of [wba_paper]).
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].
5. IPv6 address randomization at the IETF 5. IPv6 Address Randomization in the IETF
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
IPv6, which typically results in hosts configuring one or more IPv6, which typically results in hosts configuring one or more
"stable" addresses composed of a network prefix advertised by a local "stable" addresses composed of a network prefix advertised by a local
router, and an Interface Identifier (IID). [RFC8064] formally router and an Interface Identifier (IID). [RFC8064] formally updated
updated the original IPv6 IID selection mechanism to avoid generating the original IPv6 IID selection mechanism to avoid generating the IID
the IID from the MAC address of the interface (via EUI64), as this from the MAC address of the interface (via EUI64), as this
potentially allowed for tracking of a device at L3. Additionally, potentially allowed for tracking of a device at L3. Additionally,
the prefix part of an IP address provides meaningful insights of the the prefix part of an IP address provides meaningful insights of the
physical location of the device in general, which together with the physical location of the device in general, which together with the
MAC address-based IID, made it easier to perform global device IID based on the MAC address, made it easier to perform global device
tracking. tracking.
[RFC8981] identifies and describes the privacy issues associated with [RFC8981] identifies and describes the privacy issues associated with
embedding MAC stable addressing information into the IPv6 addresses embedding MAC stable addressing information into IPv6 addresses (as
(as part of the IID). It describes an extension to IPv6 SLAAC that part of the IID). It describes an extension to IPv6 SLAAC that
causes hosts to generate temporary addresses with randomized causes hosts to generate temporary addresses with randomized IIDs for
interface identifiers for each prefix advertised with each prefix advertised with autoconfiguration enabled. Changing
autoconfiguration enabled. Changing addresses over time limits the addresses over time limits the window of time during which
window of time during which eavesdroppers and other information eavesdroppers and other information collectors may trivially perform
collectors may trivially perform address-based network-activity address-based network-activity correlation when the same address is
correlation when the same address is employed for multiple employed for multiple transactions by the same host. Additionally,
transactions by the same host. Additionally, it reduces the window it reduces the window of exposure of a host as being accessible via
of exposure of a host as being accessible via an address that becomes an address that becomes revealed as a result of active communication.
revealed as a result of active communication. These temporary These temporary addresses are meant to be used for a short period of
addresses are meant to be used for a short period of time (hours to time (hours to days) and then deprecated. Deprecated addresses can
days) and would then be deprecated. Deprecated addresses can continue to be used for already-established connections but are not
continue to be used for already established connections, but are not
used to initiate new connections. New temporary addresses are used to initiate new connections. New temporary addresses are
generated periodically to replace temporary addresses that expire. generated periodically to replace temporary addresses that expire.
In order to do so, a node produces a sequence of temporary global To generate temporary addresses, a node produces a sequence of
scope addresses from a sequence of interface identifiers that appear temporary global scope addresses from a sequence of IIDs that appear
to be random in the sense that it is difficult for an outside to be random in the sense that (1) it is difficult for an outside
observer to predict a future address (or identifier) based on a observer to predict a future address (or identifier) based on a
current one, and it is difficult to determine previous addresses (or current one and (2) it is difficult to determine previous addresses
identifiers) knowing only the present one. Temporary addresses (or identifiers) knowing only the present one. Temporary addresses
should not be used by applications that listen for incoming should not be used by applications that listen for incoming
connections (as these are supposed to be waiting on permanent/well- connections (as these are supposed to be waiting on permanent/well-
known identifiers). If a node changes network and comes back to a known identifiers). If a node changes network and comes back to a
previously visited one, the temporary addresses that the node would previously visited one, the temporary addresses that the node would
use will be different, and this might be an issue in certain networks use will be different, which might be an issue in certain networks
where addresses are used for operational purposes (e.g., filtering or where addresses are used for operational purposes (e.g., filtering or
authentication). [RFC7217], summarized next, partially addresses the authentication). [RFC7217], summarized next, partially addresses the
problems aforementioned. problems aforementioned.
[RFC7217] describes a method to generate Interface Identifiers that [RFC7217] describes a method to generate IIDs that are stable for
are stable for each network interface within each subnet, but that each network interface within each subnet but change as a host moves
change as a host moves from one network to another. This method from one network to another. This method enables the "stability"
enables keeping the "stability" properties of the Interface properties of the IIDs specified in [RFC4291] to be kept, while still
Identifiers specified in [RFC4291], while still mitigating address- mitigating address-scanning attacks and preventing correlation of the
scanning attacks and preventing correlation of the activities of a activities of a host as it moves from one network to another. The
host as it moves from one network to another. The method defined to method defined to generate the IPv6 IID is based on computing a hash
generate the IPv6 IID is based on computing a hash function which function that takes the following as input: information that is
takes as input information that is stable and associated to the stable and associated to the interface (e.g., a local IID), stable
interface (e.g., a local interface identifier), stable information information associated to the visited network (e.g., the IEEE 802.11
associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 Service Set Identifier (SSID)), the IPv6 prefix, a secret key, and
prefix, and a secret key, plus some other additional information. some other additional information. This basically ensures that a
This basically ensures that a different IID is generated when any of different IID is generated when one of the input fields changes (such
the input fields changes (such as the network or the prefix), but as the network or the prefix) but that the IID is the same within
that the IID is the same within each subnet. each subnet.
Currently, [RFC8064] recommends nodes to implement [RFC7217] as the To mitigate the privacy threats posed by the use of MAC-derived IIDs,
default scheme for generating stable IPv6 addresses with SLAAC, to [RFC8064] recommends that nodes implement [RFC7217] as the default
mitigate the privacy threats posed by the use of MAC-derived IIDs. scheme for generating stable IPv6 addresses with SLAAC.
In addition to the former documents, [RFC8947] proposes "an extension In addition to the documents above, [RFC8947] proposes a DHCPv6
to DHCPv6 that allows a scalable approach to link-layer address extension that:
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. | allows a scalable approach to link-layer address assignments where
Some DHCP options carry unique identifiers. These identifiers can | preassigned link-layer address assignments (such as by a
enable device tracking even if the device administrator takes care of | manufacturer) are not possible or are unnecessary.
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.
6. A taxonomy of MAC address selection policies And [RFC8948] proposes DHCPv6 extensions that:
| 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.
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 that wish to remain anonymous to the visited
| network
and that:
| 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.
6. Taxonomy of MAC Address Selection Policies
This section documents different policies for MAC address selection. This section documents different policies for MAC address selection.
Some OSes might use combination of multiple of these policies. Some OSes might use a combination of multiple policies.
Note about the used naming convention: the "M" in MAC is included in | Note: The naming convention for the terms defined in this
the acronym, but not the "A" from address. This allows one to talk | section aligns with 802.11/Wi-Fi terminology in that the "A"
about a PVOM Address, or PNGM Address. | for "address" is not included in the acronym. For example,
| "PVOM" stands for "Per-Vendor OUI MAC address", and "PNGM"
| stands for "Per-Network Generated MAC address".
6.1. Per-Vendor OUI MAC address (PVOM) 6.1. Per-Vendor OUI MAC Address (PVOM)
This form of MAC address selection is the historical default. This form of MAC address selection is the historical default.
The vendor obtains an Organizationally Unique Identifier (OUI) from The vendor obtains an OUI from the IEEE. This is a 24-bit prefix
the IEEE. This has been a 24-bit prefix (including two upper bits (including two upper bits that are set specifically) that is assigned
which are set specifically) that is assigned to the vendor. The to the vendor. The vendor generates a unique 24-bit value for the
vendor generates a unique 24-bit value for the lower 24-bits, forming lower 24 bits, forming the 48-bit MAC address. It is not unusual for
the 48-bit MAC address. It has not been unusual for the 24-bit value the 24-bit value to be used as an incrementing counter that was
to be taken as an incrementing counter, assigned at the factory, and assigned at the factory and burnt into non-volatile storage.
burnt into non-volatile storage.
Note that 802.15.4 use 64-bit MAC addresses, and the IEEE assigns Note that IEEE Std 802.15.4 [IEEE_802.15.4] uses 64-bit MAC
32-bit prefixes. The IEEE has indicated that there may be a future addresses, and the IEEE assigns 32-bit prefixes. The IEEE has
Ethernet specification using 64-bit MAC addresses. indicated that there may be a future Ethernet specification that uses
64-bit MAC addresses.
6.2. Per-Device Generated MAC address (PDGM) 6.2. Per-Device Generated MAC Address (PDGM)
This form of MAC address is randomly generated by the device, usually This form of MAC address is randomly generated by the device, usually
upon first boot. The resulting MAC address is stored in non-volatile upon first boot. The resulting MAC address is stored in non-volatile
storage and is used for the rest of the device lifetime. storage and is used for the rest of the device lifetime.
6.3. Per-Boot Generated MAC address (PBGM) 6.3. Per-Boot Generated MAC Address (PBGM)
This form of MAC address is randomly generated by the device, each This form of MAC address is randomly generated by the device each
time the device is booted. The resulting MAC address is *not* stored time the device is booted. The resulting MAC address is *not* stored
in non-volatile storage. It does not persist across power cycles. in non-volatile storage. It does not persist across power cycles.
This case may sometimes be a PDGM where the non-volatile storage is This case may sometimes be a PDGM where the non-volatile storage is
no longer functional (or has failed). no longer functional (or has failed).
6.4. Per-Network Generated MAC address (PNGM) 6.4. Per-Network Generated MAC Address (PNGM)
This form of MAC address is generated each time a new network This form of MAC address is generated each time a new network
attachment is created. attachment is created.
This is typically used with Wi-Fi (802.11) networks where the network This is typically used with Wi-Fi networks (i.e., 802.11 networks)
is identified by an SSID Name. The generated address is stored on where the network is identified by an SSID Name. The generated
non-volatile storage, indexed by the SSID. Each time the device address is stored in non-volatile storage, indexed by the SSID. Each
returns to a network with the same SSID, the device uses the saved time the device returns to a network with the same SSID, the device
MAC address. uses the saved MAC address.
It is possible to use PNGM for wired Ethernet connections through It is possible to use PNGM for wired Ethernet connections through
some passive observation of network traffic, such as STP some passive observation of network traffic (such as spanning tree
[IEEE802.1D-2004], LLDP [IEEE802.1AB-2016], DHCP or Router protocols [IEEE_802.1Q], the Link Layer Discovery Protocol (LLDP)
Advertisements to determine which network has been attached. [IEEE_802.1AB], DHCP, or Router Advertisements) to determine which
network has been attached.
6.5. Per-Period Generated MAC address (PPGM) 6.5. Per-Period Generated MAC Address (PPGM)
This form of MAC address is generated periodically. Typical numbers This form of MAC address is generated periodically, typically around
are around every twelve hours. Like PNGM, it is used primarily with every twelve hours. Like PNGM, it is used primarily with Wi-Fi.
Wi-Fi.
When the MAC address changes, the station disconnects from the When the MAC address changes, the station disconnects from the
current session and reconnects using the new MAC address. This will current session and reconnects using the new MAC address. This will
involve a new WPA/802.1x session: new EAP, TLS, etc. negotiations. A involve a new 802.1x session, as well as obtaining or refreshing a
new DHCP, SLAAC will be done. new IP address (e.g., using DHCP or SLAAC).
If DHCP is used, then a new DUID is generated so as to not link to If DHCP is used, then a new DHCP Unique Identifier (DUID) is
the previous connection, and the result is usually new IP addresses generated so as to not link to the previous connection; this usually
allocated. results in the allocation of new IP addresses.
6.6. Per-Session Generated MAC address (PSGM) 6.6. Per-Session Generated MAC Address (PSGM)
This form of MAC address is generated on a per session basis. How a This form of MAC address is generated on a per-session basis. How a
session is defined is implementation-dependant, for example, a session is defined is implementation-dependent, for example, a
session might be defined by logging in a portal, VPN, etc. Like session might be defined by logging in to a portal, VPN, etc. Like
PNGM, it is used primarily with Wi-Fi. PNGM and PPGM, it is used primarily with Wi-Fi.
Since the address changes only when a new session is established, Since the address only changes when a new session is established,
there is no disconnection/reconnection involved. there is no disconnection/reconnection involved.
7. OS current practices 7. OS Current Practices
Most modern OSes (especially mobile ones) do implement by default By default, most modern OSes (especially mobile ones) do implement
some MAC address randomization policy. Since the mechanism and some MAC address randomization policies. Since the mechanism and
policies OSes implement can evolve with time, the content is now policies that OSes implement can evolve with time, the content is
hosted at https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac- hosted at <https://wiki.ietf.org/en/group/madinas/RFC9724>. For
address-randomization/blob/main/OS-current-practices.md. For
completeness, a snapshot of the content at the time of publication of completeness, a snapshot of the content at the time of publication of
this document is included below. Note that the extensive testing this document is included below. Note that the extensive testing
reported in this document was conducted in 2021, but no significant reported in this document was conducted in 2021, but no significant
changes have been detected at the time of publication of this changes have been detected at the time of publication of this
document. document.
Table 1 summarizes current practices for Android and iOS, as the time Table 1 summarizes current practices for Android and iOS at the time
of writing this document (original source posted at: of writing this document (the original source is available at
https://www.fing.com/news/private-mac-address-on-ios-14, latest [private_mac]) and also includes updates based on findings from the
wayback machine's snapshot available here: authors.
https://web.archive.org/web/20230905111429/https://www.fing.com/news/
private-mac-address-on-ios-14, updated based on findings from the
authors).
+=============================================+===================+ +=============================================+===================+
| Android 10+ | iOS 14+ | | Android 10+ | iOS 14+ |
+=============================================+===================+ +=============================================+===================+
| The randomized MAC address is bound to the | The randomized | | The randomized MAC address is bound to the | The randomized |
| SSID | MAC address is | | SSID. | MAC address is |
| | bound to the | | | bound to the |
| | Basic SSID | | | Basic SSID. |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+ +---------------------------------------------+-------------------+
| The randomized MAC address is stable across | The randomized | | The randomized MAC address is stable across | The randomized |
| reconnections for the same network | MAC address is | | reconnections for the same network. | MAC address is |
| | stable across | | | stable across |
| | reconnections for | | | reconnections for |
| | the same network | | | the same network. |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+ +---------------------------------------------+-------------------+
| The randomized MAC address does not get re- | The randomized | | The randomized MAC address does not get re- | The randomized |
| randomized when the device forgets a WiFI | MAC address is | | randomized when the device forgets a Wi-Fi | MAC address is |
| network | reset when the | | network. | reset when the |
| | device forgets a | | | device forgets a |
| | WiFI network | | | Wi-Fi network. |
+---------------------------------------------+-------------------+
+---------------------------------------------+-------------------+ +---------------------------------------------+-------------------+
| MAC address randomization is enabled by | MAC address | | MAC address randomization is enabled by | MAC address |
| default for all the new Wi-Fi networks. | randomization is | | default for all the new Wi-Fi networks. | randomization is |
| But if the device previously connected to a | enabled by | | But if the device previously connected to a | enabled by |
| Wi-Fi network identifying itself with the | default for all | | Wi-Fi network identifying itself with the | default for all |
| real MAC address, no randomized MAC address | the new Wi-Fi | | real MAC address, no randomized MAC address | the new Wi-Fi |
| will be used (unless manually enabled) | networks | | will be used (unless manually enabled). | networks. |
+---------------------------------------------+-------------------+ +---------------------------------------------+-------------------+
Table 1: Android and iOS MAC address randomization practices Table 1: Android and iOS MAC Address Randomization Practices
In September 2021, we have performed some additional tests to In September 2021, we performed some additional tests to evaluate how
evaluate how most widely used OSes behave regarding MAC address OSes that are widely used behave regarding MAC address randomization.
randomization. Table 2 summarizes our findings, where show on Table 2 summarizes our findings; the rows in the table show whether
different rows whether the OS performs address randomization per the OS performs address randomization per network (PNGM according to
network (PNGM according to the taxonomy introduced in Section 6), per the taxonomy introduced in Section 6), performs address randomization
new connection (PSGM), daily (PPGM with a period of 24h), supports per new connection (PSGM), performs address randomization daily (PPGM
configuration per SSID, supports address randomization for scanning, with a period of 24 hours), supports configuration per SSID, supports
and whether it does that by default. address randomization for scanning, and supports address
randomization for scanning by default.
+=================+===============+=========+=========+=====+ +=================+===============+=========+=========+=====+
| OS | Linux (Debian | Android | Windows | iOS | | OS | Linux (Debian | Android | Windows | iOS |
| | "bookworm") | 10 | 10 | 14+ | | | "bookworm") | 10 | 10 | 14+ |
+=================+===============+=========+=========+=====+ +=================+===============+=========+=========+=====+
| Random per net. | Y | Y | Y | Y | | Random. per | Y | Y | Y | Y |
| (PNGM) | | | | | | net. (PNGM) | | | | |
+-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
| Random per | Y | N | N | N | | Random. per | Y | N | N | N |
| connec. (PSGM) | | | | | | connec. (PSGM) | | | | |
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+ | Random. daily | N | N | Y | N |
| Random daily | N | N | Y | N |
| (PPGM) | | | | | | (PPGM) | | | | |
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| SSID config. | Y | N | N | N | | SSID config. | Y | N | N | N |
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| Random. for | Y | Y | Y | Y | | Random. for | Y | Y | Y | Y |
| scan | | | | | | scan | | | | |
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
+-----------------+---------------+---------+---------+-----+
| Random. for | N | Y | N | Y | | Random. for | N | Y | N | Y |
| scan by default | | | | | | scan by default | | | | |
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
Table 2: Observed behavior from different OS (as of Table 2: Observed Behavior in Different OSes (as of
September 2021) September 2021)
According to [privacy_android], starting in Android 12, Android uses According to [privacy_android], starting with Android 12, Android
non-persistent randomization in the following situations: (i) a uses non-persistent randomization in the following situations:
network suggestion app specifies that non-persistant randomization be
used for the network (through an API); or (ii) the network is an open * A network suggestion application specifies that non-persistent
network that hasn't encountered a captive portal and an internal randomization be used for the network (through an API).
config option is set to do so (by default it is not).
* The network is an open network that hasn't encountered a captive
portal, and an internal config option is set to do so (by default,
it is not).
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Security Considerations 9. Security Considerations
Privacy considerations regarding tracking the location of a user Privacy considerations regarding tracking the location of a user
through the MAC address of this device are discussed throughout this through the MAC address of a device are discussed throughout this
document. Given the informational nature of this document, no document. Given the informational nature of this document, no
protocols/solutions are specified, but current state of affairs is protocols/solutions are specified, but the current state of affairs
documented. is documented.
Any future specification in this area would have to look into Any future specification in this area would need to look into
security and privacy aspects, such as, but not limited to: i) security and privacy aspects, such as (but not limited to) the
mitigating the problem of location privacy while minimizing the following:
impact on upper layers of the protocol stack; ii) providing means to
network operators to authenticate devices and authorize network
access despite the MAC addresses changing following some pattern;
and, iii) provide means for the device not to use MAC addresses it is
not authorized to use or that are currently in use.
A major conclusion of the work in IEEE Std 802E concerned the * Mitigating the problem of location privacy while minimizing the
difficulty of defending privacy against adversaries of any impact on upper layers of the protocol stack
sophistication. Individuals can be successfully tracked by
fingerprinting using aspects of their communication other than MAC
Addresses or other permanent identifiers.
10. Acknowledgments * Providing the means for network operators to authenticate devices
and authorize network access, despite the MAC addresses changing
according some pattern
Authors would like to thank Guillermo Sanchez Illan for the extensive * Providing the means for the device not to use MAC addresses that
tests performed on different OSes to analyze their behavior regarding it is not authorized to use or that are currently in use
address randomization.
Authors would like to thank Jerome Henry, Hai Shalom, Stephen Farrel, A major conclusion of the work in IEEE Std 802E [IEEE_802E] concerned
Alan DeKok, Mathieu Cunche, Johanna Ansohn McDougall, Peter Yee, Bob the difficulty of defending privacy against adversaries of any
Hinden, Behcet Sarikaya, David Farmer, Mohamed Boucadair, Éric sophistication. Individuals can be successfully tracked by
Vyncke, Christian Amsüss, Roma Danyliw, Murray Kucherawy and Paul fingerprinting, using aspects of their communication other than MAC
Wouters for their reviews and comments on previous versions of this addresses or other permanent identifiers.
document. Authors would also like to thank Michael Richardson for
his contributions on the taxonomy section. Finally, authors would
also like 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/).
11. Informative References 10. Informative References
[contact_tracing_paper] [contact_tracing_paper]
Leith, D. J. and S. Farrell, "Contact Tracing App Privacy: Leith, D. J. and S. Farrell, "Contact Tracing App Privacy:
What Data Is Shared By Europe's GAEN Contact Tracing What Data Is Shared By Europe's GAEN Contact Tracing
Apps", IEEE INFOCOM 2021 , July 2020. Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer
Communications, DOI 10.1109/INFOCOM42981.2021.9488728, May
2021, <https://ieeexplore.ieee.org/document/9488728>.
[CSCN2015] Bernardos, CJ., Zúñiga, JC., and P. O'Hanlon, "Wi-Fi [CSCN2015] Bernardos, CJ., Zúñiga, JC., and P. O'Hanlon, "Wi-Fi
Internet Connectivity and Privacy: Hiding your tracks on Internet Connectivity and Privacy: Hiding your tracks on
the wireless Internet", Standards for Communications and the wireless Internet", 2015 IEEE Conference on Standards
Networking (CSCN), 2015 IEEE Conference on , October 2015. for Communications and Networking (CSCN),
DOI 10.1109/CSCN.2015.7390443, October 2015,
<https://doi.org/10.1109/CSCN.2015.7390443>.
[enhancing_location_privacy] [enhancing_location_privacy]
Gruteser, M. and D. Grunwald, "Enhancing location privacy Gruteser, M. and D. Grunwald, "Enhancing Location Privacy
in wireless LAN through disposable interface identifiers: in Wireless LAN Through Disposable Interface Identifiers:
a quantitative analysis", Mobile Networks and A Quantitative Analysis", Mobile Networks and
Applications, vol. 10, no. 3, pp. 315-325 , 2005. Applications, vol. 10, no. 3, pp. 315-325,
DOI 10.1007/s11036-005-6425-1, June 2005,
<https://doi.org/10.1007/s11036-005-6425-1>.
[IEEE802.1AB-2016] [IEEE_802] IEEE, "IEEE Standard for Local and Metropolitan Area
IEEE 802.1, "IEEE Std 802.1AB-2016: IEEE Standard for Networks: Overview and Architecture", IEEE Std 802-2014,
Local and metropolitan area networks - Station and Media DOI 10.1109/IEEESTD.2014.6847097, June 2014,
Access Control Connectivity Discovery", 2016. <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEE802.1AEdk-2023] [IEEE_802.11]
IEEE 802.1, "IEEE Std 802.1AEdk-2023: IEEE Standard for IEEE, "IEEE Standard for Information Technology--
Local and metropolitan area networks-Media Access Control Telecommunications and Information Exchange between
(MAC) Security - Amendment 4: MAC Privacy protection", Systems - Local and Metropolitan Area Networks--Specific
2023. Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693,
February 2021,
<https://doi.org/10.1109/IEEESTD.2021.9363693>.
[IEEE802.1D-2004] [IEEE_802.11aq]
IEEE 802.1, "IEEE Std 802.1D-2004: IEEE Standard for Local IEEE, "IEEE Standard for Information technology--
and metropolitan area networks: Media Access Control (MAC) Telecommunications and information exchange between
Bridges", 2004. systems Local and metropolitan area network--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 5:
Preassociation Discovery", IEEE Std 802.11aq-2018,
DOI 10.1109/IEEESTD.2018.8457463, August 2018,
<https://doi.org/10.1109/IEEESTD.2018.8457463>.
[IEEE_802] IEEE 802, "IEEE Std 802 - IEEE Standard for Local and [IEEE_802.15.4]
Metropolitan Area Networks: Overview and Architecture", IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
IEEE 802 , 2014. Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
December 2024,
<https://doi.org/10.1109/IEEESTD.2024.10794632>.
[IEEE_802.1AB]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE_802.1AEdk]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security - Amendment
4: MAC Privacy protection", IEEE Std 802.1AEdk-2023,
DOI 10.1109/IEEESTD.2023.10225636, August 2023,
<https://doi.org/10.1109/IEEESTD.2023.10225636>.
[IEEE_802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks", IEEE Std 802.1Q-
2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022,
<https://doi.org/10.1109/IEEESTD.2022.10004498>.
[IEEE_802c] [IEEE_802c]
IEEE 802.1 WG - 802 LAN/MAN architecture, "IEEE 802c-2017 IEEE, "IEEE Standard for Local and Metropolitan Area
- IEEE Standard for Local and Metropolitan Area
Networks:Overview and Architecture--Amendment 2: Local Networks:Overview and Architecture--Amendment 2: Local
Medium Access Control (MAC) Address Usage", IEEE 802c , Medium Access Control (MAC) Address Usage", IEEE Std 802c-
2017. 2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<https://doi.org/10.1109/IEEESTD.2017.8016709>.
[IEEE_802E] [IEEE_802E]
IEEE 802.1 WG - 802 LAN/MAN architecture, "IEEE 802E-2020 IEEE, "IEEE Recommended Practice for Privacy
- IEEE Recommended Practice for Privacy Considerations for Considerations for IEEE 802(R) Technologies", IEEE Std
IEEE 802 Technologies", IEEE 802E , 2020. 802E-2020, DOI 10.1109/IEEESTD.2020.9257130, November
2020, <https://doi.org/10.1109/IEEESTD.2020.9257130>.
[IEEE_802_11_aq]
IEEE 802.11 WG - Wireless LAN Working Group, "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", IEEE 802.11 , 2018.
[ieee_privacy_ecsg] [ieee_privacy_ecsg]
IEEE 802 Privacy EC SG, "IEEE 802 EC Privacy IEEE 802 LAN/MAN Standards Committee, "IEEE 802 EC Privacy
Recommendation Study Group", Recommendation Study Group",
<http://www.ieee802.org/PrivRecsg/>. <http://www.ieee802.org/PrivRecsg/>.
[link_layer_privacy] [link_layer_privacy]
O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the
link-layer", Contribution at W3C/IAB workshop on link-layer", W3C/IAB workshop on Strengthening the
Strengthening the Internet Against Pervasive Monitoring Internet Against Pervasive Monitoring (STRINT), February
(STRINT) , February 2014. 2014.
[privacy_android] [privacy_android]
Android Open Source Project, "MAC Randomization Behavior", Android Open Source Project, "MAC randomization behavior",
Android OS Documentation,
<https://source.android.com/devices/tech/connect/wifi-mac- <https://source.android.com/devices/tech/connect/wifi-mac-
randomization-behavior>. randomization-behavior>.
[privacy_ios] [privacy_ios]
Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14, Apple Inc., "Use private Wi-Fi addresses on Apple
and watchOS 7", Devices", Apple Support,
<https://support.apple.com/en-us/HT211227>. <https://support.apple.com/en-us/102509>.
[privacy_tutorial] [privacy_tutorial]
Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P. Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P.
O'Hanlon, "Tutorial on Pervasive Surveillance of the O'Hanlon, "Pervasive Surveillance of the Internet -
Internet - Designing Privacy into Internet Protocols", Designing Privacy into Internet Protocols", IEEE 802
<https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC- Tutorial, 14 July 2014, <https://mentor.ieee.org/802-
internet-privacy-tutorial.pdf>. ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-
tutorial.pdf>.
[privacy_windows] [privacy_windows]
Microsoft, "Windows: How to use random hardware Microsoft Corporation, "How to use random hardware
addresses", <https://support.microsoft.com/en-us/windows/ addresses in Windows", Microsoft Support,
how-to-use-random-hardware-addresses-ac58de34-35fc-31ff- <https://support.microsoft.com/en-us/windows/how-to-use-
random-hardware-addresses-ac58de34-35fc-31ff-
c650-823fc48eb1bc>. c650-823fc48eb1bc>.
[private_mac]
Pantaleone, D., "Private MAC address on iOS 14", Wayback
Machine archive, September 2020,
<https://web.archive.org/web/20230905111429/
https://www.fing.com/news/private-mac-address-on-ios-14>.
[rcm_privacy_csd] [rcm_privacy_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1346r1 , 2020. mechanisms", doc.:IEEE 802.11-20/1346r4, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-1346-04-0rcm-csd-draft-for-privacy-amendment-
of-rcm- project.docx>.
[rcm_privacy_par] [rcm_privacy_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on privacy Changing MAC Addresses Study Group PAR on privacy
mechanisms", doc.:IEEE 802.11-19/854r7 , 2020. mechanisms", doc.:IEEE 802.11-19/854r7, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-0854-07-0rcm-par-proposal-for-privacy.docx>.
[rcm_tig_final_report] [rcm_tig_final_report]
IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And
Changing MAC Addresses Topic Interest Group Report", Changing MAC Addresses Topic Interest Group Report",
doc.:IEEE 802.11-19/1442r9 , 2019. doc.:IEEE 802.11-19/1442r9, 2019. Download available at
<https://mentor.ieee.org/802.11/ dcn/19/11-19-1442-09-
0rcm-rcm-tig-draft-report-outline.odt>.
[rcm_user_experience_csd] [rcm_user_experience_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1117r3 , 2020. mechanisms", doc.:IEEE 802.11-20/1117r5, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-1117-05-0rcm-rcm-sg-proposed-rcm-csd-
draft.docx>.
[rcm_user_experience_par] [rcm_user_experience_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on user experience Changing MAC Addresses Study Group PAR on user experience
mechanisms", doc.:IEEE 802.11-20/742r5 , 2020. mechanisms", doc.:IEEE 802.11-20/742r6, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-0742-06-0rcm-proposed-par-draft.docx>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
skipping to change at page 17, line 46 skipping to change at line 836
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>. <https://www.rfc-editor.org/info/rfc7844>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer [RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, "Link-Layer
Address Assignment Mechanism for DHCPv6", RFC 8947, Address Assignment Mechanism for DHCPv6", RFC 8947,
DOI 10.17487/RFC8947, December 2020, DOI 10.17487/RFC8947, December 2020,
<https://www.rfc-editor.org/info/rfc8947>. <https://www.rfc-editor.org/info/rfc8947>.
[RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address [RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address
Plan (SLAP) Quadrant Selection Option for DHCPv6", Plan (SLAP) Quadrant Selection Option for DHCPv6",
RFC 8948, DOI 10.17487/RFC8948, December 2020, RFC 8948, DOI 10.17487/RFC8948, December 2020,
<https://www.rfc-editor.org/info/rfc8948>. <https://www.rfc-editor.org/info/rfc8948>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>. <https://www.rfc-editor.org/info/rfc8981>.
[strint] W3C/IAB, "A W3C/IAB workshop on Strengthening the Internet [strint] W3C/IAB, "STRINT Workshop: A W3C/IAB workshop on
Against Pervasive Monitoring (STRINT)", Strengthening the Internet Against Pervasive Monitoring
<https://www.w3.org/2014/strint/>. (STRINT)", <https://www.w3.org/2014/strint/>.
[wba_paper] [wba_paper]
Alliance, W. B., "Wi-Fi Identification Scope for Liasing - Wireless Broadband Alliance, "Wi-Fi Device Identification
In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro: - A Way Through MAC Randomization", WBA White Paper, July
Post MAC Randomization Era v1.0 - IETF liaison , March 2022, <https://wballiance.com/resource/wi-fi-device-
2020. identification-a-way-through-mac-randomization/>.
[when_mac_randomization_fails] [when_mac_randomization_fails]
Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown, Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown,
L., Riggins, C., Rye, E.C., and D. Brown, "A Study of MAC L., Riggins, C., Rye, E., and D. Brown, "A Study of MAC
Address Randomization in Mobile Devices and When it Address Randomization in Mobile Devices and When it
Fails", arXiv:1703.02874v2 [cs.CR] , 2017. Fails", arXiv:1703.02874v2, DOI 10.48550/arXiv.1703.02874,
March 2017, <https://doi.org/10.48550/arXiv.1703.02874>.
[wifi_tracking] [wifi_tracking]
The Independent, "London's bins are tracking your Vincent, J., "London's bins are tracking your smartphone",
smartphone", <https://www.independent.co.uk/life-style/ The Independent, 9 August 2013,
gadgets-and-tech/news/updated-london-s-bins-are-tracking- <https://www.independent.co.uk/life-style/gadgets-and-
your-smartphone-8754924.html>. tech/news/updated-london-s-bins-are-tracking-your-
smartphone-8754924.html>.
Acknowledgments
The authors would like to thank Guillermo Sanchez Illan for the
extensive tests performed on different OSes to analyze their behavior
regarding address randomization.
The authors would also like to thank Jerome 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, and Paul Wouters for their reviews and comments on
previous draft versions of this document. In addition, the authors
would like to thank Michael Richardson for his contributions on the
taxonomy section. Finally, the authors would like to thank the IEEE
802.1 Working Group for its review and comments (see
<https://datatracker.ietf.org/liaison/1884/>).
Authors' Addresses Authors' Addresses
Juan Carlos Zúñiga Juan Carlos Zúñiga
CISCO Cisco
Montreal QC Montreal QC
Canada Canada
Email: juzuniga@cisco.com Email: juzuniga@cisco.com
Carlos J. Bernardos (editor) Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad, 30 Av. Universidad, 30
28911 Leganes, Madrid 28911 Leganes, Madrid
Spain Spain
Phone: +34 91624 6236 Phone: +34 91624 6236
Email: cjbc@it.uc3m.es Email: cjbc@it.uc3m.es
 End of changes. 137 change blocks. 
472 lines changed or deleted 537 lines changed or added

This html diff was produced by rfcdiff 1.48.