RFC 9724

State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses

📅 published March 2025, from ietf

RFC 9724: State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses 🦋

okay bestie, let's get into it 💅 this one is an Informational doc from the IETF (Internet Engineering Task Force), so it's not a Standards Track spec, it's more of a "here's what's going on" update. It came out in March 2025 and has ISSN 2070-1721. The authors are JC. Zúñiga from Cisco, CJ. Bernardos (Ed.) from UC3M, and A. Andersdotter from Safespring AB 🌈 It doesn't list any RFCs it obsoletes or updates, so it's a standalone vibe ✨

Abstract 💜

okay so people are getting way more aware that everything they do online leaves a massive digital footprint 👣 and that their comms might not be properly secured, and that someone can literally track where they are and what they're doing 😭 The big thing that makes tracking so easy is the super common use of long-lasting, sometimes permanent, identifiers at different protocol layers. This doc is focused on Media Access Control (MAC) addresses 🫶

There have been a bunch of efforts in the IETF and the IEEE 802 standards committees to deal with some of the privacy problems here. This doc gives an overview of that work so the groups can coordinate their standards stuff better 🎀

Status of This Memo 🌸

This doc is NOT an Internet Standards Track spec, it's published for info purposes only 🧚

It's a product of the IETF, so it reflects what the IETF community agreed on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is up for any level of Internet Standard, though! See Section 2 of RFC 7841 for the details 🍓

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9724 💖

Copyright (c) 2025 IETF Trust and the people listed as document authors. All rights reserved 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions 🙈 Any Code Components pulled out of this doc have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Revised BSD License describes 💅

Table of Contents 🧚

1.  Introduction
2.  Background
  2.1.  MAC Address Usage
  2.2.  MAC Address Randomization
  2.3.  Privacy Workshop, Tutorial, and Experiments at IETF and
        IEEE 802 Meetings
3.  Activities Relating to Randomized and Changing MAC Addresses in
        the IEEE 802
4.  Recent Activities Related to MAC Address Randomization in the
        WBA
5.  IPv6 Address Randomization in the IETF
6.  Taxonomy of MAC Address Selection Policies
  6.1.  Per-Vendor OUI MAC Address (PVOM)
  6.2.  Per-Device Generated MAC Address (PDGM)
  6.3.  Per-Boot Generated MAC Address (PBGM)
  6.4.  Per-Network Generated MAC Address (PNGM)
  6.5.  Per-Period Generated MAC Address (PPGM)
  6.6.  Per-Session Generated MAC Address (PSGM)
7.  OS Current Practices
8.  IANA Considerations
9.  Security Considerations
10. Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

privacy is becoming a HUGE concern 😭 more and more devices are connecting to the Internet, either directly (like over Wi-Fi) or indirectly (like a phone using Bluetooth) 📱 All that constant connectivity, plus the lack of real privacy education, makes it super easy to track or monitor where users are and/or eavesdrop on their physical and online activities 👀 A big reason is the massive digital footprint people leave online, with or without consent, plus weak (or even zero) authentication and encryption protecting comms 🙈 A digital footprint can include stuff shared on social networks, cookies that browsers and servers use for all sorts of reasons, connectivity logs that let someone track a user's Layer 2 (L2) address (aka MAC address) or Layer 3 (L3) address, web trackers, and more 🕵️‍♀️

Privacy concerns hit every layer of the protocol stack, from the lower layers used to get onto the network (like MAC/L2 and L3 addresses, which can be used to find where a user is) all the way up to higher-layer protocol identifiers and user apps [CSCN2015] 🎀 Especially, IEEE 802 MAC addresses have historically been an easy target for tracking users [wifi_tracking] 💀

There have been several efforts in the IETF and the IEEE 802 standards committees to handle some of these privacy issues too. This doc gives an overview of that work so these bodies can coordinate their standardization activities 🫶

2. Background 🌸

2.1. MAC Address Usage

most mobile devices today are Wi-Fi enabled (meaning they have an IEEE 802.11 wireless local area network interface) 📶 Like any other IEEE 802-based network interface, such as Ethernet (IEEE 802.3), Wi-Fi interfaces have an L2 address (also called a MAC address) that anybody who can pick up the radio signal from that interface can see 👀 The format of these addresses (for 48-bit MAC addresses) is shown in Figure 1 🦋

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

Figure 1: IEEE 802 MAC Address Format (for 48-Bit Addresses)

MAC addresses can be universally or locally administered 🌈 You can tell them apart by checking the second least significant bit of the most significant byte of the address (the U/L bit) 💅

A universally administered address is uniquely assigned to a device by its manufacturer 🏭 Most physical devices come with one, and it has two parts:

  • Organizationally Unique Identifier (OUI): The first three octets in transmission order, which identify the organization that issued the identifier.
  • Network Interface Controller (NIC) Specific: The following three octets, which are assigned by the organization that manufactured the NIC, in such a way that the resulting MAC address is globally unique.

Locally administered addresses override the burned-in address, and either the network administrator or the Operating System (OS) of the device the address belongs to can set them up 🔧 Here's the tea though: the later sections of this doc explain that there are new efforts in the IEEE 802 and other organizations to specify how these locally administered addresses should be assigned, depending on the use case 🧚

2.2. MAC Address Randomization

okay so universally administered MAC addresses are globally unique by definition 🔑 That means when a device uses one of those over a shared medium to send data (especially over the air), it's pretty easy to track that device just by watching the medium 👀 Since a device is usually tied to one specific person, this is a real privacy concern [link_layer_privacy] 😭

MAC addresses can be easily spotted by a third party, like a passive device just listening in on the same L2 network 👂 In an 802.11 network, a device (also known as an IEEE 802.11 station or STA) exposes its MAC address in two situations:

  • While actively scanning for available networks, the MAC address is used in the Probe Request frames the device sends.
  • Once it's associated with an Access Point (AP), the MAC address is used in frame transmission and reception, as one of the addresses in the unicast address fields of an IEEE 802.11 frame.

One way to deal with this privacy concern is to use randomly generated MAC addresses 🎲 IEEE 802 addressing includes one bit that says whether the hardware address is locally or globally administered 🫶 This means local addresses can be generated without any global coordination to make sure the address is still unique within the local network 🙌 That feature can be used to generate random addresses, which decouple the globally unique identifier from the device, so it's harder to track a user device from its MAC/L2 address [enhancing_location_privacy] 🦋

Note that there are reports [contact_tracing_paper] of some mobile OSes persistently reporting (every 20 minutes or so) their MAC addresses (along with other info), which would defeat MAC address randomization 😭 Those practices might have changed by now, but it's important to note that privacy-preserving techniques should be considered across all layers of the protocol stack 💜

2.3. Privacy Workshop, Tutorial, and Experiments at IETF and IEEE 802 Meetings

okay so 🎀 after the STRINT W3C/IAB Workshop [strint], there was a tutorial called "Pervasive Surveillance of the Internet - Designing Privacy into Internet Protocols" [privacy_tutorial] at the IEEE 802 Plenary meeting in San Diego in July of 2014 💅 It gave an update on what was new with Internet privacy, what other Standards Development Organizations (SDOs) like the IETF were doing, and the guidelines people followed when they built new Internet protocol specs (for example, the considerations described in [RFC6973]). It also called out some privacy concerns that are specific to link-layer technologies and gave ideas for how IEEE 802 could help with them 🦋

Then the IEEE 802 community was like "wait, we need to do this" 🔥 On 18 July 2014, the IEEE 802 Executive Committee (EC) created the IEEE 802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. The group's work and discussions led to several outcomes, including Project Authorization Requests (PARs) that resulted in these documents:

  • "IEEE Recommended Practice for Privacy Considerations for IEEE 802(R) Technologies" [IEEE_802E]
  • "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture - Amendment 2: Local Medium Access Control (MAC) Address Usage" [IEEE_802c]

To test the effects of MAC address randomization, experiments ran at the IETF and IEEE 802 meetings between November 2014 and March 2015 🧪 That meant IETF 91, IETF 92, and the IEEE 802 Plenary in Berlin. The goal was to look at MAC address randomization from two angles: (1) how it affected the connectivity experience of the end user, plus any effect on applications and OSes, and (2) the potential impact on the network infrastructure itself. Some of the findings were published in [CSCN2015] 📚

Here's the tea ☕ 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 🙈 So, effective privacy tools should not work in isolation at a single layer; instead; they should be coordinated with other privacy features at higher layers. Layers have to team up, bestie 🫶

Since then, mobile OSes have kept building MAC address randomization in, so phone users get better privacy when they connect to public wireless networks [privacy_ios] [privacy_windows] [privacy_android] 📱✨

3. Activities Relating to Randomized and Changing MAC Addresses in the IEEE 802 🌈

Practical experiences with Randomized and Changing MAC addresses (RCM) in devices (some of which are explained in Section 6) helped researchers fine-tune their understanding of attacks against randomization mechanisms [when_mac_randomization_fails] 🔍 Inside the IEEE 802.11 group, that research turned into a specified mechanism that randomizes MAC addresses, introduced in IEEE Std 802.11aq [IEEE_802.11aq] in 2018. Iconic glow-up 💜

More recent developments include turning on MAC address randomization by default in mobile OSes, and that has an impact on the ability of network operators to customize services [rcm_user_experience_csd]. So follow-on work in IEEE 802.11 mapped the effects of a potentially large uptake of randomized MAC identifiers on a number of commonly offered operator services in 2019 [rcm_tig_final_report] 🗺️ In the summer of 2020, this work turned into two new standards projects. The goal was to develop mechanisms that do not decrease user privacy but still enable an optimal user experience when (1) the MAC address of a device in an Extended Service Set (a group of interconnected IEEE 802.11 wireless access points and stations that form a single logical network) is randomized or changes [rcm_user_experience_par] and (2) user privacy solutions described in IEEE Std 802.11 [rcm_privacy_par] apply. Privacy AND good vibes 🧚

IEEE Std 802 [IEEE_802], as of the amendment IEEE 802c-2017 [IEEE_802c], specifies a local MAC address space structure known as the Structured Local Address Plan (SLAP) [RFC8948] 🗂️ The SLAP designates a range of Extended Local Identifiers for subassignment within a block of addresses assigned by the IEEE Registration Authority via a Company ID. A range of local MAC addresses is designated for Standard Assigned Identifiers to be specified by IEEE 802 standards. Another range is designated for Administratively Assigned Identifiers, which are subject to assignment by a network administrator.

IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends the use of temporary and transient identifiers if there are no compelling reasons for a newly introduced identifier to be permanent 🦋 This recommendation is part of the basis for reviewing user privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi devices) as part of the RCM efforts [rcm_privacy_csd]. Annex I of IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk] discusses privacy considerations in bridged networks 🌸

As of 2024, two task groups in IEEE 802.11 are dealing with RCM issues 👀

  • The IEEE 802.11bh task group, which is looking at mitigating the repercussions that RCM creates on 802.11 networks and related services.
  • The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std 802.11 MAC specification [IEEE_802.11] to specify new mechanisms that address and improve user privacy.

In the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work Group has been looking at issues related to MAC address randomization 🧐 They've identified a list of potential impacts of these changes on existing systems and solutions, mainly related to Wi-Fi identification.

As part of this work, the WBA has documented a set of use cases that a Wi-Fi Identification Standard should address in order to scale and achieve longer-term sustainability of deployed services (see [wba_paper]) 📋

5. IPv6 Address Randomization in the IETF 🎀

Okay, IPv6 time 🌐 [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6, which typically results in hosts configuring one or more "stable" addresses made up of a network prefix advertised by a local router and an Interface Identifier (IID). Then [RFC8064] formally updated the original IPv6 IID selection mechanism to avoid generating the IID from the MAC address of the interface (via EUI64), because that could allow tracking of a device at L3 😬 The prefix part of an IP address also gives meaningful insight into the physical location of the device in general, and together with an IID based on the MAC address, global device tracking got a lot easier 🗺️

[RFC8981] identifies and describes the privacy issues of embedding MAC stable addressing information into IPv6 addresses (as part of the IID) 🚨 It describes an extension to IPv6 SLAAC that causes hosts to generate temporary addresses with randomized IIDs for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors can trivially perform address-based network-activity correlation when the same address is used for multiple transactions by the same host. It also shrinks the window of exposure of a host being reachable via an address that gets revealed through active communication ✨ These temporary addresses are meant to be used for a short period of time (hours to days) and then deprecated. Deprecated addresses can keep being used for already-established connections, but they are not used to initiate new connections. New temporary addresses are generated periodically to replace the ones that expire.

To generate temporary addresses, a node produces a sequence of temporary global scope addresses from a sequence of IIDs that appear to be random, in the sense that (1) it is difficult for an outside observer to predict a future address (or identifier) based on a current one and (2) it is difficult to determine previous addresses (or identifiers) knowing only the present one 🔐 Temporary addresses should not be used by applications that listen for incoming connections, since those are supposed to be waiting on permanent/well-known identifiers 🙅‍♀️ If a node changes network and then comes back to a previously visited one, the temporary addresses it would use will be different. That might be an issue in certain networks where addresses are used for operational purposes (e.g., filtering or authentication) 😵‍💫 [RFC7217], summarized next, partially addresses the problems mentioned above 💅

[RFC7217] describes a method to generate IIDs that are stable for each network interface within each subnet but change as a host moves from one network to another 🧠 This method keeps the "stability" properties of the IIDs specified in [RFC4291], while still mitigating address-scanning attacks and preventing correlation of a host's activities as it moves between networks. The method generates the IPv6 IID by computing a hash function that takes the following as input: information that is stable and associated with the interface (e.g., a local IID), stable information associated with the visited network (e.g., the IEEE 802.11 Service Set Identifier (SSID)), the IPv6 prefix, a secret key, and some other additional information. Basically, a different IID is generated when one of the input fields changes (such as the network or the prefix), but the IID stays the same within each subnet 🌸

To mitigate the privacy threats posed by MAC-derived IIDs, [RFC8064] recommends that nodes implement [RFC7217] as the default scheme for generating stable IPv6 addresses with SLAAC 🫶

In addition to the documents above, [RFC8947] proposes a DHCPv6 extension that:

allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.

And [RFC8948] proposes DHCPv6 extensions that:

enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client.

In addition to MAC and IP addresses, some DHCP options that carry unique identifiers can also be used for tracking 🕵️‍♀️ These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifiers, like link-layer addresses or IPv6 addresses. [RFC7844] introduces anonymity profiles that are:

designed for clients that wish to remain anonymous to the visited network

and that:

provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.

[RFC7844] also indicates that the link-layer address, IP address, and DHCP identifier shall evolve in synchrony 🦋👑

6. Taxonomy of MAC Address Selection Policies ✨

okay so this section is basically the menu of MAC address selection policies 🍓 Some OSes might even mix a couple of these together, so it's not always one flavor 💅

Note: The naming convention for the terms defined in this section aligns with 802.11/Wi-Fi terminology in that the "A" 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) 🏷️

this one is the historical default 👑

the vendor gets an OUI from the IEEE. That's a 24-bit prefix (with two upper bits that are set in a specific way) that belongs to the vendor 🎀 then the vendor makes a unique 24-bit value for the lower 24 bits, and together they make the 48-bit MAC address. It's super common for that 24-bit value to be an incrementing counter that gets assigned at the factory and burnt into non-volatile storage 🔥

ngl there's one more twist. IEEE Std 802.15.4 [IEEE_802.15.4] uses 64-bit MAC addresses, and the IEEE hands out 32-bit prefixes for those. The IEEE has also said there may be a future Ethernet spec that uses 64-bit MAC addresses 🦋

6.2. Per-Device Generated MAC Address (PDGM) 🧚

this one is giving "fresh start, but make it permanent" 🌸 The device randomly generates the MAC address, usually the first time it boots up. That address gets stored in non-volatile storage and sticks around for the whole life of the device 💜

6.3. Per-Boot Generated MAC Address (PBGM) 🌈

this is the "new boot, new me" policy ✨ Every time the device boots, it randomly generates a MAC address. The result is not stored in non-volatile storage, so it does not survive power cycles 💀 Sometimes this case can actually be a PDGM, when the non-volatile storage is no longer working (or has failed) 🙈

6.4. Per-Network Generated MAC Address (PNGM) 🌐

this one is generated every time a brand-new network attachment gets created 🫶

it's mostly used with Wi-Fi networks (aka 802.11 networks), where the network is identified by its SSID Name. The generated address is stored in non-volatile storage and indexed by the SSID. So whenever the device goes back to a network with the same SSID, it reuses the saved MAC address. iconic loyalty 👑

it's also possible to use PNGM on wired Ethernet connections, by passively watching network traffic (like spanning tree protocols [IEEE_802.1Q], the Link Layer Discovery Protocol (LLDP) [IEEE_802.1AB], DHCP, or Router Advertisements) to figure out which network has been attached 🔍

6.5. Per-Period Generated MAC Address (PPGM) ⏰

this one changes on a schedule, typically around every twelve hours 🕛 Like PNGM, it's mainly used with Wi-Fi 📶

when the MAC address changes, the station disconnects from its current session and reconnects using the new MAC address. That involves a new 802.1x session, plus getting or refreshing a new IP address (for example, using DHCP or SLAAC) 💅

if DHCP is being used, a new DHCP Unique Identifier (DUID) gets generated so it doesn't link back to the previous connection. This usually ends up allocating new IP addresses too 🦋

6.6. Per-Session Generated MAC Address (PSGM) 🎟️

this one gets generated per session. How a session is defined is up to the implementation, like a session might be defined by logging in to a portal, a VPN, and so on 🧁 Like PNGM and PPGM, it's mainly used with Wi-Fi 📶

since the address only changes when a new session gets set up, there's no disconnection or reconnection involved 🫶 no drama, just a new vibe ✨

7. OS Current Practices 📱

okay so by default, most modern OSes (especially mobile ones) do implement some MAC address randomization policies 💖 Since the mechanisms and policies OSes use can change over time, the content lives at https://wiki.ietf.org/en/group/madinas/RFC9724. For completeness, a snapshot of the content at the time this document was published is included below 📸 Note that the extensive testing reported in this document was done in 2021, but no significant changes had been detected at the time of publication 🙌

Table 1 sums up the current practices for Android and iOS at the time of writing (the original source is available at [private_mac]), and it also includes updates based on findings from the authors 🌸

    +=============================================+===================+
    | Android 10+                                 | iOS 14+           |
    +=============================================+===================+
    | The randomized MAC address is bound to the  | The randomized    |
    | SSID.                                       | MAC address is    |
    |                                             | bound to the      |
    |                                             | Basic SSID.       |
    +---------------------------------------------+-------------------+
    | The randomized MAC address is stable across | The randomized    |
    | reconnections for the same network.         | MAC address is    |
    |                                             | stable across     |
    |                                             | reconnections for |
    |                                             | the same network. |
    +---------------------------------------------+-------------------+
    | The randomized MAC address does not get re- | The randomized    |
    | randomized when the device forgets a Wi-Fi  | MAC address is    |
    | network.                                    | reset when the    |
    |                                             | device forgets a  |
    |                                             | Wi-Fi network.    |
    +---------------------------------------------+-------------------+
    | MAC address randomization is enabled by     | MAC address       |
    | default for all the new Wi-Fi networks.     | randomization is  |
    | But if the device previously connected to a | enabled by        |
    | Wi-Fi network identifying itself with the   | default for all   |
    | real MAC address, no randomized MAC address | the new Wi-Fi     |
    | will be used (unless manually enabled).     | networks.         |
    +---------------------------------------------+-------------------+

        Table 1: Android and iOS MAC Address Randomization Practices

in September 2021, we ran some extra tests to see how widely used OSes behave when it comes to MAC address randomization 🕵️‍♀️ Table 2 spills the tea. The rows show whether the OS does address randomization per network (PNGM according to the taxonomy in Section 6), per new connection (PSGM), daily (PPGM with a period of 24 hours), whether it supports configuration per SSID, whether it supports address randomization for scanning, and whether it supports address randomization for scanning by default 👀

    +=================+===============+=========+=========+=====+
    | OS              | Linux (Debian | Android | Windows | iOS |
    |                 |  "bookworm")  |    10   |    10   | 14+ |
    +=================+===============+=========+=========+=====+
    | Random. per     |       Y       |    Y    |    Y    |  Y  |
    | net.  (PNGM)    |               |         |         |     |
    +-----------------+---------------+---------+---------+-----+
    | Random. per     |       Y       |    N    |    N    |  N  |
    | connec.  (PSGM) |               |         |         |     |
    +-----------------+---------------+---------+---------+-----+
    | Random. daily   |       N       |    N    |    Y    |  N  |
    | (PPGM)          |               |         |         |     |
    +-----------------+---------------+---------+---------+-----+
    | SSID config.    |       Y       |    N    |    N    |  N  |
    +-----------------+---------------+---------+---------+-----+
    | Random. for     |       Y       |    Y    |    Y    |  Y  |
    | scan            |               |         |         |     |
    +-----------------+---------------+---------+---------+-----+
    | Random. for     |       N       |    Y    |    N    |  Y  |
    | scan by default |               |         |         |     |
    +-----------------+---------------+---------+---------+-----+

         Table 2: Observed Behavior in Different OSes (as of
                             September 2021)

according to [privacy_android], starting with Android 12, Android uses non-persistent randomization in these situations 🤖

  • A network suggestion application specifies that non-persistent randomization be used for the network (through an API).
  • The network is an open network that hasn't encountered a captive portal, and an internal config option is set to do so (by default, it is not).

8. IANA Considerations 🌷

this document has no IANA actions, so nothing to see here for registries 🙈

9. Security Considerations 🔐

okay this part is serious, bestie 😭 Privacy considerations about tracking a user's location through the MAC address of their device are discussed throughout this document. Since this document is informational, no protocols or solutions are specified. It just documents where things currently stand 📝

any future specification in this area would need to look into security and privacy aspects, such as (but not limited to) the following 🛡️

  • Mitigating the problem of location privacy while minimizing the impact on upper layers of the protocol stack
  • Providing the means for network operators to authenticate devices and authorize network access, despite the MAC addresses changing according some pattern
  • Providing the means for the device not to use MAC addresses that it is not authorized to use or that are currently in use

a major conclusion of the work in IEEE Std 802E [IEEE_802E] was how hard it is to defend privacy against adversaries of any sophistication 💀 Individuals can be successfully tracked by fingerprinting, using aspects of their communication other than MAC addresses or other permanent identifiers. so even if you randomize your MAC, you can still get clocked 🕵️‍♀️ not me being tracked by fingerprinting 😭

10. Informative References ✨

Okay bestie, here's the reading list 📚💖 Every source is listed exactly as cited, so you can go deep on whatever catches your eye.

Acknowledgments 🎀

Okay bestie, the authors want to give a huge shoutout to Guillermo Sanchez Illan 👑 for running the extensive tests on different OSes to see how each one behaves when it comes to address randomization. Literally so much work 😭🫶

Next up, a whole squad of reviewers who looked over earlier draft versions of this doc 💖: Jerome Henry, Hai Shalom, Stephen Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer, Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roman Danyliw, Murray Kucherawy, and Paul Wouters. They are all iconic 🦋✨

Michael Richardson gets extra love 🍓 for his contributions to the taxonomy section. And last but not least, the IEEE 802.1 Working Group reviewed the doc and left comments too 🧚. You can check out their liaison here: https://datatracker.ietf.org/liaison/1884/ 🌸

Authors' Addresses 💅

Meet the authors! Here are their contact details, exactly as they appear in the doc 💜

Juan Carlos Zúñiga
Cisco
Montreal QC
Canada
Email: juzuniga@cisco.com
Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI:   http://www.it.uc3m.es/cjbc/
Amelia Andersdotter
Safespring AB
Email: amelia.ietf@andersdotter.cc
📦 where this page comes from