<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docName="draft-ietf-madinas-mac-address-randomization-15" ipr="trust200902" number="9724" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2025-03-17T00:47:39" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization-15" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9724" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="State of Affairs for Randomized and Changing MAC Addresses">State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses</title>
    <seriesInfo name="RFC" value="9724" stream="IETF"/>
    <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
      <organization abbrev="Cisco" showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <city>Montreal</city>
          <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" showOnFrontPage="true">Universidad Carlos III de 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" showOnFrontPage="true">Safespring AB</organization>
      <address>
        <email>amelia.ietf@andersdotter.cc</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>INT</area>
    <workgroup>madinas</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
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 
Media Access Control (MAC) addresses.
      </t>
      <t indent="0" pn="section-abstract-2">
There have been several initiatives within the IETF and the IEEE 802 standards
committees to address some of the privacy issues involved. This document provides an
overview of these activities to help coordinate standardization activities in these bodies.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9724" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mac-address-usage">MAC Address Usage</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mac-address-randomization">MAC Address Randomization</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-workshop-tutorial-a">Privacy Workshop, Tutorial, and Experiments at IETF and IEEE 802 Meetings</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-activities-relating-to-rand">Activities Relating to Randomized and Changing MAC Addresses in the IEEE 802</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recent-activities-related-t">Recent Activities Related to MAC Address Randomization in the WBA</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv6-address-randomization-">IPv6 Address Randomization in the IETF</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-taxonomy-of-mac-address-sel">Taxonomy of MAC Address Selection Policies</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-vendor-oui-mac-address-">Per-Vendor OUI MAC Address (PVOM)</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-device-generated-mac-ad">Per-Device Generated MAC Address (PDGM)</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-boot-generated-mac-addr">Per-Boot Generated MAC Address (PBGM)</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-network-generated-mac-a">Per-Network Generated MAC Address (PNGM)</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-period-generated-mac-ad">Per-Period Generated MAC Address (PPGM)</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-per-session-generated-mac-a">Per-Session Generated MAC Address (PSGM)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-os-current-practices">OS Current Practices</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec_introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
Privacy is becoming a huge concern, as more and more devices are connecting to
the Internet either directly (e.g., via Wi-Fi) or indirectly (e.g., via a
smartphone using Bluetooth). This ubiquitous connectivity, together with the
lack of proper education about 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 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.
      </t>
      <t indent="0" pn="section-1-2">
Privacy concerns affect all layers of the protocol stack, from the lower
layers involved in the access to the network (e.g., MAC/L2 and L3
addresses can be used to obtain the location of a user) to higher-layer protocol
identifiers and user applications <xref target="CSCN2015" format="default" sectionFormat="of" derivedContent="CSCN2015"/>. In
particular, IEEE 802 MAC addresses have historically been an easy target for
tracking users <xref target="wifi_tracking" format="default" sectionFormat="of" derivedContent="wifi_tracking"/>.

      </t>
      <t indent="0" pn="section-1-3">
There have been several initiatives within the IETF and the IEEE 802 standards
committees to address some of these privacy issues. This document provides an
overview of these activities to help coordinate standardization activities
within these bodies.
      </t>
    </section>
    <section anchor="sec_background" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-background">Background</name>
      <section anchor="sec_mac_usage" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-mac-address-usage">MAC Address Usage</name>
        <t indent="0" pn="section-2.1-1">
Most mobile devices used today are Wi-Fi enabled (i.e., they are equipped with
an IEEE 802.11 wireless local area network interface). Like any other kind of
network interface based on IEEE 802 such as Ethernet (i.e., IEEE 802.3), Wi-Fi
interfaces have an L2 address (also referred to as a MAC 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" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
        </t>
        <figure anchor="fig_ieee802_mac_address_format" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-ieee-802-mac-address-format">IEEE 802 MAC Address Format (for 48-Bit Addresses)</name>
          <artwork name="" type="" align="left" alt="" pn="section-2.1-2.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
+--+--+--+--+--+--+--+--+
</artwork>
        </figure>
        <t indent="0" pn="section-2.1-3">
MAC addresses can be either universally or locally administered.
Universally and locally administered addresses are distinguished by
setting the second least significant bit of the most significant byte of the
address (the U/L bit).
        </t>
        <t indent="0" pn="section-2.1-4">
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>
        <dl newline="false" spacing="normal" indent="3" pn="section-2.1-5">
          <dt pn="section-2.1-5.1">Organizationally Unique
  Identifier (OUI):</dt>
          <dd pn="section-2.1-5.2">The first three octets in transmission order, which identify the organization that issued the identifier.</dd>
          <dt pn="section-2.1-5.3">Network Interface
Controller (NIC) Specific:</dt>
          <dd pn="section-2.1-5.4">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 indent="0" pn="section-2.1-6">
Locally administered addresses override the burned-in address, and they can be
set up by either the network administrator or the Operating System (OS) of the
device to which the address pertains. However, as explained in later sections
of this document, there are new initiatives 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>
      <section anchor="sec_mac_addr_random" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-mac-address-randomization">MAC Address Randomization</name>
        <t indent="0" pn="section-2.2-1">
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 over the 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" format="default" sectionFormat="of" derivedContent="link_layer_privacy"/>.
        </t>
        <t indent="0" pn="section-2.2-2">
MAC addresses can be easily observed by a third party, such as a passive
device listening to communications in 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 different situations:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-3">
          <li pn="section-2.2-3.1">
            <t indent="0" pn="section-2.2-3.1.1">
While actively scanning for available networks, the MAC address is used in the
Probe Request frames sent by the device.
            </t>
          </li>
          <li pn="section-2.2-3.2">
            <t indent="0" pn="section-2.2-3.2.1">
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>
          </li>
        </ul>
        <t indent="0" pn="section-2.2-4">
One way to address this privacy concern is by using randomly generated MAC
addresses. IEEE 802 addressing includes one bit to specify if the hardware
address is locally or globally administered. This allows local
addresses to be generated without the need for any global coordination mechanism to ensure that
the generated address is still unique within the local network. This feature can
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" sectionFormat="of" derivedContent="enhancing_location_privacy"/>.
        </t>
        <t indent="0" pn="section-2.2-5">
Note that there are reports <xref target="contact_tracing_paper" format="default" sectionFormat="of" derivedContent="contact_tracing_paper"/> of some
mobile OSes reporting persistently (every 20 minutes or so)
on MAC addresses (as well as other information), which would defeat MAC address
randomization. While these practices might have changed by now, it is important
to highlight that privacy-preserving techniques should be conducted while considering
all layers of the protocol stack.
        </t>
      </section>
      <section anchor="sec_mac_addr_experiments" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-privacy-workshop-tutorial-a">Privacy Workshop, Tutorial, and Experiments at IETF and IEEE 802 Meetings</name>
        <t indent="0" pn="section-2.3-1">
As an outcome to the STRINT W3C/IAB Workshop <xref target="strint" format="default" sectionFormat="of" derivedContent="strint"/>, a
tutorial titled "Pervasive Surveillance of the Internet - Designing Privacy into
Internet Protocols" <xref target="privacy_tutorial" format="default" sectionFormat="of" derivedContent="privacy_tutorial"/> was given at the IEEE 802 Plenary meeting in San Diego in July of 2014. The tutorial provided an update on
the recent developments regarding Internet privacy, the actions undertaken by
other 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" sectionFormat="of" derivedContent="RFC6973"/>). The
tutorial highlighted some privacy concerns that apply specifically to link-layer
technologies and provided suggestions on how IEEE 802 could help address
them.
        </t>
        <t indent="0" pn="section-2.3-2">
Following the discussions and interest within the IEEE 802 community, on 18
July 2014, the IEEE 802 Executive Committee (EC) created the IEEE 802 EC
Privacy Recommendation Study Group (SG) <xref target="ieee_privacy_ecsg" format="default" sectionFormat="of" derivedContent="ieee_privacy_ecsg"/>.

The work and discussions from the group have generated multiple outcomes, such
Project Authorization Requests (PARs) that resulted in the following
documents:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2.3-3">
          <li pn="section-2.3-3.1">"IEEE Recommended Practice for Privacy Considerations for IEEE 802(R) Technologies" <xref target="IEEE_802E" format="default" sectionFormat="of" derivedContent="IEEE_802E"/></li>
          <li pn="section-2.3-3.2">"IEEE Standard for Local and Metropolitan Area Networks: Overview and
Architecture - Amendment 2: Local Medium Access Control (MAC) Address Usage"
<xref target="IEEE_802c" format="default" sectionFormat="of" derivedContent="IEEE_802c"/></li>
        </ul>
        <t indent="0" pn="section-2.3-4">
In order to test the effects of MAC address randomization, experiments 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 experiments was to evaluate
the use of MAC address randomization from two different perspectives: (1) the
effect on the connectivity experience of the end user, as well as any effect on
applications and OSes, and (2) the potential impact on the
network infrastructure itself. Some of the findings were published in <xref target="CSCN2015" format="default" sectionFormat="of" derivedContent="CSCN2015"/>.
        </t>
        <t indent="0" pn="section-2.3-5">
During the experiments, it was observed that the probability of address duplication in
a network is negligible. The experiments also revealed that other protocol
identifiers (e.g., the DHCP client identifier) can be correlated and can therefore still be
used to track an individual. Hence, effective privacy tools should not
work in isolation at a single layer; instead; they should be coordinated with other
privacy features at higher layers.
        </t>
        <t indent="0" pn="section-2.3-6">
Since then, MAC address randomization has been further implemented by mobile OSes to
provide better privacy for mobile phone users when connecting to public wireless
networks <xref target="privacy_ios" format="default" sectionFormat="of" derivedContent="privacy_ios"/> <xref target="privacy_windows" format="default" sectionFormat="of" derivedContent="privacy_windows"/> <xref target="privacy_android" format="default" sectionFormat="of" derivedContent="privacy_android"/>.
        </t>
      </section>
    </section>
    <section anchor="sec_mac_rnd_at_ieee802" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-activities-relating-to-rand">Activities Relating to Randomized and Changing MAC Addresses in the IEEE 802</name>
      <t indent="0" pn="section-3-1">
Practical experiences with Randomized and Changing MAC addresses (RCM) in
devices (some of which are explained in <xref target="rcm-types" format="default" sectionFormat="of" derivedContent="Section 6"/>) helped researchers fine-tune their understanding of
attacks against randomization mechanisms <xref target="when_mac_randomization_fails" format="default" sectionFormat="of" derivedContent="when_mac_randomization_fails"/>. Within the IEEE
802.11 group, these research experiences eventually formed the basis for a
specified mechanism that randomizes MAC addresses, which was introduced in
IEEE Std 802.11aq <xref target="IEEE_802.11aq" format="default" sectionFormat="of" derivedContent="IEEE_802.11aq"/> in 2018.
      </t>
      <t indent="0" pn="section-3-2">
More recent developments include turning on MAC address 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" sectionFormat="of" derivedContent="rcm_user_experience_csd"/>. 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 target="rcm_tig_final_report" format="default" sectionFormat="of" derivedContent="rcm_tig_final_report"/>.

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
<xref target="rcm_user_experience_par" format="default" sectionFormat="of" derivedContent="rcm_user_experience_par"/> 
and (2) user privacy solutions described in IEEE Std 802.11 <xref target="rcm_privacy_par" format="default" sectionFormat="of" derivedContent="rcm_privacy_par"/> apply.
      </t>
      <t indent="0" pn="section-3-3">
IEEE Std 802 <xref target="IEEE_802" format="default" sectionFormat="of" derivedContent="IEEE_802"/>, as of the amendment IEEE 802c-2017
<xref target="IEEE_802c" format="default" sectionFormat="of" derivedContent="IEEE_802c"/>, specifies a local MAC address space structure known
as the Structured Local Address Plan (SLAP) <xref target="RFC8948" format="default" sectionFormat="of" derivedContent="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 of local MAC addresses is
designated for Administratively Assigned Identifiers, which are subject to assignment
by a network administrator.
      </t>
      <t indent="0" pn="section-3-4">
IEEE Std 802E-2020 ("IEEE Recommended Practice for Privacy Considerations for IEEE 802(R)
Technologies") <xref target="IEEE_802E" format="default" sectionFormat="of" derivedContent="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
the review of user privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi devices) as
part of the RCM efforts <xref target="rcm_privacy_csd" format="default" sectionFormat="of" derivedContent="rcm_privacy_csd"/>. Annex I of IEEE Std
802.1AEdk-2023 ("MAC Privacy Protection") <xref target="IEEE_802.1AEdk" format="default" sectionFormat="of" derivedContent="IEEE_802.1AEdk"/>
discusses privacy considerations in bridged networks.
</t>
      <t indent="0" pn="section-3-5">
As of 2024, two task groups in IEEE 802.11 are dealing with issues related to RCM:

      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-6">
        <li pn="section-3-6.1">
          <t indent="0" pn="section-3-6.1.1">
The IEEE 802.11bh task group, which is looking at mitigating the repercussions that RCM
creates on 802.11 networks and related services.
          </t>
        </li>
        <li pn="section-3-6.2">
          <t indent="0" pn="section-3-6.2.1">
The IEEE 802.11bi task group, which is chartered to define modifications to the IEEE Std
802.11 MAC specification <xref target="IEEE_802.11" format="default" sectionFormat="of" derivedContent="IEEE_802.11"/> to specify new mechanisms that
address and improve user privacy.
          </t>
        </li>
      </ul>
    </section>
    <section anchor="sec_wba" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-recent-activities-related-t">Recent Activities Related to MAC Address Randomization in the WBA</name>
      <t indent="0" pn="section-4-1">
In the Wireless Broadband Alliance (WBA), the Testing and Interoperability Work
Group has been looking at issues related to MAC address randomization and
has identified a list of potential impacts of these changes to existing systems
and solutions, mainly related to Wi-Fi identification.
      </t>
      <t indent="0" pn="section-4-2">
   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 <xref target="wba_paper" format="default" sectionFormat="of" derivedContent="wba_paper"/>).
      </t>
    </section>
    <section anchor="sec_mac_rnd_at_ietf" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-ipv6-address-randomization-">IPv6 Address Randomization in the IETF</name>
      <t indent="0" pn="section-5-1">
<xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC4862"/> 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 and an
Interface Identifier (IID). <xref target="RFC8064" format="default" sectionFormat="of" derivedContent="RFC8064"/> 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, made it easier to perform global device
tracking.
      </t>
      <t indent="0" pn="section-5-2">
<xref target="RFC8981" format="default" sectionFormat="of" derivedContent="RFC8981"/> identifies and describes the privacy
issues associated with 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 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 then deprecated. Deprecated addresses can
continue to be used for already-established connections but are not used to
initiate new connections. New temporary addresses are generated periodically
to replace temporary addresses 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 (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, 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" sectionFormat="of" derivedContent="RFC7217"/>, summarized next,
partially addresses the problems aforementioned.
      </t>
      <t indent="0" pn="section-5-3">
<xref target="RFC7217" format="default" sectionFormat="of" derivedContent="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 enables the
"stability" properties of the IIDs specified in <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/> 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 that takes the following as input: information that is stable and associated to
the interface (e.g., a local IID), stable information
associated to the visited network (e.g., the IEEE 802.11 Service Set Identifier (SSID)), the IPv6 prefix,
a secret key, and some other additional information. This basically ensures
that a different IID is generated when one of the input fields changes (such as
the network or the prefix) but that the IID is the same within each subnet.
      </t>
      <t indent="0" pn="section-5-4">
To mitigate the privacy threats posed by the use of MAC-derived
IIDs, <xref target="RFC8064" format="default" sectionFormat="of" derivedContent="RFC8064"/> recommends that nodes implement <xref target="RFC7217" format="default" sectionFormat="of" derivedContent="RFC7217"/> as the default scheme for generating stable IPv6 addresses
with SLAAC.
      </t>
      <t indent="0" pn="section-5-5">
In addition to the documents above, <xref target="RFC8947" format="default" sectionFormat="of" derivedContent="RFC8947"/>
      proposes a DHCPv6 extension that:</t>
      <blockquote pn="section-5-6">
      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.
</blockquote>
      <t indent="0" pn="section-5-7">And <xref target="RFC8948" format="default" sectionFormat="of" derivedContent="RFC8948"/> proposes DHCPv6 extensions that:</t>
      <blockquote pn="section-5-8">
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.
</blockquote>
      <t indent="0" pn="section-5-9">
     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" sectionFormat="of" derivedContent="RFC7844"/> introduces
     anonymity profiles that are:</t>
      <blockquote pn="section-5-10">
designed for clients that
wish to remain anonymous to the visited network
</blockquote>
      <t indent="0" pn="section-5-11">and that:</t>
      <blockquote pn="section-5-12">
provide guidelines
on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure
of identifying information.
</blockquote>
      <t indent="0" pn="section-5-13"><xref target="RFC7844" format="default" sectionFormat="of" derivedContent="RFC7844"/> also indicates that the
link-layer address, IP address, and DHCP identifier shall evolve in synchrony.
      </t>
    </section>
    <section anchor="rcm-types" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-taxonomy-of-mac-address-sel">Taxonomy of MAC Address Selection Policies</name>
      <t indent="0" pn="section-6-1">
This section documents different policies for MAC address selection. Some OSes
might use a combination of multiple policies.
      </t>
      <aside pn="section-6-2">
        <t indent="0" pn="section-6-2.1">
   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".
        </t>
      </aside>
      <section anchor="policy-pvom" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-per-vendor-oui-mac-address-">Per-Vendor OUI MAC Address (PVOM)</name>
        <t indent="0" pn="section-6.1-1">
          This form of MAC address selection is the historical default.
        </t>
        <t indent="0" pn="section-6.1-2">
          The vendor obtains an OUI from the IEEE.
          This is a 24-bit prefix (including two upper bits that are
          set specifically) that is assigned to the vendor.
          The vendor generates a unique 24-bit value for the lower 24 bits,
          forming the 48-bit MAC address.
   It is not unusual for the 24-bit value
   to be used as an incrementing counter that was assigned at the factory and
   burnt into non-volatile storage.
        </t>
        <t indent="0" pn="section-6.1-3">
          Note that IEEE Std 802.15.4 <xref target="IEEE_802.15.4" format="default" sectionFormat="of" derivedContent="IEEE_802.15.4"/> uses 64-bit MAC addresses, and the IEEE assigns
          32-bit prefixes.
          The IEEE has indicated that there may be a future Ethernet
          specification that uses 64-bit MAC addresses.
        </t>
      </section>
      <section anchor="policy-pdgm" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-per-device-generated-mac-ad">Per-Device Generated MAC Address (PDGM)</name>
        <t indent="0" pn="section-6.2-1">
          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" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-per-boot-generated-mac-addr">Per-Boot Generated MAC Address (PBGM)</name>
        <t indent="0" pn="section-6.3-1">
          This form of MAC address is randomly generated by the device each
          time the device is booted.

          The resulting MAC address is <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" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-per-network-generated-mac-a">Per-Network Generated MAC Address (PNGM)</name>
        <t indent="0" pn="section-6.4-1">
          This form of MAC address is generated each time a new network
          attachment is created.
        </t>
        <t indent="0" pn="section-6.4-2">
          This is typically used with Wi-Fi networks (i.e., 802.11 networks) where the network is identified by an SSID Name.
          The generated address is stored 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 indent="0" pn="section-6.4-3">
          It is possible to use PNGM for wired Ethernet connections through
          some passive observation of network traffic (such as spanning tree protocols <xref target="IEEE_802.1Q" format="default" sectionFormat="of" derivedContent="IEEE_802.1Q"/>, the Link Layer Discovery Protocol (LLDP) <xref target="IEEE_802.1AB" format="default" sectionFormat="of" derivedContent="IEEE_802.1AB"/>,
          DHCP, or Router Advertisements) to determine which network has been
          attached.
        </t>
      </section>
      <section anchor="policy-ppgm" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-per-period-generated-mac-ad">Per-Period Generated MAC Address (PPGM)</name>
        <t indent="0" pn="section-6.5-1">
          This form of MAC address is generated periodically, 
          typically around every twelve hours.
          Like PNGM, it is used primarily with Wi-Fi.
        </t>
        <t indent="0" pn="section-6.5-2">
          When the MAC address changes, the station disconnects from the current
          session and reconnects using the new MAC address.

	  This will involve a new 802.1x session, as well as obtaining or refreshing a new IP address (e.g., using DHCP or SLAAC).

        </t>
        <t indent="0" pn="section-6.5-3">
          If DHCP is used, then a new DHCP Unique Identifier (DUID) is generated so as to not link to
          the previous connection; this usually results in the allocation of new IP addresses.
        </t>
      </section>
      <section anchor="policy-psgm" numbered="true" toc="include" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-per-session-generated-mac-a">Per-Session Generated MAC Address (PSGM)</name>
        <t indent="0" pn="section-6.6-1">
          This form of MAC address is generated on a per-session basis. How a session is defined is implementation-dependent, for example, a session might be defined by logging in to a portal, VPN, etc. Like PNGM and PPGM, it is used primarily with Wi-Fi.
        </t>
        <t indent="0" pn="section-6.6-2">
          Since the address only changes when a new session is established, there is no disconnection/reconnection involved.
        </t>
      </section>
    </section>
    <section anchor="sec_os_current_practices" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-os-current-practices">OS Current Practices</name>
      <t indent="0" pn="section-7-1">
By default, most modern OSes (especially mobile ones) do implement some MAC
address randomization policies. Since the mechanism and policies that OSes implement can evolve with time, the content is hosted at <eref target="https://wiki.ietf.org/en/group/madinas/RFC9724" brackets="angle"/>. 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 indent="0" pn="section-7-2">

<xref target="tab_current_practices" format="default" sectionFormat="of" derivedContent="Table 1"/> summarizes current
practices for Android and iOS at the time of writing this document (the original source is available
at <xref target="private_mac" format="default" sectionFormat="of" derivedContent="private_mac"/>) and also includes
updates based on findings from the authors.
      </t>
      <table anchor="tab_current_practices" align="center" pn="table-1">
        <name slugifiedName="name-android-and-ios-mac-address">Android and iOS MAC Address Randomization Practices</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Android 10+</th>
            <th align="left" colspan="1" rowspan="1">iOS 14+</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">The randomized MAC address is bound to the SSID.</td>
            <td align="left" colspan="1" rowspan="1">The randomized MAC address is bound to the Basic SSID.</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">The randomized MAC address is stable across reconnections for the same network.</td>
            <td align="left" colspan="1" rowspan="1">The randomized MAC address is stable across reconnections for the same network.</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">The randomized MAC address does not get re-randomized when the device forgets a Wi-Fi network.</td>
            <td align="left" colspan="1" rowspan="1">The randomized MAC address is reset when the device forgets a Wi-Fi network.</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">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).</td>
            <td align="left" colspan="1" rowspan="1">MAC address randomization is enabled by default for all the new Wi-Fi networks.</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-7-4">
In September 2021, we performed some additional tests to evaluate how OSes
that are widely used behave regarding MAC address randomization. <xref target="tab_experiments-2021" format="default" sectionFormat="of" derivedContent="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 <xref target="rcm-types" format="default" sectionFormat="of" derivedContent="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.
      </t>
      <table anchor="tab_experiments-2021" align="center" pn="table-2">
        <name slugifiedName="name-observed-behavior-in-differ">Observed Behavior in Different OSes (as of September 2021)</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">OS</th>
            <th align="center" colspan="1" rowspan="1">Linux (Debian "bookworm")</th>
            <th align="center" colspan="1" rowspan="1">Android 10</th>
            <th align="center" colspan="1" rowspan="1">Windows 10</th>
            <th align="center" colspan="1" rowspan="1">iOS 14+</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">Random. per net. (PNGM)</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Random. per connec. (PSGM)</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">N</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Random. daily (PPGM)</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">N</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SSID config.</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">N</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Random. for scan</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Random. for scan by default</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
            <td align="center" colspan="1" rowspan="1">N</td>
            <td align="center" colspan="1" rowspan="1">Y</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-7-6">
According to <xref target="privacy_android" format="default" sectionFormat="of" derivedContent="privacy_android"/>, starting with Android 12, Android
      uses non-persistent randomization in the following situations: </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-7">
        <li pn="section-7-7.1">A network
suggestion application specifies that non-persistent randomization be used for the
      network (through an API).</li>
        <li pn="section-7-7.2">The network is an open network that hasn't
encountered a captive portal, and an internal config option is set to do so (by
default, it is not).</li>
      </ul>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">
This document has no IANA actions.
      </t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">
Privacy considerations regarding tracking the location of a user through the MAC
address of 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 indent="0" pn="section-9-2">
Any future specification in this area would need to look into security and
privacy aspects, such as (but not limited to) the following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-3">
        <li pn="section-9-3.1">Mitigating the problem of
location privacy while minimizing the impact on upper layers of the protocol
stack</li>
        <li pn="section-9-3.2">Providing the means for network operators to authenticate devices
and authorize network access, despite the MAC addresses changing according
some pattern</li>
        <li pn="section-9-3.3">Providing the means for the device not to use MAC
addresses that it is not authorized to use or that are currently in use</li>
      </ul>
      <t indent="0" pn="section-9-4">
A major conclusion of the work in IEEE Std 802E <xref target="IEEE_802E" format="default" sectionFormat="of" derivedContent="IEEE_802E"/> concerned the difficulty of
defending 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.
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="contact_tracing_paper" target="https://ieeexplore.ieee.org/document/9488728" quoteTitle="true" derivedAnchor="contact_tracing_paper">
        <front>
          <title>Contact Tracing App Privacy: What Data Is Shared By Europe's GAEN Contact Tracing Apps</title>
          <author fullname="Douglas J. Leith"/>
          <author fullname="Stephen Farrell"/>
          <date month="May" year="2021"/>
        </front>
        <refcontent>IEEE INFOCOM 2021 - IEEE Conference on Computer Communications</refcontent>
        <seriesInfo name="DOI" value="10.1109/INFOCOM42981.2021.9488728"/>
      </reference>
      <reference anchor="CSCN2015" quoteTitle="true" target="https://doi.org/10.1109/CSCN.2015.7390443" derivedAnchor="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>
        <refcontent>2015 IEEE Conference on Standards for Communications and Networking (CSCN)</refcontent>
        <seriesInfo name="DOI" value="10.1109/CSCN.2015.7390443"/>
      </reference>
      <reference anchor="enhancing_location_privacy" quoteTitle="true" target="https://doi.org/10.1007/s11036-005-6425-1" derivedAnchor="enhancing_location_privacy">
        <front>
          <title>Enhancing Location Privacy in Wireless LAN 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="June" year="2005"/>
        </front>
        <refcontent>Mobile Networks and Applications, vol. 10, no. 3, pp. 315-325</refcontent>
        <seriesInfo name="DOI" value="10.1007/s11036-005-6425-1"/>
      </reference>
      <reference anchor="IEEE_802" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2014.6847097" derivedAnchor="IEEE_802">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="June" year="2014"/>
        </front>
        <seriesInfo name="IEEE Std" value="802-2014"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
      </reference>
      <reference anchor="IEEE_802.11" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2021.9363693" derivedAnchor="IEEE_802.11">
        <front>
          <title>IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks--Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="February" year="2021"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11-2020"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
      </reference>
      <reference anchor="IEEE_802.11aq" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2018.8457463" derivedAnchor="IEEE_802.11aq">
        <front>
          <title>IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area network--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Preassociation Discovery</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="August" year="2018"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.11aq-2018"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457463"/>
      </reference>
      <reference anchor="IEEE_802.15.4" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2024.10794632" derivedAnchor="IEEE_802.15.4">
        <front>
          <title>IEEE Standard for Low-Rate Wireless Networks</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="December" year="2024"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.15.4-2024"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2024.10794632"/>
      </reference>
      <reference anchor="IEEE_802.1AB" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2016.7433915" derivedAnchor="IEEE_802.1AB">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date 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="IEEE_802.1AEdk" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2023.10225636" derivedAnchor="IEEE_802.1AEdk">
        <front>
          <title>IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security - Amendment 4: MAC Privacy protection</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date 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="IEEE_802.1Q" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2022.10004498" derivedAnchor="IEEE_802.1Q">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="December" year="2022"/>
        </front>
        <seriesInfo name="IEEE Std" value="802.1Q-2022"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.10004498"/>
      </reference>
      <reference anchor="IEEE_802c" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2017.8016709" derivedAnchor="IEEE_802c">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture--Amendment 2: Local Medium Access Control (MAC) Address Usage</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="August" year="2017"/>
        </front>
        <seriesInfo name="IEEE Std" value="802c-2017"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
      </reference>
      <reference anchor="IEEE_802E" quoteTitle="true" target="https://doi.org/10.1109/IEEESTD.2020.9257130" derivedAnchor="IEEE_802E">
        <front>
          <title>IEEE Recommended Practice for Privacy Considerations for IEEE 802(R) Technologies</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
          </author>
          <date month="November" year="2020"/>
        </front>
        <seriesInfo name="IEEE Std" value="802E-2020"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9257130"/>
      </reference>
      <reference anchor="ieee_privacy_ecsg" target="http://www.ieee802.org/PrivRecsg/" quoteTitle="true" derivedAnchor="ieee_privacy_ecsg">
        <front>
          <title>IEEE 802 EC Privacy Recommendation Study Group</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802 LAN/MAN Standards Committee</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="link_layer_privacy" quoteTitle="true" derivedAnchor="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>
        <refcontent>W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)</refcontent>
      </reference>
      <reference anchor="privacy_android" target="https://source.android.com/devices/tech/connect/wifi-mac-randomization-behavior" quoteTitle="true" derivedAnchor="privacy_android">
        <front>
          <title>MAC randomization behavior</title>
          <author>
            <organization showOnFrontPage="true">Android Open Source Project</organization>
          </author>
          <date/>
        </front>
        <refcontent>Android OS Documentation</refcontent>
      </reference>
      <reference anchor="privacy_ios" target="https://support.apple.com/en-us/102509" quoteTitle="true" derivedAnchor="privacy_ios">
        <front>
          <title>Use private Wi-Fi addresses on Apple Devices</title>
          <author>
            <organization showOnFrontPage="true">Apple Inc.</organization>
          </author>
          <date/>
        </front>
        <refcontent>Apple Support</refcontent>
      </reference>
      <reference anchor="privacy_tutorial" target="https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-01-00EC-internet-privacy-tutorial.pdf" quoteTitle="true" derivedAnchor="privacy_tutorial">
        <front>
          <title>Pervasive Surveillance of the Internet - Designing Privacy into Internet 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="privacy_windows" target="https://support.microsoft.com/en-us/windows/how-to-use-random-hardware-addresses-ac58de34-35fc-31ff-c650-823fc48eb1bc" quoteTitle="true" derivedAnchor="privacy_windows">
        <front>
          <title>How to use random hardware addresses in Windows</title>
          <author>
            <organization showOnFrontPage="true">Microsoft Corporation</organization>
          </author>
          <date/>
        </front>
        <refcontent>Microsoft Support</refcontent>
      </reference>
      <reference anchor="private_mac" target="https://web.archive.org/web/20230905111429/https://www.fing.com/news/private-mac-address-on-ios-14" quoteTitle="true" derivedAnchor="private_mac">
        <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="rcm_privacy_csd" quoteTitle="true" derivedAnchor="rcm_privacy_csd">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on user experience mechanisms</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802.11 WG RCM SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <refcontent>doc.:IEEE 802.11-20/1346r4</refcontent>
        <annotation>Download available at <eref brackets="angle" target="https://mentor.ieee.org/802.11/dcn/20/11-20-1346-04-0rcm-csd-draft-for-privacy-amendment-of-rcm-project.docx"/>.</annotation>
      </reference>
      <reference anchor="rcm_privacy_par" quoteTitle="true" derivedAnchor="rcm_privacy_par">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on privacy mechanisms</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802.11 WG RCM SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <refcontent>doc.:IEEE 802.11-19/854r7</refcontent>
        <annotation>Download available at <eref brackets="angle" target="https://mentor.ieee.org/802.11/dcn/20/11-20-0854-07-0rcm-par-proposal-for-privacy.docx"/>.</annotation>
      </reference>
      <reference anchor="rcm_tig_final_report" quoteTitle="true" derivedAnchor="rcm_tig_final_report">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Topic Interest Group Report</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802.11 WG RCM TIG</organization>
          </author>
          <date month="" year="2019"/>
        </front>
        <refcontent>doc.:IEEE 802.11-19/1442r9</refcontent>
        <annotation>Download available at <eref brackets="angle" target="https://mentor.ieee.org/802.11/dcn/19/11-19-1442-09-0rcm-rcm-tig-draft-report-outline.odt"/>.</annotation>
      </reference>
      <reference anchor="rcm_user_experience_csd" quoteTitle="true" derivedAnchor="rcm_user_experience_csd">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group CSD on user experience mechanisms</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802.11 WG RCM SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <refcontent>doc.:IEEE 802.11-20/1117r5</refcontent>
        <annotation>Download available at <eref brackets="angle" target="https://mentor.ieee.org/802.11/dcn/20/11-20-1117-05-0rcm-rcm-sg-proposed-rcm-csd-draft.docx"/>.</annotation>
      </reference>
      <reference anchor="rcm_user_experience_par" quoteTitle="true" derivedAnchor="rcm_user_experience_par">
        <front>
          <title>IEEE 802.11 Randomized And Changing MAC Addresses Study Group PAR on user experience mechanisms</title>
          <author>
            <organization showOnFrontPage="true">IEEE 802.11 WG RCM SG</organization>
          </author>
          <date month="" year="2020"/>
        </front>
        <refcontent>doc.:IEEE 802.11-20/742r6</refcontent>
        <annotation>Download available at <eref brackets="angle" target="https://mentor.ieee.org/802.11/dcn/20/11-20-0742-06-0rcm-proposed-par-draft.docx"/>.</annotation>
      </reference>
      <reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4291" quoteTitle="true" derivedAnchor="RFC4291">
        <front>
          <title>IP Version 6 Addressing Architecture</title>
          <author fullname="R. Hinden" initials="R." surname="Hinden"/>
          <author fullname="S. Deering" initials="S." surname="Deering"/>
          <date month="February" year="2006"/>
          <abstract>
            <t indent="0">This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
            <t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4291"/>
        <seriesInfo name="DOI" value="10.17487/RFC4291"/>
      </reference>
      <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862" quoteTitle="true" derivedAnchor="RFC4862">
        <front>
          <title>IPv6 Stateless Address Autoconfiguration</title>
          <author fullname="S. Thomson" initials="S." surname="Thomson"/>
          <author fullname="T. Narten" initials="T." surname="Narten"/>
          <author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
          <date month="September" year="2007"/>
          <abstract>
            <t indent="0">This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4862"/>
        <seriesInfo name="DOI" value="10.17487/RFC4862"/>
      </reference>
      <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973" quoteTitle="true" derivedAnchor="RFC6973">
        <front>
          <title>Privacy Considerations for Internet Protocols</title>
          <author fullname="A. Cooper" initials="A." surname="Cooper"/>
          <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
          <author fullname="B. Aboba" initials="B." surname="Aboba"/>
          <author fullname="J. Peterson" initials="J." surname="Peterson"/>
          <author fullname="J. Morris" initials="J." surname="Morris"/>
          <author fullname="M. Hansen" initials="M." surname="Hansen"/>
          <author fullname="R. Smith" initials="R." surname="Smith"/>
          <date month="July" year="2013"/>
          <abstract>
            <t indent="0">This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6973"/>
        <seriesInfo name="DOI" value="10.17487/RFC6973"/>
      </reference>
      <reference anchor="RFC7217" target="https://www.rfc-editor.org/info/rfc7217" quoteTitle="true" derivedAnchor="RFC7217">
        <front>
          <title>A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
          <author fullname="F. Gont" initials="F." surname="Gont"/>
          <date month="April" year="2014"/>
          <abstract>
            <t indent="0">This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7217"/>
        <seriesInfo name="DOI" value="10.17487/RFC7217"/>
      </reference>
      <reference anchor="RFC7844" target="https://www.rfc-editor.org/info/rfc7844" quoteTitle="true" derivedAnchor="RFC7844">
        <front>
          <title>Anonymity Profiles for DHCP Clients</title>
          <author fullname="C. Huitema" initials="C." surname="Huitema"/>
          <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
          <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
          <date month="May" year="2016"/>
          <abstract>
            <t indent="0">Some DHCP options carry unique identifiers. 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. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7844"/>
        <seriesInfo name="DOI" value="10.17487/RFC7844"/>
      </reference>
      <reference anchor="RFC8064" target="https://www.rfc-editor.org/info/rfc8064" quoteTitle="true" derivedAnchor="RFC8064">
        <front>
          <title>Recommendation on Stable IPv6 Interface Identifiers</title>
          <author fullname="F. Gont" initials="F." surname="Gont"/>
          <author fullname="A. Cooper" initials="A." surname="Cooper"/>
          <author fullname="D. Thaler" initials="D." surname="Thaler"/>
          <author fullname="W. Liu" initials="W." surname="Liu"/>
          <date month="February" year="2017"/>
          <abstract>
            <t indent="0">This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8064"/>
        <seriesInfo name="DOI" value="10.17487/RFC8064"/>
      </reference>
      <reference anchor="RFC8947" target="https://www.rfc-editor.org/info/rfc8947" quoteTitle="true" derivedAnchor="RFC8947">
        <front>
          <title>Link-Layer Address Assignment Mechanism for DHCPv6</title>
          <author fullname="B. Volz" initials="B." surname="Volz"/>
          <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
          <author fullname="CJ. Bernardos" initials="CJ." surname="Bernardos"/>
          <date month="December" year="2020"/>
          <abstract>
            <t indent="0">In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable. Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 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.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8947"/>
        <seriesInfo name="DOI" value="10.17487/RFC8947"/>
      </reference>
      <reference anchor="RFC8948" target="https://www.rfc-editor.org/info/rfc8948" quoteTitle="true" derivedAnchor="RFC8948">
        <front>
          <title>Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6</title>
          <author fullname="CJ. Bernardos" initials="CJ." surname="Bernardos"/>
          <author fullname="A. Mourad" initials="A." surname="Mourad"/>
          <date month="December" year="2020"/>
          <abstract>
            <t indent="0">The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.</t>
            <t indent="0">The IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.</t>
            <t indent="0">This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option (QUAD) is defined for this purpose.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8948"/>
        <seriesInfo name="DOI" value="10.17487/RFC8948"/>
      </reference>
      <reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8981" quoteTitle="true" derivedAnchor="RFC8981">
        <front>
          <title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
          <author fullname="F. Gont" initials="F." surname="Gont"/>
          <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
          <author fullname="T. Narten" initials="T." surname="Narten"/>
          <author fullname="R. Draves" initials="R." surname="Draves"/>
          <date month="February" year="2021"/>
          <abstract>
            <t indent="0">This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers 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. This document obsoletes RFC 4941.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8981"/>
        <seriesInfo name="DOI" value="10.17487/RFC8981"/>
      </reference>
      <reference anchor="strint" target="https://www.w3.org/2014/strint/" quoteTitle="true" derivedAnchor="strint">
        <front>
          <title>STRINT Workshop: A W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)</title>
          <author>
            <organization showOnFrontPage="true">W3C/IAB</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="wba_paper" target="https://wballiance.com/resource/wi-fi-device-identification-a-way-through-mac-randomization/" quoteTitle="true" derivedAnchor="wba_paper">
        <front>
          <title>Wi-Fi Device Identification - A Way Through MAC Randomization</title>
          <author>
            <organization showOnFrontPage="true">Wireless Broadband Alliance</organization>
          </author>
          <date month="July" year="2022"/>
        </front>
        <refcontent>WBA White Paper</refcontent>
      </reference>
      <reference anchor="when_mac_randomization_fails" quoteTitle="true" target="https://doi.org/10.48550/arXiv.1703.02874" derivedAnchor="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." surname="Rye" fullname="E. C. Rye">
           </author>
          <author initials="D." surname="Brown" fullname="D. Brown">
           </author>
          <date month="March" year="2017"/>
        </front>
        <refcontent>arXiv:1703.02874v2</refcontent>
        <seriesInfo name="DOI" value="10.48550/arXiv.1703.02874"/>
      </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" quoteTitle="true" derivedAnchor="wifi_tracking">
        <front>
          <title>London's bins are tracking your smartphone</title>
          <author fullname="James Vincent"/>
          <date day="9" month="August" year="2013"/>
        </front>
        <refcontent>The Independent</refcontent>
      </reference>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">
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>
      <t indent="0" pn="section-appendix.a-2">
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 (see <eref target="https://datatracker.ietf.org/liaison/1884/" brackets="angle"/>).
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
        <organization abbrev="Cisco" showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <city>Montreal</city>
            <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" showOnFrontPage="true">Universidad Carlos III de 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" showOnFrontPage="true">Safespring AB</organization>
        <address>
          <email>amelia.ietf@andersdotter.cc</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
