idnits 2.17.00 (12 Aug 2021) /tmp/idnits59765/draft-ietf-madinas-mac-address-randomization-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (6 March 2022) is 69 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MADINAS JC. Zuniga 3 Internet-Draft CISCO 4 Intended status: Informational CJ. Bernardos 5 Expires: 7 September 2022 UC3M 6 A. Andersdotter 7 Sky UK 8 6 March 2022 10 MAC address randomization 11 draft-ietf-madinas-mac-address-randomization-01 13 Abstract 15 Internet privacy has become a major concern over the past few years. 16 Users are becoming more aware that their online activity leaves a 17 vast digital footprint, that communications are not always properly 18 secured, and that their location and actions can be easily tracked. 19 One of the main factors for the location tracking issue is the wide 20 use of long-lasting identifiers, such as MAC addresses. 22 There have been several initiatives at the IETF and the IEEE 802 23 standards committees to overcome some of these privacy issues. This 24 document provides an overview of these activities, with the intention 25 to inform the technical community about them, and help coordinate 26 between present and future standardization activities. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 7 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. MAC address usage . . . . . . . . . . . . . . . . . . . . 3 65 3.2. MAC address randomization . . . . . . . . . . . . . . . . 4 66 3.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 67 802 meetings . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Recent RCM activities at the IEEE 802 . . . . . . . . . . . . 6 69 5. Recent MAC randomization-related activities at the WBA . . . 7 70 6. MAC randomization-related activities at the IETF . . . . . . 8 71 7. OS current practices . . . . . . . . . . . . . . . . . . . . 9 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 11.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Internet privacy is becoming a huge concern, as more and more mobile 83 devices are getting directly (e.g., via cellular or Wi-Fi) or 84 indirectly (e.g., via a smartphone using Bluetooth) connected to the 85 Internet. This ubiquitous connectivity, together with not very 86 secure protocol stacks and the lack of proper education about privacy 87 make it very easy to track/monitor the location of users and/or 88 eavesdrop their physical and online activities. This is due to many 89 factors, such as the vast digital footprint that users leave on the 90 Internet, for instance sharing information on social networks, 91 cookies used by browsers and servers to provide a better navigation 92 experience, connectivity logs that allow tracking of a user's Layer-2 93 (L2/MAC) or Layer-3 (L3) address, web trackers, etc.; and/or the weak 94 (or even null in some cases) authentication and encryption mechanisms 95 used to secure communications. 97 This privacy concern affects all layers of the protocol stack, from 98 the lower layers involved in the actual access to the network (e.g., 99 the MAC/Layer-2 and Layer-3 addresses can be used to obtain the 100 location of a user) to higher layer protocol identifiers and user 101 applications [wifi_internet_privacy]. In particular, IEEE 802 MAC 102 addresses have historically been an easy target for tracking users 103 [wifi_tracking]. 105 There have been several initiatives at the IETF and the IEEE 802 106 standards committees to overcome some of these privacy issues. This 107 document provides an overview of these activities, with the intention 108 to inform the community and help coordinate between present and 109 futures standardization activities. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 The following terms are used in this document: 119 MAC: Medium Access Control 121 3. Background 123 3.1. MAC address usage 125 Most mobile devices used today are Wi-Fi enabled (i.e. they are 126 equipped with an IEEE 802.11 wireless local area network interface). 127 Wi-Fi interfaces, as any other kind of IEEE 802-based network 128 interface, like Ethernet (i.e. IEEE 802.3) have a Layer-2 address 129 also referred to as MAC address, which can be seen by anybody who can 130 receive the signal transmitted by the network interface. The format 131 of these addresses is shown in Figure 1. 133 +--------+--------+---------+--------+--------+---------+ 134 | Organizationally Unique | Network Interface | 135 | Identifier (OUI) | Controller (NIC) Specific | 136 +--------+--------+---------+--------+--------+---------+ 137 / \ 138 / \ 139 / \ b0 (U/L bit): 140 / \ 0: unicast 141 / \ 1: multicast 142 / \ 143 / \ b1: 144 +--+--+--+--+--+--+--+--+ 0: globally unique (OUI enforced) 145 |b7|b6|b5|b4|b3|b2|b1|b0| 1: locally administered 146 +--+--+--+--+--+--+--+--+ 148 Figure 1: IEEE 802 MAC Address Format 150 MAC addresses can either be universally administered or locally 151 administered. Universally administered and locally administered 152 addresses are distinguished by setting the second-least-significant 153 bit of the most significant byte of the address (the U/L bit). 155 A universally administered address is uniquely assigned to a device 156 by its manufacturer. Most physical devices are provided with a 157 universally administered address, which is composed of two parts: (i) 158 the Organizationally Unique Identifier (OUI), which are the first 159 three octets in transmission order and identify the organization that 160 issued the identifier, and (ii) Network Interface Controller (NIC) 161 Specific, which are the following three octets, assigned by the 162 organization that manufactured the NIC, in such a way that the 163 resulting MAC address is globally unique. 165 Locally administered addresses override the burned-in address, and 166 they can either be set-up by the network administrator, or by the 167 Operating System (OS) of the device to which the address pertains. 168 However, as explained in further sections of this document, there are 169 new initiatives at the IEEE 802 and other organizations to specify 170 ways in which these locally administered addresses should be 171 assigned, depending on the use case. 173 3.2. MAC address randomization 175 Since universally administered MAC addresses are by definition 176 globally-unique, when a device uses this MAC address to transmit data 177 -especially over the air- it is relatively easy to track this device 178 by simple medium observation. Since a device is usually directly 179 associated to an individual, this poses a privacy concern 180 [link_layer_privacy]. 182 MAC addresses can be easily observed by a third party, such as a 183 passive device listening to communications in the same network. In 184 an 802.11 network, a station exposes its MAC address in two different 185 situations: 187 * While actively scanning for available networks, the MAC address is 188 used in the Probe Request frames sent by the device (aka IEEE 189 802.11 STA). 191 * Once associated to a given Access Point (AP), the MAC address is 192 used in frame transmission and reception, as one of the addresses 193 used in the address fields of an IEEE 802.11 frame. 195 One way to overcome this privacy concern is by using randomly 196 generated MAC addresses. As described in the previous section, the 197 IEEE 802 addressing includes one bit to specify if the hardware 198 address is locally or globally administered. This allows generating 199 local addresses without the need of any global coordination mechanism 200 to ensure that the generated address is still unique within the local 201 network. This feature can be used to generate random addresses, 202 which decouple the globally-unique identifier from the device and 203 therefore make it more difficult to track a user device from its MAC/ 204 L2 address [enhancing_location_privacy]. 206 3.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802 207 meetings 209 As an outcome to the STRINT W3C/IAB Workshop [strint], on July 2014 a 210 Tutorial on Pervasive Surveillance of the Internet - Designing 211 Privacy into Internet Protocols was given at the IEEE 802 Plenary 212 meeting in San Diego [privacy_tutorial]. The Tutorial provided an 213 update on the recent developments regarding Internet privacy, the 214 actions that other SDOs such as IETF were taking, and guidelines that 215 were being followed when developing new Internet protocol 216 specifications (e.g. [RFC6973]). The Tutorial highlighted some 217 Privacy concerns applicable specifically to Link Layer technologies 218 and provided suggestions on how IEEE 802 could help addressing them. 220 Following the discussions and interest within the IEEE 802 community, 221 on 18 July 2014 the IEEE 802 Executive Committee (EC) created an IEEE 222 802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. 223 The work and discussions from the group have generated multiple 224 outcomes, such as: 802E PAR: Recommended Practice for Privacy 225 Considerations for IEEE 802 Technologies [IEEE_802E], and the 802c 226 PAR: Standard for Local and Metropolitan Area Networks - Overview and 227 Architecture Amendment - Local Medium Access Control (MAC) Address 228 Usage [IEEE_802c]. 230 In order to test the effects of MAC address randomization, major 231 trials were conducted at the IETF and IEEE 802 meetings between 232 November 2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in 233 Berlin. The purpose of the experiments was to evaluate the use of 234 MAC address randomization from two different perspectives: (i) the 235 effect on the connectivity experience of the end-user, also checking 236 if applications and operating systems (OSs) were affected; and (ii) 237 the potential impact on the network infrastructure itself. Some of 238 the findings were published in [wifi_internet_privacy]. 240 During the experiments it was observed that the probability of 241 address duplication in a network with this characteristics is 242 negligible. The experiments also showed that other protocol 243 identifiers can be correlated and therefore be used to still track an 244 individual. Hence, effective privacy tools should not work in 245 isolation at a single layer, but they should be coordinated with 246 other privacy features at higher layers. 248 Since then, MAC randomization has further been implemented by mobile 249 operating systems to provide better privacy for mobile phone users 250 when connecting to public wireless networks [privacy_ios], 251 [privacy_windows], [privacy_android]. 253 4. Recent RCM activities at the IEEE 802 255 Practical experiences of Randomized And Changing MAC Addresses (RCM) 256 in live devices helped researchers fine-tune their understanding of 257 attacks against randomization mechanisms 258 [when_mac_randomization_fails]. At IEEE 802.11 these research 259 experiences eventually formed the basis for a specified mechanism 260 introduced in the IEEE 802.11aq in 2018 which randomize MAC addresses 261 that recommends mechanisms to avoid pitfalls [IEEE_802_11_aq]. 263 More recent developments include turning on MAC randomization in 264 mobile operating systems by default, which has an impact on the 265 ability of network operators to personalize or customize services 266 [rcm_user_experience_csd]. Therefore, follow-on work in the IEEE 267 802.11 mapped effects of potentially large uptake of randomized MAC 268 identifiers on a number of commonly offered operator services in 269 2019[rcm_tig_final_report]. In the summer of 2020 this work emanated 270 in two new standards projects with the purpose of developing 271 mechanisms that do not decrease user privacy and enable an optimal 272 user experience when the MAC address of a device in an Extended 273 Service Set is randomized or changes [rcm_user_experience_par] and 274 user privacy solutions applicable to IEEE Std 802.11 275 [rcm_privacy_par]. 277 The IEEE 802.1 working group has also published a specification that 278 defines a local MAC address space structure, known as the Structured 279 Local Address Plan (SLAP). This structure designates a range of 280 local MAC addresses for protocols using a Company ID (CID) assigned 281 by the IEEE Registration Authority. Another range of local MAC 282 addresses is designated for assignment by administrators. The 283 specification recommends a range of local MAC addresses for use by 284 IEEE 802 protocols [IEEE_802c]. 286 Work within the IEEE 802.1 Security task group on privacy 287 recommendations for all IEEE 802 network technologies has also looked 288 into general recommendations on identifiers, reaching the conclusion 289 that temporary and transient identifiers are preferably in network 290 technology design if there are no compelling reasons of service 291 quality for a newly introduced identifier to be permanent. This work 292 has been specified in the recently published IEEE P802E: Recommended 293 Practice for Privacy Considerations for IEEE 802 Technologies 294 [IEEE_802E]. The IEEE P802E specification will form part of the 295 basis for the review of user privacy solutions applicable to IEEE Std 296 802.11 (aka Wi-Fi) devices as part of the RCM [rcm_privacy_csd] 297 efforts. 299 Currently, two task groups in IEEE 802.11 are dealing with issues 300 related to RCM: 302 * The IEEE 802.11bh task group, looking at mitigating the 303 repercussions that RCM creates on 802.11 networks and related 304 services, and 306 * The IEEE 802.11bi task group, which will define modifications to 307 the IEEE Std 802.11 medium access control (MAC) specification to 308 specify new mechanisms that address and improve user privacy. 310 5. Recent MAC randomization-related activities at the WBA 312 At the Wireless Broadband Alliance (WBA), the Testing and 313 Interoperability Work Group has been looking at the issues related to 314 MAC address randomization and has identified a list of potential 315 impacts of these changes to existing systems and solutions, mainly 316 related to Wi-Fi identification. 318 As part of this work, WBA has documented a set of use cases that a 319 Wi-Fi Identification Standard should address in order to scale and 320 achieve longer term sustainability of deployed services. A first 321 version of this document has been liaised with the IETF as part of 322 the MAC Address Device Identification for Network and Application 323 Services (MADINAS) activities through the "Wi-Fi Identification In a 324 post MAC Randomization Era v1.0" paper [wba_paper]. 326 6. MAC randomization-related activities at the IETF 328 Several IP address assignment mechanisms such as the IPv6 stateless 329 autoconfiguration techniques (SLAAC) [RFC4862] generate the Interface 330 Identifier (IID) of the address from its MAC address (via EUI64), 331 which then becomes visible to all IPv6 communication peers. This 332 potentially allows for global tracking of a device at L3 from any 333 point on the Internet. Besides, the prefix part of the address 334 provides meaningful insights of the physical location of the device 335 in general, which together with the MAC address-based IID, makes it 336 easier to perform global device tracking. 338 There are some solutions that might mitigate this privacy threat, 339 such as the use of temporary addresses [RFC4191], the use of opaque 340 IIDs [RFC7217], [I-D.gont-6man-deprecate-eui64-based-addresses]. 341 Next, we briefly describe how these solutions work. 343 [RFC4191] identifies and describes the privacy issues associated with 344 embedding MAC stable addressing information into the IPv6 addresses 345 (as part of the IID) and describes some mechanisms to mitigate the 346 associated problems. The specification is meant for IPv6 nodes that 347 auto-configure IPv6 addresses based on the MAC address (EUI-64 348 mechanism). It defines how to create additional addresses (generally 349 known as "temporary addresses") based on a random interface 350 identifier for the purpose of initiating outgoing sessions. These 351 "random" or temporary addresses are meant to be used for a short 352 period of time (hours to days) and would then be deprecated. 353 Deprecated addresses can continue to be used for already established 354 connections, but are not used to initiate new connections. New 355 temporary addresses are generated periodically to replace temporary 356 addresses that expire. In order to do so, a node produces a sequence 357 of temporary global scope addresses from a sequence of interface 358 identifiers that appear to be random in the sense that it is 359 difficult for an outside observer to predict a future address (or 360 identifier) based on a current one, and it is difficult to determine 361 previous addresses (or identifiers) knowing only the present one. 362 The main problem with the temporary addresses is that they should not 363 be used by applications that listen for incoming connections (as 364 these are supposed to be waiting on permanent/well-known 365 identifiers). Besides, if a node changes network and comes back to a 366 previously visited one, the temporary addresses that the node would 367 use will be different, and this might be an issue in certain networks 368 where addresses are used for operational purposes (e.g., filtering or 369 authentication). [RFC7217], summarized next, partially addresses the 370 problems aforementioned. 372 [RFC7217] defines a method for generating IPv6 IIDs to be used with 373 IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 374 address configured using this method is stable within each subnet, 375 but the corresponding IID changes when the host moves from one 376 network to another. This method is meant to be an alternative to 377 generating Interface Identifiers based on MAC addresses, such that 378 the benefits of stable addresses can be achieved without sacrificing 379 the security and privacy of users. The method defined to generate 380 the IPv6 IID is based on computing a hash function which takes as 381 input information that is stable and associated to the interface 382 (e.g., MAC address or local interface identifier), stable information 383 associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 384 prefix, and a secret key, plus some other additional information. 385 This basically ensures that a different IID is generated when any of 386 the input fields changes (such as the network or the prefix), but 387 that the IID is the same within each subnet. 389 In addition to the former documents, [RFC8947] proposes an extension 390 to DHCPv6 that allows a scalable approach to link-layer address 391 assignments where preassigned link-layer address assignments (such as 392 by a manufacturer) are not possible or unnecessary. [RFC8948] 393 proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or 394 a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, 395 so that the server may allocate MAC addresses in the quadrant 396 requested by the relay or client. 398 Not only MAC and IP addresses can be used for tracking purposes. 399 Some DHCP options carry unique identifiers. These identifiers can 400 enable device tracking even if the device administrator takes care of 401 randomizing other potential identifications like link-layer addresses 402 or IPv6 addresses. [RFC7844] introduces anonymity profiles, designed 403 for clients that wish to remain anonymous to the visited network. 404 The profiles provide guidelines on the composition of DHCP or DHCPv6 405 messages, designed to minimize disclosure of identifying information. 406 [RFC7844] also indicates that the link-layer address, IP address, and 407 DHCP identifier shall evolve in synchrony. 409 7. OS current practices 411 Most modern OSes (especially mobile ones) do implement by default 412 some MAC address randomization policy. Table 1 summarizes current 413 practices for Androiod and iOS, as the time of writing this document 414 (original source: https://www.fing.com/news/private-mac-address-on- 415 ios-14, updated based on findings from the authors). 417 +=============================================+===================+ 418 | Android 10+ | iOS 14+ | 419 +=============================================+===================+ 420 | The randomized MAC address is bound to the | The randomized | 421 | SSID | MAC address is | 422 | | bound to the | 423 | | BSSID | 424 +---------------------------------------------+-------------------+ 425 +---------------------------------------------+-------------------+ 426 | The randomized MAC address is stable across | The randomized | 427 | reconnections for the same network | MAC address is | 428 | | stable across | 429 | | reconnections for | 430 | | the same network | 431 +---------------------------------------------+-------------------+ 432 +---------------------------------------------+-------------------+ 433 | The randomized MAC address does not get re- | The randomized | 434 | randomized when the device forgets a WiFI | MAC address is | 435 | network | reset when the | 436 | | device forgets a | 437 | | WiFI network | 438 +---------------------------------------------+-------------------+ 439 +---------------------------------------------+-------------------+ 440 | MAC address randomization is enabled by | MAC address | 441 | default for all the new WiFi networks. But | randomization is | 442 | if the device previously connected to a | enabled by | 443 | WiFi network identifying itself with the | default for all | 444 | real MAC address, no randomized MAC address | the new WiFi | 445 | will be used (unless manually enabled) | networks | 446 +---------------------------------------------+-------------------+ 448 Table 1: Android and iOS MAC address randomization practices 450 In September 2021, we have performed some additional tests to 451 evaluate how most widely used OSes behave regarfing MAC address 452 randomization. Table 2 summarizes our findings, where show on 453 different rows whether the OS performs address randomization per 454 network, per new connection, daily, supports configuration per SSID, 455 supports address randomization for scanning, and whether it does that 456 by default. 458 +====================+=======+============+============+=========+ 459 | OS | Linux | Android 10 | Windows 10 | iOS 14+ | 460 +====================+=======+============+============+=========+ 461 | Random per net. | Y | Y | Y | Y | 462 +--------------------+-------+------------+------------+---------+ 463 +--------------------+-------+------------+------------+---------+ 464 | Random per connec. | Y | N | N | N | 465 +--------------------+-------+------------+------------+---------+ 466 +--------------------+-------+------------+------------+---------+ 467 | Random daily | N | N | Y | N | 468 +--------------------+-------+------------+------------+---------+ 469 +--------------------+-------+------------+------------+---------+ 470 | SSID config. | Y | N | N | N | 471 +--------------------+-------+------------+------------+---------+ 472 +--------------------+-------+------------+------------+---------+ 473 | Random. for scan | Y | Y | Y | Y | 474 +--------------------+-------+------------+------------+---------+ 475 +--------------------+-------+------------+------------+---------+ 476 | Random. for scan | N | Y | N | Y | 477 | by default | | | | | 478 +--------------------+-------+------------+------------+---------+ 480 Table 2: Observed behavior from different OS (as of September 481 2022) 483 According to [privacy_android], starting in Android 12, Android uses 484 non-persistent randomization in the following situations: (i) a 485 network suggestion app specifies that non-persistant randomization be 486 used for the network (through an API); or (ii) the network is an open 487 network that hasn't encountered a captive portal and an internal 488 config option is set to do so (by default it is not). 490 8. IANA Considerations 492 N/A. 494 9. Security Considerations 496 TBD. 498 10. Acknowledgments 500 Authors would like to thank Guillermo Sanchez Illan for the extensive 501 tests performed on different OSes to analyze their behavior regarding 502 address randomization. 504 Authors would like to thank Jerome Henry and Hai Shalom for their 505 review and comments on previous versions of this document. 507 11. References 509 11.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 11.2. Informative References 518 [enhancing_location_privacy] 519 Gruteser, M. and D. Grunwald, "Enhancing location privacy 520 in wireless LAN through disposable interface identifiers: 521 a quantitative analysis", Mobile Networks and 522 Applications, vol. 10, no. 3, pp. 315-325 , 2005. 524 [I-D.gont-6man-deprecate-eui64-based-addresses] 525 Gont, F., Cooper, A., Thaler, D., and W. Liu, "Deprecating 526 EUI-64 Based IPv6 Addresses", Work in Progress, Internet- 527 Draft, draft-gont-6man-deprecate-eui64-based-addresses-00, 528 21 October 2013, . 531 [IEEE_802c] 532 architecture, 8. W. -. 8. L., "IEEE 802c-2017 - IEEE 533 Standard for Local and Metropolitan Area Networks:Overview 534 and Architecture--Amendment 2: Local Medium Access Control 535 (MAC) Address Usage", IEEE 802c , 2017. 537 [IEEE_802E] 538 architecture, 8. W. -. 8. L., "IEEE 802E-2020 - IEEE 539 Recommended Practice for Privacy Considerations for IEEE 540 802 Technologies", IEEE 802E , 2020. 542 [IEEE_802_11_aq] 543 Group, 8. W. -. W. L. W., "IEEE 802.11aq-2018 - IEEE 544 Standard for Information technology--Telecommunications 545 and information exchange between systems Local and 546 metropolitan area networks--Specific requirements Part 11: 547 Wireless LAN Medium Access Control (MAC) and Physical 548 Layer (PHY) Specifications Amendment 5: Preassociation 549 Discovery", IEEE 802.11 , 2018. 551 [ieee_privacy_ecsg] 552 IEEE 802 Privacy EC SG, "IEEE 802 EC Privacy 553 Recommendation Study Group", 554 . 556 [link_layer_privacy] 557 O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the 558 link layer", Contribution at W3C/IAB workshop on 559 Strengthening the Internet Against Pervasive Monitoring 560 (STRINT) , February 2014. 562 [privacy_android] 563 Android Open Source Project, "MAC Randomization Behavior", 564 . 567 [privacy_ios] 568 Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14, 569 and watchOS 7", 570 . 572 [privacy_tutorial] 573 Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P. 574 O'Hanlon, "Tutorial on Pervasive Surveillance of the 575 Internet - Designing Privacy into Internet Protocols", 576 . 579 [privacy_windows] 580 Microsoft, "Windows: How to use random hardware 581 addresses", . 585 [rcm_privacy_csd] 586 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 587 Addresses Study Group CSD on user experience mechanisms", 588 doc.:IEEE 802.11-20/1346r1 , 2020. 590 [rcm_privacy_par] 591 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 592 Addresses Study Group PAR on privacy mechanisms", 593 doc.:IEEE 802.11-19/854r7 , 2020. 595 [rcm_tig_final_report] 596 TIG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 597 Addresses Topic Interest Group Report", doc.:IEEE 598 802.11-19/1442r9 , 2019. 600 [rcm_user_experience_csd] 601 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 602 Addresses Study Group CSD on user experience mechanisms", 603 doc.:IEEE 802.11-20/1117r3 , 2020. 605 [rcm_user_experience_par] 606 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 607 Addresses Study Group PAR on user experience mechanisms", 608 doc.:IEEE 802.11-20/742r5 , 2020. 610 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 611 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 612 November 2005, . 614 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 615 Address Autoconfiguration", RFC 4862, 616 DOI 10.17487/RFC4862, September 2007, 617 . 619 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 620 Morris, J., Hansen, M., and R. Smith, "Privacy 621 Considerations for Internet Protocols", RFC 6973, 622 DOI 10.17487/RFC6973, July 2013, 623 . 625 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 626 Interface Identifiers with IPv6 Stateless Address 627 Autoconfiguration (SLAAC)", RFC 7217, 628 DOI 10.17487/RFC7217, April 2014, 629 . 631 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 632 Profiles for DHCP Clients", RFC 7844, 633 DOI 10.17487/RFC7844, May 2016, 634 . 636 [RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer 637 Address Assignment Mechanism for DHCPv6", RFC 8947, 638 DOI 10.17487/RFC8947, December 2020, 639 . 641 [RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address 642 Plan (SLAP) Quadrant Selection Option for DHCPv6", 643 RFC 8948, DOI 10.17487/RFC8948, December 2020, 644 . 646 [strint] W3C/IAB, "A W3C/IAB workshop on Strengthening the Internet 647 Against Pervasive Monitoring (STRINT)", 648 . 650 [wba_paper] 651 Alliance, W. B., "Wi-Fi Identification Scope for Liasing - 652 In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro: 653 Post MAC Randomization Era v1.0 - IETF liaison , March 654 2020. 656 [when_mac_randomization_fails] 657 Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown, 658 L., Riggins, C., Rye, E.C., and D. Brown, "A Study of MAC 659 Address Randomization in Mobile Devices and When it 660 Fails", arXiv:1703.02874v2 [cs.CR] , 2017. 662 [wifi_internet_privacy] 663 Bernardos, CJ., Zúñiga, JC., and P. O'Hanlon, "Wi-Fi 664 Internet Connectivity and Privacy: Hiding your tracks on 665 the wireless Internet", Standards for Communications and 666 Networking (CSCN), 2015 IEEE Conference on , October 2015. 668 [wifi_tracking] 669 The Independent, "London's bins are tracking your 670 smartphone", . 674 Authors' Addresses 676 Juan Carlos Zuniga 677 CISCO 678 Montreal QC 679 Canada 680 Email: juzuniga@cisco.com 682 Carlos J. Bernardos 683 Universidad Carlos III de Madrid 684 Av. Universidad, 30 685 28911 Leganes, Madrid 686 Spain 687 Phone: +34 91624 6236 688 Email: cjbc@it.uc3m.es 689 URI: http://www.it.uc3m.es/cjbc/ 690 Amelia Andersdotter 691 Sky UK Group, Sky Labs 692 Chatham Way 693 Brentwood 694 CM14 4DZ 695 United Kingdom 696 Email: amelia.ietf@andersdotter.cc