rfc9724xml2.original.xml   rfc9724.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.2119.xml'>
<!ENTITY rfc4862 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4862.xml'>
<!ENTITY rfc6973 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.6973.xml'>
<!ENTITY rfc7217 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.7217.xml'>
<!ENTITY rfc8947 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.8947.xml'>
<!ENTITY rfc8948 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.8948.xml'>
<!ENTITY rfc7844 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.7844.xml'>
<!ENTITY rfc8981 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.8981.xml'>
<!ENTITY rfc4291 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4291.xml'>
<!ENTITY rfc8064 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.8064.xml'>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<?rfc tocompact="yes"?> etf-madinas-mac-address-randomization-15" ipr="trust200902" number="9724" consen
<?rfc tocdepth="3"?> sus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclud
<?rfc tocindent="yes"?> e="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-madinas-mac-address-randomization-15"
ipr="trust200902">
<front> <front>
<title abbrev="Randomized and Changing MAC Address"> <title abbrev="State of Affairs for Randomized and Changing MAC Addresses">S
Randomized and Changing MAC Address State of Affairs tate of Affairs for Randomized and Changing Media Access Control (MAC) Addresses
</title> </title>
<seriesInfo name="RFC" value="9724"/>
<!-- AUTHORS --> <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
<author fullname="Juan Carlos Zúñiga" <organization abbrev="Cisco">Cisco</organization>
initials="JC."
surname="Zúñiga">
<organization abbrev="CISCO">
CISCO
</organization>
<address> <address>
<postal> <postal>
<street></street>
<city>Montreal</city> <city>Montreal</city>
<code> QC</code> <region>QC</region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>juzuniga@cisco.com</email> <email>juzuniga@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos" ro
<author fullname="Carlos J. Bernardos" le="editor">
initials="CJ." <organization abbrev="UC3M">Universidad Carlos III de Madrid</organization
surname="Bernardos" role="editor"> >
<organization abbrev="UC3M">
Universidad Carlos III de Madrid
</organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Leganes, Madrid</city>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 6236</phone> <phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email> <email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri> <uri>http://www.it.uc3m.es/cjbc/</uri>
</address> </address>
</author> </author>
<author fullname="Amelia Andersdotter" initials="A." surname="Andersdotter">
<author fullname="Amelia Andersdotter" <organization abbrev="Safespring AB">Safespring AB</organization>
initials="A." <address>
surname="Andersdotter">
<organization abbrev="Safespring AB">
Safespring AB
</organization>
<address>
<email>amelia.ietf@andersdotter.cc</email> <email>amelia.ietf@andersdotter.cc</email>
</address> </address>
</author> </author>
<date year="2025" month="January"/>
<date year="2024"/> <area>INT</area>
<workgroup>madinas</workgroup>
<area>Internet</area>
<workgroup>MADINAS</workgroup>
<abstract> <abstract>
<t> <t>
Internet users are becoming more aware that their activity over the Internet lea ves a Internet users are becoming more aware that their activity over the Internet lea ves a
vast digital footprint, that communications might not always be properly vast digital footprint, that communications might not always be properly
secured, and that their location and actions can be tracked. One of the main secured, and that their location and actions can be tracked. One of the main
factors that eases tracking Internet users is the wide use of long-lasting, and factors that eases tracking of Internet users is the wide use of long-lasting, a
sometimes nd sometimes
persistent, identifiers at various protocol layers. This document focuses on MAC persistent, identifiers at various protocol layers. This document focuses on
addresses. Media Access Control (MAC) addresses.
</t> </t>
<t> <t>
There have been several initiatives within the IETF and the IEEE 802 standards There have been several initiatives within the IETF and the IEEE 802 standards
committees to overcome some of these privacy issues. This document provides an committees to address some of the privacy issues involved. This document provide
overview of these activities to help coordinating standardization activities in s an
these bodies. overview of these activities to help coordinate standardization activities in th
ese bodies.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- BEGIN Terminology --> <section anchor="sec_introduction" numbered="true" toc="default">
<section anchor="sec:introduction" title="Introduction"> <name>Introduction</name>
<t> <t>
Privacy is becoming a huge concern, as more and more devices are Privacy is becoming a huge concern, as more and more devices are connecting to
getting directly (e.g., via Wi-Fi) or indirectly (e.g., via a smartphone using the Internet either directly (e.g., via Wi-Fi) or indirectly (e.g., via a
Bluetooth) connected to the Internet. This ubiquitous connectivity, together smartphone using Bluetooth). This ubiquitous connectivity, together with the
with the lack of proper education about privacy make it very easy to lack of proper education about privacy, makes it very easy to track/monitor
track/monitor the location of users and/or eavesdrop their physical and online the location of users and/or eavesdrop on their physical and online
activities. This is due to many factors, such as the vast digital footprint that activities. This is due to many factors, such as the vast digital footprint
users leave on the Internet with or without their consent, for instance sharing that users leave on the Internet with or without their consent and the weak
information on social networks, cookies used by browsers and servers for various (or even null) authentication and encryption mechanisms used to
reasons, connectivity logs that allow tracking of a user's Layer-2 (L2/MAC) or secure communications. A digital footprint may include
Layer-3 (L3) address, web trackers, etc.; and/or the weak (or even null in some information shared on social networks, cookies used by browsers and servers
cases) authentication and encryption mechanisms used to secure communications. for various reasons, connectivity logs that allow tracking of a user's Layer 2
(L2) address (i.e., MAC address) or Layer 3 (L3) address, web trackers, etc.
</t> </t>
<t> <t>
This privacy concern affects all layers of the protocol stack, from the lower Privacy concerns affect all layers of the protocol stack, from the lower
layers involved in the access to the network (e.g., the MAC/Layer-2 and Layer-3 layers involved in the access to the network (e.g., MAC/L2 and L3
addresses can be used to obtain the location of a user) to higher layer protocol addresses can be used to obtain the location of a user) to higher-layer protocol
identifiers and user applications <xref target="CSCN2015" />. In identifiers and user applications <xref target="CSCN2015" format="default"/>. In
particular, IEEE 802 MAC addresses have historically been an easy target for particular, IEEE 802 MAC addresses have historically been an easy target for
tracking users <xref target="wifi_tracking" />. tracking users <xref target="wifi_tracking" format="default"/>.
</t> </t>
<t> <t>
There have been several initiatives at the IETF and the IEEE 802 standards There have been several initiatives within the IETF and the IEEE 802 standards
committees to overcome some of these privacy issues. This document provides an committees to address some of these privacy issues. This document provides an
overview of these activities to help coordinating standardization activities overview of these activities to help coordinate standardization activities
within these bodies. within these bodies.
</t> </t>
</section> </section>
<!-- BEGIN Problem statement --> <section anchor="sec_background" numbered="true" toc="default">
<section anchor="sec:background" title="Background"> <name>Background</name>
<section anchor="sec_mac_usage" numbered="true" toc="default">
<section anchor="sec:mac_usage" title="MAC address usage"> <name>MAC Address Usage</name>
<t> <t>
Most mobile devices used today are WLAN enabled (i.e., they are equipped with an Most mobile devices used today are WLAN enabled (i.e., they are equipped with
IEEE 802.11 wireless local area network interface). Wi-Fi interfaces, as any an IEEE 802.11 wireless local area network interface). Like any other kind of
other kind of IEEE 802-based network interface, like Ethernet (i.e., IEEE 802.3) network interface based on IEEE 802 such as Ethernet (i.e., IEEE 802.3), Wi-Fi
have a Layer-2 address also referred to as MAC address, which can be seen by interfaces have an L2 address (also referred to as a MAC address) that can be
anybody who can receive the radio signal transmitted by the network interface. T seen by anybody who can receive the radio signal transmitted by the network
he interface. The format of these addresses (for 48-bit MAC addresses) is shown
format of these addresses (for 48-bit MAC addresses) is shown in <xref target="f in <xref target="fig_ieee802_mac_address_format" format="default"/>.
ig:ieee802_mac_address_format" />.
</t> </t>
<figure anchor="fig:ieee802_mac_address_format" title="IEEE 802 MAC Address Form <figure anchor="fig_ieee802_mac_address_format">
at (for 48-bit addresses)" > <name>IEEE 802 MAC Address Format (for 48-Bit Addresses)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+--------+---------+--------+--------+---------+ +--------+--------+---------+--------+--------+---------+
| 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
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
MAC addresses can either be universally administered or locally administered. MAC addresses can be either universally or locally administered.
Universally administered and locally administered addresses are distinguished by Universally and locally administered addresses are distinguished by
setting the second-least-significant bit of the most significant byte of the setting the second least significant bit of the most significant byte of the
address (the U/L bit). address (the U/L bit).
</t> </t>
<t> <t>
A universally administered address is uniquely assigned to a device by its A universally administered address is uniquely assigned to a device by its
manufacturer. Most physical devices are provided with a universally administered manufacturer. Most physical devices are provided with a universally administered
address, which is composed of two parts: (i) the Organizationally Unique address, which is composed of two parts:</t>
Identifier (OUI), which are the first three octets in transmission order and
identify the organization that issued the identifier, and (ii) Network Interface <dl newline="false" spacing="normal">
Controller (NIC) Specific, which are the following three octets, assigned by the <dt>Organizationally Unique
Identifier (OUI):</dt><dd>The first three octets in transmission order, which
identify the organization that issued the identifier.</dd>
<dt>Network Interface
Controller (NIC) Specific:</dt><dd>The following three octets, which are assigne
d by the
organization that manufactured the NIC, in such a way that the resulting MAC organization that manufactured the NIC, in such a way that the resulting MAC
address is globally unique. address is globally unique.</dd>
</t> </dl>
<t> <t>
Locally administered addresses override the burned-in address, and they can Locally administered addresses override the burned-in address, and they can be
either be set-up by the network administrator, or by the Operating System (OS) set up by either the network administrator or the Operating System (OS) of the
of the device to which the address pertains. However, as explained in further device to which the address pertains. However, as explained in later sections
sections of this document, there are new initiatives at the IEEE 802 and other of this document, there are new initiatives in the IEEE 802 and other
organizations to specify ways in which these locally administered addresses organizations to specify ways in which these locally administered addresses
should be assigned, depending on the use case. should be assigned, depending on the use case.
</t> </t>
</section>
</section> <section anchor="sec_mac_addr_random" numbered="true" toc="default">
<!-- END Problem statement --> <name>MAC Address Randomization</name>
<t>
<!-- BEGIN MAC address randomization -->
<section anchor="sec:mac_addr_random" title="MAC address randomization">
<t>
Since universally administered MAC addresses are by definition globally unique, Since universally administered MAC addresses are by definition globally unique,
when a device uses this MAC address over a shared medium to transmit data -espec ially over the air- when a device uses this MAC address over a shared medium to transmit data -- esp ecially over the air --
it is relatively easy to track this device by simple medium observation. Since a 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 device is usually directly associated to an individual, this poses a privacy
concern <xref target="link_layer_privacy"/>. concern <xref target="link_layer_privacy" format="default"/>.
</t> </t>
<t> <t>
MAC addresses can be easily observed by a third party, such as a passive device MAC addresses can be easily observed by a third party, such as a passive device
listening to communications in the same layer-2 network. In an 802.11 network, a station listening to communications in the same L2 network. In an 802.11 network, a stat ion (STA)
exposes its MAC address in two different situations: exposes its MAC address in two different situations:
</t> </t>
<ul spacing="normal">
<li>
<t><list style="symbols"> <t>
<t>
While actively scanning for available networks, the MAC address is used in the While actively scanning for available networks, the MAC address is used in the
Probe Request frames sent by the device (a.k.a. IEEE 802.11 STA). Probe Request frames sent by the device.
</t> </t>
</li>
<t> <li>
<t>
Once associated to a given Access Point (AP), the MAC address is used in frame 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 unicast address fields transmission and reception, as one of the addresses used in the unicast address fields
of an IEEE 802.11 frame. of an IEEE 802.11 frame.
</t> </t>
</list></t> </li>
</ul>
<t> <t>
One way to overcome this privacy concern is by using randomly generated MAC One way to address this privacy concern is by using randomly generated MAC
addresses. The IEEE 802 addressing includes one bit to specify if the hardware addresses. IEEE 802 addressing includes one bit to specify if the hardware
address is locally or globally administered. This allows generating local address is locally or globally administered. This allows local
addresses without the need of any global coordination mechanism to ensure that addresses to be generated without the need for any global coordination mechanism
to ensure that
the generated address is still unique within the local network. This feature can the generated address is still unique within the local network. This feature can
be used to generate random addresses, which decouple the globally unique 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 identifier from the device and therefore make it more difficult to track a user
device from its MAC/L2 address <xref target="enhancing_location_privacy" />. device from its MAC/L2 address <xref target="enhancing_location_privacy" format=
</t> "default"/>.
</t>
<t> <t>
Note that there are reports <xref target="contact_tracing_paper" /> of some Note that there are reports <xref target="contact_tracing_paper" format="default
mobile Operating Systems (OSes) reporting persistently (every 20 minutes or so) "/> of some
on MAC addresses (among other information), which would defeat MAC address mobile OSes reporting persistently (every 20 minutes or so)
on MAC addresses (as well as other information), which would defeat MAC address
randomization. While these practices might have changed by now, it is important randomization. While these practices might have changed by now, it is important
to highlight that privacy preserving techniques should be conducted considering to highlight that privacy-preserving techniques should be conducted while consid ering
all layers of the protocol stack. all layers of the protocol stack.
</t> </t>
</section>
</section> <section anchor="sec_mac_addr_experiments" numbered="true" toc="default">
<name>Privacy Workshop, Tutorial, and Experiments at IETF and IEEE 802 M
<section anchor="sec:mac_addr_experiments" title="Privacy Workshop, Tutorial eetings</name>
and Experiments at IETF and IEEE 802 meetings"> <t>
As an outcome to the STRINT W3C/IAB Workshop <xref target="strint" format="defau
<t> lt"/>, a
As an outcome to the STRINT W3C/IAB Workshop <xref target="strint" />, a tutorial titled "Pervasive Surveillance of the Internet - Designing Privacy into
tutorial on "Pervasive Surveillance of the Internet - Designing Privacy into Internet Protocols" <xref target="privacy_tutorial" format="default"/> was given
Internet Protocols" was given at the IEEE 802 Plenary meeting in San Diego <xref at the IEEE 802 Plenary meeting in San Diego in July of 2014. The tutorial prov
target="privacy_tutorial" /> in July of 2014. The tutorial provided an update on ided an update on
the recent developments regarding Internet privacy, the actions undertaken by the recent developments regarding Internet privacy, the actions undertaken by
other SDOs such as IETF, and guidelines that were being followed when developing other Standards Development Organizations (SDOs) like the IETF, and guidelines t
new Internet protocol specifications (e.g., <xref target="RFC6973" />). The hat were being followed when developing
tutorial highlighted some privacy concerns applicable specifically to link-layer new Internet protocol specifications (e.g., the considerations described in <xre
technologies and provided suggestions on how IEEE 802 could help addressing f target="RFC6973" format="default"/>). The
tutorial highlighted some privacy concerns that apply specifically to link-layer
technologies and provided suggestions on how IEEE 802 could help address
them. them.
</t> </t>
<t> <t>
Following the discussions and interest within the IEEE 802 community, on 18 July 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 2014, the IEEE 802 Executive Committee (EC) created the IEEE 802 EC Privacy
Recommendation Study Group (SG) <xref target="ieee_privacy_ecsg" />. The work Recommendation Study Group (SG) <xref target="ieee_privacy_ecsg" format="default
and discussions from the group have generated multiple outcomes, such as: 802E "/>. The work
and discussions from the group have generated multiple outcomes, such as:
802E
PAR (Project Authorization Request, this is the means by which standards project s are started within the IEEE. PARs define the scope, purpose, and contact point s for a new project): Recommended Practice for Privacy Considerations for IEEE 8 02 Technologies PAR (Project Authorization Request, this is the means by which standards project s are started within the IEEE. PARs define the scope, purpose, and contact point s for a new project): Recommended Practice for Privacy Considerations for IEEE 8 02 Technologies
<xref target="IEEE_802E" />, and the 802c PAR: Standard for Local and <xref target="IEEE_802E" format="default"/>, and the 802c PAR: Standard for Loca
Metropolitan Area Networks - Overview and Architecture Amendment - Local Medium l and
Access Control (MAC) Address Usage <xref target="IEEE_802c" />. Metropolitan Area Networks - Overview and Architecture - Amendment 2: Local Medi
</t> um
Access Control (MAC) Address Usage <xref target="IEEE_802c" format="default"/>.
</t>
<t> <t>
In order to test the effects of MAC address randomization, trials were conducted In order to test the effects of MAC address randomization, experiments were cond
at the IETF and IEEE 802 meetings between November 2014 and March 2015 - IETF91, ucted
IETF92 and IEEE 802 Plenary in Berlin. The purpose of the trials was to evaluate at the IETF and IEEE 802 meetings between November 2014 and March 2015 -- IETF 9
the use of MAC address randomization from two different perspectives: (i) the 1,
effect on the connectivity experience of the end-user, also checking if IETF 92, and the IEEE 802 Plenary in Berlin. The purpose of the experiments was
applications and OSes were affected; and (ii) the potential impact on the to evaluate
network infrastructure itself. Some of the findings were published in <xref the use of MAC address randomization from two different perspectives: (1) the
target="CSCN2015" />. effect on the connectivity experience of the end user, as well as any effect on
</t> applications and OSes, and (2) the potential impact on the
network infrastructure itself. Some of the findings were published in <xref targ
et="CSCN2015" format="default"/>.
</t>
<t> <t>
During the trials it was observed that the probability of address duplication in During the experiments, it was observed that the probability of address duplicat
a network is negligible. The trials also revealed that other protocol ion in
identifiers (e.g., DHCP client identifier) can be correlated and therefore be a network is negligible. The experiments also revealed that other protocol
used to still track an individual. Hence, effective privacy tools should not identifiers (e.g., the DHCP client identifier) can be correlated and can therefo
work in isolation at a single layer, but they should be coordinated with other re 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 ot
her
privacy features at higher layers. privacy features at higher layers.
</t> </t>
<t>
<t> Since then, MAC address randomization has been further implemented by mobile OSe
Since then, MAC randomization has further been implemented by mobile OSes to s to
provide better privacy for mobile phone users when connecting to public wireless provide better privacy for mobile phone users when connecting to public wireless
networks <xref target="privacy_ios" />, <xref target="privacy_windows" />, <xref networks <xref target="privacy_ios" format="default"/> <xref target="privacy_win
target="privacy_android" />. dows" format="default"/> <xref target="privacy_android" format="default"/>.
</t> </t>
</section>
</section>
<!-- END L2 address randomization -->
</section> </section>
<!-- BEGIN Tools --> <section anchor="sec_mac_rnd_at_ieee802" numbered="true" toc="default">
<section anchor="sec:mac_rnd_at_ieee802" title="Randomized and Changing MAC <name>Activities Relating to Randomized and Changing MAC Addresses in the
addresses activities at the IEEE 802"> IEEE 802</name>
<t> <t>
Practical experiences of Randomized and Changing MAC addresses (RCM) in devices Practical experiences with Randomized and Changing MAC (RCM) addresses in
(some of them are explained in Section <xref target="rcm-types" />) devices (some of which are explained in <xref target="rcm-types"
helped researchers fine-tune their understanding of attacks against format="default"/>) helped researchers fine-tune their understanding of
randomization mechanisms <xref target="when_mac_randomization_fails" />. At the attacks against randomization mechanisms <xref
IEEE 802.11 group these research experiences eventually formed the basis for a target="when_mac_randomization_fails" format="default"/>. Within the IEEE
specified mechanism introduced in the IEEE 802.11aq in 2018 which randomize MAC 802.11 group, these research experiences eventually formed the basis for a
addresses <xref target="IEEE_802_11_aq" />. specified mechanism that randomizes MAC addresses, which was introduced in
IEEE Std 802.11aq <xref target="IEEE_802.11aq" format="default"/> in 2018.
</t> </t>
<t> <t>
More recent developments include turning on MAC randomization in mobile More recent developments include turning on MAC address randomization in mobile
OSes by default, which has an impact on the ability of network OSes by default, which has an impact on the ability of network
operators to customize services <xref operators to customize services <xref target="rcm_user_experience_csd" format="d
target="rcm_user_experience_csd" />. Therefore, follow-on work in the IEEE efault"/>. Therefore, follow-on work in the IEEE
802.11 mapped effects of potentially large uptake of randomized MAC identifiers 802.11 mapped effects of a potentially large uptake of randomized MAC identifier
on a number of commonly offered operator services in 2019<xref s
target="rcm_tig_final_report" />. In the summer of 2020 this work emanated in on a number of commonly offered operator services in 2019 <xref target="rcm_tig_
final_report" format="default"/>. In the summer of 2020, this work emanated in
two new standards projects with the purpose of developing mechanisms that do not two new standards projects with the purpose of developing mechanisms that do not
decrease user privacy but enable an optimal user experience when the MAC address decrease user privacy but enable an optimal user experience when the MAC address
of a device in an Extended Service Set (a group of interconnected IEEE 802.11 wi of a device in an Extended Service Set (a group of interconnected IEEE 802.11 wi
reless access points and stations that form a single logical network) is randomi reless access points and stations that form a single logical network) is randomi
zed or changes <xref zed or changes <xref target="rcm_user_experience_par" format="default"/> and use
target="rcm_user_experience_par" /> and user privacy solutions applicable to r privacy solutions applicable to
IEEE Std 802.11 <xref target="rcm_privacy_par" />. IEEE Std 802.11 <xref target="rcm_privacy_par" format="default"/>.
</t> </t>
<t> <t>
IEEE Std 802 <xref target="IEEE_802" />, as of the amendment IEEE 802c-2017 IEEE Std 802 <xref target="IEEE_802" format="default"/>, as of the amendment IEE
<xref target="IEEE_802c" />, specifies a local MAC address space structure known E 802c-2017
as the Structured Local Address Plan (SLAP) <xref target="RFC8948" />. The SLAP <xref target="IEEE_802c" format="default"/>, specifies a local MAC address space
designates a range of structure known
as the Structured Local Address Plan (SLAP) <xref target="RFC8948" format="defau
lt"/>. The SLAP designates a range of
Extended Local Identifiers for subassignment within a block of addresses Extended Local Identifiers for subassignment within a block of addresses
assigned by the IEEE Registration Authority via a Company ID. A range of assigned by the IEEE Registration Authority via a Company ID. A range of
local MAC addresses is designated for Standard Assigned Identifiers to be local MAC addresses is designated for Standard Assigned Identifiers to be
specified by IEEE 802 standards. Another range of local MAC addresses is specified by IEEE 802 standards. Another range of local MAC addresses is
designated for Administratively Assigned Identifiers subject to assignment designated for Administratively Assigned Identifiers, which are subject to assig nment
by a network administrator. by a network administrator.
</t> </t>
<t> <t>
"IEEE Std 802E-2020: Recommended Practice for Privacy Considerations for IEEE 80 IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy Considerations for IE
2 EE 802(R)
Technologies" <xref target="IEEE_802E" /> recommends the use of temporary and Technologies") <xref target="IEEE_802E" format="default"/> recommends the use of
temporary and
transient identifiers if there are no compelling reasons for a newly introduced transient identifiers if there are no compelling reasons for a newly introduced
identifier to be permanent. This recommendation is part of the basis for identifier to be permanent. This recommendation is part of the basis for
the review of user privacy solutions for IEEE Std 802.11 (a.k.a. Wi-Fi) devices the review of user privacy solutions for IEEE Std 802.11 devices (also known as
as Wi-Fi devices) as
part of the RCM <xref target="rcm_privacy_csd" /> efforts. Annex T of IEEE Std part of the RCM efforts <xref target="rcm_privacy_csd" format="default"/>. Annex
802.1AEdk-2023: MAC Privacy Protection <xref target="IEEE802.1AEdk-2023" /> T of IEEE Std
802.1AEdk-2023 ("MAC Privacy Protection") <xref target="IEEE_802.1AEdk" format="
default"/>
discusses privacy considerations in bridged networks. discusses privacy considerations in bridged networks.
</t> </t>
<t>
As of 2024, two task groups in IEEE 802.11 are dealing with issues related to RC
M addresses:
<t> </t>
As per 2024, two task groups in IEEE 802.11 are dealing with issues related to R <ul spacing="normal">
CM: <li>
<t>
<list style="symbols"> The IEEE 802.11bh task group, which is looking at mitigating the repercussions t
hat RCM addresses
<t> create on 802.11 networks and related services.
The IEEE 802.11bh task group, looking at mitigating the repercussions that RCM </t>
creates on 802.11 networks and related services, and </li>
</t> <li>
<t> <t>
The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std
802.11 medium access control (MAC) specification to specify new mechanisms that 802.11 MAC specification to specify new mechanisms that
address and improve user privacy. address and improve user privacy.
</t> </t>
</li>
</list> </ul>
</t>
</section> </section>
<!-- END Tools -->
<section anchor="sec:wba" title="Recent MAC randomization-related activities at the WBA"> <section anchor="sec_wba" numbered="true" toc="default">
<name>Recent Activities Related to MAC Address Randomization in the WBA</n ame>
<t> <t>
At the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work In the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work
Group has been looking at the issues related to MAC address randomization and Group has been looking at issues related to MAC address randomization and
has identified a list of potential impacts of these changes to existing systems has identified a list of potential impacts of these changes to existing systems
and solutions, mainly related to Wi-Fi identification. and solutions, mainly related to Wi-Fi identification.
</t> </t>
<t> <t>
As part of this work, WBA has documented a set of use cases that a Wi-Fi As part of this work, the WBA has documented a set of use cases that a Wi-Fi
Identification Standard should address in order to scale and achieve longer term Identification Standard should address in order to scale and achieve
sustainability of deployed services. A first version of this document has been longer-term sustainability of deployed services. A first version of that
liaised with the IETF as part of the MAC Address Device Identification for document, a paper titled "Wi-Fi Identification In a post MAC Randomization
Network and Application Services (MADINAS) activities through the "Wi-Fi Era v1.0" <xref target="wba_paper" format="default"/>, was created while
Identification In a post MAC Randomization Era v1.0" paper <xref liaising with the IETF MADINAS Working Group.
target="wba_paper" />.
</t> </t>
</section> </section>
<!-- BEGIN Evaluation --> <section anchor="sec_mac_rnd_at_ietf" numbered="true" toc="default">
<section anchor="sec:mac_rnd_at_ietf" title="IPv6 address randomization at t <name>IPv6 Address Randomization in the IETF</name>
he IETF">
<t> <t>
<xref target="RFC4862" /> specifies Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862" format="default"/> specifies Stateless Address Autoconfig uration (SLAAC)
for IPv6, which typically results in hosts configuring one or more "stable" for IPv6, which typically results in hosts configuring one or more "stable"
addresses composed of a network prefix advertised by a local router, and an addresses composed of a network prefix advertised by a local router and an
Interface Identifier (IID). <xref target="RFC8064" /> formally updated the Interface Identifier (IID). <xref target="RFC8064" format="default"/> formally u
pdated the
original IPv6 IID selection mechanism to avoid generating the IID from the MAC original IPv6 IID selection mechanism to avoid generating the IID from the MAC
address of the interface (via EUI64), as this potentially allowed for tracking address of the interface (via EUI64), as this potentially allowed for tracking
of a device at L3. Additionally, the prefix part of an IP address provides of a device at L3. Additionally, the prefix part of an IP address provides
meaningful insights of the physical location of the device in general, which meaningful insights of the physical location of the device in general, which
together with the MAC address-based IID, made it easier to perform global device together with the IID based on the MAC address, made it easier to perform global device
tracking. tracking.
</t> </t>
<t> <t>
<xref target="RFC8981" /> identifies and describes the privacy issues associated <xref target="RFC8981" format="default"/> identifies and describes the privacy
with embedding MAC stable addressing information into the IPv6 addresses (as issues associated with embedding MAC stable addressing information into IPv6
part of the IID). It describes an extension to IPv6 SLAAC that causes hosts to g addresses (as part of the IID). It describes an extension to IPv6 SLAAC that
enerate temporary addresses with causes hosts to generate temporary addresses with randomized IIDs for each
randomized interface identifiers for each prefix advertised with prefix advertised with autoconfiguration enabled. Changing addresses over time
autoconfiguration enabled. Changing addresses over time limits the window of limits the window of time during which eavesdroppers and other information
time during which eavesdroppers and other information collectors may trivially collectors may trivially perform address-based network-activity correlation
perform address-based network-activity correlation when the same address is when the same address is employed for multiple transactions by the same
employed for multiple transactions by the same host. Additionally, it reduces host. Additionally, it reduces the window of exposure of a host as being
the window of exposure of a host as being accessible via an address that becomes accessible via an address that becomes revealed as a result of active
revealed as a result of active communication. These temporary addresses are communication. These temporary addresses are meant to be used for a short
meant to be used for a short period of time (hours to days) and would then be period of time (hours to days) and then deprecated. Deprecated addresses can
deprecated. Deprecated addresses can continue to be used for already established continue to be used for already-established connections but are not used to
connections, but are not used to initiate new connections. New temporary initiate new connections. New temporary addresses are generated periodically
addresses are generated periodically to replace temporary addresses that expire. to replace temporary addresses that expire. To generate temporary addresses,
In order to do so, a node produces a sequence of temporary global scope a node produces a sequence of temporary global scope addresses from a sequence
addresses from a sequence of interface identifiers that appear to be random in of IIDs that appear to be random in the sense that (1) it is
the sense that it is difficult for an outside observer to predict a future difficult for an outside observer to predict a future address (or identifier)
address (or identifier) based on a current one, and it is difficult to determine based on a current one and (2) it is difficult to determine previous addresses
previous addresses (or identifiers) knowing only the present one. Temporary (or identifiers) knowing only the present one. Temporary addresses should not
addresses should not be used by applications that listen for incoming be used by applications that listen for incoming connections (as these are
connections (as these are supposed to be waiting on permanent/well-known supposed to be waiting on permanent/well-known identifiers). If a node changes
identifiers). If a node changes network and comes back to a previously visited network and comes back to a previously visited one, the temporary addresses
one, the temporary addresses that the node would use will be different, and this that the node would use will be different, which might be an issue in certain
might be an issue in certain networks where addresses are used for operational networks where addresses are used for operational purposes (e.g., filtering or
purposes (e.g., filtering or authentication). <xref target="RFC7217" />, authentication). <xref target="RFC7217" format="default"/>, summarized next,
summarized next, partially addresses the problems aforementioned. partially addresses the problems aforementioned.
</t> </t>
<t> <t>
<xref target="RFC7217" /> describes a method to generate Interface Identifiers <xref target="RFC7217" format="default"/> describes a method to generate IIDs
that are stable for each network interface within each subnet, but that change that are stable for each network interface within each subnet but change
as a host moves from one network to another. This method enables keeping the as a host moves from one network to another. This method enables the
"stability" properties of the Interface Identifiers specified in <xref "stability" properties of the IIDs specified in <xref target="RFC4291" format="d
target="RFC4291" />, while still mitigating address-scanning attacks and efault"/> to be kept, while still mitigating address-scanning attacks and
preventing correlation of the activities of a host as it moves from one network preventing correlation of the activities of a host as it moves from one network
to another. The method defined to generate the IPv6 IID is based on computing a to another. 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 hash function that takes the following as input: information that is stable and
the interface (e.g., a local interface identifier), stable information associated to
associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 prefix, and the interface (e.g., a local IID), stable information
a secret key, plus some other additional information. This basically ensures associated to the visited network (e.g., the IEEE 802.11 Service Set Identifier
that a different IID is generated when any of the input fields changes (such as (SSID)), the IPv6 prefix,
the network or the prefix), but that the IID is the same within each subnet. a secret key, and some other additional information. This basically ensures
that a different IID is generated when one of the input fields changes (such as
the network or the prefix) but that the IID is the same within each subnet.
</t> </t>
<t> <t>
Currently, <xref target="RFC8064" /> recommends nodes to implement <xref To mitigate the privacy threats posed by the use of MAC-derived
target="RFC7217" /> as the default scheme for generating stable IPv6 addresses IIDs, <xref target="RFC8064" format="default"/> recommends that nodes implement
with SLAAC, to mitigate the privacy threats posed by the use of MAC-derived <xref target="RFC7217" format="default"/> as the default scheme for generating s
IIDs. table IPv6 addresses
with SLAAC.
</t> </t>
<t> <t>
In addition to the former documents, <xref target="RFC8947" /> In addition to the documents above, <xref target="RFC8947" format="default"/>
proposes "an extension to DHCPv6 that allows a scalable approach to link-layer proposes a DHCPv6 extension that:</t>
<blockquote>
allows a scalable approach to link-layer
address assignments where preassigned link-layer address assignments (such as by address assignments where preassigned link-layer address assignments (such as by
a manufacturer) are not possible or unnecessary". <xref a manufacturer) are not possible or are unnecessary.
target="RFC8948" /> proposes "extensions to DHCPv6 protocols </blockquote>
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".
</t>
<t> <t>And <xref target="RFC8948" format="default"/> proposes DHCPv6 extensions that
Not only MAC and IP addresses can be used for tracking purposes. Some DHCP :</t>
options carry unique identifiers. These identifiers can enable device tracking
even if the device administrator takes care of randomizing other potential <blockquote>
identifications like link-layer addresses or IPv6 addresses. <xref enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP
target="RFC7844" /> introduces anonymity profiles, "designed for clients that quadrant to the server so that the server may allocate MAC addresses in the
wish to remain anonymous to the visited network. The profiles provide guidelines quadrant requested by the relay or client.
</blockquote>
<t>
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. <xref target="RFC7844" format="default"/> introduces
anonymity profiles that are:</t>
<blockquote>
designed for clients that
wish to remain anonymous to the visited network
</blockquote>
<t>and that:</t>
<blockquote>
provide guidelines
on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure
of identifying information". <xref target="RFC7844" /> also indicates that the of identifying information.
link-layer address, IP address, and DHCP identifier shall evolve in synchrony. </blockquote>
</t>
<!-- <t><xref target="RFC7844" format="default"/> also indicates that the
<t> link-layer address, IP address, and DHCP identifier shall evolve in synchrony.
Lately, the MAC Address Device Identification for Network and Application Servic
es (MADINAS) IETF BoF
has discussed the need to examine the effect of RCM schemes on network and appli
cation services in several
scenarios identified as relevant.
</t> </t>
</section> </section>
<!-- END Evaluation -->
<section anchor="rcm-types" title="A taxonomy of MAC address selection <section anchor="rcm-types" numbered="true" toc="default">
policies"> <name>Taxonomy of MAC Address Selection Policies</name>
<t> <t>
This section documents different policies for MAC address selection. Some OSes This section documents different policies for MAC address selection. Some OSes
might use combination of multiple of these policies. might use a combination of multiple policies.
</t> </t>
<aside><t>
Note about the naming convention used: The "M" in "MAC" is included in t
he
acronym but not the "A" from "Address". This allows one to talk about a "PVOM
address" or "PNGM address".
</t></aside>
<t> <t>
Note about the used naming convention: the "M" in MAC is included in the
acronym, but not the "A" from address. This allows one to talk about a PVOM
Address, or PNGM Address.
</t>
<t>
<!-- The names are all in the form for per-period-of-time-selection. -->
</t> </t>
<section anchor="policy-pvom" title="Per-Vendor OUI MAC address (PVOM)"> <section anchor="policy-pvom" numbered="true" toc="default">
<name>Per-Vendor OUI MAC (PVOM) Address</name>
<t> <t>
This form of MAC address selection is the historical default. This form of MAC address selection is the historical default.
</t> </t>
<t>
The vendor obtains an Organizationally Unique Identifier (OUI) from th <t>
e IEEE. The vendor obtains an OUI from the IEEE.
This has been a 24-bit prefix (including two upper bits which are This is a 24-bit prefix (including two upper bits that are
set specifically) that is assigned to the vendor. set specifically) that is assigned to the vendor.
The vendor generates a unique 24-bit value for the lower 24-bits, The vendor generates a unique 24-bit value for the lower 24 bits,
forming the 48-bit MAC address. forming the 48-bit MAC address.
It has not been unusual for the 24-bit value to be taken as an It is not unusual for the 24-bit value
incrementing counter, assigned at the factory, and burnt into to be used as an incrementing counter that was assigned at the factory and
non-volatile storage. burnt into non-volatile storage.
</t> </t>
<t> <t>
Note that 802.15.4 use 64-bit MAC addresses, and the IEEE assigns Note that IEEE Std 802.15.4 <xref target="IEEE_802.15.4"/> uses 64-bit MAC addresses, and the IEEE assigns
32-bit prefixes. 32-bit prefixes.
The IEEE has indicated that there may be a future Ethernet The IEEE has indicated that there may be a future Ethernet
specification using 64-bit MAC addresses. specification that uses 64-bit MAC addresses.
</t> </t>
</section> </section>
<section anchor="policy-pdgm" numbered="true" toc="default">
<section anchor="policy-pdgm" title="Per-Device Generated MAC address (PDG <name>Per-Device Generated MAC (PDGM) Address</name>
M)">
<t> <t>
This form of MAC address is randomly generated by the device, usually upon first boot. This form of MAC address is randomly generated by the device, usually upon first boot.
The resulting MAC address is stored in non-volatile storage and is The resulting MAC address is stored in non-volatile storage and is
used for the rest of the device lifetime. used for the rest of the device lifetime.
</t> </t>
</section> </section>
<section anchor="policy-pbgm" numbered="true" toc="default">
<section anchor="policy-pbgm" title="Per-Boot Generated MAC address (PBGM) <name>Per-Boot Generated MAC (PBGM) Address</name>
">
<t> <t>
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. time the device is booted.
The resulting MAC address is *not* stored in non-volatile storage. The resulting MAC address is <strong>not</strong> stored in non-volati le storage.
It does not persist across power cycles. It does not persist across power cycles.
This case may sometimes be a PDGM where the non-volatile storage is no longer functional This case may sometimes be a PDGM address where the non-volatile stora ge is no longer functional
(or has failed). (or has failed).
</t> </t>
</section> </section>
<section anchor="policy-pngm" numbered="true" toc="default">
<section anchor="policy-pngm" title="Per-Network Generated MAC address (PN <name>Per-Network Generated MAC (PNGM) Address</name>
GM)">
<t> <t>
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.
</t> </t>
<t> <t>
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) whe
is identified by an SSID Name. re the network is identified by an SSID Name.
The generated address is stored on non-volatile storage, indexed by th The generated address is stored in non-volatile storage, indexed by th
e SSID. e SSID.
Each time the device returns to a network with the same SSID, the Each time the device returns to a network with the same SSID, the
device uses the saved MAC address. device uses the saved MAC address.
</t> </t>
<t> <t>
It is possible to use PNGM for wired Ethernet connections through It is possible to use a PNGM address for wired Ethernet connections th
some passive observation of network traffic, such as STP <xref target= rough
"IEEE802.1D-2004" />, LLDP <xref target="IEEE802.1AB-2016" />, some passive observation of network traffic (such as the Spanning Tree
DHCP or Router Advertisements to determine which network has been Protocol (SPT) <xref target="IEEE_802.1D" format="default"/>, the Link Layer Di
scovery Protocol (LLDP) <xref target="IEEE_802.1AB" format="default"/>,
DHCP, or Router Advertisements) to determine which network has been
attached. attached.
</t> </t>
</section> </section>
<section anchor="policy-ppgm" numbered="true" toc="default">
<section anchor="policy-ppgm" title="Per-Period Generated MAC address (PPG <name>Per-Period Generated MAC (PPGM) Address</name>
M)">
<t> <t>
This form of MAC address is generated periodically. This form of MAC address is generated periodically,
Typical numbers are around every twelve hours. typically around every twelve hours.
Like PNGM, it is used primarily with Wi-Fi. Like PNGM addresses, it is used primarily with Wi-Fi.
</t> </t>
<t> <t>
When the MAC address changes, the station disconnects from the current When the MAC address changes, the station disconnects from the current
session and reconnects using the new MAC address. session and reconnects using the new MAC address.
This will involve a new WPA/802.1x session: new EAP, TLS, etc. negotia
tions.
A new DHCP, SLAAC will be done.
</t>
<t>
If DHCP is used, then a new DUID is generated so as to not link to
the previous connection, and the result is usually new IP addresses
allocated.
</t>
</section>
<section anchor="policy-psgm" title="Per-Session Generated MAC address (PS GM)"> This will involve a new WPA/802.1x session, as well as obtaining (or re freshing) a new IP address (e.g., using DHCP or SLAAC).
<t>
This form of MAC address is generated on a per session basis. How a se
ssion is defined is implementation-dependant, for example, a session might be de
fined by logging in a portal, VPN, etc. Like PNGM, it is used primarily with Wi-
Fi.
</t> </t>
<t> <t>
Since the address changes only when a new session is established, ther If DHCP is used, then a new DHCP Unique Identifier (DUID) is generated
e is no disconnection/reconnection involved. so as to not link to
the previous connection; this usually results in the allocation of new
IP addresses.
</t> </t>
</section> </section>
<section anchor="policy-psgm" numbered="true" toc="default">
</section> <name>Per-Session Generated MAC (PSGM) Address</name>
<!-- BEGIN OSes current practices -->
<section anchor="sec:os_current_practices" title="OS current practices">
<!--
<t>
Since this content can evolve with time, it is now hosted at <eref target="https
://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/
main/OS-current-practices.md" />
</t>
<t> <t>
Most modern OSes (especially mobile ones) do implement by default some MAC This form of MAC address is generated on a per-session basis. How a se
address randomization policy. Since the mechanism and policies OSes implement ca ssion is defined is implementation-dependent, for example, a session might be de
n evolve with time, the content is now hosted at <eref target="https://github.co fined by logging in to a portal, VPN, etc. Like PNGM and PPGM addresses, it is u
m/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-curr sed primarily with Wi-Fi.
ent-practices.md" />. For completeness, a snapshot of the content at the time of
publication of this document is included below. Note that the extensive testing
reported in this document was conducted in 2021, but no significant changes hav
e been detected at the time of publication of this document.
</t> </t>
<t> <t>
<xref target="tab:current_practices" /> summarizes Since the address only changes when a new session is established, ther
current practices for Android and iOS, as the time of writing this document e is no disconnection/reconnection involved.
(original source posted at: https://www.fing.com/news/private-mac-address-on-ios
-14, latest wayback machine's
snapshot available here: https://web.archive.org/web/20230905111429/https://www.
fing.com/news/private-mac-address-on-ios-14,
updated based on findings from the authors).
</t> </t>
</section>
</section>
<texttable anchor="tab:current_practices" <section anchor="sec_os_current_practices" numbered="true" toc="default">
title="Android and iOS MAC address randomization practices"> <name>OS Current Practices</name>
<ttcol width="50%" align="left">Android 10+</ttcol>
<ttcol width="50%" align="left">iOS 14+</ttcol>
<c>The randomized MAC address is bound to the SSID</c>
<c>The randomized MAC address is bound to the Basic SSID</c>
<c></c>
<c></c>
<c>The randomized MAC address is stable across reconnections for the
same network</c>
<c>The randomized MAC address is stable across reconnections for the
same network</c>
<c></c>
<c></c>
<c>The randomized MAC address does not get re-randomized when the de
vice forgets a WiFI network</c>
<c>The randomized MAC address is reset when the device forgets a WiF
I network</c>
<c></c>
<c></c>
<c>MAC address randomization is enabled by default for all the new W
i-Fi networks. But if the device previously connected to a Wi-Fi network identif
ying itself with the real MAC address, no randomized MAC address will be used (u
nless manually enabled)</c>
<c>MAC address randomization is enabled by default for all the new W
i-Fi networks</c>
</texttable>
<t> <t>
In September 2021, we have performed some additional tests to evaluate how most By default, most modern OSes (especially mobile ones) do implement some MAC
widely used OSes behave regarding MAC address randomization. <xref address randomization policies. Since the mechanism and policies that OSes imple
target="tab:experiments-2021" /> summarizes our findings, where show on ment can evolve with time, the content is now hosted at <xref target="OS_current
different rows whether the OS performs address randomization per network (PNGM a _practices"/>. For completeness, a snapshot of the content at the time of public
ccording to the taxonomy introduced in <xref target="rcm-types" />), per ation of this document is included below. Note that the extensive testing report
new connection (PSGM), daily (PPGM with a period of 24h), supports configuration ed in this document was conducted in 2021, but no significant changes have been
per SSID, supports address detected at the time of publication of this document.
randomization for scanning, and whether it does that by default. </t>
</t> <t>
<texttable anchor="tab:experiments-2021"
title="Observed behavior from different OS (as of September 2
021)">
<ttcol width="35%" align="left">OS</ttcol>
<ttcol width="15%" align="center">Linux (Debian "bookworm")</ttcol>
<ttcol width="20%" align="center">Android 10</ttcol>
<ttcol width="20%" align="center">Windows 10</ttcol>
<ttcol width="10%" align="center">iOS 14+</ttcol>
<c>Random per net. (PNGM)</c><c>Y</c><c>Y</c><c>Y</c><c>Y</c>
<c></c><c></c><c></c><c></c><c></c>
<c>Random per connec. (PSGM)</c><c>Y</c><c>N</c><c>N</c><c>N</c>
<c></c><c></c><c></c><c></c><c></c>
<c>Random daily (PPGM)</c><c>N</c><c>N</c><c>Y</c><c>N</c>
<c></c><c></c><c></c><c></c><c></c>
<c>SSID config.</c><c>Y</c><c>N</c><c>N</c><c>N</c>
<c></c><c></c><c></c><c></c><c></c>
<c>Random. for scan</c><c>Y</c><c>Y</c><c>Y</c><c>Y</c>
<c></c><c></c><c></c><c></c><c></c>
<c>Random. for scan by default</c><c>N</c><c>Y</c><c>N</c><c>Y</c>
</texttable>
<xref target="tab_current_practices" format="default"/> summarizes current
practices for Android and iOS at the time of writing this document (the original
source is available
at <xref target="private_mac"/>) and also includes
updates based on findings from the authors.
</t>
<table anchor="tab_current_practices" align="center">
<name>Android and iOS MAC Address Randomization Practices</name>
<thead>
<tr>
<th align="left">Android 10+</th>
<th align="left">iOS 14+</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">The randomized MAC address is bound to the SSID.</t
d>
<td align="left">The randomized MAC address is bound to the Basic SS
ID.</td>
</tr>
<tr>
<td align="left">The randomized MAC address is stable across reconne
ctions for the same network.</td>
<td align="left">The randomized MAC address is stable across reconne
ctions for the same network.</td>
</tr>
<tr>
<td align="left">The randomized MAC address does not get re-randomiz
ed when the device forgets a Wi-Fi network.</td>
<td align="left">The randomized MAC address is reset when the device
forgets a Wi-Fi network.</td>
</tr>
<tr>
<td align="left">MAC address randomization is enabled by default for
all the new Wi-Fi networks. But if the device previously connected to a Wi-Fi n
etwork identifying itself with the real MAC address, no randomized MAC address w
ill be used (unless manually enabled).</td>
<td align="left">MAC address randomization is enabled by default for
all the new Wi-Fi networks.</td>
</tr>
</tbody>
</table>
<t> <t>
According to <xref target="privacy_android"/>, starting in Android 12, Android In September 2021, we performed some additional tests to evaluate how OSes
uses non-persistent randomization in the following situations: (i) a network that are widely used behave regarding MAC address randomization. <xref
suggestion app specifies that non-persistant randomization be used for the target="tab_experiments-2021" format="default"/> summarizes our findings;
network (through an API); or (ii) the network is an open network that hasn't the rows in the table show whether the OS performs address randomization per
encountered a captive portal and an internal config option is set to do so (by network (PNGM according to the taxonomy introduced in <xref target="rcm-types"
default it is not). format="default"/>), performs address randomization per new connection (PSGM), p
erforms address randomization daily (PPGM with a period of
24 hours), supports configuration per SSID, supports address randomization for
scanning, and supports address randomization for scanning by default.
</t> </t>
<table anchor="tab_experiments-2021" align="center">
<name>Observed Behavior in Different OSes (as of September 2021)</name>
<thead>
<tr>
<th align="left">OS</th>
<th align="center">Linux (Debian "bookworm")</th>
<th align="center">Android 10</th>
<th align="center">Windows 10</th>
<th align="center">iOS 14+</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Random. per net. (PNGM)</td>
<td align="center">Y</td>
<td align="center">Y</td>
<td align="center">Y</td>
<td align="center">Y</td>
</tr>
<tr>
<td align="left">Random. per connec. (PSGM)</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">N</td>
<td align="center">N</td>
</tr>
<tr>
<td align="left">Random. daily (PPGM)</td>
<td align="center">N</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">N</td>
</tr>
<tr>
<td align="left">SSID config.</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">N</td>
<td align="center">N</td>
</tr>
<tr>
<td align="left">Random. for scan</td>
<td align="center">Y</td>
<td align="center">Y</td>
<td align="center">Y</td>
<td align="center">Y</td>
</tr>
<tr>
<td align="left">Random. for scan by default</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">Y</td>
</tr>
</tbody>
</table>
<t>
According to <xref target="privacy_android" format="default"/>, starting with An
droid 12, Android
uses non-persistent randomization in the following situations: </t>
<ul spacing="normal">
<li>A network
suggestion application specifies that non-persistent randomization be used for t
he
network (through an API).</li>
<li>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).</li>
</ul>
</section>
</section> <section anchor="IANA" numbered="true" toc="default">
<!-- END OSes current practices --> <name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations">
<t> <t>
This document has no IANA actions. This document has no IANA actions.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
Privacy considerations regarding tracking the location of a user through the MAC Privacy considerations regarding tracking the location of a user through the MAC
address of this device are discussed throughout this document. Given the address of a device are discussed throughout this document. Given the
informational nature of this document, no protocols/solutions are specified, but informational nature of this document, no protocols/solutions are specified, but
current state of affairs is documented. the current state of affairs is documented.
</t> </t>
<t> <t>
Any future specification in this area would have to look into security and Any future specification in this area would need to look into security and
privacy aspects, such as, but not limited to: i) mitigating the problem of privacy aspects, such as (but not limited to) the following:</t>
<ul spacing="normal">
<li>Mitigating the problem of
location privacy while minimizing the impact on upper layers of the protocol location privacy while minimizing the impact on upper layers of the protocol
stack; ii) providing means to network operators to authenticate devices and stack</li>
authorize network access despite the MAC addresses changing following some <li>Providing the means for network operators to authenticate devices
pattern; and, iii) provide means for the device not to use MAC addresses it is and authorize network access, despite the MAC addresses changing according
not authorized to use or that are currently in use. some pattern</li>
</t> <li>Providing the means for the device not to use MAC
addresses that it is not authorized to use or that are currently in use</li>
</ul>
<t> <t>
A major conclusion of the work in IEEE Std 802E concerned the difficulty of A major conclusion of the work in IEEE Std 802E <xref target="IEEE_802E" format=
defending privacy against adversaries of any sophistication. Individuals can be "default"/> concerned the difficulty of
successfully tracked by fingerprinting defending privacy against adversaries of any sophistication. Individuals can be
using aspects of their communication other than MAC Addresses or other permanent successfully tracked by fingerprinting,
using aspects of their communication other than MAC addresses or other permanent
identifiers. identifiers.
</t> </t>
</section> </section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
Authors would like to thank Guillermo Sanchez Illan for the extensive tests
performed on different OSes to analyze their behavior regarding address
randomization.
</t>
<t>
Authors would like to thank Jerome Henry, Hai Shalom, Stephen Farrel, Alan
DeKok, Mathieu Cunche, Johanna Ansohn McDougall, Peter Yee, Bob Hinden, Behcet
Sarikaya, David Farmer, Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roma D
anyliw, Murray Kucherawy and Paul Wouters for their reviews and comments on
previous versions of this 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, per
formed as part of the Liaison statement on Randomized and Changing MAC Address (
https://datatracker.ietf.org/liaison/1884/).
</t>
</section>
</middle> </middle>
<back> <back>
<!-- <references title="Normative References"> <references>
&rfc2119; <name>Informative References</name>
</references> --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.486
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.697
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.721
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894
8.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.784
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.898
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.429
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.806
4.xml"/>
<references title="Informative References"> <reference anchor="private_mac" target="https://web.archive.org/web/202309051114
29/https://www.fing.com/news/private-mac-address-on-ios-14">
<front>
<title>Private MAC address on iOS 14</title>
<author fullname="Daniele Pantaleone"/>
<date month="September" year="2020"/>
</front>
<refcontent>Wayback Machine archive</refcontent>
</reference>
&rfc4862; <reference anchor="OS_current_practices" target="https://github.com/ietf-w
&rfc6973; g-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-prac
&rfc7217; tices.md">
&rfc8947; <front>
&rfc8948; <title>OS current practices</title>
&rfc7844; <author/>
&rfc8981; <date month="July" year="2024"/>
&rfc4291; </front>
&rfc8064; <refcontent>commit 795739b</refcontent>
</reference>
<reference anchor="CSCN2015" > <reference anchor="CSCN2015">
<front> <front>
<title>Wi-Fi Internet Connectivity and Privacy: Hiding your tracks on the wireless Internet</title> <title>Wi-Fi Internet Connectivity and Privacy: Hiding your tracks on the wireless Internet</title>
<author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernard os"> <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernard os">
</author> </author>
<author initials="JC." surname="Zúñiga" fullname="Juan C. Zúñiga"> <author initials="JC." surname="Zúñiga" fullname="Juan C. Zúñiga">
</author> </author>
<author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon"> <author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon">
</author> </author>
<date month="October" year="2015"/> <date month="October" year="2015"/>
</front> </front>
<seriesInfo name="Standards for Communications and Networking (CSCN), 20 <refcontent>2015 IEEE Conference on Standards for Communications and Net
15 IEEE Conference on" value="" /> working (CSCN)</refcontent>
<seriesInfo name="DOI" value="10.1109/CSCN.2015.7390443"/>
</reference> </reference>
<reference anchor="link_layer_privacy" > <reference anchor="link_layer_privacy">
<front> <front>
<title>Privacy at the link-layer</title> <title>Privacy at the link-layer</title>
<author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon"> <author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon">
</author> </author>
<author initials="J." surname="Wright" fullname="J. Wright"> <author initials="J." surname="Wright" fullname="J. Wright">
</author> </author>
<author initials="I." surname="Brown" fullname="Ian Brown"> <author initials="I." surname="Brown" fullname="Ian Brown">
</author> </author>
<date month="February" year="2014"/> <date month="February" year="2014"/>
</front> </front>
<seriesInfo name="Contribution at W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)" value="" /> <refcontent>W3C/IAB workshop on Strengthening the Internet Against Perva sive Monitoring (STRINT)</refcontent>
</reference> </reference>
<reference anchor="enhancing_location_privacy" > <reference anchor="enhancing_location_privacy">
<front> <front>
<title>Enhancing location privacy in wireless LAN through disposable i <title>Enhancing Location Privacy in Wireless LAN Through Disposable I
nterface identifiers: a quantitative analysis</title> nterface Identifiers: A Quantitative Analysis</title>
<author initials="M." surname="Gruteser" fullname="M. Gruteser"> <author initials="M." surname="Gruteser" fullname="M. Gruteser">
</author> </author>
<author initials="D." surname="Grunwald" fullname="D. Grunwald"> <author initials="D." surname="Grunwald" fullname="D. Grunwald">
</author> </author>
<date month="" year="2005"/> <date month="June" year="2005"/>
</front> </front>
<seriesInfo name="Mobile Networks and Applications, vol. 10, no. 3, pp. <refcontent>Mobile Networks and Applications, vol. 10, no. 3, pp. 315-32
315-325" value="" /> 5</refcontent>
<seriesInfo name="DOI" value="10.1007/s11036-005-6425-1"/>
</reference> </reference>
<reference anchor="privacy_ios" target="https://support.apple.com/en-us/HT <reference anchor="privacy_ios" target="https://support.apple.com/en-us/10
211227"> 2509">
<front> <front>
<title>Use private Wi-Fi addresses in iOS 14, iPadOS 14, and watchOS 7 <title>Use private Wi-Fi addresses on Apple Devices</title>
</title> <author>
<author initials="" surname="Apple" fullname="Apple"> <organization>Apple Inc.</organization>
<organization></organization>
</author> </author>
<date /> <date/>
</front> </front>
<refcontent>Apple Support</refcontent>
</reference> </reference>
<reference anchor="strint" target="https://www.w3.org/2014/strint/"> <reference anchor="strint" target="https://www.w3.org/2014/strint/">
<front> <front>
<title>A W3C/IAB workshop on Strengthening the Internet Against Perv <title>STRINT Workshop: A W3C/IAB workshop on Strengthening the Intern
asive Monitoring (STRINT)</title> et Against Pervasive Monitoring (STRINT)</title>
<author initials="" surname="W3C/IAB" fullname="W3C/IAB"> <author>
<organization></organization> <organization>W3C/IAB</organization>
</author> </author>
<date /> <date/>
</front> </front>
</reference> </reference>
<reference anchor="ieee_privacy_ecsg" target="http://www.ieee802.org/PrivR ecsg/"> <reference anchor="ieee_privacy_ecsg" target="http://www.ieee802.org/PrivR ecsg/">
<front> <front>
<title>IEEE 802 EC Privacy Recommendation Study Group</title> <title>IEEE 802 EC Privacy Recommendation Study Group</title>
<author initials="" surname="IEEE 802 Privacy EC SG" fullname="IEEE <author>
802 Privacy EC SG"> <organization>IEEE 802 LAN/MAN Standards Committee</organization>
<organization></organization> </author>
</author> <date/>
<date />
</front> </front>
</reference> </reference>
<reference anchor="privacy_tutorial" target="https://mentor.ieee.org/802-e c/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf"> <reference anchor="privacy_tutorial" target="https://mentor.ieee.org/802-e c/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf">
<front> <front>
<title>Tutorial on Pervasive Surveillance of the Internet - Designin <title>Pervasive Surveillance of the Internet - Designing Privacy into
g Privacy into Internet Protocols </title> Internet Protocols</title>
<author initials="A." surname="Cooper" fullname="Alissa Cooper"> <author initials="A." surname="Cooper" fullname="Alissa Cooper">
</author> </author>
<author initials="T." surname="Hardie" fullname="Ted Hardie"> <author initials="T." surname="Hardie" fullname="Ted Hardie">
</author> </author>
<author initials="JC." surname="Zuniga" fullname="Juan-Carlos Zuniga "> <author initials="JC." surname="Zuniga" fullname="Juan-Carlos Zuniga">
</author> </author>
<author initials="L." surname="Chen" fullname="Lily Chen"> <author initials="L." surname="Chen" fullname="Lily Chen">
</author> </author>
<author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon"> <author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon">
</author> </author>
<date day="14" month="July" year="2014"/>
<date /> </front>
</front> <refcontent>IEEE 802 Tutorial</refcontent>
</reference> </reference>
<reference anchor="wifi_tracking" target="https://www.independent.co.uk/li fe-style/gadgets-and-tech/news/updated-london-s-bins-are-tracking-your-smartphon e-8754924.html"> <reference anchor="wifi_tracking" target="https://www.independent.co.uk/li fe-style/gadgets-and-tech/news/updated-london-s-bins-are-tracking-your-smartphon e-8754924.html">
<front> <front>
<title>London's bins are tracking your smartphone</title> <title>London's bins are tracking your smartphone</title>
<author initials="" surname="The Independent" fullname="The Independ <author fullname="James Vincent"/>
ent"> <date day="9" month="August" year="2013"/>
<organization></organization> </front>
</author> <refcontent>The Independent</refcontent>
<date />
</front>
</reference> </reference>
<reference anchor="privacy_android" target="https://source.android.com/dev ices/tech/connect/wifi-mac-randomization-behavior"> <reference anchor="privacy_android" target="https://source.android.com/dev ices/tech/connect/wifi-mac-randomization-behavior">
<front> <front>
<title>MAC Randomization Behavior</title> <title>MAC randomization behavior</title>
<author initials="" surname="Android Open Source Project" fullname=" <author>
Android Open Source Project"> <organization>Android Open Source Project</organization>
<organization></organization> </author>
</author> <date/>
<date /> </front>
</front> <refcontent>Android OS Documentation</refcontent>
</reference> </reference>
<reference anchor="privacy_windows" target="https://support.microsoft.com/ en-us/windows/how-to-use-random-hardware-addresses-ac58de34-35fc-31ff-c650-823fc 48eb1bc"> <reference anchor="privacy_windows" target="https://support.microsoft.com/ en-us/windows/how-to-use-random-hardware-addresses-ac58de34-35fc-31ff-c650-823fc 48eb1bc">
<front> <front>
<title>Windows: How to use random hardware addresses</title> <title>How to use random hardware addresses in Windows</title>
<author initials="" surname="Microsoft" fullname="Microsoft"> <author>
<organization></organization> <organization>Microsoft Corporation</organization>
</author> </author>
<date /> <date/>
</front> </front>
<refcontent>Microsoft Support</refcontent>
</reference> </reference>
<reference anchor="when_mac_randomization_fails" > <reference anchor="when_mac_randomization_fails">
<front> <front>
<title>A Study of MAC Address Randomization in Mobile Devices and When it Fails</title> <title>A Study of MAC Address Randomization in Mobile Devices and When it Fails</title>
<author initials="J." surname="Martin" fullname="J. Martin"> <author initials="J." surname="Martin" fullname="J. Martin">
</author> </author>
<author initials="T." surname="Mayberry" fullname="T. Mayberry"> <author initials="T." surname="Mayberry" fullname="T. Mayberry">
</author> </author>
<author initials="C." surname="Donahue" fullname="C. Donahue"> <author initials="C." surname="Donahue" fullname="C. Donahue">
</author> </author>
<author initials="L." surname="Foppe" fullname="L. Foppe"> <author initials="L." surname="Foppe" fullname="L. Foppe">
</author> </author>
<author initials="L." surname="Brown" fullname="L. Brown"> <author initials="L." surname="Brown" fullname="L. Brown">
</author> </author>
<author initials="C." surname="Riggins" fullname="C. Riggins"> <author initials="C." surname="Riggins" fullname="C. Riggins">
</author> </author>
<author initials="E.C." surname="Rye" fullname="E.C. Rye"> <author initials="E." surname="Rye" fullname="E. C. Rye">
</author> </author>
<author initials="D." surname="Brown" fullname="D. Brown"> <author initials="D." surname="Brown" fullname="D. Brown">
</author> </author>
<date month="" year="2017"/> <date month="March" year="2017"/>
</front> </front>
<seriesInfo name="arXiv:1703.02874v2 [cs.CR]" value="" /> <refcontent>arXiv:1703.02874v2</refcontent>
</reference> <seriesInfo name="DOI" value="10.48550/arXiv.1703.02874"/>
</reference>
<reference anchor="IEEE_802E" > <reference anchor="IEEE_802E">
<front> <front>
<title>IEEE 802E-2020 - IEEE Recommended Practice for Privacy Consider <title>IEEE Recommended Practice for Privacy Considerations for IEEE 8
ations for IEEE 802 Technologies</title> 02(R) Technologies</title>
<author initials="" surname="IEEE 802.1 WG - 802 LAN/MAN architecture" ful <author>
lname="IEEE 802.1 WG - 802 LAN/MAN architecture"> <organization>IEEE</organization>
</author> </author>
<date month="" year="2020"/> <date month="November" year="2020"/>
</front> </front>
<seriesInfo name="IEEE 802E" value="" /> <seriesInfo name="IEEE Std" value="802E-2020"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9257130"/>
</reference>
<reference anchor="IEEE_802" > <reference anchor="IEEE_802.15.4">
<front> <front>
<title>IEEE Std 802 - IEEE Standard for Local and Metropolitan Area Ne <title>IEEE Standard for Low‐Rate Wireless Networks</title>
tworks: Overview and Architecture</title> <author>
<author initials="" surname="IEEE 802" fullname="IEEE 802"> <organization>IEEE</organization>
</author> </author>
<date month="" year="2014"/> <date month="December" year="2024"/>
</front> </front>
<seriesInfo name="IEEE 802" value="" /> <seriesInfo name="IEEE Std" value="802.15.4-2024"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2024.10794632"/>
</reference>
<reference anchor="IEEE_802c" > <reference anchor="IEEE_802">
<front> <front>
<title>IEEE 802c-2017 - IEEE Standard for Local and Metropolitan Area <title>IEEE Standard for Local and Metropolitan Area Networks: Overvie
Networks:Overview and Architecture--Amendment 2: Local Medium Access Control (MA w and Architecture</title>
C) Address Usage</title> <author>
<author initials="" surname="IEEE 802.1 WG - 802 LAN/MAN architecture" ful <organization>IEEE</organization>
lname="IEEE 802.1 WG - 802 LAN/MAN architecture">
</author> </author>
<date month="" year="2017"/> <date month="June" year="2014"/>
</front> </front>
<seriesInfo name="IEEE 802c" value="" /> <seriesInfo name="IEEE Std" value="802-2014"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
</reference>
<reference anchor="IEEE_802_11_aq" > <reference anchor="IEEE_802c">
<front> <front>
<title>IEEE 802.11aq-2018 - IEEE Standard for Information technology-- <title>IEEE Standard for Local and Metropolitan Area Networks:Overview
Telecommunications and information exchange between systems Local and metropolit and Architecture--Amendment 2: Local Medium Access Control (MAC) Address Usage<
an area networks--Specific requirements Part 11: Wireless LAN Medium Access Cont /title>
rol (MAC) and Physical Layer (PHY) Specifications Amendment 5: Preassociation Di <author>
scovery</title> <organization>IEEE</organization>
<author initials="" surname="IEEE 802.11 WG - Wireless LAN Working Group"
fullname="IEEE 802.11 WG - Wireless LAN Working Group">
</author> </author>
<date month="" year="2018"/> <date month="August" year="2017"/>
</front> </front>
<seriesInfo name="IEEE 802.11" value="" /> <seriesInfo name="IEEE Std" value="802c-2017"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
</reference>
<reference anchor="rcm_user_experience_csd" > <reference anchor="IEEE_802.11aq">
<front>
<title>IEEE Standard for Information technology--Telecommunications an
d information exchange between systems Local and metropolitan area network--Spec
ific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications Amendment 5: Preassociation Discovery</title>
<author>
<organization>IEEE</organization>
</author>
<date month="August" year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="802.11aq-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457463"/>
</reference>
<reference anchor="rcm_user_experience_csd">
<front> <front>
<title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group C SD on user experience mechanisms</title> <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group C SD on user experience mechanisms</title>
<author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE 80 <author>
2.11 WG RCM SG"> <organization>IEEE 802.11 WG RCM SG</organization>
</author> </author>
<date month="" year="2020"/> <date month="" year="2020"/>
</front> </front>
<seriesInfo name="doc.:IEEE 802.11-20/1117r3" value="" /> <refcontent>doc.:IEEE 802.11-20/1117r3</refcontent>
</reference> </reference>
<reference anchor="rcm_tig_final_report" > <reference anchor="rcm_tig_final_report">
<front> <front>
<title>IEEE 802.11 Randomized And Changing MAC Addresses Topic Interes t Group Report</title> <title>IEEE 802.11 Randomized And Changing MAC Addresses Topic Interes t Group Report</title>
<author initials="" surname="IEEE 802.11 WG RCM TIG" fullname="IEEE 8 <author>
02.11 WG RCM TIG"> <organization>IEEE 802.11 WG RCM TIG</organization>
</author> </author>
<date month="" year="2019"/> <date month="" year="2019"/>
</front> </front>
<seriesInfo name="doc.:IEEE 802.11-19/1442r9" value="" /> <refcontent>doc.:IEEE 802.11-19/1442r9</refcontent>
</reference> </reference>
<reference anchor="rcm_user_experience_par" > <reference anchor="rcm_user_experience_par">
<front> <front>
<title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group P AR on user experience mechanisms</title> <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group P AR on user experience mechanisms</title>
<author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE 80 <author>
2.11 WG RCM SG"> <organization>IEEE 802.11 WG RCM SG</organization>
</author> </author>
<date month="" year="2020"/> <date month="" year="2020"/>
</front> </front>
<seriesInfo name="doc.:IEEE 802.11-20/742r5" value="" /> <refcontent>doc.:IEEE 802.11-20/742r5</refcontent>
</reference> </reference>
<reference anchor="rcm_privacy_par" > <reference anchor="rcm_privacy_par">
<front> <front>
<title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group P AR on privacy mechanisms</title> <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group P AR on privacy mechanisms</title>
<author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE 80 <author>
2.11 WG RCM SG"> <organization>IEEE 802.11 WG RCM SG</organization>
</author> </author>
<date month="" year="2020"/> <date month="" year="2020"/>
</front> </front>
<seriesInfo name="doc.:IEEE 802.11-19/854r7" value="" /> <refcontent>doc.:IEEE 802.11-19/854r7</refcontent>
</reference> </reference>
<reference anchor="rcm_privacy_csd" > <reference anchor="rcm_privacy_csd">
<front> <front>
<title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group C SD on user experience mechanisms</title> <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group C SD on user experience mechanisms</title>
<author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE 80 <author>
2.11 WG RCM SG"> <organization>IEEE 802.11 WG RCM SG</organization>
</author> </author>
<date month="" year="2020"/> <date month="" year="2020"/>
</front> </front>
<seriesInfo name="doc.:IEEE 802.11-20/1346r1" value="" /> <refcontent>doc.:IEEE 802.11-20/1346r1</refcontent>
</reference> </reference>
<reference anchor="IEEE802.1AEdk-2023" > <reference anchor="IEEE_802.1AEdk">
<front> <front>
<title>IEEE Std 802.1AEdk-2023: IEEE Standard for Local and metropolit <title>IEEE Standard for Local and metropolitan area networks-Media Ac
an area networks-Media Access Control (MAC) Security - Amendment 4: MAC Privacy cess Control (MAC) Security - Amendment 4: MAC Privacy protection</title>
protection</title> <author>
<author initials="" surname="IEEE 802.1" fullname="IEEE 802.1"> <organization>IEEE</organization>
</author> </author>
<date month="" year="2023"/> <date month="August" year="2023"/>
</front> </front>
</reference> <seriesInfo name="IEEE Std" value="802.1AEdk-2023"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2023.10225636"/>
</reference>
<reference anchor="IEEE802.1D-2004" > <reference anchor="IEEE_802.1D">
<front> <front>
<title>IEEE Std 802.1D-2004: IEEE Standard for Local and metropolitan <title>IEEE Standard for Local and metropolitan area networks: Media A
area networks: Media Access Control (MAC) Bridges</title> ccess Control (MAC) Bridges</title>
<author initials="" surname="IEEE 802.1" fullname="IEEE 802.1"> <author>
<organization>IEEE</organization>
</author> </author>
<date month="" year="2004"/> <date month="June" year="2004"/>
</front> </front>
</reference> <seriesInfo name="IEEE Std" value="802.1D-2004"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2004.94569"/>
</reference>
<reference anchor="IEEE802.1AB-2016" > <reference anchor="IEEE_802.1AB">
<front> <front>
<title>IEEE Std 802.1AB-2016: IEEE Standard for Local and metropolitan <title>IEEE Standard for Local and metropolitan area networks - Statio
area networks - Station and Media Access Control Connectivity Discovery</title> n and Media Access Control Connectivity Discovery</title>
<author initials="" surname="IEEE 802.1" fullname="IEEE 802.1"> <author>
<organization>IEEE</organization>
</author> </author>
<date month="" year="2016"/> <date month="March" year="2016"/>
</front> </front>
</reference> <seriesInfo name="IEEE Std" value="802.1AB-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
</reference>
<reference anchor="wba_paper" > <reference anchor="wba_paper">
<front> <front>
<title>Wi-Fi Identification Scope for Liasing - In a post MAC Randomiz ation Era</title> <title>Wi-Fi Identification Scope for Liasing - In a post MAC Randomiz ation Era</title>
<author fullname="Wireless Broadband Alliance"> <author>
<organization>Wireless Broadband Alliance</organization>
</author> </author>
<date month="March" year="2020"/> <date month="March" year="2020"/>
</front> </front>
<seriesInfo name="doc.:WBA Wi-Fi ID Intro: Post MAC Randomization Era v1 <refcontent>doc.:WBA Wi-Fi ID Intro: Post MAC Randomization Era v1.0 - IE
.0 - IETF liaison" value="" /> TF liaison</refcontent>
</reference> </reference>
<reference anchor="contact_tracing_paper" > <reference anchor="contact_tracing_paper" target="https://ieeexplore.ieee. org/document/9488728">
<front> <front>
<title>Contact Tracing App Privacy: What Data Is Shared By Europe's GA EN Contact Tracing Apps</title> <title>Contact Tracing App Privacy: What Data Is Shared By Europe's GA EN Contact Tracing Apps</title>
<author fullname="Douglas J. Leith"></author> <author fullname="Douglas J. Leith"/>
<author fullname="Stephen Farrell"></author> <author fullname="Stephen Farrell"/>
<date month="July" year="2020"/> <date month="May" year="2021"/>
</front> </front>
<seriesInfo name="IEEE INFOCOM 2021" value="" /> <refcontent>IEEE INFOCOM 2021 - IEEE Conference on Computer Communicatio
</reference> ns</refcontent>
<seriesInfo name="DOI" value="10.1109/INFOCOM42981.2021.9488728"/>
</reference>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Guillermo Sanchez Illan"/> fo
r the extensive tests
performed on different OSes to analyze their behavior regarding address
randomization.
</t>
<t>
The authors would also like to thank <contact fullname="Jerome Henry"/>, <contac
t fullname="Hai Shalom"/>, <contact fullname="Stephen Farrell"/>, <contact fulln
ame="Alan
DeKok"/>, <contact fullname="Mathieu Cunche"/>, <contact fullname="Johanna Ansoh
n McDougall"/>, <contact fullname="Peter Yee"/>, <contact fullname="Bob Hinden"/
>, <contact fullname="Behcet
Sarikaya"/>, <contact fullname="David Farmer"/>, <contact fullname="Mohamed Bouc
adair"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Christian Amsüss
"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Murray Kucherawy"/>
, and <contact fullname="Paul Wouters"/> for their reviews and comments on
previous draft versions of this document. In addition, the authors would like to
thank <contact fullname="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 <eref target="https://datatracker.ietf.org/liaison/1884/"/>).
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 223 change blocks. 
765 lines changed or deleted 828 lines changed or added

This html diff was produced by rfcdiff 1.48.