idnits 2.17.1 draft-zuniga-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 12, 2021) is 1018 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 Network Working Group JC. Zuniga 3 Internet-Draft SIGFOX 4 Intended status: Informational CJ. Bernardos 5 Expires: January 13, 2022 UC3M 6 A. Andersdotter 7 CENTR 8 July 12, 2021 10 MAC address randomization 11 draft-zuniga-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 futures 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 January 13, 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. MAC address usage . . . . . . . . . . . . . . . . . . . . 3 66 3.2. MAC address randomization . . . . . . . . . . . . . . . . 4 67 3.3. Privacy Workshop, Tutorial and Experiments at IETF and 68 IEEE 802 meetings . . . . . . . . . . . . . . . . . . . . 5 69 4. Recent RCM activities at the IEEE 802 . . . . . . . . . . . . 6 70 5. Recent MAC randomization-related activities at the WBA . . . 7 71 6. MAC randomization-related activities at the IETF . . . . . . 7 72 7. OS current practices . . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Internet privacy is becoming a huge concern, as more and more mobile 84 devices are getting directly (e.g., via cellular or Wi-Fi) or 85 indirectly (e.g., via a smartphone using Bluetooth) connected to the 86 Internet. This ubiquitous connectivity, together with not very 87 secure protocol stacks and the lack of proper education about privacy 88 make it very easy to track/monitor the location of users and/or 89 eavesdrop their physical and online activities. This is due to many 90 factors, such as the vast digital footprint that users leave on the 91 Internet, for instance sharing information on social networks, 92 cookies used by browsers and servers to provide a better navigation 93 experience, connectivity logs that allow tracking of a user's Layer-2 94 (L2/MAC) or Layer-3 (L3) address, web trackers, etc.; and/or the weak 95 (or even null in some cases) authentication and encryption mechanisms 96 used to secure communications. 98 This privacy concern affects all layers of the protocol stack, from 99 the lower layers involved in the actual access to the network (e.g., 100 the MAC/Layer-2 and Layer-3 addresses can be used to obtain the 101 location of a user) to higher layer protocol identifiers and user 102 applications [wifi_internet_privacy]. In particular, IEEE 802 MAC 103 addresses have historically been an easy target for tracking users 104 [wifi_tracking]. 106 There have been several initiatives at the IETF and the IEEE 802 107 standards committees to overcome some of these privacy issues. This 108 document provides an overview of these activities, with the intention 109 to inform the community and help coordinate between present and 110 futures standardization activities. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 The following terms are used in this document: 120 MAC: Medium Access Control 122 3. Background 124 3.1. MAC address usage 126 Most mobile devices used today are Wi-Fi enabled (i.e. they are 127 equipped with an IEEE 802.11 wireless local area network interface). 128 Wi-Fi interfaces, as any other kind of IEEE 802-based network 129 interface, like Ethernet (i.e. IEEE 802.3) have a Layer-2 address 130 also referred to as MAC address, which can be seen by anybody who can 131 receive the signal transmitted by the network interface. The format 132 of these addresses is shown in Figure 1. 134 Figure 1: IEEE 802 MAC Address Format (TBD) 136 MAC addresses can either be universally administered or locally 137 administered. Universally administered and locally administered 138 addresses are distinguished by setting the second-least-significant 139 bit of the most significant byte of the address (the U/L bit). 141 A universally administered address is uniquely assigned to a device 142 by its manufacturer. Most physical devices are provided with a 143 universally administered address, which is composed of two parts: (i) 144 the Organizationally Unique Identifier (OUI), which are the first 145 three octets in transmission order and identify the organization that 146 issued the identifier, and (ii) Network Interface Controller (NIC) 147 Specific, which are the following three octets, assigned by the 148 organization that manufactured the NIC, in such a way that the 149 resulting MAC address is globally unique. 151 Locally administered addresses override the burned-in address, and 152 they can either be set-up by the network administrator, or by the 153 Operating System (OS) of the device to which the address pertains. 154 However, as explained in further sections of this document, there are 155 new initiatives at the IEEE 802 and other organizations to specify 156 ways in which these locally administered addresses should be 157 assigned, depending on the use case. 159 3.2. MAC address randomization 161 Since universally administered MAC addresses are by definition 162 globally-unique, when a device uses this MAC address to transmit data 163 -especially over the air- it is relatively easy to track this device 164 by simple medium observation. Since a device is usually directly 165 associated to an individual, this poses a privacy concern 166 [link_layer_privacy]. 168 MAC addresses can be easily observed by a third party, such as a 169 passive device listening to communications in the same network. In 170 an 802.11 network, a station exposes its MAC address in two different 171 situations: 173 o While actively scanning for available networks, the MAC address is 174 used in the Probe Request frames sent by the device (aka IEEE 175 802.11 STA). 177 o Once associated to a given Access Point (AP), the MAC address is 178 used in frame transmission and reception, as one of the addresses 179 used in the address fields of an IEEE 802.11 frame. 181 One way to overcome this privacy concern is by using randomly 182 generated MAC addresses. As described in the previous section, the 183 IEEE 802 addressing includes one bit to specify if the hardware 184 address is locally or globally administered. This allows generating 185 local addresses without the need of any global coordination mechanism 186 to ensure that the generated address is still unique within the local 187 network. This feature can be used to generate random addresses, 188 which decouple the globally-unique identifier from the device and 189 therefore make it more difficult to track a user device from its MAC/ 190 L2 address [enhancing_location_privacy]. 192 3.3. Privacy Workshop, Tutorial and Experiments at IETF and IEEE 802 193 meetings 195 As an outcome to the STRINT W3C/IAB Workshop [strint], on July 2014 a 196 Tutorial on Pervasive Surveillance of the Internet - Designing 197 Privacy into Internet Protocols was given at the IEEE 802 Plenary 198 meeting in San Diego [privacy_tutorial]. The Tutorial provided an 199 update on the recent developments regarding Internet privacy, the 200 actions that other SDOs such as IETF were taking, and guidelines that 201 were being followed when developing new Internet protocol 202 specifications (e.g. [RFC6973]). The Tutorial highlighted some 203 Privacy concerns applicable specifically to Link Layer technologies 204 and provided suggestions on how IEEE 802 could help addressing them. 206 Following the discussions and interest within the IEEE 802 community, 207 on 18 July 2014 the IEEE 802 Executive Committee (EC) created an IEEE 208 802 EC Privacy Recommendation Study Group (SG) [ieee_privacy_ecsg]. 209 The work and discussions from the group have generated multiple 210 outcomes, such as: 802E PAR: Recommended Practice for Privacy 211 Considerations for IEEE 802 Technologies [IEEE_802E], and the 802c 212 PAR: Standard for Local and Metropolitan Area Networks - Overview and 213 Architecture Amendment - Local Medium Access Control (MAC) Address 214 Usage [IEEE_802c]. 216 In order to test the effects of MAC address randomization, major 217 trials were conducted at the IETF and IEEE 802 meetings between 218 November 2014 and March 2015 - IETF91, IETF92 and IEEE 802 Plenary in 219 Berlin. The purpose of the experiments was to evaluate the use of 220 MAC address randomization from two different perspectives: (i) the 221 effect on the connectivity experience of the end-user, also checking 222 if applications and operating systems (OSs) were affected; and (ii) 223 the potential impact on the network infrastructure itself. Some of 224 the findings were published in [wifi_internet_privacy]. 226 During the experiments it was observed that the probability of 227 address duplication in a network with this characteristics is 228 negligible. The experiments also showed that other protocol 229 identifiers can be correlated and therefore be used to still track an 230 individual. Hence, effective privacy tools should not work in 231 isolation at a single layer, but they should be coordinated with 232 other privacy features at higher layers. 234 Since then, MAC randomization has further been implemented by mobile 235 operating systems to provide better privacy for mobile phone users 236 when connecting to public wireless networks [privacy_ios], 237 [privacy_windows], [privacy_android]. 239 4. Recent RCM activities at the IEEE 802 241 Practical experiences of Randomized And Changing MAC Addresses (RCM) 242 in live devices helped researchers fine-tune their understanding of 243 attacks against randomization mechanisms 244 [when_mac_randomization_fails]. At IEEE 802.11 these research 245 experiences eventually formed the basis for a specified mechanism 246 introduced in the IEEE 802.11aq in 2018 which randomize MAC addresses 247 that recommends mechanisms to avoid pitfalls [IEEE_802_11_aq]. 249 More recent developments include turning on MAC randomization in 250 mobile operating systems by default, which has an impact on the 251 ability of network operators to personalize or customize services 252 [rcm_user_experience_csd]. Therefore, follow-on work in the IEEE 253 802.11 mapped effects of potentially large uptake of randomized MAC 254 identifiers on a number of commonly offered operator services in 255 2019[rcm_tig_final_report]. In the summer of 2020 this work emanated 256 in two new standards projects with the purpose of developing 257 mechanisms that do not decrease user privacy and enable an optimal 258 user experience when the MAC address of a device in an Extended 259 Service Set is randomized or changes [rcm_user_experience_par] and 260 user privacy solutions applicable to IEEE Std 802.11 261 [rcm_privacy_par]. 263 The IEEE 802.1 working group has also published a specification that 264 defines a local MAC address space structure, known as the Structured 265 Local Address Plan (SLAP). This structure designates a range of 266 local MAC addresses for protocols using a Company ID (CID) assigned 267 by the IEEE Registration Authority. Another range of local MAC 268 addresses is designated for assignment by administrators. The 269 specification recommends a range of local MAC addresses for use by 270 IEEE 802 protocols [IEEE_802c]. 272 Work within the IEEE 802.1 Security task group on privacy 273 recommendations for all IEEE 802 network technologies has also looked 274 into general recommendations on identifiers, reaching the conclusion 275 that temporary and transient identifiers are preferably in network 276 technology design if there are no compelling reasons of service 277 quality for a newly introduced identifier to be permanent. This work 278 has been specified in the recently published IEEE P802E: Recommended 279 Practice for Privacy Considerations for IEEE 802 Technologies 280 [IEEE_802E]. The IEEE P802E specification will form part of the 281 basis for the review of user privacy solutions applicable to IEEE Std 282 802.11 (aka Wi-Fi) devices as part of the RCM [rcm_privacy_csd] 283 efforts. 285 Currently, two task groups in IEEE 802.11 are dealing with issues 286 related to RCM: 288 o The IEEE 802.11bh task group, looking at mitigating the 289 repercussions that RCM creates on 802.11 networks and related 290 services, and 292 o The IEEE 802.11bi task group, which will define modifications to 293 the IEEE Std 802.11 medium access control (MAC) specification to 294 specify new mechanisms that address and improve user privacy. 296 5. Recent MAC randomization-related activities at the WBA 298 At the Wireless Broadband Alliance (WBA), the Testing and 299 Interoperability Work Group has been looking at the issues related to 300 MAC address randomization and has identified a list of potential 301 impacts of these changes to existing systems and solutions, mainly 302 realted to Wi-Fi identification. 304 As part of this work, WBA has documented a set of use cases that a 305 Wi-Fi Identification Standard should address in order to scale and 306 achieve longer term sustainability of deployed services. A first 307 version of this document has been liaised with the IETF as part of 308 the MAC Address Device Identification for Network and Application 309 Services (MADINAS) activities through the "Wi-Fi Identification In a 310 post MAC Randomization Era v1.0" paper [wba_paper]. 312 6. MAC randomization-related activities at the IETF 314 Several IP address assignment mechanisms such as the IPv6 stateless 315 autoconfiguration techniques (SLAAC) [RFC4862] generate the Interface 316 Identifier (IID) of the address from its MAC address (via EUI64), 317 which then becomes visible to all IPv6 communication peers. This 318 potentially allows for global tracking of a device at L3 from any 319 point on the Internet. Besides, the prefix part of the address 320 provides meaningful insights of the physical location of the device 321 in general, which together with the MAC address-based IID, makes it 322 easier to perform global device tracking. 324 There are some solutions that might mitigate this privacy threat, 325 such as the use of temporary addresses [RFC4191], the use of opaque 326 IIDs [RFC7217], [I-D.gont-6man-deprecate-eui64-based-addresses]. 327 Next, we briefly describe how these solutions work. 329 [RFC4191] identifies and describes the privacy issues associated with 330 embedding MAC stable addressing information into the IPv6 addresses 331 (as part of the IID) and describes some mechanisms to mitigate the 332 associated problems. The specification is meant for IPv6 nodes that 333 auto-configure IPv6 addresses based on the MAC address (EUI-64 334 mechanism). It defines how to create additional addresses (generally 335 known as "temporary addresses") based on a random interface 336 identifier for the purpose of initiating outgoing sessions. These 337 "random" or temporary addresses are meant to be used for a short 338 period of time (hours to days) and would then be deprecated. 339 Deprecated addresses can continue to be used for already established 340 connections, but are not used to initiate new connections. New 341 temporary addresses are generated periodically to replace temporary 342 addresses that expire. In order to do so, a node produces a sequence 343 of temporary global scope addresses from a sequence of interface 344 identifiers that appear to be random in the sense that it is 345 difficult for an outside observer to predict a future address (or 346 identifier) based on a current one, and it is difficult to determine 347 previous addresses (or identifiers) knowing only the present one. 348 The main problem with the temporary addresses is that they should not 349 be used by applications that listen for incoming connections (as 350 these are supposed to be waiting on permanent/well-known 351 identifiers). Besides, if a node changes network and comes back to a 352 previously visited one, the temporary addresses that the node would 353 use will be different, and this might be an issue in certain networks 354 where addresses are used for operational purposes (e.g., filtering or 355 authentication). [RFC7217], summarized next, partially addresses the 356 problems aforementioned. 358 [RFC7217] defines a method for generating IPv6 IIDs to be used with 359 IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 360 address configured using this method is stable within each subnet, 361 but the corresponding IID changes when the host moves from one 362 network to another. This method is meant to be an alternative to 363 generating Interface Identifiers based on MAC addresses, such that 364 the benefits of stable addresses can be achieved without sacrificing 365 the security and privacy of users. The method defined to generate 366 the IPv6 IID is based on computing a hash function which takes as 367 input information that is stable and associated to the interface 368 (e.g., MAC address or local interface identifier), stable information 369 associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6 370 prefix, and a secret key, plus some other additional information. 371 This basically ensures that a different IID is generated when any of 372 the input fields changes (such as the network or the prefix), but 373 that the IID is the same within each subnet. 375 In addition to the former documents, [I-D.ietf-dhc-mac-assign] 376 proposes an extension to DHCPv6 that allows a scalable approach to 377 link-layer address assignments where preassigned link-layer address 378 assignments (such as by a manufacturer) are not possible or 379 unnecessary. [I-D.ietf-dhc-slap-quadrant] proposes extensions to 380 DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to 381 indicate a preferred SLAP quadrant to the server, so that the server 382 may allocate MAC addresses in the quadrant requested by the relay or 383 client. 385 Not only MAC and IP addresses can be used for tracking purposes. 386 Some DHCP options carry unique identifiers. These identifiers can 387 enable device tracking even if the device administrator takes care of 388 randomizing other potential identifications like link-layer addresses 389 or IPv6 addresses. [RFC7844] introduces anonymity profiles, designed 390 for clients that wish to remain anonymous to the visited network. 391 The profiles provide guidelines on the composition of DHCP or DHCPv6 392 messages, designed to minimize disclosure of identifying information. 393 [RFC7844] also indicates that the link-layer address, IP address, and 394 DHCP identifier shall evolve in synchrony. 396 Lately, the MAC Address Device Identification for Network and 397 Application Services (MADINAS) IETF BoF has discussed the need to 398 examine the effect of RCM schemes on network and application services 399 in several scenarios identified as relevant. 401 7. OS current practices 403 Most modern OSes (especially mobile ones) do implement by default 404 some MAC address randomization policy. Table 1 summarizes current 405 practices for Androiod and iOS, as the time of writing this document 406 (original source: https://www.fing.com/news/private-mac-address-on- 407 ios-14, updated based on findings from the authors). 409 +---------------------------------+---------------------------------+ 410 | Android 10+ | iOS 14+ | 411 +---------------------------------+---------------------------------+ 412 | The randomized MAC address is | The randomized MAC address is | 413 | bound to the SSID | bound to the BSSID | 414 | | | 415 | The randomized MAC address is | The randomized MAC address is | 416 | stable across reconnections for | stable across reconnections for | 417 | the same network | the same network | 418 | | | 419 | The randomized MAC address is | The randomized MAC address is | 420 | reset when the device forgets a | reset when the device forgets a | 421 | WiFI network | WiFI network | 422 | | | 423 | MAC address randomization is | MAC address randomization is | 424 | enabled by default for all the | enabled by default for all the | 425 | new WiFi networks. But if the | new WiFi networks | 426 | device previously connected to | | 427 | a WiFi network identifying | | 428 | itself with the real MAC | | 429 | address, no randomized MAC | | 430 | address will be used (unless | | 431 | manually enabled) | | 432 +---------------------------------+---------------------------------+ 434 Table 1: Android and iOS MAC address randomization practices 436 8. IANA Considerations 438 N/A. 440 9. Security Considerations 442 TBD. 444 10. Acknowledgments 446 TBD. 448 11. References 450 11.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 11.2. Informative References 459 [enhancing_location_privacy] 460 Gruteser, M. and D. Grunwald, "Enhancing location privacy 461 in wireless LAN through disposable interface identifiers: 462 a quantitative analysis", Mobile Networks and 463 Applications, vol. 10, no. 3, pp. 315-325 , 2005. 465 [I-D.gont-6man-deprecate-eui64-based-addresses] 466 Gont, F., Cooper, A., Thaler, D., and W. Liu, "Deprecating 467 EUI-64 Based IPv6 Addresses", draft-gont-6man-deprecate- 468 eui64-based-addresses-00 (work in progress), October 2013. 470 [I-D.ietf-dhc-mac-assign] 471 Volz, B., Mrugalski, T., and C. J. Bernardos, "Link-Layer 472 Address Assignment Mechanism for DHCPv6", draft-ietf-dhc- 473 mac-assign-09 (work in progress), September 2020. 475 [I-D.ietf-dhc-slap-quadrant] 476 Bernardos, C. J. and A. Mourad, "Structured Local Address 477 Plan (SLAP) Quadrant Selection Option for DHCPv6", draft- 478 ietf-dhc-slap-quadrant-12 (work in progress), October 479 2020. 481 [IEEE_802_11_aq] 482 Group, 8. W. -. W. L. W., "IEEE 802.11aq-2018 - IEEE 483 Standard for Information technology--Telecommunications 484 and information exchange between systems Local and 485 metropolitan area networks--Specific requirements Part 11: 486 Wireless LAN Medium Access Control (MAC) and Physical 487 Layer (PHY) Specifications Amendment 5: Preassociation 488 Discovery", IEEE 802.11 , 2018. 490 [IEEE_802c] 491 architecture, 8. W. -. 8. L., "IEEE 802c-2017 - IEEE 492 Standard for Local and Metropolitan Area Networks:Overview 493 and Architecture--Amendment 2: Local Medium Access Control 494 (MAC) Address Usage", IEEE 802c , 2017. 496 [IEEE_802E] 497 architecture, 8. W. -. 8. L., "IEEE 802E-2020 - IEEE 498 Recommended Practice for Privacy Considerations for IEEE 499 802 Technologies", IEEE 802E , 2020. 501 [ieee_privacy_ecsg] 502 IEEE 802 Privacy EC SG, "IEEE 802 EC Privacy 503 Recommendation Study Group", 504 . 506 [link_layer_privacy] 507 O'Hanlon, P., Wright, J., and I. Brown, "Privacy at the 508 link layer", Contribution at W3C/IAB workshop on 509 Strengthening the Internet Against Pervasive Monitoring 510 (STRINT) , February 2014. 512 [privacy_android] 513 Google/Open Handset Alliance, "Android Privacy: MAC 514 Randomization", 515 . 518 [privacy_ios] 519 Apple, "Use private Wi-Fi addresses in iOS 14, iPadOS 14, 520 and watchOS 7", 521 . 523 [privacy_tutorial] 524 Cooper, A., Hardie, T., Zuniga, JC., Chen, L., and P. 525 O'Hanlon, "Tutorial on Pervasive Surveillance of the 526 Internet - Designing Privacy into Internet Protocols", 527 . 530 [privacy_windows] 531 Microsoft, "Windows: How to use random hardware 532 addresses", . 536 [rcm_privacy_csd] 537 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 538 Addresses Study Group CSD on user experience mechanisms", 539 doc.:IEEE 802.11-20/1346r1 , 2020. 541 [rcm_privacy_par] 542 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 543 Addresses Study Group PAR on privacy mechanisms", 544 doc.:IEEE 802.11-19/854r7 , 2020. 546 [rcm_tig_final_report] 547 TIG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 548 Addresses Topic Interest Group Report", doc.:IEEE 549 802.11-19/1442r9 , 2019. 551 [rcm_user_experience_csd] 552 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 553 Addresses Study Group CSD on user experience mechanisms", 554 doc.:IEEE 802.11-20/1117r3 , 2020. 556 [rcm_user_experience_par] 557 SG, 8. W. R., "IEEE 802.11 Randomized And Changing MAC 558 Addresses Study Group PAR on user experience mechanisms", 559 doc.:IEEE 802.11-20/742r5 , 2020. 561 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 562 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 563 November 2005, . 565 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 566 Address Autoconfiguration", RFC 4862, 567 DOI 10.17487/RFC4862, September 2007, 568 . 570 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 571 Morris, J., Hansen, M., and R. Smith, "Privacy 572 Considerations for Internet Protocols", RFC 6973, 573 DOI 10.17487/RFC6973, July 2013, 574 . 576 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 577 Interface Identifiers with IPv6 Stateless Address 578 Autoconfiguration (SLAAC)", RFC 7217, 579 DOI 10.17487/RFC7217, April 2014, 580 . 582 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 583 Profiles for DHCP Clients", RFC 7844, 584 DOI 10.17487/RFC7844, May 2016, 585 . 587 [strint] W3C/IAB, "A W3C/IAB workshop on Strengthening the Internet 588 Against Pervasive Monitoring (STRINT)", 589 . 591 [wba_paper] 592 Alliance, W. B., "Wi-Fi Identification Scope for Liasing - 593 In a post MAC Randomization Era", doc.:WBA Wi-Fi ID Intro: 594 Post MAC Randomization Era v1.0 - IETF liaison , March 595 2020. 597 [when_mac_randomization_fails] 598 Martin, J., Mayberry, T., Donahue, C., Foppe, L., Brown, 599 L., Riggins, C., Rye, E., and D. Brown, "A Study of MAC 600 Address Randomization in Mobile Devices and When it 601 Fails", arXiv:1703.02874v2 [cs.CR] , 2017. 603 [wifi_internet_privacy] 604 Bernardos, CJ., Zuniga, JC., and P. O'Hanlon, "Wi-Fi 605 Internet Connectivity and Privacy: Hiding your tracks on 606 the wireless Internet", Standards for Communications and 607 Networking (CSCN), 2015 IEEE Conference on , October 2015. 609 [wifi_tracking] 610 The Independent, "London's bins are tracking your 611 smartphone", . 615 Authors' Addresses 617 Juan Carlos Zuniga 618 SIGFOX 619 Montreal QC 620 Canada 622 Email: j.c.zuniga@ieee.org 624 Carlos J. Bernardos 625 Universidad Carlos III de Madrid 626 Av. Universidad, 30 627 Leganes, Madrid 28911 628 Spain 630 Phone: +34 91624 6236 631 Email: cjbc@it.uc3m.es 632 URI: http://www.it.uc3m.es/cjbc/ 634 Amelia Andersdotter 635 CENTR 636 Belliardstraat 20 (6th floor) 637 Brussels 1040 638 Belgium 640 Email: amelia@centr.org 641 URI: https://www.centr.org