idnits 2.17.1 draft-ietf-6man-ipv6-address-generation-privacy-00.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 date (October 17, 2013) is 3837 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 621, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-6man-stable-privacy-addresses-14 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-02 -- Obsolete informational reference (is this intentional?): RFC 1972 (Obsoleted by RFC 2464) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Duplicate reference: RFC3972, mentioned in 'RFC3972', was also mentioned in 'CGA-IPR'. -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cooper 3 Internet-Draft CDT 4 Intended status: Informational F. Gont 5 Expires: April 20, 2014 Huawei Technologies 6 D. Thaler 7 Microsoft 8 October 17, 2013 10 Privacy Considerations for IPv6 Address Generation Mechanisms 11 draft-ietf-6man-ipv6-address-generation-privacy-00.txt 13 Abstract 15 This document discusses privacy and security considerations for 16 several IPv6 address generation mechanisms, both standardized and 17 non-standardized. It evaluates how different mechanisms mitigate 18 different threats and the trade-offs that implementors, developers, 19 and users face in choosing different addresses or address generation 20 mechanisms. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 20, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4 59 3.1. Correlation of activities over time . . . . . . . . . . . 5 60 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Device-specific vulnerability exploitation . . . . . . . 6 62 3.4. Address scanning . . . . . . . . . . . . . . . . . . . . 6 63 4. Privacy and security properties of address generation 64 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9 66 4.2. Static, manually configured IIDs . . . . . . . . . . . . 9 67 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10 68 4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10 69 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10 70 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 10 71 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 11 72 4.8. Transition/co-existence technologies . . . . . . . . . . 11 73 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 74 5.1. Geographic Location . . . . . . . . . . . . . . . . . . . 12 75 5.2. Network Operation . . . . . . . . . . . . . . . . . . . . 12 76 5.3. Compliance . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.4. Intellectual Property Rights (IPRs) . . . . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 9. Informative References . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 IPv6 was designed to improve upon IPv4 in many respects, and 87 mechanisms for address assignment were one such area for improvement. 88 In addition to static address assignment and DHCP, stateless address 89 autoconfiguration (SLAAC) was developed as a less intensive, fate- 90 shared means of performing address configuration. With stateless 91 autoconfiguration, routers advertise on-link prefixes and hosts 92 generate their own interface identifiers (IIDs) to complete their 93 addresses. Over the years, many interface identifier generation 94 techniques have been defined, both standardized and non-standardized: 96 o Manual configuration 97 * IPv4 address 99 * Service port 101 * Wordy 103 * Low-byte 105 o Stateless Address Auto-Cofiguration (SLAAC) 107 * IEEE 802 48-bit MAC or IEEE EUI-64 identifier 108 [RFC1972][RFC2464] 110 * Cryptographically generated [RFC3972] 112 * Temporary (also known as "privacy addresses") [RFC4941] 114 * Constant, semantically opaque (also known as random) 115 [Microsoft] 117 * Stable, semantically opaque 118 [I-D.ietf-6man-stable-privacy-addresses] 120 o DHCPv6-based [RFC3315] 122 o Specified by transition/co-existence technologies 124 * IPv4 address and port [RFC4380] 126 Deriving the IID from a globally unique IEEE identifier [RFC2462] was 127 one of the earliest mechanisms developed. A number of privacy and 128 security issues related to the interface IDs derived from IEEE 129 identifiers were discovered after their standardization, and many of 130 the mechanisms developed later aimed to mitigate some or all of these 131 weaknesses. This document identifies four types of threats against 132 IEEE-identifier-based IIDs, and discusses how other existing 133 techniques for generating IIDs do or do not mitigate those threats. 134 For simplicity sake, most of the discussion in this document assumes 135 that addresses have global scope. However, the scope of an address 136 just limits the number of potential nodes that might exploit such 137 address for different malicious purposes (host-tracking, device- 138 specific vulnerability exploitation, etc.). Additionally, we note 139 that even addresses with limited scopes (e.g. link-local) might leak 140 out as a result of, for example, application-layer protocols (e.g., 141 consider email headers). 143 2. Terminology 144 This section clarifies the terminology used throughout this document. 146 Public address: 147 An address that has been published in a directory or other public 148 location, such as the DNS, a SIP proxy, an application-specific 149 DHT, or a publicly available URI. A host's public addresses are 150 intended to be discoverable by third parties. 152 Stable address: 153 An address that does not vary over time within the same network. 154 Note that [RFC4941] refers to these as "public" addresses, but 155 "stable" is used here for reasons explained in Section 4. 157 Temporary address: 158 An address that varies over time within the same network. 160 Constant IID: 161 An IPv6 Interface Identifier that is globally stable. That is, 162 the Interface ID will remain constant even if the node moves from 163 one network to another. 165 Stable IID: 166 An IPv6 Interface Identifier that is stable within some specified 167 context. For example, an Interface ID can be globally stable 168 (constant), or could be stable per network (meaning that the 169 Interface ID will remain unchanged as long as a the node stays on 170 the same network, but may change when the node moves from one 171 network to another). 173 Temporary IID: 174 An IPv6 Interface Identifier that varies over time. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in 179 [RFC2119]. These words take their normative meanings only when they 180 are presented in ALL UPPERCASE. 182 3. Weaknesses in IEEE-identifier-based IIDs 184 There are a number of privacy and security implications that exist 185 for hosts that use IEEE-identifier-based IIDs. This section 186 discusses four generic attack types: correlation of activities over 187 time, location tracking, device-specific vulnerability exploitation, 188 and address scanning. The first three of these rely on the attacker 189 first gaining knowledge of the target host's IID. This can be 190 achieved by different types of attackers: the operator of a server to 191 which the host connects, such as a web server or a peer-to-peer 192 server; an entity that connects to the same network as the target 193 (such as a conference network or any public network); or an entity 194 that is on-path to the destinations with which the host communicates, 195 such as a network operator. 197 3.1. Correlation of activities over time 199 As with other identifiers, an IPv6 address can be used to correlate 200 the activities of a host for at least as long as the lifetime of the 201 address. The correlation made possible by IEEE-identifier-based IIDs 202 is of particular concern because MAC addresses are much more 203 permanent than, say, DHCP leases. MAC addresses tend to last roughly 204 the lifetime of a device's network interface, allowing correlation on 205 the order of years, compared to days for DHCP. 207 As [RFC4941] explains, 209 "[t]he use of a non-changing interface identifier to form 210 addresses is a specific instance of the more general case where a 211 constant identifier is reused over an extended period of time and 212 in multiple independent activities. Anytime the same identifier 213 is used in multiple contexts, it becomes possible for that 214 identifier to be used to correlate seemingly unrelated activity. 215 ... The use of a constant identifier within an address is of 216 special concern because addresses are a fundamental requirement of 217 communication and cannot easily be hidden from eavesdroppers and 218 other parties. Even when higher layers encrypt their payloads, 219 addresses in packet headers appear in the clear." 221 IP addresses are just one example of information that can be used to 222 correlate activities over time. DNS names, cookies [RFC6265], 223 browser fingerprints [Panopticlick], and application-layer usernames 224 can all be used to link a host's activities together. Although IEEE- 225 identifier-based IIDs are likely to last at least as long or longer 226 than these other identifiers, IIDs generated in other ways may have 227 shorter or longer lifetimes than these identifiers depending on how 228 they are generated. Therefore, the extent to which a host's 229 activities can be correlated depends on whether the host uses 230 multiple identifiers together and the lifetimes of all of those 231 identifiers. Frequently refreshing an IPv6 address may not mitigate 232 correlation if an attacker has access to other longer lived 233 identifiers for a particular host. This is an important caveat to 234 keep in mind throughout the discussion of correlation in this 235 document. For further discussion of correlation, see Section 5.2.1 236 of [I-D.iab-privacy-considerations]. 238 As noted in [RFC4941], in some cases correlation is just as feasible 239 for a host using an IPv4 address as for a host using an IEEE 240 identifier to generate its IID in its IPv6 address. Hosts that use 241 static IPv4 addressing or who are consistently allocated the same 242 address via DHCPv4 can be tracked as described above. However, the 243 widespread use of both NAT and DHCPv4 implementations that assign the 244 same host a different address upon lease expiration mitigates this 245 threat in the IPv4 case as compared to the IEEE identifier case in 246 IPv6. 248 3.2. Location tracking 250 Because the IPv6 address structure is divided between a topological 251 portion and an interface identifier portion, an interface identifier 252 that remains constant when a host connects to different networks (as 253 an IEEE-identifier-based IID does) provides a way for observers to 254 track the movements of that host. In a passive attack on a mobile 255 host, a server that receives connections from the same host over time 256 would be able to determine the host's movements as its prefix 257 changes. 259 Active attacks are also possible. An attacker that first learns the 260 host's interface identifier by being connected to the same network 261 segment, running a server that the host connects to, or being on-path 262 to the host's communications could subsequently probe other networks 263 for the presence of the same interface identifier by sending a probe 264 packet (ICMPv6 Echo Request, or any other probe packet). Even if the 265 host does not respond (e.g. as a result of a personal firewall), the 266 first hop router will usually respond with an ICMP Address 267 Unreachable when the host is not present, and be silent when the host 268 is present. 270 Location tracking based on IP address is generally not possible in 271 IPv4 since hosts get assigned wholly new addresses when they change 272 networks. 274 3.3. Device-specific vulnerability exploitation 276 IPv6 addresses that embed IEEE identifiers leak information about the 277 device (Network Interface Card vendor, or even Operating System and/ 278 or software type), which could be leveraged by an attacker with 279 knowledge of device/software-specific vulnerabilities to quickly find 280 possible targets. Attackers can exploit vulnerabilities in hosts 281 whose IIDs they have previously obtained, or scan an address space to 282 find potential targets. 284 3.4. Address scanning 286 The structure of IEEE-based identifiers used for address generation 287 can be leveraged by an attacker to reduce the target search space 289 [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally 290 Unique Identifier (OUI) of MAC addresses, together with the fixed 291 value (0xff, 0xfe) used to form a Modified EUI-64 Interface 292 Identifier, greatly help to reduce the search space, making it easier 293 for an attacker to scan for individual addresses using widely-known 294 popular OUIs. This erases much of the protection against address 295 scanning that the larger IPv6 address space was supposed to provide 296 as compared to IPv4. 298 4. Privacy and security properties of address generation mechanisms 300 Analysis of the extent to which a particular host is protected 301 against the threats described in Section 3 depends on how each of a 302 host's addresses is generated and used. In some scenarios, a host 303 configures a single global address and uses it for all 304 communications. In other scenarios, a host configures multiple 305 addresses using different mechanisms and may use any or all of them. 307 [RFC3041] (later obsoleted by [RFC4941]) sought to address some of 308 the problems described in Section 3 by defining "temporary addresses" 309 for outbound connections. Temporary addresses are meant to 310 supplement the other addresses that a device might use, not to 311 replace them. They use IIDs that are randomly generated and change 312 daily by default. The idea was for temporary addresses to be used 313 for outgoing connections (e.g., web browsing) while maintaining the 314 ability to use a stable address when more address stability is 315 desired (e.g., in DNS advertisements). 317 [RFC3484] originally specified that stable addresses be used for 318 outbound connections unless an application explicitly prefers 319 temporary addresses. The default preference for stable addresses was 320 established to avoid applications potentially failing due to the 321 short lifetime of temporary addresses or the possibility of a reverse 322 look-up failure or error. However, [RFC3484] allowed that 323 "implementations for which privacy considerations outweigh these 324 application compatibility concerns MAY reverse the sense of this 325 rule" and instead prefer by default temporary addresses rather than 326 stable addresses. Indeed most implementations (notably including 327 Windows) chose to default to temporary addresses for outbound 328 connections since privacy was considered more important (and few 329 applications supported IPv6 at the time, so application compatibility 330 concerns were minimal). [RFC6724] then obsoleted [RFC3484] and 331 changed the default to match what implementations actually did. 333 The envisioned relationship in [RFC3484] between stability of an 334 address and its use in "public" can be misleading when conducting 335 privacy analysis. The stability of an address and the extent to 336 which it is linkable to some other public identifier are independent 337 of one another. For example, there is nothing that prevents a host 338 from publishing a temporary address in a public place, such as the 339 DNS. Publishing both a stable address and a temporary address in the 340 DNS or elsewhere where they can be linked together by a public 341 identifier allows the host's activities when using either address to 342 be correlated together. 344 Moreover, because temporary addresses were designed to supplement 345 other addresses generated by a host, the host may still configure a 346 more stable address even if it only ever intentionally uses temporary 347 addresses (as source addresses) for communication to off-link 348 destinations. An attacker can probe for the stable address even if 349 it is never used as such a source address or advertised (e.g., in DNS 350 or SIP) outside the link. 352 This section compares the privacy and security properties of a 353 variety of IID generation mechanisms and their possible usage 354 scenarios, including scenarios in which a single mechanism is used to 355 generate all of a host's IIDs and those in which temporary addresses 356 are used together with addresses generated using a different IID 357 generation mechanism. The analysis of the exposure of each IID type 358 to correlation assumes that IPv6 prefixes are shared by a reasonably 359 large number of nodes. As [RFC4941] notes, if a very small number of 360 nodes (say, only one) use a particular prefix for an extended period 361 of time, the prefix itself can be used to correlate the host's 362 activities regardless of how the IID is generated. 364 The table below provides a summary of the whole analysis. 366 +--------------+-------------+------------+------------+------------+ 367 | Mechanism(s) | Correlation | Location | Address | Device | 368 | | | tracking | scanning | exploits | 369 +--------------+-------------+------------+------------+------------+ 370 | IEEE | Possible | Possible | Possible | Possible | 371 | identifier | (for device | (for | | | 372 | | lifetime) | device | | | 373 | | | lifetime) | | | 374 | | | | | | 375 | Static | Possible | Depends on | Depends on | Depends on | 376 | manual | (for | generation | generation | generation | 377 | | address | mechanism | mechanism | mechanism | 378 | | lifetime) | | | | 379 | | | | | | 380 | Constant, | Possible | Possible | No | No | 381 | semantically | (for OS | (for OS | | | 382 | opaque | lifetime) | lifetime) | | | 383 | | | | | | 384 | CGA | Typically | Typically | No | No | 385 | | possible | possible | | | 386 | | (for public | (for | | | 387 | | key | public key | | | 388 | | lifetime) | lifetime) | | | 389 | | | | | | 390 | Stable, | Possible | No | No | No | 391 | semantically | (for OS | | | | 392 | opaque | lifetime) | | | | 393 | | | | | | 394 | Temporary | Only | No | No | No | 395 | | possible | | | | 396 | | for temp | | | | 397 | | address | | | | 398 | | lifetime | | | | 399 | | | | | | 400 | DHCPv6 | Possible | No | Depends on | No | 401 | | for lease | | DHCPv6 | | 402 | | lifetime | | server imp | | 403 | | (typically | | lementatio | | 404 | | hours) | | n | | 405 +--------------+-------------+------------+------------+------------+ 407 Table 1: Privacy and security properties of IID generation mechanisms 409 4.1. IEEE-identifier-based IIDs 411 As discussed in Section 3, addresses that use IIDs based on IEEE 412 identifiers are vulnerable to all four threats. They allow 413 correlation and location tracking for the lifetime of the device 414 since IEEE identifiers last that long and their structure makes 415 address scanning and device exploits possible. 417 4.2. Static, manually configured IIDs 419 Because static, manually configured IIDs are stable, both correlation 420 and location tracking are possible for the life of the address. 422 The extent to which location tracking can be successfully performed 423 depends, to a some extent, on the uniqueness of the employed 424 Interface ID. For example, one would expect "low byte" Interface IDs 425 to be more widely reused than, for example, Interface IDs where the 426 whole 64-bits follow some pattern that is unique to a specific 427 organization. Widely reused Interface IDs will typically lead to 428 false positives when performing location tracking. 430 Whether manually configured addresses are vulnerable to address 431 scanning and device exploits depends on the specifics of how the IIDs 432 are generated. For example, low-byte and IPv4-embedded IIDs will 433 greatly reduce the search space when performing address scans. 435 4.3. Constant, semantically opaque IIDs 437 Although a mechanism to generate a constant, semantically opaque IID 438 has not been standardized, it has been in wide use for many years on 439 at least one platform (Windows). Windows uses the [RFC4941] random 440 generation mechanism in lieu of generating an IEEE-identifier-based 441 IID. This mitigates the device-specific exploitation and address 442 scanning attacks, but still allows correlation and location tracking 443 because the IID is constant across networks and time. 445 4.4. Cryptographically generated IIDs 447 Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of 448 the host's public key to an IPv6 address in the SEcure Neighbor 449 Discovery (SEND) [RFC3971] protocol. CGAs may be regenerated for 450 each subnet prefix, but this is not required given that they are 451 computationally expensive to generate. A host using a CGA can be 452 correlated for as long as the life of the public key. If the host 453 does not generate a new public key when it moves to a different 454 network, its location can also be tracked. CGAs do not allow device- 455 specific exploitation or address scanning attacks. 457 4.5. Stable, semantically opaque IIDs 459 [I-D.ietf-6man-stable-privacy-addresses] specifies a mechanism that 460 generates a unique random IID for each network. A host that stays 461 connected to the same network could therefore be tracked at length, 462 whereas a mobile host's activities could only be correlated for the 463 duration of each network connection. Location tracking is not 464 possible with these addresses. They also do not allow device- 465 specific exploitation or address scanning attacks. 467 4.6. Temporary IIDs 469 A host that uses only a temporary address mitigates all four threats. 470 Its activities may only be correlated for the lifetime a single 471 temporary address. 473 A host that configures both an IEEE-identifier-based IID and 474 temporary addresses makes the host vulnerable to the same attacks as 475 if temporary addresses were not in use, although the viability of 476 some of them depends on how the host uses each address. An attacker 477 can correlate all of the host's activities for which it uses its 478 IEEE-identifier-based IID. Once an attacker has obtained the IEEE- 479 identifier-based IID, location tracking becomes possible on other 480 networks even if the host only makes use of temporary addresses on 481 those other networks; the attacker can actively probe the other 482 networks for the presence of the IEEE-identifier-based IID. Device- 483 specific vulnerabilities can still be exploited. Address scanning is 484 also still possible because the IEEE-identifier-based address will 485 result in predictable patterns. 487 If the host instead generates a constant semantically-opaque IID to 488 use in a stable address for server-like connections together with 489 temporary addresses for outbound connections (as is the default in 490 Windows), it sees some improvements over the previous scenario. The 491 address scanning and device-specific exploitation attacks are no 492 longer possible because the OUI is no longer embedded in any of the 493 host's addresses. However, correlation of some activities across 494 time is still possible because the semantically opaque IID is 495 constant. And once an attacker has obtained the host's semantically 496 opaque IID, location tracking is possible on any network by probing 497 for that IID, even if the host only uses temporary addresses on those 498 networks. 500 When used together with temporary addresses, the stable (per- 501 network), semantically opaque IID generation mechanism 502 [I-D.ietf-6man-stable-privacy-addresses] improves upon the previous 503 scenario by eliminating the possibility for location tracking (since 504 a different IID is generated for each subnet prefix). Correlation of 505 node activities within the same network will be typically possible 506 for the lifetime of the stable address (which may still be lengthy 507 for hosts that are not mobile). 509 4.7. DHCPv6 generation of IIDs 511 The security/privacy implications of DHCPv6-based addresses will 512 typically depend on the specific DHCPv6 server software being 513 employed. For example, some DHCPv6-server implementations lease low- 514 byte addresses, while others randomly select the IPv6 addresses they 515 lease from the entire IPv6 address space they manage. Thus, the 516 security/privacy implications of DHCPv6-addresses will essentially be 517 those of the policy with which the leased addresses are selected. 519 4.8. Transition/co-existence technologies 521 Addresses specified based on transition/co-existence technologies 522 that embed an IPv4 address within an IPv6 address are not included in 523 Table 1 because their privacy and security properties are inherited 524 from the embedded address. For example, Teredo [RFC4380] specifies a 525 means to generate an IPv6 address from the underlying IPv4 address 526 and port, leaving many other bits set to zero. This makes it 527 relatively easy for an attacker to scan for IPv6 addresses by 528 guessing the Teredo client's IPv4 address and port (which for many 529 NATs is not randomized). For this reason, popular implementations 530 (e.g., Windows), began deviating from the standard by including 12 531 random bits in place of zero bits. This modification was later 532 standardized in [RFC5991]. 534 5. Miscellaneous Issues with IPv6 addressing 536 5.1. Geographic Location 538 Since IPv6 subnets have unique prefixes, they reveal some information 539 about the location of the subnet, just as IPv4 addresses do. Hiding 540 this information is one motivation for using NAT in IPv6 (see RFC 541 5902 section 2.4). 543 5.2. Network Operation 545 It is generally agreed that IPv6 addresses that vary over time in a 546 specific network tend to increase the complexity of event logging, 547 trouble-shooting, enforcement of access controls and quality of 548 service, etc. As a result, some organizations disable the use of 549 temporary addresses [RFC4941] even at the expense of reduced privacy 550 [Broersma]. 552 5.3. Compliance 554 Major IPv6 compliance testing suites required (and still require) 555 implementations to support MAC-derived suffixes in order to be 556 approved as compliant. Implementations that fail to support MAC- 557 derived suffixes are therefore largely not eligible to receive the 558 benefits of compliance certification (e.g., use of the IPv6 logo, 559 eligibility for government contracts, etc.). This document 560 recommends that these be relaxed to allow other forms of address 561 generation that are more amenable to privacy. 563 5.4. Intellectual Property Rights (IPRs) 565 Some IPv6 addressing techniques might be covered by Intellectual 566 Property rights, which might limit their implementation in different 567 Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on 568 CGAs. 570 6. Security Considerations 572 This whole document concerns the privacy and security properties of 573 different IPv6 address generation mechanisms. 575 7. IANA Considerations 577 This document does not require actions by IANA. 579 8. Acknowledgements 581 The authors would like to thank Bernard Aboba and Rich Draves. 583 9. Informative References 585 [Broersma] 586 Broersma, R., "IPv6 Everywhere: Living with a Fully 587 IPv6-enabled environment", Australian IPv6 Summit 2010, 588 Melbourne, VIC Australia, October 2010, October 2010, 589 . 592 [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. 594 [I-D.iab-privacy-considerations] 595 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 596 Morris, J., Hansen, M., and R. Smith, "Privacy 597 Considerations for Internet Protocols", draft-iab-privacy- 598 considerations-09 (work in progress), May 2013. 600 [I-D.ietf-6man-stable-privacy-addresses] 601 Gont, F., "A Method for Generating Semantically Opaque 602 Interface Identifiers with IPv6 Stateless Address 603 Autoconfiguration (SLAAC)", draft-ietf-6man-stable- 604 privacy-addresses-14 (work in progress), October 2013. 606 [I-D.ietf-opsec-ipv6-host-scanning] 607 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 608 Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in 609 progress), July 2013. 611 [KAME-CGA] 612 KAME, "The KAME IPR policy and concerns of some 613 technologies which have IPR claims", 2005. 615 [Microsoft] 616 Microsoft, "IPv6 interface identifiers", 2013. 618 [Panopticlick] 619 Electronic Frontier Foundation, "Panopticlick", 2011. 621 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 622 STD 13, RFC 1034, November 1987. 624 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 625 Packets over Ethernet Networks", RFC 1972, August 1996. 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 631 Autoconfiguration", RFC 2462, December 1998. 633 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 634 Networks", RFC 2464, December 1998. 636 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 637 Stateless Address Autoconfiguration in IPv6", RFC 3041, 638 January 2001. 640 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 641 and M. Carney, "Dynamic Host Configuration Protocol for 642 IPv6 (DHCPv6)", RFC 3315, July 2003. 644 [RFC3484] Draves, R., "Default Address Selection for Internet 645 Protocol version 6 (IPv6)", RFC 3484, February 2003. 647 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 648 Neighbor Discovery (SEND)", RFC 3971, March 2005. 650 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 651 RFC 3972, March 2005. 653 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 654 Network Address Translations (NATs)", RFC 4380, February 655 2006. 657 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 658 Extensions for Stateless Address Autoconfiguration in 659 IPv6", RFC 4941, September 2007. 661 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 662 Security Updates", RFC 5991, September 2010. 664 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 665 April 2011. 667 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 668 "Default Address Selection for Internet Protocol Version 6 669 (IPv6)", RFC 6724, September 2012. 671 Authors' Addresses 673 Alissa Cooper 674 CDT 675 1634 Eye St. NW, Suite 1100 676 Washington, DC 20006 677 US 679 Phone: +1-202-637-9800 680 Email: acooper@cdt.org 681 URI: http://www.cdt.org/ 683 Fernando Gont 684 Huawei Technologies 685 Evaristo Carriego 2644 686 Haedo, Provincia de Buenos Aires 1706 687 Argentina 689 Phone: +54 11 4650 8472 690 Email: fgont@si6networks.com 691 URI: http://www.si6networks.com 693 Dave Thaler 694 Microsoft 695 Microsoft Corporation 696 One Microsoft Way 697 Redmond, WA 98052 699 Phone: +1 425 703 8835 700 Email: dthaler@microsoft.com