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 March 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 Address (PVOM)
6.2. Per-Device Generated MAC Address (PDGM) 6.2. Per-Device Generated MAC Address (PDGM)
6.3. Per-Boot Generated MAC Address (PBGM) 6.3. Per-Boot Generated MAC Address (PBGM)
6.4. Per-Network Generated MAC Address (PNGM) 6.4. Per-Network Generated MAC Address (PNGM)
6.5. Per-Period Generated MAC Address (PPGM) 6.5. Per-Period Generated MAC Address (PPGM)
6.6. Per-Session Generated MAC Address (PSGM) 6.6. Per-Session Generated MAC Address (PSGM)
7. OS Current Practices 7. OS Current Practices
8. IANA Considerations 8. IANA Considerations
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 Wi-Fi enabled (i.e., they are
equipped with an IEEE 802.11 wireless local area network interface). equipped with an IEEE 802.11 wireless local area network interface).
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
Ethernet (i.e., IEEE 802.3), Wi-Fi interfaces have an L2 address Ethernet (i.e., IEEE 802.3), Wi-Fi interfaces have an L2 address
(also referred to as a MAC address) that can be seen by anybody who (also referred to as a MAC address) that can be seen by anybody who
can receive the radio signal transmitted by the network interface. can receive the radio signal transmitted by the network interface.
The format of these addresses (for 48-bit MAC addresses) is shown in The format of these addresses (for 48-bit MAC addresses) is shown in
Figure 1. Figure 1.
+--------+--------+---------+--------+--------+---------+ +--------+--------+---------+--------+--------+---------+
| Organizationally Unique | Network Interface | | Organizationally Unique | Network Interface |
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 device (also known as an IEEE 802.11 station
different situations: or STA) exposes its MAC address in two different situations:
* While actively scanning for available networks, the MAC address is * While actively scanning for available networks, the MAC address is
used in the Probe Request frames sent by the device (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 230 skipping to change at line 230
developing new Internet protocol specifications (e.g., the developing new Internet protocol specifications (e.g., the
considerations described in [RFC6973]). The tutorial highlighted considerations described in [RFC6973]). The tutorial highlighted
some privacy concerns that apply specifically to link-layer some privacy concerns that apply specifically to link-layer
technologies and provided suggestions on how IEEE 802 could help technologies and provided suggestions on how IEEE 802 could help
address them. address them.
Following the discussions and interest within the IEEE 802 community, Following the discussions and interest within the IEEE 802 community,
on 18 July 2014, the IEEE 802 Executive Committee (EC) created the on 18 July 2014, the IEEE 802 Executive Committee (EC) created the
IEEE 802 EC Privacy Recommendation Study Group (SG) IEEE 802 EC Privacy Recommendation Study Group (SG)
[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 Project Authorization Requests
Request, this is the means by which standards projects are started (PARs) that resulted in the following documents:
within the IEEE. PARs define the scope, purpose, and contact points
for a new project): Recommended Practice for Privacy Considerations
for IEEE 802 Technologies [IEEE_802E], and the 802c PAR: Standard for
Local and Metropolitan Area Networks - Overview and Architecture -
Amendment 2: Local Medium Access Control (MAC) Address Usage
[IEEE_802c].
In order to test the effects of MAC address randomization, trials * "IEEE Recommended Practice for Privacy Considerations for IEEE
were conducted at the IETF and IEEE 802 meetings between November 802(R) Technologies" [IEEE_802E]
2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802 Plenary in
Berlin. The purpose of the trials was to evaluate the use of MAC
address randomization from two different perspectives: (1) the effect
on the connectivity experience of the end user, as well as any effect
on applications and OSes, and (2) the potential impact on the network
infrastructure itself. Some of the findings were published in
[CSCN2015].
During the trials, it was observed that the probability of address * "IEEE Standard for Local and Metropolitan Area Networks: Overview
duplication in a network is negligible. The trials also revealed and Architecture - Amendment 2: Local Medium Access Control (MAC)
that other protocol identifiers (e.g., the DHCP client identifier) Address Usage" [IEEE_802c]
can be correlated and can therefore still be used to track an
individual. Hence, effective privacy tools should not work in
isolation at a single layer; instead; they should be coordinated with
other privacy features at higher layers.
Since then, MAC randomization has been further implemented by mobile In order to test the effects of MAC address randomization,
OSes to provide better privacy for mobile phone users when connecting experiments were conducted at the IETF and IEEE 802 meetings between
to public wireless networks [privacy_ios] [privacy_windows] November 2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802
[privacy_android]. Plenary in Berlin. The purpose of the experiments was to evaluate
the use of MAC address randomization from two different perspectives:
(1) the effect on the connectivity experience of the end user, as
well as any effect on applications and OSes, and (2) the potential
impact on the network infrastructure itself. Some of the findings
were published in [CSCN2015].
During the experiments, it was observed that the probability of
address duplication in a network is negligible. The experiments also
revealed that other protocol identifiers (e.g., the DHCP client
identifier) can be correlated and can therefore still be used to
track an individual. Hence, effective privacy tools should not work
in isolation at a single layer; instead; they should be coordinated
with other privacy features at higher layers.
Since then, MAC address randomization has been further implemented by
mobile OSes to provide better privacy for mobile phone users when
connecting to public wireless networks [privacy_ios]
[privacy_windows] [privacy_android].
3. Activities Relating to Randomized and Changing MAC Addresses in the 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 addresses
(RCM) in devices (some of which are explained in Section 6) helped (RCM) in devices (some of which are explained in Section 6) helped
researchers fine-tune their understanding of attacks against researchers fine-tune their understanding of attacks against
randomization mechanisms [when_mac_randomization_fails]. 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. The purpose of these projects was to develop mechanisms
decrease user privacy but enable an optimal user experience when the that do not decrease user privacy but enable an optimal user
MAC address of a device in an Extended Service Set (a group of experience when (1) the MAC address of a device in an Extended
interconnected IEEE 802.11 wireless access points and stations that Service Set (a group of interconnected IEEE 802.11 wireless access
form a single logical network) is randomized or changes points and stations that form a single logical network) is randomized
[rcm_user_experience_par] and user privacy solutions applicable to or changes [rcm_user_experience_par] and (2) user privacy solutions
IEEE Std 802.11 [rcm_privacy_par]. described in IEEE Std 802.11 [rcm_privacy_par] apply.
IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017 IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017
[IEEE_802c], specifies a local MAC address space structure known as [IEEE_802c], specifies a local MAC address space structure known as
the Structured Local Address Plan (SLAP) [RFC8948]. The SLAP the Structured Local Address Plan (SLAP) [RFC8948]. The SLAP
designates a range of Extended Local Identifiers for subassignment designates a range of Extended Local Identifiers for subassignment
within a block of addresses assigned by the IEEE Registration within a block of addresses assigned by the IEEE Registration
Authority via a Company ID. A range of local MAC addresses is Authority via a Company ID. A range of local MAC addresses is
designated for Standard Assigned Identifiers to be specified by IEEE designated for Standard Assigned Identifiers to be specified by IEEE
802 standards. Another range of local MAC addresses is designated 802 standards. Another range of local MAC addresses is designated
for Administratively Assigned Identifiers, which are subject to for Administratively Assigned Identifiers, which are subject to
assignment by a network administrator. assignment by a network administrator.
IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy
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 I 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:
* 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 creates on 802.11 networks and related
services. 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
new mechanisms that address and improve user privacy. [IEEE_802.11] to specify 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 (see
version of this document has been liaised with the IETF as part of [wba_paper]).
the MAC Address Device Identification for Network and Application
Services (MADINAS) activities through the "Wi-Fi Identification In a
post MAC Randomization Era v1.0" paper [wba_paper].
5. IPv6 Address Randomization 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: The naming convention for the terms defined in this
in the acronym but not the "A" from "Address". This allows one to | section aligns with 802.11/Wi-Fi terminology in that the "A"
talk about a PVOM Address or PNGM Address. | for "address" is not included in the acronym. For example,
| "PVOM" stands for "Per-Vendor OUI MAC address", and "PNGM"
| stands for "Per-Network Generated MAC address".
6.1. Per-Vendor OUI MAC Address (PVOM) 6.1. Per-Vendor OUI MAC Address (PVOM)
This form of MAC address selection is the historical default. This form of MAC address selection is the historical default.
The vendor obtains an 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 Address (PDGM)
This form of MAC address is randomly generated by the device, usually This form of MAC address is randomly generated by the device, usually
upon first boot. The resulting MAC address is stored in non-volatile upon first boot. The resulting MAC address is stored in non-volatile
storage and is used for the rest of the device lifetime. storage and is used for the rest of the device lifetime.
6.3. Per-Boot Generated MAC Address (PBGM) 6.3. Per-Boot Generated MAC Address (PBGM)
This form of MAC address is randomly generated by the device each This form of MAC address is randomly generated by the device each
time the device is booted. The resulting MAC address is *not* stored time the device is booted. The resulting MAC address is *not* stored
in non-volatile storage. It does not persist across power cycles. in non-volatile storage. It does not persist across power cycles.
This case may sometimes be a PDGM where the non-volatile storage is This case may sometimes be a PDGM where the non-volatile storage is
no longer functional (or has failed). no longer functional (or has failed).
6.4. Per-Network Generated MAC Address (PNGM) 6.4. Per-Network Generated MAC Address (PNGM)
This form of MAC address is generated each time a new network This form of MAC address is generated each time a new network
attachment is created. attachment is created.
This is typically used with Wi-Fi (802.11) networks where the network This is typically used with Wi-Fi networks (i.e., 802.11 networks)
is identified by an SSID Name. The generated address is stored 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 PNGM for wired Ethernet connections through
some passive observation of network traffic (such as STP some passive observation of network traffic (such as spanning tree
[IEEE_802.1D], the Link Layer Discovery Protocol (LLDP) protocols [IEEE_802.1Q], the Link Layer Discovery Protocol (LLDP)
[IEEE_802.1AB], DHCP, or Router Advertisements) to determine which [IEEE_802.1AB], DHCP, or Router Advertisements) to determine which
network has been attached. network has been attached.
6.5. Per-Period Generated MAC Address (PPGM) 6.5. Per-Period Generated MAC Address (PPGM)
This form of MAC address is generated periodically, 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, 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 802.1x session, as well as obtaining or refreshing a
Protocol (EAP), TLS, etc. negotiations. A new DHCP, SLAAC will be 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 Address (PSGM)
This form of MAC address is generated on a per-session basis. How a This form of MAC address is generated on a per-session basis. How a
session is defined is implementation-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, 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
hosted at [OS_current_practices]. For completeness, a snapshot of hosted at <https://wiki.ietf.org/en/group/madinas/RFC9724>. For
the content at the time of publication of this document is included completeness, a snapshot of the content at the time of publication of
below. Note that the extensive testing reported in this document was this document is included below. Note that the extensive testing
conducted in 2021, but no significant changes have been detected at reported in this document was conducted in 2021, but no significant
the time of publication of this document. changes have been detected at the time of publication of this
document.
Table 1 summarizes current practices for Android and iOS at the time Table 1 summarizes current practices for Android and iOS at the time
of writing this document (the original source is available at of writing this document (the original source is available at
[private_mac]) and also includes updates based on findings from the [private_mac]) and also includes updates based on findings from the
authors. authors.
+=============================================+===================+ +=============================================+===================+
| Android 10+ | iOS 14+ | | Android 10+ | iOS 14+ |
+=============================================+===================+ +=============================================+===================+
| The randomized MAC address is bound to the | The randomized | | The randomized MAC address is bound to the | The randomized |
skipping to change at line 570 skipping to change at line 574
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 631
* 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 662 skipping to change at line 666
A Quantitative Analysis", Mobile Networks and A Quantitative Analysis", Mobile Networks and
Applications, vol. 10, no. 3, pp. 315-325, Applications, vol. 10, no. 3, pp. 315-325,
DOI 10.1007/s11036-005-6425-1, June 2005, DOI 10.1007/s11036-005-6425-1, June 2005,
<https://doi.org/10.1007/s11036-005-6425-1>. <https://doi.org/10.1007/s11036-005-6425-1>.
[IEEE_802] IEEE, "IEEE Standard for Local and Metropolitan Area [IEEE_802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2014, Networks: Overview and Architecture", IEEE Std 802-2014,
DOI 10.1109/IEEESTD.2014.6847097, June 2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014,
<https://doi.org/10.1109/IEEESTD.2014.6847097>. <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEE_802.11]
IEEE, "IEEE Standard for Information Technology--
Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Networks--Specific
Requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693,
February 2021,
<https://doi.org/10.1109/IEEESTD.2021.9363693>.
[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.1Q]
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--Bridges and Bridged Networks", IEEE Std 802.1Q-
802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June 2004, 2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022,
<https://ieeexplore.ieee.org/document/1309630>. <https://doi.org/10.1109/IEEESTD.2022.10004498>.
[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 716 skipping to change at line 736
IEEE 802 LAN/MAN Standards Committee, "IEEE 802 EC Privacy IEEE 802 LAN/MAN Standards Committee, "IEEE 802 EC Privacy
Recommendation Study Group", Recommendation Study Group",
<http://www.ieee802.org/PrivRecsg/>. <http://www.ieee802.org/PrivRecsg/>.
[link_layer_privacy] [link_layer_privacy]
O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the
link-layer", W3C/IAB workshop on Strengthening the link-layer", W3C/IAB workshop on Strengthening the
Internet Against Pervasive Monitoring (STRINT), February Internet Against Pervasive Monitoring (STRINT), February
2014. 2014.
[OS_current_practices]
"OS current practices", commit 795739b, July 2024,
<https://github.com/ietf-wg-madinas/draft-ietf-madinas-
mac-address-randomization/blob/main/OS-current-
practices.md>.
[privacy_android] [privacy_android]
Android Open Source Project, "MAC randomization behavior", Android Open Source Project, "MAC randomization behavior",
Android OS Documentation, Android OS Documentation,
<https://source.android.com/devices/tech/connect/wifi-mac- <https://source.android.com/devices/tech/connect/wifi-mac-
randomization-behavior>. randomization-behavior>.
[privacy_ios] [privacy_ios]
Apple Inc., "Use private Wi-Fi addresses on Apple Apple Inc., "Use private Wi-Fi addresses on Apple
Devices", Apple Support, Devices", Apple Support,
<https://support.apple.com/en-us/102509>. <https://support.apple.com/en-us/102509>.
skipping to change at line 757 skipping to change at line 771
[private_mac] [private_mac]
Pantaleone, D., "Private MAC address on iOS 14", Wayback Pantaleone, D., "Private MAC address on iOS 14", Wayback
Machine archive, September 2020, Machine archive, September 2020,
<https://web.archive.org/web/20230905111429/ <https://web.archive.org/web/20230905111429/
https://www.fing.com/news/private-mac-address-on-ios-14>. https://www.fing.com/news/private-mac-address-on-ios-14>.
[rcm_privacy_csd] [rcm_privacy_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1346r1, 2020. mechanisms", doc.:IEEE 802.11-20/1346r4, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-1346-04-0rcm-csd-draft-for-privacy-amendment-
of-rcm- project.docx>.
[rcm_privacy_par] [rcm_privacy_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on privacy Changing MAC Addresses Study Group PAR on privacy
mechanisms", doc.:IEEE 802.11-19/854r7, 2020. mechanisms", doc.:IEEE 802.11-19/854r7, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-0854-07-0rcm-par-proposal-for-privacy.docx>.
[rcm_tig_final_report] [rcm_tig_final_report]
IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And
Changing MAC Addresses Topic Interest Group Report", Changing MAC Addresses Topic Interest Group Report",
doc.:IEEE 802.11-19/1442r9, 2019. doc.:IEEE 802.11-19/1442r9, 2019. Download available at
<https://mentor.ieee.org/802.11/ dcn/19/11-19-1442-09-
0rcm-rcm-tig-draft-report-outline.odt>.
[rcm_user_experience_csd] [rcm_user_experience_csd]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group CSD on user experience Changing MAC Addresses Study Group CSD on user experience
mechanisms", doc.:IEEE 802.11-20/1117r3, 2020. mechanisms", doc.:IEEE 802.11-20/1117r5, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-1117-05-0rcm-rcm-sg-proposed-rcm-csd-
draft.docx>.
[rcm_user_experience_par] [rcm_user_experience_par]
IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
Changing MAC Addresses Study Group PAR on user experience Changing MAC Addresses Study Group PAR on user experience
mechanisms", doc.:IEEE 802.11-20/742r5, 2020. mechanisms", doc.:IEEE 802.11-20/742r6, 2020. Download
available at <https://mentor.ieee.org/802.11/
dcn/20/11-20-0742-06-0rcm-proposed-par-draft.docx>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
skipping to change at line 831 skipping to change at line 857
"Temporary Address Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>. <https://www.rfc-editor.org/info/rfc8981>.
[strint] W3C/IAB, "STRINT Workshop: A W3C/IAB workshop on [strint] W3C/IAB, "STRINT Workshop: A W3C/IAB workshop on
Strengthening the Internet Against Pervasive Monitoring Strengthening the Internet Against Pervasive Monitoring
(STRINT)", <https://www.w3.org/2014/strint/>. (STRINT)", <https://www.w3.org/2014/strint/>.
[wba_paper] [wba_paper]
Wireless Broadband Alliance, "Wi-Fi Identification Scope Wireless Broadband Alliance, "Wi-Fi Device Identification
for Liasing - In a post MAC Randomization Era", doc.:WBA - A Way Through MAC Randomization", WBA White Paper, July
Wi-Fi ID Intro: Post MAC Randomization Era v1.0 - IETF 2022, <https://wballiance.com/resource/wi-fi-device-
liaison, March 2020. identification-a-way-through-mac-randomization/>.
[when_mac_randomization_fails] [when_mac_randomization_fails]
Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown, Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown,
L., Riggins, C., Rye, E., and D. Brown, "A Study of MAC L., Riggins, C., Rye, E., and D. Brown, "A Study of MAC
Address Randomization in Mobile Devices and When it Address Randomization in Mobile Devices and When it
Fails", arXiv:1703.02874v2, DOI 10.48550/arXiv.1703.02874, Fails", arXiv:1703.02874v2, DOI 10.48550/arXiv.1703.02874,
March 2017, <https://doi.org/10.48550/arXiv.1703.02874>. March 2017, <https://doi.org/10.48550/arXiv.1703.02874>.
[wifi_tracking] [wifi_tracking]
Vincent, J., "London's bins are tracking your smartphone", Vincent, J., "London's bins are tracking your smartphone",
skipping to change at line 864 skipping to change at line 890
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. 44 change blocks. 
131 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.48.