<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> nbsp    "&#160;">
  <!ENTITY rfc4862 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'> zwsp   "&#8203;">
  <!ENTITY rfc6973 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml'> nbhy   "&#8209;">
  <!ENTITY rfc7217 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7217.xml'>
  <!ENTITY rfc8947 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8947.xml'>
  <!ENTITY rfc8948 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8948.xml'>
  <!ENTITY rfc7844 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7844.xml'>
  <!ENTITY rfc8981 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8981.xml'>
  <!ENTITY rfc4291 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
  <!ENTITY rfc8064 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8064.xml'> wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-madinas-mac-address-randomization-15"
     ipr="trust200902"> ipr="trust200902" number="9724" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

<!-- [rfced] How may we update the document title to improve clarity?  Also,
note that we expanded the acronym MAC per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.

Original:
  Randomized and Changing MAC Address State of Affairs

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

Or:
  Overview of Privacy Issues with Randomized and Changing Media Access Control (MAC) Addresses
-->

  <front>
    <title abbrev="Randomized and Changing MAC Address">
       Randomized Addresses">Randomized and
    Changing MAC Media Access Control (MAC) Address State of Affairs
      </title>

    <!-- AUTHORS --> Affairs</title>
    <seriesInfo name="RFC" value="9724"/>
    <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
      <organization abbrev="CISCO">
        CISCO
      </organization> abbrev="Cisco">Cisco</organization>
      <address>
        <postal>
          <street></street>
          <city>Montreal</city>
          <code> QC</code>
          <region>QC</region>
          <country>Canada</country>
        </postal>
        <email>juzuniga@cisco.com</email>
      </address>
    </author>
    <author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos" role="editor">
      <organization abbrev="UC3M">
        Universidad abbrev="UC3M">Universidad Carlos III de Madrid
      </organization> Madrid</organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>
    <author fullname="Amelia Andersdotter" initials="A." surname="Andersdotter">
      <organization abbrev="Safespring AB">
        Safespring AB
      </organization> AB">Safespring AB</organization>
      <address>
        <email>amelia.ietf@andersdotter.cc</email>
      </address>
    </author>
    <date year="2024"/>

    <area>Internet</area>

    <workgroup>MADINAS</workgroup> year="2025" month="January"/>
    <area>INT</area>
    <workgroup>madinas</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>
Internet users are becoming more aware that their activity over the Internet leaves a
vast digital footprint, that communications might not always be properly
secured, and that their location and actions can be tracked. One of the main
factors that eases tracking of Internet users is the wide use of long-lasting, and sometimes
persistent, identifiers at various protocol layers. This document focuses on MAC
Media Access Control (MAC) addresses.
      </t>
      <t>
There have been several initiatives within the IETF and the IEEE 802 standards
committees to overcome some of these the privacy issues. issues involved. This document provides an
overview of these activities to help coordinating coordinate standardization activities in these bodies.
      </t>
    </abstract>
  </front>
  <middle>

    <section anchor="sec_introduction" numbered="true" toc="default">
      <name>Introduction</name>

<!-- BEGIN Terminology [rfced] We updated this long sentence as follows to improve
readability. Note that we pulled out the text "for instance...web
trackers, etc." into a new sentence. Please review to ensure the updated
text accurately conveys the intended meaning.

Original:
   This is due to many factors, such as the vast digital footprint that users
   leave on the Internet with or without their consent, for instance
   sharing information on social networks, cookies used by browsers and
   servers for various reasons, connectivity logs that allow tracking of
   a user's Layer-2 (L2/MAC) or Layer-3 (L3) address, web trackers,
   etc.; and/or the weak (or even null in some cases) authentication and
   encryption mechanisms used to secure communications.

Updated:
   This is due to many factors, such as the vast digital footprint that users
   leave on the Internet with or without their consent and the weak (or
   even null) authentication and encryption mechanisms used to secure
   communications.  A digital footprint may include information shared
   on social networks, cookies used by browsers and servers for various
   reasons, connectivity logs that allow tracking of a user's Layer 2
   (L2) address (i.e, MAC address) or Layer 3 (L3) address, web
   trackers, etc.
-->
    <section anchor="sec:introduction" title="Introduction">

      <t>
Privacy is becoming a huge concern, as more and more devices are
getting connecting to
the Internet either directly (e.g., via Wi-Fi) or indirectly (e.g., via a
smartphone using
Bluetooth) connected to the Internet. Bluetooth). This ubiquitous connectivity, together with the
lack of proper education about privacy make privacy, makes it very easy to track/monitor
the location of users and/or eavesdrop on their physical and online
activities. This is due to many factors, such as the vast digital footprint
that users leave on the Internet with or without their consent, for instance sharing consent and the weak
(or even null) authentication and encryption mechanisms used to
secure communications. A digital footprint may include
information shared on social networks, cookies used by browsers and servers
for various reasons, connectivity logs that allow tracking of a user's Layer-2 (L2/MAC) Layer 2
(L2) address (i.e., MAC address) or
Layer-3 Layer 3 (L3) address, web trackers, etc.; and/or the weak (or even null in some
cases) authentication and encryption mechanisms used to secure communications. etc.
      </t>
      <t>
This privacy concern affects
Privacy concerns affect all layers of the protocol stack, from the lower
layers involved in the access to the network (e.g., the MAC/Layer-2 MAC/L2 and Layer-3 L3
addresses can be used to obtain the location of a user) to higher layer higher-layer protocol
identifiers and user applications <xref target="CSCN2015" />. format="default"/>. In
particular, IEEE 802 MAC addresses have historically been an easy target for
tracking users <xref target="wifi_tracking" />. format="default"/>.

      </t>
      <t>
There have been several initiatives at within the IETF and the IEEE 802 standards
committees to overcome some of these privacy issues. This document provides an
overview of these activities to help coordinating coordinate standardization activities
within these bodies.
      </t>
    </section>

<!-- BEGIN Problem statement -->

    <section anchor="sec:background" title="Background"> anchor="sec_background" numbered="true" toc="default">
      <name>Background</name>
      <section anchor="sec:mac_usage" title="MAC address usage"> anchor="sec_mac_usage" numbered="true" toc="default">
        <name>MAC Address Usage</name>
        <t>
Most mobile devices used today are WLAN enabled (i.e., they are equipped with
an IEEE 802.11 wireless local area network interface). Wi-Fi interfaces, as Like any other kind of IEEE 802-based
network interface, like interface based on IEEE 802 such as Ethernet (i.e., IEEE 802.3) 802.3), Wi-Fi
interfaces have a Layer-2 an L2 address also (also referred to as a MAC address, which address) that can be
seen by anybody who can receive the radio signal transmitted by the network
interface. The format of these addresses (for 48-bit MAC addresses) is shown
in <xref target="fig:ieee802_mac_address_format" />. target="fig_ieee802_mac_address_format" format="default"/>.
        </t>

<!-- [rfced] In Figure 1, will readers know what the "I/G bit" is? The "U/L
bit" is described in the paragraph following the figure.
-->

        <figure anchor="fig:ieee802_mac_address_format" title="IEEE anchor="fig_ieee802_mac_address_format">
          <name>IEEE 802 MAC Address Format (for 48-bit addresses)" >
<artwork><![CDATA[ 48-Bit Addresses)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
        +--------+--------+---------+--------+--------+---------+
        |  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
+--+--+--+--+--+--+--+--+
]]></artwork>
        </figure>

        <t>
MAC addresses can either be either universally administered or locally administered.
Universally administered and locally administered addresses are distinguished by
setting the second-least-significant second least significant bit of the most significant byte of the
address (the U/L bit).
        </t>
        <t>
A universally administered address is uniquely assigned to a device by its
manufacturer. Most physical devices are provided with a universally administered
address, which is composed of two parts:</t>

<!-- [rfced] We updated this long sentence to use a definition list (i.e.,
<dl>). Let us know any concerns.

Original:
   Most physical devices are provided with a
   universally administered address, which is composed of two parts: (i)
   the Organizationally Unique Identifier (OUI), which are the first
   three octets in transmission order and identify the organization that
   issued the identifier, and (ii) Network Interface Controller (NIC)
   Specific, which are the following three octets, assigned by the
   organization that manufactured the NIC, in such a way that the
   resulting MAC address is globally unique.
        </t>

Updated:
   A universally administered address is uniquely assigned to a device
   by its manufacturer.  Most physical devices are provided with a
   universally administered address, which is composed of 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.
-->

<dl newline="false" spacing="normal">
  <dt>Organizationally Unique
  Identifier (OUI):</dt><dd>The first three octets in transmission order, which identify the organization that issued the identifier.</dd>
  <dt>Network Interface
Controller (NIC) Specific:</dt><dd>The following three octets, which are assigned by the
organization that manufactured the NIC, in such a way that the resulting MAC
address is globally unique.</dd>
</dl>

        <t>
Locally administered addresses override the burned-in address, and they can
either be set-up
set up by either the network administrator, administrator or by the Operating System (OS) of the
device to which the address pertains. However, as explained in further later sections
of this document, there are new initiatives at in the IEEE 802 and other
organizations to specify ways in which these locally administered addresses
should be assigned, depending on the use case.
        </t>
      </section>
<!-- END Problem statement -->

<!-- BEGIN MAC address randomization -->

    <section anchor="sec:mac_addr_random" title="MAC address randomization"> anchor="sec_mac_addr_random" numbered="true" toc="default">
        <name>MAC Address Randomization</name>
        <t>
Since universally administered MAC addresses are by definition globally unique,
when a device uses this MAC address over a shared medium to transmit data -especially -- especially over the air- air --
it is relatively easy to track this device by simple medium observation. Since a
device is usually directly associated to an individual, this poses a privacy
concern <xref target="link_layer_privacy"/>. target="link_layer_privacy" format="default"/>.
        </t>

<!-- [rfced] How may we expand "STA"? As "station"? If so, would it be helpful
to describe this in the first sentence below rather than in the second?

Original:
   In an 802.11 network, a station exposes its MAC address in two
   different situations:

   *  While actively scanning for available networks, the MAC address is
      used in the Probe Request frames sent by the device (a.k.a.
      IEEE 802.11 STA).

Perhaps:
   In an 802.11 network, a device (also known as an IEEE 802.11 station or STA)
   exposes its MAC address in two different situations:

   *  While actively scanning for available networks, the MAC address is
      used in the Probe Request frames sent by the STA.
-->

        <t>
MAC addresses can be easily observed by a third party, such as a passive device
listening to communications in the same layer-2 L2 network. In an 802.11 network, a station
exposes its MAC address in two different situations:
        </t>

<t><list style="symbols">
        <ul spacing="normal">
          <li>

            <t>
While actively scanning for available networks, the MAC address is used in the
Probe Request frames sent by the device (a.k.a. (also known as IEEE 802.11 STA).
            </t>
          </li>
          <li>
            <t>
Once associated to a given Access Point (AP), the MAC address is used in frame
transmission and reception, as one of the addresses used in the unicast address fields
of an IEEE 802.11 frame.
            </t>
</list></t>
          </li>
        </ul>
        <t>
One way to overcome this privacy concern is by using randomly generated MAC
addresses. The IEEE 802 addressing includes one bit to specify if the hardware
address is locally or globally administered. This allows generating local
addresses to be generated without the need of for any global coordination mechanism to ensure that
the generated address is still unique within the local network. This feature can
be used to generate random addresses, which decouple the globally unique
identifier from the device and therefore make it more difficult to track a user
device from its MAC/L2 address <xref target="enhancing_location_privacy" />. format="default"/>.
        </t>
        <t>
Note that there are reports <xref target="contact_tracing_paper" /> format="default"/> of some
mobile Operating Systems (OSes) OSes reporting persistently (every 20 minutes or so)
on MAC addresses (among (as well as other information), which would defeat MAC address
randomization. While these practices might have changed by now, it is important
to highlight that privacy preserving privacy-preserving techniques should be conducted while considering
all layers of the protocol stack.
        </t>
      </section>
      <section anchor="sec:mac_addr_experiments" title="Privacy anchor="sec_mac_addr_experiments" numbered="true" toc="default">
        <name>Privacy Workshop, Tutorial Tutorial, and Experiments at IETF and IEEE 802 meetings"> Meetings</name>
        <t>
As an outcome to the STRINT W3C/IAB Workshop <xref target="strint" />, format="default"/>, a
tutorial on titled "Pervasive Surveillance of the Internet - Designing Privacy into
Internet Protocols" <xref target="privacy_tutorial" format="default"/> was given at the IEEE 802 Plenary meeting in San Diego <xref
target="privacy_tutorial" /> in July of 2014. The tutorial provided an update on
the recent developments regarding Internet privacy, the actions undertaken by
other SDOs such as Standards Development Organizations (SDOs) like the IETF, and guidelines that were being followed when developing
new Internet protocol specifications (e.g., the considerations described in <xref target="RFC6973" />). format="default"/>). The
tutorial highlighted some privacy concerns applicable that apply specifically to link-layer
technologies and provided suggestions on how IEEE 802 could help addressing address
them.
        </t>
<!-- [rfced] We recommend updating this long sentence to use a bulleted list
to improve readability. Also, because [IEEE_802E] and [IEEE_802c] seem to be
published, is it correct to refer to them as PARs and include the
definition of PARs?

Original:
   The work and discussions from the group have generated multiple
   outcomes, such as: 802E PAR (Project Authorization Request, this is
   the means by which standards projects are started 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
   - Local Medium Access Control (MAC) Address Usage [IEEE_802c].

Perhaps:
   The work and discussions from the group have generated multiple
   outcomes, such as the following Project Authorization Requests (PARs).
   PARs are the means by which standards projects are started within the
   IEEE; they define the scope, purpose, and contact points for a new
   project.

   * "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]

Or:
   The work and discussions from the group have generated multiple
   outcomes, such Project Authorization Requests (PARs) that resulted in the
   following 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]
-->

        <t>
Following the discussions and interest within the IEEE 802 community, on 18 July
2014
2014, the IEEE 802 Executive Committee (EC) created an the IEEE 802 EC Privacy
Recommendation Study Group (SG) <xref target="ieee_privacy_ecsg" />. format="default"/>. The work
	and discussions from the group have generated multiple outcomes, such as: 802E
PAR (Project Authorization Request, this is the means by which standards projects are started within the IEEE. PARs define the scope, purpose, and contact points for a new project): Recommended Practice for Privacy Considerations for IEEE 802 Technologies
<xref target="IEEE_802E" />, format="default"/>, and the 802c PAR: Standard for Local and
Metropolitan Area Networks - Overview and Architecture Amendment - Amendment 2: Local Medium
Access Control (MAC) Address Usage <xref target="IEEE_802c" />. format="default"/>.
        </t>

      <t>

<!-- [rfced] The title of Section 2.3 uses "Experiments", but the text in
paragraphs 3 and 4 uses "trials". Would you like to make these
consistent?

For example:
   2.3.  Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802
         meetings
   ...
   In order to test the effects of MAC address randomization, trials
   were conducted at the IETF and IEEE 802 meetings between November
   2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in Berlin.
   The purpose of the trials was to evaluate ...
-->

        <t>
In order to test the effects of MAC address randomization, trials were conducted
at the IETF and IEEE 802 meetings between November 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: (i) (1) the
effect on the connectivity experience of the end-user, also checking if end user, as well as any effect on
applications and OSes were affected; OSes, and (ii) (2) the potential impact on the
network infrastructure itself. Some of the findings were published in <xref target="CSCN2015" />. format="default"/>.
        </t>

        <t>
During the trials trials, it was observed that the probability of address duplication in
a network is negligible. The trials also revealed that other protocol
identifiers (e.g., the DHCP client identifier) can be correlated and can therefore still be
used to still track an individual. Hence, effective privacy tools should not
work in isolation at a single layer, but layer; instead; they should be coordinated with other
privacy features at higher layers.
        </t>
        <t>
Since then, MAC randomization has further been further implemented by mobile OSes to
provide better privacy for mobile phone users when connecting to public wireless
networks <xref target="privacy_ios" />, format="default"/> <xref target="privacy_windows" />, format="default"/> <xref target="privacy_android" />. format="default"/>.
        </t>
      </section>
<!-- END L2 address randomization -->

    </section>

<!-- BEGIN Tools -->

    <section anchor="sec:mac_rnd_at_ieee802" title="Randomized anchor="sec_mac_rnd_at_ieee802" numbered="true" toc="default">
      <name>Activities Relating to Randomized and Changing MAC addresses activities at Addresses in the IEEE 802"> 802</name>
      <t>
Practical experiences of with Randomized and Changing MAC addresses (RCM) in
devices (some of them which are explained in Section <xref target="rcm-types" />)
format="default"/>) helped researchers fine-tune their understanding of
attacks against randomization mechanisms <xref
target="when_mac_randomization_fails" />. At format="default"/>. Within the IEEE
802.11 group group, these research experiences eventually formed the basis for a
specified mechanism that randomizes MAC addresses, which was introduced in the
IEEE Std 802.11aq <xref target="IEEE_802.11aq" format="default"/> in 2018.
      </t>

<!-- [rfced] We have several questions about the text below.

a) Please review the text starting with "user privacy solutions applicable to
IEEE Std 802.11", and let us know how we can revise for clarity.

b) Would it be helpful to add numbers like (1) and (2) to improve readability
of this long sentence?

c) Are the "two new standards projects" projects mentioned in 2018 this sentence
the [IEEE_802] and [IEEE_802E], which randomize are discussed in the two paragraphs
following this text? If so, adding a sentence indicating this might be helpful
to readers. See suggestion below.

Original:
   In the summer of 2020 this work emanated in two new standards projects
   with the purpose of developing mechanisms that do not decrease user
   privacy but enable an optimal user experience when the MAC
addresses <xref target="IEEE_802_11_aq" />.
      </t> 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 user
   privacy solutions applicable to IEEE Std 802.11 [rcm_privacy_par].

Perhaps:
   In the summer of 2020, this work emanated in two new standards projects.
   The purpose of these projects was to develop mechanisms that do not decrease user
   privacy but 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 descibed in IEEE Std 802.11 [rcm_privacy_par] apply. These projects
   are described below.
-->

      <t>
More recent developments include turning on MAC randomization in mobile
OSes by default, which has an impact on the ability of network
operators to customize services <xref target="rcm_user_experience_csd" />. format="default"/>. Therefore, follow-on work in the IEEE
802.11 mapped effects of a potentially large uptake of randomized MAC identifiers
on a number of commonly offered operator services in 2019<xref 2019 <xref target="rcm_tig_final_report" />. format="default"/>. In the summer of 2020 2020, this work emanated in
two new standards projects with the purpose of developing mechanisms that do not
decrease user privacy but enable an optimal user experience when the MAC address
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 <xref target="rcm_user_experience_par" /> format="default"/> and user privacy solutions applicable to
IEEE Std 802.11 <xref target="rcm_privacy_par" />. format="default"/>.
      </t>
      <t>
IEEE Std 802 <xref target="IEEE_802" />, format="default"/>, as of the amendment IEEE 802c-2017
<xref target="IEEE_802c" />, format="default"/>, specifies a local MAC address space structure known
as the Structured Local Address Plan (SLAP) <xref target="RFC8948" />. format="default"/>. 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 of local MAC addresses is
designated for Administratively Assigned Identifiers Identifiers, which are subject to assignment
by a network administrator.
      </t>

<!-- [rfced] Please confirm that "Annex T" is correct here. We do not see an
Annex T in the referenced document, but we do see that Annex I is titled
"Privacy considerations in bridged networks".

Link: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10225636
(You may need to sign in to view.)

Original:
   Annex T of IEEE Std 802.1AEdk-2023:
   MAC Privacy Protection [IEEE_802.1AEdk-2023] discusses privacy
   considerations in bridged networks.
-->

      <t>
"IEEE
IEEE Std 802E-2020: 802E-2020 ("IEEE Recommended Practice for Privacy Considerations for IEEE 802
Technologies" 802(R)
Technologies") <xref target="IEEE_802E" /> format="default"/> recommends the use of temporary and
transient identifiers if there are no compelling reasons for a newly introduced
identifier to be permanent. This recommendation is part of the basis for
the review of user privacy solutions for IEEE Std 802.11 (a.k.a. Wi-Fi) devices (also known as Wi-Fi devices) as
part of the RCM efforts <xref target="rcm_privacy_csd" /> efforts. format="default"/>. Annex T of IEEE Std
802.1AEdk-2023: MAC
802.1AEdk-2023 ("MAC Privacy Protection Protection") <xref target="IEEE802.1AEdk-2023" /> target="IEEE_802.1AEdk" format="default"/>
discusses privacy considerations in bridged networks.
</t>
      <t>
As per of 2024, two task groups in IEEE 802.11 are dealing with issues related to RCM:

  <list style="symbols">

      </t>
      <ul spacing="normal">
        <li>
          <t>
The IEEE 802.11bh task group, which is looking at mitigating the repercussions that RCM
creates on 802.11 networks and related services, and services.
          </t>

    <t>
        </li>
        <li>

<!-- [rfced] Would it be helpful to include a citation for "IEEE Std 802.11
medium access control (MAC) specification"? Will readers know which
specification is being discussed here?

Original:
   *  The IEEE 802.11bi task group, which is chartered to define
      modifications to the IEEE Std 802.11 medium access control (MAC)
      specification to specify new mechanisms that address and improve
      user privacy.
-->

          <t>
The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std
802.11 MAC specification to specify new mechanisms that
address and improve user privacy.
          </t>

  </list>

</t>
        </li>
      </ul>
    </section>
<!-- END Tools -->

    <section anchor="sec:wba" title="Recent anchor="sec_wba" numbered="true" toc="default">

      <name>Recent Activities Related to MAC randomization-related activities at Randomization in the WBA"> WBA</name>
      <t>
At
In the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work
Group has been looking at the issues related to MAC address randomization and
has identified a list of potential impacts of these changes to existing systems
and solutions, mainly related to Wi-Fi identification.
      </t>

      <t>

<!-- [rfced] We have questions about the text below and the [wba_paper]
reference entry.

a) The second sentence below is difficult to follow (the first is included for
context). How may we update for clarity?

Original:
   As part of this work, 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.  A first
   version of this document has been liaised with the IETF as part of
   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].

Perhaps:
   As part of this work, 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.  A first
   version of that document, a paper titled "Wi-Fi Identification In a
   post MAC Randomization Era v1.0" [wba_paper], was created while
   liaising with the IETF MADINAS Working Group.

b) We cannot locate this this document. We do not see it listed at
https://wballiance.com/resource/. Can you provide a URL?

Original:
   [wba_paper]
              Alliance, W. B., "Wi-Fi Identification Scope for Liasing -
              In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro:
              Post MAC Randomization Era v1.0 - IETF liaison , March
              2020.
-->

      <t>
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. A first version of this document has been
liaised with the IETF as part of 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 <xref target="wba_paper" />. format="default"/>.
      </t>
    </section>

<!-- BEGIN Evaluation -->

    <section anchor="sec:mac_rnd_at_ietf" title="IPv6 address randomization at anchor="sec_mac_rnd_at_ietf" numbered="true" toc="default">
      <name>IPv6 Address Randomization in the IETF"> IETF</name>
      <t>
<xref target="RFC4862" /> format="default"/> specifies Stateless Address Autoconfiguration (SLAAC)
for IPv6, which typically results in hosts configuring one or more "stable"
addresses composed of a network prefix advertised by a local router, router and an
Interface Identifier (IID). <xref target="RFC8064" /> format="default"/> formally updated the
original IPv6 IID selection mechanism to avoid generating the IID from the MAC
address of the interface (via EUI64), as this potentially allowed for tracking
of a device at L3. Additionally, the prefix part of an IP address provides
meaningful insights of the physical location of the device in general, which
together with the IID based on the MAC address-based IID, address, made it easier to perform global device
tracking.
      </t>

<!-- [rfced] Please clarify "In order to do so". Is the intended meaning "To
generate temporary addresses"? Also, may we add numbers to improve
readability of this long sentence?

Original:
   In order to do so, a node produces a sequence of temporary global
   scope addresses from a sequence of interface identifiers that appear
   to be random in the sense that it is difficult for an outside
   observer to predict a future address (or identifier) based on a
   current one, and it is difficult to determine previous addresses (or
   identifiers) knowing only the present one.

Perhaps:
   To generate temporary addresses, a node produces a sequence of temporary global
   scope addresses from a sequence of interface identifiers 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.
-->

      <t>
<xref target="RFC8981" /> format="default"/> identifies and describes the privacy issues associated
with embedding MAC stable addressing information into the IPv6 addresses (as
part of the IID). It describes an extension to IPv6 SLAAC that causes hosts to generate temporary addresses with
randomized interface identifiers IIDs for each prefix advertised with
autoconfiguration enabled. Changing addresses over time limits the window of
time during which eavesdroppers and other information collectors may trivially
perform address-based network-activity correlation when the same address is
employed for multiple transactions by the same host. Additionally, it reduces
the window of exposure of a host as being accessible via an address that becomes
revealed as a result of active communication. These temporary addresses are
meant to be used for a short period of time (hours to days) and would then be
deprecated. Deprecated addresses can continue to be used for already established
connections, already-established
connections but are not used to initiate new connections. New temporary
addresses are generated periodically to replace temporary addresses that expire.
In order to do so, a node produces a sequence of temporary global scope
addresses from a sequence of interface identifiers IIDs that appear to be random in
the sense that it is difficult for an outside observer to predict a future
address (or identifier) based on a current one, one and 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 (as these are supposed to be waiting on permanent/well-known
identifiers). If a node changes network and comes back to a previously visited
one, the temporary addresses that the node would use will be different, and this which
might be an issue in certain networks where addresses are used for operational
purposes (e.g., filtering or authentication). <xref target="RFC7217" />, format="default"/>,
summarized next, partially addresses the problems aforementioned.
      </t>
      <t>
<xref target="RFC7217" /> format="default"/> describes a method to generate Interface Identifiers IIDs
that are stable for each network interface within each subnet, subnet but that change
as a host moves from one network to another. This method enables keeping the
"stability" properties of the Interface Identifiers IIDs specified in <xref target="RFC4291" />, format="default"/> to be kept, while still mitigating address-scanning attacks and
preventing correlation of the activities of a host as it moves from one network
to another. The method defined to generate the IPv6 IID is based on computing a
hash function which that takes the following as input input: information that is stable and associated to
the interface (e.g., a local interface identifier), IID), stable information
associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 prefix, and
a secret key, plus and some other additional information. This basically ensures
that a different IID is generated when any one of the input fields changes (such as
the network or the prefix), prefix) but that the IID is the same within each subnet.
      </t>
      <t>
Currently,
To mitigate the privacy threats posed by the use of MAC-derived
IIDs, <xref target="RFC8064" /> format="default"/> recommends that nodes to implement <xref target="RFC7217" /> format="default"/> as the default scheme for generating stable IPv6 addresses
with SLAAC, to mitigate the privacy threats posed by the use of MAC-derived
IIDs. SLAAC.
      </t>

      <t>
In addition to the former documents, documents above, <xref target="RFC8947" /> format="default"/>
      proposes "an extension to a DHCPv6 that extension that:</t>
<blockquote>
      allows a scalable approach to link-layer
address assignments where preassigned link-layer address assignments (such as by
a manufacturer) are not possible or unnecessary". are unnecessary.
</blockquote>

<t>And <xref target="RFC8948" /> format="default"/> proposes "extensions to DHCPv6 protocols
to extensions that:</t>

<blockquote>
enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP
quadrant to the server, server so that the server may allocate MAC addresses in the
quadrant requested by the relay or client".
      </t>

      <t> client.
</blockquote>

<!-- [rfced] FYI - We combined these sentences. Please review to confirm that
the updated text conveys the intended meaning.

Original:
   Not only MAC and IP addresses can be used for tracking purposes.
   Some DHCP options carry unique identifiers.

Updated:
   In addition to MAC and IP addresses, some DHCP options that carry unique
   identifiers can also be used for tracking purposes.
-->

<t>
     In addition to MAC and IP addresses, some DHCP options that carry unique
     identifiers can also be used for tracking purposes.  These identifiers
     can enable device tracking even if the device administrator takes care of
     randomizing other potential identifications like link-layer addresses or
     IPv6 addresses. <xref target="RFC7844" /> format="default"/> introduces
     anonymity profiles, "designed profiles that are:</t>

<blockquote>
designed for clients that
wish to remain anonymous to the visited network. The profiles network
</blockquote>
<t>and that:</t>
<blockquote>
provide guidelines
on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure
of identifying information". <xref information.
</blockquote>

<t><xref target="RFC7844" /> format="default"/> also indicates that the
link-layer address, IP address, and DHCP identifier shall evolve in synchrony.
      </t>
      <!--
      <t>
Lately, the MAC Address Device Identification for Network and Application Services (MADINAS) IETF BoF
has discussed the need to examine the effect of RCM schemes on network and application services in several
scenarios identified as relevant.
      </t>
-->

    </section>
<!-- END Evaluation -->

    <section anchor="rcm-types" title="A taxonomy numbered="true" toc="default">
      <name>Taxonomy of MAC address selection
                                       policies"> Address Selection Policies</name>
      <t>
This section documents different policies for MAC address selection. Some OSes
might use a combination of multiple of these policies.
      </t>
      <t>
        Note about the used naming convention: the convention used: The "M" in MAC "MAC" is included in the
acronym,
acronym but not the "A" from address. "Address". This allows one to talk about a PVOM
Address,
Address or PNGM Address.
      </t>
      <t>
       <!-- The names are all in the form for per-period-of-time-selection. -->
      </t>
      <section anchor="policy-pvom" title="Per-Vendor numbered="true" toc="default">
        <name>Per-Vendor OUI MAC address (PVOM)"> Address (PVOM)</name>
        <t>
          This form of MAC address selection is the historical default.
        </t>

<!-- [rfced] Please review the text starting with "to be taken..." and let us
know how to update for clarity.

Original:
   It has not been unusual for the 24-bit value
   to be taken as an incrementing counter, assigned at the factory, and
   burnt into non-volatile storage.

Perhaps:
   It is not unusual for the 24-bit value
   to be an incrementing counter that was assigned at the factory and
   burnt into non-volatile storage.

Or:
   It is not unusual for the 24-bit value
   to be used as an incrementing counter that was assigned at the factory and
   burnt into non-volatile storage.
-->

<!-- [rfced] Does "802.15.4" need a reference entry?

Original:
   Note that 802.15.4 use 64-bit MAC addresses, and the IEEE assigns
   32-bit prefixes.

Perhaps:
   Note that IEEE Std 802.15.4 [IEEE_802.15.4] uses 64-bit MAC addresses, and the IEEE assigns
   32-bit prefixes.
   ...
   [IEEE_802.15.4] IEEE, "IEEE Standard for Low‐Rate Wireless Networks", IEEE Std 802.15.4-2024,
            DOI 10.1109/IEEESTD.2024.10794632, 2024 <https://ieeexplore.ieee.org/document/10794632>.
-->

	<t>
          The vendor obtains an Organizationally Unique Identifier (OUI) OUI from the IEEE.
          This has been is a 24-bit prefix (including two upper bits which that are
          set specifically) that is assigned to the vendor.
          The vendor generates a unique 24-bit value for the lower 24-bits, 24 bits,
          forming the 48-bit MAC address.
          It has is not been unusual for the 24-bit value to be taken as an
          incrementing counter, assigned at the factory, and burnt into
          non-volatile storage.
        </t>
        <t>
          Note that 802.15.4 use uses 64-bit MAC addresses, and the IEEE assigns
          32-bit prefixes.
          The IEEE has indicated that there may be a future Ethernet
          specification using that uses 64-bit MAC addresses.
        </t>
      </section>
      <section anchor="policy-pdgm" title="Per-Device numbered="true" toc="default">
        <name>Per-Device Generated MAC address (PDGM)"> Address (PDGM)</name>
        <t>
          This form of MAC address is randomly generated by the device, usually upon first boot.
          The resulting MAC address is stored in non-volatile storage and is
          used for the rest of the device lifetime.
        </t>
      </section>
      <section anchor="policy-pbgm" title="Per-Boot numbered="true" toc="default">
        <name>Per-Boot Generated MAC Address (PBGM)</name>

<!-- [rfced] FYI - We updated "*not*" here to be enclosed in the <strong>
element. This yields asterisks in the txt output and bold in the html and
pdf outputs.

Original:
   The resulting MAC address (PBGM)"> is *not* stored
   in non-volatile storage.
-->

        <t>
          This form of MAC address is randomly generated by the device, device each
          time the device is booted.

          The resulting MAC address is *not* <strong>not</strong> stored in non-volatile storage.
          It does not persist across power cycles.

          This case may sometimes be a PDGM where the non-volatile storage is no longer functional
          (or has failed).
        </t>
      </section>
      <section anchor="policy-pngm" title="Per-Network numbered="true" toc="default">
        <name>Per-Network Generated MAC address (PNGM)"> Address (PNGM)</name>
        <t>
          This form of MAC address is generated each time a new network
          attachment is created.
        </t>

<!-- [rfced] How may we clarify the parenthetical here?

Original:
   This is typically used with Wi-Fi (802.11) networks where the network
   is identified by an SSID Name.

Perhaps:
   This is typically used with Wi-Fi networks (i.e., 802.11 networks) where the network
   is identified by an SSID Name.
-->

        <t>
          This is typically used with Wi-Fi (802.11) networks where the network is identified by an SSID Name.
          The generated address is stored on in non-volatile storage, indexed by the SSID.
          Each time the device returns to a network with the same SSID, the
          device uses the saved MAC address.
        </t>

        <t>
          It is possible to use PNGM for wired Ethernet connections through
          some passive observation of network traffic, such traffic (such as STP <xref target="IEEE802.1D-2004" />, LLDP target="IEEE_802.1D" format="default"/>, the Link Layer Discovery Protocol (LLDP) <xref target="IEEE802.1AB-2016" />,
          DHCP target="IEEE_802.1AB" format="default"/>,
          DHCP, or Router Advertisements Advertisements) to determine which network has been
          attached.
        </t>
      </section>
      <section anchor="policy-ppgm" title="Per-Period numbered="true" toc="default">
        <name>Per-Period Generated MAC address (PPGM)"> Address (PPGM)</name>
        <t>
          This form of MAC address is generated periodically.
          Typical numbers are periodically,
          typically around every twelve hours.
          Like PNGM, it is used primarily with Wi-Fi.
        </t>

<!-- [rfced] These sentences are difficult to parse. Please clarify. Also, how
should "WPA/802.1x" be expanded here?

Original:
   This will
   involve a new WPA/802.1x session: new EAP, TLS, etc. negotiations.  A
   new DHCP, SLAAC will be done.
-->

        <t>
          When the MAC address changes, the station disconnects from the current
          session and reconnects using the new MAC address.
          This will involve a new WPA/802.1x session: new EAP, Extensible Authentication Protocol (EAP), TLS, etc. negotiations.
          A new DHCP, SLAAC will be done.
        </t>
        <t>
          If DHCP is used, then a new DUID DHCP Unique Identifier (DUID) is generated so as to not link to
          the previous connection, and the result is connection; this usually results in the allocation of new IP addresses
          allocated. addresses.
        </t>
      </section>
      <section anchor="policy-psgm" title="Per-Session numbered="true" toc="default">
        <name>Per-Session Generated MAC address (PSGM)"> Address (PSGM)</name>

<!-- [rfced] This sentence appears in both Sections 6.5 and 6.6. In Section
6.6 about PSGM, would you like to update "Like PNGM" to "Like PNGM and
PPGM"?

Original:
   Like PNGM, it is used primarily with Wi-Fi.

Perhaps:
   Like PNGM and PPGM, it is used primarily with Wi-Fi.
-->

        <t>
          This form of MAC address is generated on a per session per-session basis. How a session is defined is implementation-dependant, implementation-dependent, for example, a session might be defined by logging in to a portal, VPN, etc. Like PNGM, it PSGM is used primarily with Wi-Fi.
        </t>
        <t>
          Since the address changes only changes when a new session is established, there is no disconnection/reconnection involved.
        </t>
      </section>
    </section>

<!-- BEGIN OSes current practices -->

      <section anchor="sec:os_current_practices" title="OS current practices"> anchor="sec_os_current_practices" numbered="true" toc="default">
      <name>OS Current Practices</name>
      <!--
        <t>
Since this content can evolve with time, it is now hosted at <eref target="https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-practices.md" />
        </t>
-->

<!-- [rfced] This question is for the *AD and authors. This GitHub URL appears
in the first paragraph of Section 7:

https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-practices.md

Because the link contains text from Section 7 of this document, we recommend
creating a new repo or a wiki page on https://wiki.ietf.org/ to host the
information in order to remove "draft" from the URL. We also recommend
updating the text to align with the edited document and replacing
"draft-ietf-madinas-mac-address-randomization" with "RFC 9724". Please let us
know your thoughts.
-->

        <t>
Most
By default, most modern OSes (especially mobile ones) do implement by default some MAC
address randomization policy. policies. Since the mechanism and policies that OSes implement can evolve with time, the content is now hosted at <eref target="https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-practices.md" />. <xref target="OS_current_practices"/>. For completeness, a snapshot of the content at the time of publication of this document is included below. Note that the extensive testing reported in this document was conducted in 2021, but no significant changes have been detected at the time of publication of this document.
      </t>
      <t>
<xref target="tab:current_practices" />
<!-- [rfced] FYI - The URL provided in the following sentence results in a 404
error, so we removed it. We also created a reference entry for the
Wayback Machine URL.

Original:
   Table 1 summarizes current practices for Android and iOS, as the time
   of writing this document (original source posted at:
   https://www.fing.com/news/private-mac-address-on-ios-14, latest
   wayback machine's snapshot available here: https://web.archive.org/web/20230905111429/https://www.fing.com/news/private-mac-address-on-ios-14,
   https://web.archive.org/web/20230905111429/https://www.fing.com/news/
   private-mac-address-on-ios-14, updated based on findings from the
   authors).

Updated:
   Table 1 summarizes current practices for Android and iOS at the time
   of writing this document (the original source is available at
   [private_mac]) and includes updates based on findings from the
   authors.
-->

<xref target="tab_current_practices" format="default"/> summarizes current
practices for Android and iOS at the time of writing this document (the original source is available
at <xref target="private_mac"/>) and also includes
updates based on findings from the authors.
      </t>

        <texttable anchor="tab:current_practices"
                   title="Android
      <table anchor="tab_current_practices" align="center">
        <name>Android and iOS MAC address randomization practices">
          <ttcol width="50%" Address Randomization Practices</name>
        <thead>
          <tr>
            <th align="left">Android 10+</ttcol>
          <ttcol width="50%" 10+</th>
            <th align="left">iOS 14+</ttcol>
            <c>The 14+</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">The randomized MAC address is bound to the SSID</c>
            <c>The SSID.</td>
            <td align="left">The randomized MAC address is bound to the Basic SSID</c>
            <c></c>
            <c></c>
            <c>The SSID.</td>
          </tr>
          <tr>
            <td align="left">The randomized MAC address is stable across reconnections for the same network</c>
            <c>The network.</td>
            <td align="left">The randomized MAC address is stable across reconnections for the same network</c>
            <c></c>
            <c></c>
            <c>The network.</td>
          </tr>
          <tr>
            <td align="left">The randomized MAC address does not get re-randomized when the device forgets a WiFI network</c>
            <c>The Wi-Fi network.</td>
            <td align="left">The randomized MAC address is reset when the device forgets a WiFI network</c>
            <c></c>
            <c></c>
            <c>MAC Wi-Fi network.</td>
          </tr>
          <tr>
            <td align="left">MAC address randomization is enabled by default for all the new Wi-Fi networks. But if the device previously connected to a Wi-Fi network identifying itself with the real MAC address, no randomized MAC address will be used (unless manually enabled)</c>
            <c>MAC enabled).</td>
            <td align="left">MAC address randomization is enabled by default for all the new Wi-Fi networks</c>
        </texttable> networks.</td>
          </tr>
        </tbody>
      </table>

<!-- [rfced] Table 2 includes both "Random" (no period) and "Random." (with
period). We believe this stands for "randomization", so may we update all
instances in the table to be "Random."?
-->

<!-- [rfced] We updated this sentences as follows, including creating parallel
structure in the list. Would it be helpful to further update to use a
bulleted list?

Original:
   Table 2 summarizes our findings, where show on
   different rows whether the OS performs address randomization per
   network (PNGM according to the taxonomy introduced in Section 6), per
   new connection (PSGM), daily (PPGM with a period of 24h), supports
   configuration per SSID, supports address randomization for scanning,
   and whether it does that by default.

Current:
   Table 2 summarizes our findings; the rows in the table show whether
   the OS performs address randomization per network (PNGM according to
   the taxonomy introduced in Section 6), performs address randomization
   per new connection (PSGM), performs address randomization daily (PPGM
   with a period of 24 hours), supports configuration per SSID, supports
   address randomization for scanning, and supports address randomization
   for scanning by default.

Or:
   Table 2 summarizes our findings; the rows in the table show whether
   the OS:

   * performs address randomization per network (PNGM according to
     the taxonomy introduced in Section 6)

   * performs address randomization per new connection (PSGM)

   * performs address randomization daily (PPGM with a period of 24 hours)

   * supports configuration per SSID

   * supports address randomization for scanning

   * supports address randomization for scanning by default
-->

      <t>
In September 2021, we have performed some additional tests to evaluate how most OSes
that are widely used OSes behave regarding MAC address randomization. <xref
target="tab:experiments-2021" />
target="tab_experiments-2021" format="default"/> summarizes our findings, where show on
different findings;
the rows in the table show whether the OS performs address randomization per
network (PNGM according to the taxonomy introduced in <xref target="rcm-types" />),
format="default"/>), performs address randomization per new connection (PSGM), performs address randomization daily (PPGM with a period of 24h),
24 hours), supports configuration per SSID, supports address randomization for
scanning, and whether it does that supports address randomization for scanning by default.
      </t>

        <texttable anchor="tab:experiments-2021"
                   title="Observed behavior from different OS
      <table anchor="tab_experiments-2021" align="center">
        <name>Observed Behavior in Different OSes (as of September 2021)">
          <ttcol width="35%" align="left">OS</ttcol>
          <ttcol width="15%" 2021)</name>
        <thead>
          <tr>
            <th align="left">OS</th>
            <th align="center">Linux (Debian "bookworm")</ttcol>
          <ttcol width="20%" "bookworm")</th>
            <th align="center">Android 10</ttcol>
          <ttcol width="20%" 10</th>
            <th align="center">Windows 10</ttcol>
          <ttcol width="10%" 10</th>
            <th align="center">iOS 14+</ttcol>
            <c>Random 14+</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Random per net. (PNGM)</c><c>Y</c><c>Y</c><c>Y</c><c>Y</c>
            <c></c><c></c><c></c><c></c><c></c>
            <c>Random (PNGM)</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
          </tr>
          <tr>
            <td align="left">Random per connec. (PSGM)</c><c>Y</c><c>N</c><c>N</c><c>N</c>
            <c></c><c></c><c></c><c></c><c></c>
            <c>Random (PSGM)</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="left">Random daily (PPGM)</c><c>N</c><c>N</c><c>Y</c><c>N</c>
            <c></c><c></c><c></c><c></c><c></c>
            <c>SSID config.</c><c>Y</c><c>N</c><c>N</c><c>N</c>
            <c></c><c></c><c></c><c></c><c></c>
            <c>Random. for scan</c><c>Y</c><c>Y</c><c>Y</c><c>Y</c>
            <c></c><c></c><c></c><c></c><c></c>
            <c>Random. (PPGM)</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="left">SSID config.</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="left">Random. for scan</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
          </tr>
          <tr>
            <td align="left">Random. for scan by default</c><c>N</c><c>Y</c><c>N</c><c>Y</c>
        </texttable> default</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">Y</td>
          </tr>
        </tbody>
      </table>
      <t>
According to <xref target="privacy_android"/>, target="privacy_android" format="default"/>, starting in with Android 12, Android
      uses non-persistent randomization in the following situations: (i) a </t>
<ul spacing="normal">
      <li>A network
suggestion app application specifies that non-persistant non-persistent randomization be used for the
      network (through an API); or (ii) the API).</li>
      <li>The network is an open network that hasn't
encountered a captive portal portal, and an internal config option is set to do so (by
default
default, it is not).
      </t> not).</li>
      </ul>
    </section>
<!-- END OSes current practices -->

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
This document has no IANA actions.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
Privacy considerations regarding tracking the location of a user through the MAC
address of this a device are discussed throughout this document. Given the
informational nature of this document, no protocols/solutions are specified, but
the current state of affairs is documented.
      </t>

      <t>
Any future specification in this area would have need to look into security and
privacy aspects, such as, but as (but not limited to: i) mitigating to) the following:</t>
<ul spacing="normal">
<li>Mitigating the problem of
location privacy while minimizing the impact on upper layers of the protocol
stack; ii) providing
stack</li>
<li>Providing the means to for network operators to authenticate devices
and authorize network access access, despite the MAC addresses changing following according
some
pattern; and, iii) provide pattern</li>
<li>Providing the means for the device not to use MAC
addresses that it is not authorized to use or that are currently in use.
      </t> use</li>
      </ul>

<!-- [rfced] Would it be helpful to add a citation [IEEE_802E] here?

Original:
   A major conclusion of the work in IEEE Std 802E concerned the
   difficulty of defending privacy against adversaries of any
   sophistication.

Perhaps:
   A major conclusion of the work in IEEE Std 802E [IEEE_802E] concerned the
   difficulty of defending privacy against adversaries of any
   sophistication.
-->

      <t>
A major conclusion of the work in IEEE Std 802E concerned the difficulty of
defending privacy against adversaries of any sophistication. Individuals can be successfully tracked by fingerprinting fingerprinting,
using aspects of their communication other than MAC Addresses addresses or other permanent
identifiers.
      </t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">

      <t>
Authors would like to thank Guillermo Sanchez Illan for the extensive tests
performed on different OSes to analyze their behavior regarding address
randomization.
      </t>

      <t>
Authors would like to thank Jerome Henry, Hai Shalom, Stephen Farrel, Alan
DeKok, Mathieu Cunche, Johanna Ansohn McDougall, Peter Yee, Bob Hinden, Behcet
Sarikaya, David Farmer, Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roma Danyliw, Murray Kucherawy and Paul Wouters for their reviews and comments on
previous versions of this document. Authors would also like to thank Michael
Richardson for his contributions on the taxonomy section. Finally, authors would
also like to thank the IEEE 802.1 Working Group for its review and comments, performed as part of the Liaison statement on Randomized and Changing MAC Address (https://datatracker.ietf.org/liaison/1884/).
      </t>

    </section>
  </middle>
  <back>

<!--    <references title="Normative References">
      &rfc2119;
    </references> -->

    <references title="Informative References">

      &rfc4862;
      &rfc6973;
      &rfc7217;
      &rfc8947;
      &rfc8948;
      &rfc7844;
      &rfc8981;
      &rfc4291;
      &rfc8064;

    <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8947.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8948.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"/>

<reference anchor="private_mac" target="https://web.archive.org/web/20230905111429/https://www.fing.com/news/private-mac-address-on-ios-14">
   <front>
   <title>Private MAC address on iOS 14</title>
      <author fullname="Daniele Pantaleone"/>
   <date month="September" year="2020"/>
   </front>
   <refcontent>Wayback Machine archive</refcontent>
</reference>

      <reference anchor="OS_current_practices" target="https://github.com/ietf-wg-madinas/draft-ietf-madinas-mac-address-randomization/blob/main/OS-current-practices.md">
   <front>
      <title>OS current practices</title>
      <author/>
      <date month="July" year="2024"/>
   </front>
   <refcontent>commit 795739b</refcontent>
</reference>

      <reference anchor="CSCN2015" > anchor="CSCN2015">
        <front>
          <title>Wi-Fi Internet Connectivity and Privacy: Hiding your tracks on the wireless Internet</title>
          <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos">
          </author>
          <author initials="JC." surname="Zúñiga" fullname="Juan C. Zúñiga">
          </author>
          <author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon">
          </author>
          <date month="October" year="2015"/>
        </front>
        <seriesInfo name="Standards
        <refcontent>2015 IEEE Conference on Standards for Communications and Networking (CSCN), 2015 IEEE Conference on" value="" /> (CSCN)</refcontent>
        <seriesInfo name="DOI" value="10.1109/CSCN.2015.7390443"/>
      </reference>

      <reference anchor="link_layer_privacy" > anchor="link_layer_privacy">
        <front>
          <title>Privacy at the link-layer</title>
          <author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon">
          </author>
          <author initials="J." surname="Wright" fullname="J. Wright">
          </author>
          <author initials="I." surname="Brown" fullname="Ian Brown">
          </author>
          <date month="February" year="2014"/>
        </front>
        <seriesInfo name="Contribution at W3C/IAB
        <refcontent>W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)" value="" /> (STRINT)</refcontent>
      </reference>

      <reference anchor="enhancing_location_privacy" > anchor="enhancing_location_privacy">
        <front>
          <title>Enhancing location privacy Location Privacy in wireless Wireless LAN through disposable interface identifiers: a quantitative analysis</title> Through Disposable Interface Identifiers: A Quantitative Analysis</title>
          <author initials="M." surname="Gruteser" fullname="M. Gruteser">
          </author>
          <author initials="D." surname="Grunwald" fullname="D. Grunwald">
          </author>
          <date month="" month="June" year="2005"/>
        </front>
        <seriesInfo name="Mobile
        <refcontent>Mobile Networks and Applications, vol. 10, no. 3, pp. 315-325" value="" /> 315-325</refcontent>
        <seriesInfo name="DOI" value="10.1007/s11036-005-6425-1"/>
      </reference>

      <reference anchor="privacy_ios" target="https://support.apple.com/en-us/HT211227">
       <front>
          <title>Use

<!-- [rfced] FYI - We updated the title of this reference entry to match the
title at the included URL. In addition, we updated the URL because
https://support.apple.com/en-us/HT211227 redirects to
https://support.apple.com/en-us/102509.

Original:
   [privacy_ios]
              Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14,
              and watchOS 7</title>
          <author initials="" surname="Apple" fullname="Apple">
            <organization></organization> 7",
              <https://support.apple.com/en-us/HT211227>.

Current:
   [privacy_ios]
              Apple Inc., "Use private Wi-Fi addresses on Apple
              Devices", Apple Support,
              <https://support.apple.com/en-us/102509>.
-->
      <reference anchor="privacy_ios" target="https://support.apple.com/en-us/102509">
        <front>
          <title>Use private Wi-Fi addresses on Apple Devices</title>
          <author>
            <organization>Apple Inc.</organization>
          </author>
          <date />
          <date/>
        </front>
        <refcontent>Apple Support</refcontent>
      </reference>

      <reference anchor="strint" target="https://www.w3.org/2014/strint/">
        <front>
            <title>A
          <title>STRINT Workshop: A W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)</title>
            <author initials="" surname="W3C/IAB" fullname="W3C/IAB">
                  <organization></organization>
          <author>
            <organization>W3C/IAB</organization>
          </author>
            <date />
          <date/>
        </front>
      </reference>

      <reference anchor="ieee_privacy_ecsg" target="http://www.ieee802.org/PrivRecsg/">
        <front>
          <title>IEEE 802 EC Privacy Recommendation Study Group</title>
            <author initials="" surname="IEEE
          <author>
            <organization>IEEE 802 Privacy EC SG" fullname="IEEE 802 Privacy EC SG">
                  <organization></organization> LAN/MAN Standards Committee</organization>
          </author>
            <date />
          <date/>
        </front>
      </reference>

      <reference anchor="privacy_tutorial" target="https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf">
        <front>
            <title>Tutorial on Pervasive
          <title>Pervasive Surveillance of the Internet - Designing Privacy into Internet Protocols </title> Protocols</title>
          <author initials="A." surname="Cooper" fullname="Alissa Cooper">
          </author>
          <author initials="T." surname="Hardie" fullname="Ted Hardie">
          </author>
          <author initials="JC." surname="Zuniga" fullname="Juan-Carlos Zuniga">
          </author>
          <author initials="L." surname="Chen" fullname="Lily Chen">
          </author>
          <author initials="P." surname="O'Hanlon" fullname="Piers O'Hanlon">
          </author>
          <date /> day="14" month="July" year="2014"/>
        </front>
        <refcontent>IEEE 802 Tutorial</refcontent>
      </reference>

      <reference anchor="wifi_tracking" target="https://www.independent.co.uk/life-style/gadgets-and-tech/news/updated-london-s-bins-are-tracking-your-smartphone-8754924.html">
        <front>
          <title>London's bins are tracking your smartphone</title>
          <author initials="" surname="The Independent" fullname="The Independent">
                  <organization></organization>
            </author> fullname="James Vincent"/>
          <date /> day="9" month="August" year="2013"/>
        </front>
        <refcontent>The Independent</refcontent>
      </reference>

      <reference anchor="privacy_android" target="https://source.android.com/devices/tech/connect/wifi-mac-randomization-behavior">
        <front>
          <title>MAC Randomization Behavior</title>
            <author initials="" surname="Android Open Source Project" fullname="Android randomization behavior</title>
          <author>
            <organization>Android Open Source Project">
                  <organization></organization> Project</organization>
          </author>
            <date />
          <date/>
        </front>
        <refcontent>Android OS Documentation</refcontent>
      </reference>

      <reference anchor="privacy_windows" target="https://support.microsoft.com/en-us/windows/how-to-use-random-hardware-addresses-ac58de34-35fc-31ff-c650-823fc48eb1bc">
        <front>
            <title>Windows: How
          <title>How to use random hardware addresses</title>
            <author initials="" surname="Microsoft" fullname="Microsoft">
                  <organization></organization> addresses in Windows</title>
          <author>
            <organization>Microsoft Corporation</organization>
          </author>
            <date />
          <date/>
        </front>
        <refcontent>Microsoft Support</refcontent>
      </reference>

      <reference anchor="when_mac_randomization_fails" > anchor="when_mac_randomization_fails">
        <front>
          <title>A Study of MAC Address Randomization in Mobile Devices and When it Fails</title>
          <author initials="J." surname="Martin" fullname="J. Martin">
           </author>
          <author initials="T." surname="Mayberry" fullname="T. Mayberry">
           </author>
          <author initials="C." surname="Donahue" fullname="C. Donahue">
           </author>
          <author initials="L." surname="Foppe" fullname="L. Foppe">
           </author>
          <author initials="L." surname="Brown" fullname="L. Brown">
           </author>
          <author initials="C." surname="Riggins" fullname="C. Riggins">
           </author>
          <author initials="E.C." initials="E." surname="Rye" fullname="E.C. fullname="E. C. Rye">
           </author>
          <author initials="D." surname="Brown" fullname="D. Brown">
           </author>
          <date month="" month="March" year="2017"/>
        </front>
        <refcontent>arXiv:1703.02874v2</refcontent>
        <seriesInfo name="arXiv:1703.02874v2 [cs.CR]" value="" /> name="DOI" value="10.48550/arXiv.1703.02874"/>
      </reference>

<reference anchor="IEEE_802E" > anchor="IEEE_802E">
        <front>
          <title>IEEE 802E-2020 - IEEE Recommended Practice for Privacy Considerations for IEEE 802 802(R) Technologies</title>
      <author initials="" surname="IEEE 802.1 WG - 802 LAN/MAN architecture" fullname="IEEE 802.1 WG - 802 LAN/MAN architecture">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="November" year="2020"/>
        </front>
        <seriesInfo name="IEEE 802E" value="" /> Std" value="802E-2020"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9257130"/>
      </reference>

<reference anchor="IEEE_802" > anchor="IEEE_802">
        <front>
          <title>IEEE Std 802 - IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture</title>
      <author initials="" surname="IEEE 802" fullname="IEEE 802">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="June" year="2014"/>
        </front>
        <seriesInfo name="IEEE 802" value="" /> Std" value="802-2014"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
      </reference>

      <reference anchor="IEEE_802c" > anchor="IEEE_802c">
        <front>
          <title>IEEE 802c-2017 - IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture--Amendment 2: Local Medium Access Control (MAC) Address Usage</title>
      <author initials="" surname="IEEE 802.1 WG - 802 LAN/MAN architecture" fullname="IEEE 802.1 WG - 802 LAN/MAN architecture">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="August" year="2017"/>
        </front>
        <seriesInfo name="IEEE 802c" value="" /> Std" value="802c-2017"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
      </reference>

      <reference anchor="IEEE_802_11_aq" > anchor="IEEE_802.11aq">
        <front>
          <title>IEEE 802.11aq-2018 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific network--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Preassociation Discovery</title>
      <author initials="" surname="IEEE 802.11 WG - Wireless LAN Working Group" fullname="IEEE 802.11 WG - Wireless LAN Working Group">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="August" year="2018"/>
        </front>
        <seriesInfo name="IEEE 802.11" value="" /> Std" value="802.11aq-2018"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457463"/>
      </reference>

<!-- [rfced] We were unable to locate the following reference entries. Can you
point us to URLs so that we can verify these?

Original:
   [rcm_privacy_csd]
              IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
              Changing MAC Addresses Study Group CSD on user experience
              mechanisms", doc.:IEEE 802.11-20/1346r1 , 2020.

   [rcm_privacy_par]
              IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
              Changing MAC Addresses Study Group PAR on privacy
              mechanisms", doc.:IEEE 802.11-19/854r7 , 2020.

   [rcm_tig_final_report]
              IEEE 802.11 WG RCM TIG, "IEEE 802.11 Randomized And
              Changing MAC Addresses Topic Interest Group Report",
              doc.:IEEE 802.11-19/1442r9 , 2019.

   [rcm_user_experience_csd]
              IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
              Changing MAC Addresses Study Group CSD on user experience
              mechanisms", doc.:IEEE 802.11-20/1117r3 , 2020.

   [rcm_user_experience_par]
              IEEE 802.11 WG RCM SG, "IEEE 802.11 Randomized And
              Changing MAC Addresses Study Group PAR on user experience
              mechanisms", doc.:IEEE 802.11-20/742r5 , 2020.
-->

      <reference anchor="rcm_user_experience_csd" > anchor="rcm_user_experience_csd">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on user experience mechanisms</title>
           <author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE
          <author>
<organization>IEEE 802.11 WG RCM SG"> SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <seriesInfo name="doc.:IEEE 802.11-20/1117r3" value="" />
	<refcontent>doc.:IEEE 802.11-20/1117r3</refcontent>
      </reference>

      <reference anchor="rcm_tig_final_report" > anchor="rcm_tig_final_report">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Topic Interest Group Report</title>
           <author initials="" surname="IEEE
          <author>
<organization>IEEE 802.11 WG RCM TIG" fullname="IEEE 802.11 WG RCM TIG"> TIG</organization>
          </author>
          <date month="" year="2019"/>
        </front>
        <seriesInfo name="doc.:IEEE 802.11-19/1442r9" value="" />
	<refcontent>doc.:IEEE 802.11-19/1442r9</refcontent>
      </reference>

      <reference anchor="rcm_user_experience_par" > anchor="rcm_user_experience_par">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on user experience mechanisms</title>
           <author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE
          <author>
<organization>IEEE 802.11 WG RCM SG"> SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <seriesInfo name="doc.:IEEE 802.11-20/742r5" value="" />
	<refcontent>doc.:IEEE 802.11-20/742r5</refcontent>
      </reference>

      <reference anchor="rcm_privacy_par" > anchor="rcm_privacy_par">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on privacy mechanisms</title>
           <author initials="" surname="IEEE
          <author>
<organization>IEEE 802.11 WG RCM SG" fullname="IEEE 802.11 WG RCM SG"> SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <seriesInfo name="doc.:IEEE 802.11-19/854r7" value="" />
	<refcontent>doc.:IEEE 802.11-19/854r7</refcontent>
      </reference>

      <reference anchor="rcm_privacy_csd" > anchor="rcm_privacy_csd">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on user experience mechanisms</title>
           <author initials="" surname="IEEE 802.11 WG RCM SG" fullname="IEEE
          <author>
<organization>IEEE 802.11 WG RCM SG"> SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <seriesInfo name="doc.:IEEE 802.11-20/1346r1" value="" />
	<refcontent>doc.:IEEE 802.11-20/1346r1</refcontent>
      </reference>

<reference anchor="IEEE802.1AEdk-2023" > anchor="IEEE_802.1AEdk">
        <front>
          <title>IEEE Std 802.1AEdk-2023: IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security - Amendment 4: MAC Privacy protection</title>
           <author initials="" surname="IEEE 802.1" fullname="IEEE 802.1">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="August" year="2023"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1AEdk-2023"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2023.10225636"/>
      </reference>

        <reference anchor="IEEE802.1D-2004" >
        <front>
          <title>IEEE

<!-- [rfced] We have some questions about the following text and the
accompanying reference entry:

Original:
   It is possible to use PNGM for wired Ethernet connections through
   some passive observation of network traffic, such as STP
   [IEEE802.1D-2004], LLDP [IEEE802.1AB-2016], DHCP or Router
   Advertisements to determine which network has been attached.
   ...
   [IEEE802.1D-2004]
              IEEE 802.1, "IEEE Std 802.1D-2004: IEEE Standard for Local
              and metropolitan area networks: Media Access Control (MAC)
              Bridges", 2004.

a) This reference entry is provided for STP, but we see the following at
https://ieeexplore.ieee.org/document/1309630: "remove the Spanning Tree
protocol defined in Clause 8". The document is behind a paywall so we cannot
check that it contains information about STP. Please confirm this reference
is accurate.

b) We see that IEEE Std 802.1D-2004 has been superseded. See
https://standards.ieee.org/ieee/802.1D/3387/.

It seems that it has been superseded several times:
by 802.1Q-2014 - https://standards.ieee.org/ieee/802.1D/3387/
by 802.1Q-2014 - https://standards.ieee.org/ieee/802.1Q/5801/
by 802.1Q-2018 - https://standards.ieee.org/ieee/802.1Q/6844/

The active standard seems to be IEEE 802.1Q-2022 (see
https://standards.ieee.org/ieee/802.1Q/10323/ and
https://ieeexplore.ieee.org/document/10004498).

Would you like to cite the active standard? If so, please note that it is also
behind a paywall so we cannot check that it discusses STP.
-->
      <reference anchor="IEEE_802.1D" target="https://ieeexplore.ieee.org/document/1309630">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges</title>
           <author initials="" surname="IEEE 802.1" fullname="IEEE 802.1">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="June" year="2004"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1D-2004"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2004.94569"/>
      </reference>

      <reference anchor="IEEE802.1AB-2016" > anchor="IEEE_802.1AB">
        <front>
          <title>IEEE Std 802.1AB-2016: IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery</title>
           <author initials="" surname="IEEE 802.1" fullname="IEEE 802.1">
          <author>
             <organization>IEEE</organization>
          </author>
          <date month="" month="March" year="2016"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1AB-2016"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
      </reference>

      <reference anchor="wba_paper" > anchor="wba_paper">
        <front>
          <title>Wi-Fi Identification Scope for Liasing - In a post MAC Randomization Era</title>
           <author fullname="Wireless
          <author>
<organization>Wireless Broadband Alliance"> Alliance</organization>
          </author>
          <date month="March" year="2020"/>
        </front>
        <seriesInfo name="doc.:WBA
	<refcontent>doc.:WBA Wi-Fi ID Intro: Post MAC Randomization Era v1.0 - IETF liaison" value="" /> liaison</refcontent>
      </reference>

<!-- [rfced] FYI - We updated the date in this reference entry from July 2020
to May 2021 match the date of the conference (see
https://ieeexplore.ieee.org/document/9488728).

Original:
   [contact_tracing_paper]
              Leith, D. J. and S. Farrell, "Contact Tracing App Privacy:
              What Data Is Shared By Europe's GAEN Contact Tracing
              Apps", IEEE INFOCOM 2021 , July 2020.

Updated:
   [contact_tracing_paper]
              Leith, D. J. and S. Farrell, "Contact Tracing App Privacy:
              What Data Is Shared By Europe's GAEN Contact Tracing
              Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer
              Communications, DOI 10.1109/INFOCOM42981.2021.9488728, May
              2021, <https://ieeexplore.ieee.org/document/9488728>.
-->
      <reference anchor="contact_tracing_paper" > target="https://ieeexplore.ieee.org/document/9488728">
        <front>
          <title>Contact Tracing App Privacy: What Data Is Shared By Europe's GAEN Contact Tracing Apps</title>
          <author fullname="Douglas J. Leith"></author> Leith"/>
          <author fullname="Stephen Farrell"></author> Farrell"/>
          <date month="July" year="2020"/> month="May" year="2021"/>
        </front>
        <seriesInfo name="IEEE
        <refcontent>IEEE INFOCOM 2021" value="" /> 2021 - IEEE Conference on Computer Communications</refcontent>
        <seriesInfo name="DOI" value="10.1109/INFOCOM42981.2021.9488728"/>
      </reference>
    </references>

    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
The authors would like to thank <contact fullname="Guillermo Sanchez Illan"/> for the extensive tests
performed on different OSes to analyze their behavior regarding address
randomization.
      </t>

<!-- [rfced] Please review the text starting with "performed as part..." and
let us know how to update for clarity.

Original:
   Finally, authors would
   also like to thank the IEEE 802.1 Working Group for its review and
   comments, performed as part of the Liaison statement on Randomized
   and Changing MAC Address (https://datatracker.ietf.org/
   liaison/1884/).

Perhaps:
   Finally, authors would
   like to thank the IEEE 802.1 Working Group for its review and
   comments, which resulted in the "Liaison statement on Randomized
   and Changing MAC Address" (https://datatracker.ietf.org/
   liaison/1884/).

Or:
   Finally, authors would
   like to thank the IEEE 802.1 Working Group for its review and
   comments (see <https://datatracker.ietf.org/
   liaison/1884/>).
-->

      <t>
The authors would also like to thank <contact fullname="Jerome Henry"/>, <contact fullname="Hai Shalom"/>, <contact fullname="Stephen Farrell"/>, <contact fullname="Alan
DeKok"/>, <contact fullname="Mathieu Cunche"/>, <contact fullname="Johanna Ansohn McDougall"/>, <contact fullname="Peter Yee"/>, <contact fullname="Bob Hinden"/>, <contact fullname="Behcet
Sarikaya"/>, <contact fullname="David Farmer"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Christian Amsüss"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Murray Kucherawy"/>, and <contact fullname="Paul Wouters"/> for their reviews and comments on
previous draft versions of this document. In addition, the authors would like to thank <contact fullname="Michael
Richardson"/> for his contributions on the taxonomy section. Finally, the authors would
like to thank the IEEE 802.1 Working Group for its review and comments, performed as part of the "Liaison statement on Randomized and Changing MAC Address" (<eref target="https://datatracker.ietf.org/liaison/1884/"/>).
      </t>
    </section>

  </back>

<!-- [rfced] We see a number of author-inserted comments in the .xml file for
this document. We are unsure if these have been resolved. Please review
and let us know if these can be deleted or if they need to be addressed.
-->

<!-- [rfced] Terminology

a) We note inconsistencies in the term below throughout the text. Should these
be uniform? If so, please let us know which form is preferred.

MAC address randomization vs. MAC randomization

b) Is "overcome" the best word choice here? Would "address" or
something else be better?

Original:
   There have been several initiatives within the IETF and the IEEE 802
   standards committees to overcome some of these privacy issues.
   ...
   There have been several initiatives at the IETF and the IEEE 802
   standards committees to overcome some of these privacy issues.
   ...
   One way to overcome this privacy concern is by using randomly
   generated MAC addresses.
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Media Access Control (MAC)
Standards Development Organization (SDO)
Link Layer Discovery Protocol (LLDP)
Extensible Authentication Protocol (EAP)
DHCP Unique Identifier (DUID)

b) How should the following acronyms be expanded in this document? Our list
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list) includes several
expansions for each.

SSID
STP

c) May we update the expansion of RCM as follows? If so, we will also update
"RCM" to "RCM address" in the sentences below.

Original (expansion):
  Randomized and Changing MAC addresses (RCM)

Perhaps:
  Randomized and Changing MAC (RCM) addresses

Original (sentences with RCM):
   As of 2024, two task groups in IEEE 802.11 are dealing with issues
   related to RCM:

   *  The IEEE 802.11bh task group, which is looking at mitigating the
      repercussions that RCM creates on 802.11 networks and related
      services.

Perhaps:
   As of 2024, two task groups in IEEE 802.11 are dealing with issues
   related to RCM addresses:

   *  The IEEE 802.11bh task group, which is looking at mitigating the
      repercussions that RCM addresses create on 802.11 networks and related
      services.

d) We see this note in Section 6:

   Note about the used naming convention: the "M" in MAC is included in
   the acronym, but not the "A" from address.  This allows one to talk
   about a PVOM Address, or PNGM Address.

Per this note, may we update the expansions in Section 6.1-6.6 as follows and
then update instances like "PDGM" in the document to "PDGM address"?

Original:
  Per-Vendor OUI MAC address (PVOM)
  Per-Device Generated MAC address (PDGM)
  Per-Boot Generated MAC address (PBGM)
  Per-Network Generated MAC address (PNGM)
  Per-Period Generated MAC address (PPGM)
  Per-Session Generated MAC address (PSGM)

Perhaps:
  Per-Vendor OUI MAC (PVOM) Address
  Per-Device Generated MAC (PDGM) Address
  Per-Boot Generated MAC (PBGM) Address
  Per-Network Generated MAC (PNGM) Address
  Per-Period Generated MAC (PPGM) Address
  Per-Session Generated MAC (PSGM) Address

e) FYI - We see "Interface Identifier", "interface identifier", and "IID" used
throughout the document. We updated to use the expansion in the first instance
and the abbreviation for all other instances.
-->

<!-- [rfced] Please review whether the following note in this document should
be in the <aside> element. It is defined as "a container for content that
is semantically less important or tangential to the content that
surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).

Original:
   Note about the used naming convention: the "M" in MAC is included in
   the acronym, but not the "A" from address.  This allows one to talk
   about a PVOM Address, or PNGM Address.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>