rfc9724v1.txt   rfc9724.txt 
Internet Engineering Task Force (IETF) JC. Zúñiga Internet Engineering Task Force (IETF) JC. Zúñiga
Request for Comments: 9724 Cisco Request for Comments: 9724 Cisco
Category: Informational CJ. Bernardos, Ed. Category: Informational CJ. Bernardos, Ed.
ISSN: 2070-1721 UC3M ISSN: 2070-1721 UC3M
A. Andersdotter A. Andersdotter
Safespring AB Safespring AB
January 2025 January 2025
Randomized and Changing Media Access Control (MAC) Address State of State of Affairs for Randomized and Changing Media Access Control (MAC)
Affairs 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 of can be tracked. One of the main factors that eases tracking of
Internet users is the wide use of long-lasting, and sometimes Internet users is the wide use of long-lasting, and sometimes
persistent, identifiers at various protocol layers. This document persistent, identifiers at various protocol layers. This document
focuses on Media Access Control (MAC) 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 the privacy issues involved. standards committees to address some of the privacy issues involved.
This document provides an overview of these activities to help This document provides an overview of these activities to help
coordinate standardization activities in these bodies. coordinate standardization activities in these bodies.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for informational purposes. published for informational purposes.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
skipping to change at line 69 skipping to change at line 69
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Background 2. Background
2.1. MAC Address Usage 2.1. MAC Address Usage
2.2. MAC Address Randomization 2.2. MAC Address Randomization
2.3. Privacy Workshop, Tutorial, and Experiments at IETF and 2.3. Privacy Workshop, Tutorial, and Experiments at IETF and
IEEE 802 Meetings IEEE 802 Meetings
3. Activities Relating to Randomized and Changing MAC Addresses in 3. Activities Relating to Randomized and Changing MAC Addresses in
the IEEE 802 the IEEE 802
4. Recent Activities Related to MAC Randomization in the WBA 4. Recent Activities Related to MAC Address Randomization in the
WBA
5. IPv6 Address Randomization in the IETF 5. IPv6 Address Randomization in the IETF
6. Taxonomy of MAC Address Selection Policies 6. Taxonomy of MAC Address Selection Policies
6.1. Per-Vendor OUI MAC Address (PVOM) 6.1. Per-Vendor OUI MAC (PVOM) Address
6.2. Per-Device Generated MAC Address (PDGM) 6.2. Per-Device Generated MAC (PDGM) Address
6.3. Per-Boot Generated MAC Address (PBGM) 6.3. Per-Boot Generated MAC (PBGM) Address
6.4. Per-Network Generated MAC Address (PNGM) 6.4. Per-Network Generated MAC (PNGM) Address
6.5. Per-Period Generated MAC Address (PPGM) 6.5. Per-Period Generated MAC (PPGM) Address
6.6. Per-Session Generated MAC Address (PSGM) 6.6. Per-Session Generated MAC (PSGM) Address
7. OS Current Practices 7. OS Current Practices
8. IANA Considerations 8. IANA Considerations
9. Security Considerations 9. Security Considerations
10. Informative References 10. Informative References
Acknowledgments Acknowledgments
Authors' Addresses 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
skipping to change at line 110 skipping to change at line 111
trackers, etc. trackers, etc.
Privacy concerns affect all layers of the protocol stack, from the Privacy concerns affect all layers of the protocol stack, from the
lower layers involved in the access to the network (e.g., MAC/L2 and lower 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- L3 addresses can be used to obtain the location of a user) to higher-
layer protocol identifiers and user applications [CSCN2015]. In layer protocol identifiers and user applications [CSCN2015]. In
particular, IEEE 802 MAC addresses have historically been an easy particular, IEEE 802 MAC addresses have historically been an easy
target for tracking users [wifi_tracking]. target for tracking users [wifi_tracking].
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 these privacy issues. This
document provides an overview of these activities to help coordinate document provides an overview of these activities to help coordinate
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 WLAN 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).
Like any other kind of network interface based on IEEE 802 such as Like any other kind of network interface based on IEEE 802 such as
skipping to change at line 181 skipping to change at line 182
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 medium to transmit data -- especially over the air -- it is
relatively easy to track this device by simple medium observation. relatively easy to track this device by simple medium observation.
Since a device is usually directly associated to an individual, this Since a device is usually directly associated to an individual, this
poses a 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 L2 network. passive device listening to communications in the same L2 network.
In an 802.11 network, a station exposes its MAC address in two In an 802.11 network, a station (STA) exposes its MAC address in two
different situations: 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 (also known as used in the Probe Request frames sent by the device.
IEEE 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. 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 local addresses to be generated without the need for any
global coordination mechanism to ensure that the generated address is global coordination mechanism to ensure that the generated address is
still unique within the local network. This feature can be used to still 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].
skipping to change at line 239 skipping to change at line 239
[ieee_privacy_ecsg]. The work and discussions from the group have [ieee_privacy_ecsg]. The work and discussions from the group have
generated multiple outcomes, such as: 802E PAR (Project Authorization generated multiple outcomes, such as: 802E PAR (Project Authorization
Request, this is the means by which standards projects are started Request, this is the means by which standards projects are started
within the IEEE. PARs define the scope, purpose, and contact points within the IEEE. PARs define the scope, purpose, and contact points
for a new project): Recommended Practice for Privacy Considerations for a new project): Recommended Practice for Privacy Considerations
for IEEE 802 Technologies [IEEE_802E], and the 802c PAR: Standard for for IEEE 802 Technologies [IEEE_802E], and the 802c PAR: Standard for
Local and Metropolitan Area Networks - Overview and Architecture - Local and Metropolitan Area Networks - Overview and Architecture -
Amendment 2: Local Medium Access Control (MAC) Address Usage Amendment 2: Local Medium Access Control (MAC) Address Usage
[IEEE_802c]. [IEEE_802c].
In order to test the effects of MAC address randomization, trials In order to test the effects of MAC address randomization,
were conducted at the IETF and IEEE 802 meetings between November experiments were conducted at the IETF and IEEE 802 meetings between
2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802 Plenary in November 2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802
Berlin. The purpose of the trials was to evaluate the use of MAC Plenary in Berlin. The purpose of the experiments was to evaluate
address randomization from two different perspectives: (1) the effect the use of MAC address randomization from two different perspectives:
on the connectivity experience of the end user, as well as any effect (1) the effect on the connectivity experience of the end user, as
on applications and OSes, and (2) the potential impact on the network well as any effect on applications and OSes, and (2) the potential
infrastructure itself. Some of the findings were published in impact on the network infrastructure itself. Some of the findings
[CSCN2015]. were published in [CSCN2015].
During the trials, it was observed that the probability of address During the experiments, it was observed that the probability of
duplication in a network is negligible. The trials also revealed address duplication in a network is negligible. The experiments also
that other protocol identifiers (e.g., the DHCP client identifier) revealed that other protocol identifiers (e.g., the DHCP client
can be correlated and can therefore still be used to track an identifier) can be correlated and can therefore still be used to
individual. Hence, effective privacy tools should not work in track an individual. Hence, effective privacy tools should not work
isolation at a single layer; instead; they should be coordinated with in isolation at a single layer; instead; they should be coordinated
other privacy features at higher layers. with other privacy features at higher layers.
Since then, MAC randomization has been further implemented by mobile Since then, MAC address randomization has been further implemented by
OSes to provide better privacy for mobile phone users when connecting mobile OSes to provide better privacy for mobile phone users when
to public wireless networks [privacy_ios] [privacy_windows] connecting to public wireless networks [privacy_ios]
[privacy_android]. [privacy_windows] [privacy_android].
3. Activities Relating to Randomized and Changing MAC Addresses in the 3. Activities Relating to Randomized and Changing MAC Addresses in the
IEEE 802 IEEE 802
Practical experiences with Randomized and Changing MAC addresses Practical experiences with Randomized and Changing MAC (RCM)
(RCM) in devices (some of which are explained in Section 6) helped addresses in devices (some of which are explained in Section 6)
researchers fine-tune their understanding of attacks against helped researchers fine-tune their understanding of attacks against
randomization mechanisms [when_mac_randomization_fails]. Within the randomization mechanisms [when_mac_randomization_fails]. Within the
IEEE 802.11 group, these research experiences eventually formed the IEEE 802.11 group, these research experiences eventually formed the
basis for a specified mechanism that randomizes MAC addresses, which basis for a specified mechanism that randomizes MAC addresses, which
was introduced in IEEE Std 802.11aq [IEEE_802.11aq] in 2018. 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 a 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]. commonly offered operator services in 2019 [rcm_tig_final_report].
In the summer of 2020, this work emanated in two new standards In the summer of 2020, this work emanated in two new standards
projects with the purpose of developing mechanisms that do not projects with the purpose of developing mechanisms that do not
decrease user privacy but enable an optimal user experience when the decrease user privacy but enable an optimal user experience when the
MAC address of a device in an Extended Service Set (a group of MAC address of a device in an Extended Service Set (a group of
interconnected IEEE 802.11 wireless access points and stations that interconnected IEEE 802.11 wireless access points and stations that
form a single logical network) is randomized or changes form a single logical network) is randomized or changes
[rcm_user_experience_par] and user privacy solutions applicable to [rcm_user_experience_par] and user privacy solutions applicable to
skipping to change at line 310 skipping to change at line 310
Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends
the use of temporary and transient identifiers if there are no the use of temporary and transient identifiers if there are no
compelling reasons for a newly introduced identifier to be permanent. compelling reasons for a newly introduced identifier to be permanent.
This recommendation is part of the basis for the review of user This recommendation is part of the basis for the review of user
privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi
devices) as part of the RCM efforts [rcm_privacy_csd]. Annex T of devices) as part of the RCM efforts [rcm_privacy_csd]. Annex T of
IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk] IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk]
discusses privacy considerations in bridged networks. discusses privacy considerations in bridged networks.
As of 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 addresses:
* The IEEE 802.11bh task group, which is 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 addresses create on 802.11 networks and
services. related 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 MAC specification to specify modifications to the IEEE Std 802.11 MAC specification to specify
new mechanisms that address and improve user privacy. new mechanisms that address and improve user privacy.
4. Recent Activities Related to MAC Randomization in the WBA 4. Recent Activities Related to MAC Address Randomization in the WBA
In the Wireless Broadband Alliance (WBA), the Testing and In the Wireless Broadband Alliance (WBA), the Testing and
Interoperability Work Group has been looking at issues related to MAC Interoperability Work Group has been looking at issues related to MAC
address randomization and has identified a list of potential impacts address randomization and has identified a list of potential impacts
of these changes to existing systems and solutions, mainly related to of these changes to existing systems and solutions, mainly related to
Wi-Fi identification. Wi-Fi identification.
As part of this work, the WBA has documented a set of use cases that 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 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. A first
version of this document has been liaised with the IETF as part of version of that document, a paper titled "Wi-Fi Identification In a
the MAC Address Device Identification for Network and Application post MAC Randomization Era v1.0" [wba_paper], was created while
Services (MADINAS) activities through the "Wi-Fi Identification In a liaising with the IETF MADINAS Working Group.
post MAC Randomization Era v1.0" paper [wba_paper].
5. IPv6 Address Randomization in 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 updated router and an Interface Identifier (IID). [RFC8064] formally updated
the original IPv6 IID selection mechanism to avoid generating the IID the original IPv6 IID selection mechanism to avoid generating 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,
skipping to change at line 366 skipping to change at line 365
eavesdroppers and other information collectors may trivially perform eavesdroppers and other information collectors may trivially perform
address-based network-activity correlation when the same address is address-based network-activity correlation when the same address is
employed for multiple transactions by the same host. Additionally, employed for multiple transactions by the same host. Additionally,
it reduces the window of exposure of a host as being accessible via it reduces the window of exposure of a host as being accessible via
an address that becomes revealed as a result of active communication. an address that becomes revealed as a result of active communication.
These temporary addresses are meant to be used for a short period of These temporary addresses are meant to be used for a short period of
time (hours to days) and then deprecated. Deprecated addresses can time (hours to days) and then 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 IIDs that appear to be random in temporary global scope addresses from a sequence of IIDs that appear
the sense that it is difficult for an outside observer to predict a to be random in the sense that (1) it is difficult for an outside
future address (or identifier) based on a current one and it is observer to predict a future address (or identifier) based on a
difficult to determine previous addresses (or identifiers) knowing current one and (2) it is difficult to determine previous addresses
only the present one. Temporary addresses should not be used by (or identifiers) knowing only the present one. Temporary addresses
applications that listen for incoming connections (as these are should not be used by applications that listen for incoming
supposed to be waiting on permanent/well-known identifiers). If a connections (as these are supposed to be waiting on permanent/well-
node changes network and comes back to a previously visited one, the known identifiers). If a node changes network and comes back to a
temporary addresses that the node would use will be different, which previously visited one, the temporary addresses that the node would
might be an issue in certain networks where addresses are used for use will be different, which might be an issue in certain networks
operational purposes (e.g., filtering or authentication). [RFC7217], where addresses are used for operational purposes (e.g., filtering or
summarized next, partially addresses the problems aforementioned. authentication). [RFC7217], summarized next, partially addresses the
problems aforementioned.
[RFC7217] describes a method to generate IIDs that are stable for [RFC7217] describes a method to generate IIDs that are stable for
each network interface within each subnet but change as a host moves each network interface within each subnet but change as a host moves
from one network to another. This method enables the "stability" from one network to another. This method enables the "stability"
properties of the IIDs specified in [RFC4291] to be kept, while still properties of the IIDs specified in [RFC4291] to be kept, while still
mitigating address-scanning attacks and preventing correlation of the mitigating address-scanning attacks and preventing correlation of the
activities of a host as it moves from one network to another. 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 hash method defined to generate the IPv6 IID is based on computing a hash
function that takes the following as input: information that is function that takes the following as input: information that is
stable and associated to the interface (e.g., a local IID), stable stable and associated to the interface (e.g., a local IID), stable
information associated to the visited network (e.g., IEEE 802.11 information associated to the visited network (e.g., the IEEE 802.11
SSID), the IPv6 prefix, a secret key, and some other additional Service Set Identifier (SSID)), the IPv6 prefix, a secret key, and
information. This basically ensures that a different IID is some other additional information. This basically ensures that a
generated when one of the input fields changes (such as the network different IID is generated when one of the input fields changes (such
or the prefix) but that the IID is the same within each subnet. as the network or the prefix) but that the IID is the same within
each subnet.
To mitigate the privacy threats posed by the use of MAC-derived IIDs, To mitigate the privacy threats posed by the use of MAC-derived IIDs,
[RFC8064] recommends that nodes implement [RFC7217] as the default [RFC8064] recommends that nodes implement [RFC7217] as the default
scheme for generating stable IPv6 addresses with SLAAC. scheme for generating stable IPv6 addresses with SLAAC.
In addition to the documents above, [RFC8947] proposes a DHCPv6 In addition to the documents above, [RFC8947] proposes a DHCPv6
extension that: extension that:
| allows a scalable approach to link-layer address assignments where | allows a scalable approach to link-layer address assignments where
| preassigned link-layer address assignments (such as by a | preassigned link-layer address assignments (such as by a
skipping to change at line 435 skipping to change at line 436
| designed to minimize disclosure of identifying information. | designed to minimize disclosure of identifying information.
[RFC7844] also indicates that the link-layer address, IP address, and [RFC7844] also indicates that the link-layer address, IP address, and
DHCP identifier shall evolve in synchrony. DHCP identifier shall evolve in synchrony.
6. Taxonomy of MAC Address Selection Policies 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 a combination of multiple policies. Some OSes might use a combination of multiple policies.
Note about the naming convention used: The "M" in "MAC" is included | Note about the naming convention used: The "M" in "MAC" is
in the acronym but not the "A" from "Address". This allows one to | included in the acronym but not the "A" from "Address". This
talk about a PVOM Address or PNGM Address. | allows one to talk about a "PVOM address" or "PNGM address".
6.1. Per-Vendor OUI MAC Address (PVOM) 6.1. Per-Vendor OUI MAC (PVOM) Address
This form of MAC address selection is the historical default. This form of MAC address selection is the historical default.
The vendor obtains an OUI from the IEEE. This is a 24-bit prefix The vendor obtains an OUI from the IEEE. This is a 24-bit prefix
(including two upper bits that are set specifically) that is assigned (including two upper bits that are set specifically) that is assigned
to the vendor. The vendor generates a unique 24-bit value for the to the vendor. The vendor generates a unique 24-bit value for the
lower 24 bits, forming the 48-bit MAC address. It is not unusual for lower 24 bits, forming the 48-bit MAC address. It is not unusual for
the 24-bit value to be taken as an incrementing counter, assigned at the 24-bit value to be used as an incrementing counter that was
the factory, and burnt into non-volatile storage. assigned at the factory and burnt into non-volatile storage.
Note that 802.15.4 uses 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 that uses 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 (PDGM) Address
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 (PBGM) Address
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 address where the non-volatile
no longer functional (or has failed). storage is no longer functional (or has failed).
6.4. Per-Network Generated MAC Address (PNGM) 6.4. Per-Network Generated MAC (PNGM) Address
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 in 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 a PNGM address for wired Ethernet connections
some passive observation of network traffic (such as STP through some passive observation of network traffic (such as the
[IEEE_802.1D], the Link Layer Discovery Protocol (LLDP) Spanning Tree Protocol (SPT) [IEEE_802.1D], the Link Layer Discovery
[IEEE_802.1AB], DHCP, or Router Advertisements) to determine which Protocol (LLDP) [IEEE_802.1AB], DHCP, or Router Advertisements) to
network has been attached. determine which network has been attached.
6.5. Per-Period Generated MAC Address (PPGM) 6.5. Per-Period Generated MAC (PPGM) Address
This form of MAC address is generated periodically, typically around This form of MAC address is generated periodically, typically around
every twelve hours. Like PNGM, it is used primarily with Wi-Fi. every twelve hours. Like PNGM addresses, it is used primarily with
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 Extensible Authentication involve a new WPA/802.1x session, as well as obtaining (or
Protocol (EAP), TLS, etc. negotiations. A new DHCP, SLAAC will be refreshing) a new IP address (e.g., using DHCP or SLAAC).
done.
If DHCP is used, then a new DHCP Unique Identifier (DUID) is If DHCP is used, then a new DHCP Unique Identifier (DUID) is
generated so as to not link to the previous connection; this usually generated so as to not link to the previous connection; this usually
results in the allocation of new IP addresses. results in the allocation of new IP addresses.
6.6. Per-Session Generated MAC Address (PSGM) 6.6. Per-Session Generated MAC (PSGM) Address
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-dependent, for example, a session is defined is implementation-dependent, for example, a
session might be defined by logging in to a portal, VPN, etc. Like session might be defined by logging in to a portal, VPN, etc. Like
PNGM, PSGM is used primarily with Wi-Fi. PNGM and PPGM addresses, it is used primarily with Wi-Fi.
Since the address only changes 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
By default, most modern OSes (especially mobile ones) do implement By default, most modern OSes (especially mobile ones) do implement
some MAC address randomization policies. Since the mechanism and some MAC address randomization policies. Since the mechanism and
policies that OSes implement can evolve with time, the content is now policies that OSes implement can evolve with time, the content is now
hosted at [OS_current_practices]. For completeness, a snapshot of hosted at [OS_current_practices]. For completeness, a snapshot of
skipping to change at line 570 skipping to change at line 572
the taxonomy introduced in Section 6), performs address randomization the taxonomy introduced in Section 6), performs address randomization
per new connection (PSGM), performs address randomization daily (PPGM per new connection (PSGM), performs address randomization daily (PPGM
with a period of 24 hours), supports configuration per SSID, supports with a period of 24 hours), supports configuration per SSID, supports
address randomization for scanning, and supports address address randomization for scanning, and supports address
randomization for scanning by default. 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 | | | | |
+-----------------+---------------+---------+---------+-----+ +-----------------+---------------+---------+---------+-----+
skipping to change at line 627 skipping to change at line 629
* Mitigating the problem of location privacy while minimizing the * Mitigating the problem of location privacy while minimizing the
impact on upper layers of the protocol stack impact on upper layers of the protocol stack
* Providing the means for network operators to authenticate devices * Providing the means for network operators to authenticate devices
and authorize network access, despite the MAC addresses changing and authorize network access, despite the MAC addresses changing
according some pattern according some pattern
* Providing the means for the device not to use MAC addresses that * Providing the means for the device not to use MAC addresses that
it is not authorized to use or that are currently in use it is not authorized to use or that are currently in use
A major conclusion of the work in IEEE Std 802E concerned the A major conclusion of the work in IEEE Std 802E [IEEE_802E] concerned
difficulty of defending privacy against adversaries of any the difficulty of defending privacy against adversaries of any
sophistication. Individuals can be successfully tracked by sophistication. Individuals can be successfully tracked by
fingerprinting, using aspects of their communication other than MAC fingerprinting, using aspects of their communication other than MAC
addresses or other permanent identifiers. addresses or other permanent identifiers.
10. 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 - IEEE Conference on Computer Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer
skipping to change at line 672 skipping to change at line 674
[IEEE_802.11aq] [IEEE_802.11aq]
IEEE, "IEEE Standard for Information technology-- IEEE, "IEEE Standard for Information technology--
Telecommunications and information exchange between Telecommunications and information exchange between
systems Local and metropolitan area network--Specific systems Local and metropolitan area network--Specific
requirements Part 11: Wireless LAN Medium Access Control requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 5: (MAC) and Physical Layer (PHY) Specifications Amendment 5:
Preassociation Discovery", IEEE Std 802.11aq-2018, Preassociation Discovery", IEEE Std 802.11aq-2018,
DOI 10.1109/IEEESTD.2018.8457463, August 2018, DOI 10.1109/IEEESTD.2018.8457463, August 2018,
<https://doi.org/10.1109/IEEESTD.2018.8457463>. <https://doi.org/10.1109/IEEESTD.2018.8457463>.
[IEEE_802.15.4]
IEEE, "IEEE Standard for Low‐Rate Wireless Networks", IEEE
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_802.1AB]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks - Station and Media Access Control Connectivity networks - Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2016, Discovery", IEEE Std 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016, DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>. <https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE_802.1AEdk] [IEEE_802.1AEdk]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security - Amendment networks-Media Access Control (MAC) Security - Amendment
4: MAC Privacy protection", IEEE Std 802.1AEdk-2023, 4: MAC Privacy protection", IEEE Std 802.1AEdk-2023,
DOI 10.1109/IEEESTD.2023.10225636, August 2023, DOI 10.1109/IEEESTD.2023.10225636, August 2023,
<https://doi.org/10.1109/IEEESTD.2023.10225636>. <https://doi.org/10.1109/IEEESTD.2023.10225636>.
[IEEE_802.1D] [IEEE_802.1D]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks: Media Access Control (MAC) Bridges", IEEE Std networks: Media Access Control (MAC) Bridges", IEEE Std
802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June 2004, 802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June 2004,
<https://ieeexplore.ieee.org/document/1309630>. <https://doi.org/10.1109/IEEESTD.2004.94569>.
[IEEE_802c] [IEEE_802c]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "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 Std 802c- Medium Access Control (MAC) Address Usage", IEEE Std 802c-
2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, 2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017,
<https://doi.org/10.1109/IEEESTD.2017.8016709>. <https://doi.org/10.1109/IEEESTD.2017.8016709>.
[IEEE_802E] [IEEE_802E]
IEEE, "IEEE Recommended Practice for Privacy IEEE, "IEEE Recommended Practice for Privacy
skipping to change at line 864 skipping to change at line 872
regarding address randomization. regarding address randomization.
The authors would also like to thank Jerome Henry, Hai Shalom, The authors would also like to thank Jerome Henry, Hai Shalom,
Stephen Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn Stephen Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn
McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer, McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer,
Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roman Danyliw, Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roman Danyliw,
Murray Kucherawy, and Paul Wouters for their reviews and comments on Murray Kucherawy, and Paul Wouters for their reviews and comments on
previous draft versions of this document. In addition, the authors previous draft versions of this document. In addition, the authors
would like to thank Michael Richardson for his contributions on the would like to thank Michael Richardson for his contributions on the
taxonomy section. Finally, the authors would like to thank the IEEE taxonomy section. Finally, the authors would like to thank the IEEE
802.1 Working Group for its review and comments, performed as part of 802.1 Working Group for its review and comments (see
the "Liaison statement on Randomized and Changing MAC Address" https://datatracker.ietf.org/liaison/1884/).
(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)
 End of changes. 41 change blocks. 
108 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.48.