idnits 2.17.1 draft-ietf-6man-ipv6-address-generation-privacy-04.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 (February 23, 2015) is 3350 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1972 (Obsoleted by RFC 2464) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Duplicate reference: RFC3972, mentioned in 'CGA-IPR', was also mentioned in 'RFC3972'. == Outdated reference: A later version (-02) exists of draft-ietf-dhc-stable-privacy-addresses-01 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-06 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Cooper 3 Internet-Draft Cisco 4 Intended status: Informational F. Gont 5 Expires: August 27, 2015 Huawei Technologies 6 D. Thaler 7 Microsoft 8 February 23, 2015 10 Privacy Considerations for IPv6 Address Generation Mechanisms 11 draft-ietf-6man-ipv6-address-generation-privacy-04.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 August 27, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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. Address scanning . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Device-specific vulnerability exploitation . . . . . . . 7 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 . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 71 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12 72 4.8. Transition/co-existence technologies . . . . . . . . . . 12 73 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 74 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 9.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 IPv6 was designed to improve upon IPv4 in many respects, and 88 mechanisms for address assignment were one such area for improvement. 89 In addition to static address assignment and DHCP, stateless 90 autoconfiguration was developed as a less intensive, fate-shared 91 means of performing address assignment. With stateless 92 autoconfiguration, routers advertise on-link prefixes and hosts 93 generate their own interface identifiers (IIDs) to complete their 94 addresses. [RFC7136] clarifies that the IID should be treated as an 95 opaque value, while [RFC7421] provides an analysis of the 64-bit 96 boundary in IPv6 addressing (e.g. the implications of the IID length 97 on security and privacy). Over the years, many interface identifier 98 generation techniques have been defined, both standardized and non- 99 standardized: 101 o Manual configuration 103 * IPv4 address 105 * Service port 107 * Wordy 109 * Low-byte 111 o Stateless Address Auto-Cofiguration (SLAAC) 113 * IEEE 802 48-bit MAC or IEEE EUI-64 identifier 114 [RFC1972][RFC2464] 116 * Cryptographically generated [RFC3972] 118 * Temporary (also known as "privacy addresses") [RFC4941] 120 * Constant, semantically opaque (also known as random) 121 [Microsoft] 123 * Stable, semantically opaque [RFC7217] 125 o DHCPv6-based [RFC3315] 127 o Specified by transition/co-existence technologies 129 * IPv4 address and port [RFC4380] 131 Deriving the IID from a globally unique IEEE identifier [RFC2462] was 132 one of the earliest mechanisms developed. A number of privacy and 133 security issues related to the IIDs derived from IEEE identifiers 134 were discovered after their standardization, and many of the 135 mechanisms developed later aimed to mitigate some or all of these 136 weaknesses. This document identifies four types of threats against 137 IEEE-identifier-based IIDs, and discusses how other existing 138 techniques for generating IIDs do or do not mitigate those threats. 140 2. Terminology 142 This section clarifies the terminology used throughout this document. 144 Public address: 146 An address that has been published in a directory or other public 147 location, such as the DNS, a SIP proxy, an application-specific 148 DHT, or a publicly available URI. A host's public addresses are 149 intended to be discoverable by third parties. 151 Stable address: 152 An address that does not vary over time within the same network. 153 Note that [RFC4941] refers to these as "public" addresses, but 154 "stable" is used here for reasons explained in Section 4. 156 Temporary address: 157 An address that varies over time within the same network. 159 Constant IID: 160 An IPv6 Interface Identifier that is globally stable. That is, 161 the Interface ID will remain constant even if the node moves from 162 one network to another. 164 Stable IID: 165 An IPv6 Interface Identifier that is stable within some specified 166 context. For example, an Interface ID can be globally stable 167 (constant), or could be stable per network (meaning that the 168 Interface ID will remain unchanged as long as a the node stays on 169 the same network, but may change when the node moves from one 170 network to another). 172 Temporary IID: 173 An IPv6 Interface Identifier that varies over time. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in 178 [RFC2119]. These words take their normative meanings only when they 179 are presented in ALL UPPERCASE. 181 3. Weaknesses in IEEE-identifier-based IIDs 183 There are a number of privacy and security implications that exist 184 for hosts that use IEEE-identifier-based IIDs. This section 185 discusses four generic attack types: correlation of activities over 186 time, location tracking, address scanning, and device-specific 187 vulnerability exploitation. The first three of these rely on the 188 attacker first gaining knowledge of the target host's IID. This can 189 be achieved by a number of different attackers: the operator of a 190 server to which the host connects, such as a web server or a peer-to- 191 peer server; an entity that connects to the same network as the 192 target (such as a conference network or any public network); or an 193 entity that is on-path to the destinations with which the host 194 communicates, such as a network operator. 196 3.1. Correlation of activities over time 198 As with other identifiers, an IPv6 address can be used to correlate 199 the activities of a host for at least as long as the lifetime of the 200 address. The correlation made possible by IEEE-identifier-based IIDs 201 is of particular concern because MAC addresses are much more 202 permanent than, say, DHCP leases. MAC addresses tend to last roughly 203 the lifetime of a device's network interface, allowing correlation on 204 the order of years, compared to days for DHCP. 206 As [RFC4941] explains, 208 "[t]he use of a non-changing interface identifier to form 209 addresses is a specific instance of the more general case where a 210 constant identifier is reused over an extended period of time and 211 in multiple independent activities. Anytime the same identifier 212 is used in multiple contexts, it becomes possible for that 213 identifier to be used to correlate seemingly unrelated activity. 214 ... The use of a constant identifier within an address is of 215 special concern because addresses are a fundamental requirement of 216 communication and cannot easily be hidden from eavesdroppers and 217 other parties. Even when higher layers encrypt their payloads, 218 addresses in packet headers appear in the clear." 220 IP addresses are just one example of information that can be used to 221 correlate activities over time. DNS names, cookies [RFC6265], 222 browser fingerprints [Panopticlick], and application-layer usernames 223 can all be used to link a host's activities together. Although IEEE- 224 identifier-based IIDs are likely to last at least as long or longer 225 than these other identifiers, IIDs generated in other ways may have 226 shorter or longer lifetimes than these identifiers depending on how 227 they are generated. Therefore, the extent to which a host's 228 activities can be correlated depends on whether the host uses 229 multiple identifiers together and the lifetimes of all of those 230 identifiers. Frequently refreshing an IPv6 address may not mitigate 231 correlation if an attacker has access to other longer lived 232 identifiers for a particular host. This is an important caveat to 233 keep in mind throughout the discussion of correlation in this 234 document. For further discussion of correlation, see Section 5.2.1 235 of [RFC6973]. 237 As noted in [RFC4941], in some cases correlation is just as feasible 238 for a host using an IPv4 address as for a host using an IEEE 239 identifier to generate its IID in its IPv6 address. Hosts that use 240 static IPv4 addressing or who are consistently allocated the same 241 address via DHCPv4 can be tracked as described above. However, the 242 widespread use of both NAT and DHCPv4 implementations that assign the 243 same host a different address upon lease expiration mitigates this 244 threat in the IPv4 case as compared to the IEEE identifier case in 245 IPv6. 247 3.2. Location tracking 249 Because the IPv6 address structure is divided between a topological 250 portion and an interface identifier portion, an interface identifier 251 that remains constant when a host connects to different networks (as 252 an IEEE-identifier-based IID does) provides a way for observers to 253 track the movements of that host. In a passive attack on a mobile 254 host, a server that receives connections from the same host over time 255 would be able to determine the host's movements as its prefix 256 changes. 258 Active attacks are also possible. An attacker that first learns the 259 host's interface identifier by being connected to the same network 260 segment, running a server that the host connects to, or being on-path 261 to the host's communications could subsequently probe other networks 262 for the presence of the same interface identifier by sending a probe 263 packet (ICMPv6 Echo Request, or any other probe packet). Even if the 264 host does not respond, the first hop router will usually respond with 265 an ICMP Address Unreachable when the host is not present, and be 266 silent when the host is present. 268 Location tracking based on IP address is generally not possible in 269 IPv4 since hosts get assigned wholly new addresses when they change 270 networks. 272 3.3. Address scanning 274 The structure of IEEE-based identifiers used for address generation 275 can be leveraged by an attacker to reduce the target search space 276 [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally 277 Unique Identifier (OUI) of MAC addresses, together with the fixed 278 value (0xff, 0xfe) used to form a Modified EUI-64 Interface 279 Identifier, greatly help to reduce the search space, making it easier 280 for an attacker to scan for individual addresses using widely-known 281 popular OUIs. This erases much of the protection against address 282 scanning that the larger IPv6 address space was supposed to provide 283 as compared to IPv4. 285 3.4. Device-specific vulnerability exploitation 287 IPv6 addresses that embed IEEE identifiers leak information about the 288 device (Network Interface Card vendor, or even Operating System and/ 289 or software type), which could be leveraged by an attacker with 290 knowledge of device/software-specific vulnerabilities to quickly find 291 possible targets. Attackers can exploit vulnerabilities in hosts 292 whose IIDs they have previously obtained, or scan an address space to 293 find potential targets. 295 4. Privacy and security properties of address generation mechanisms 297 Analysis of the extent to which a particular host is protected 298 against the threats described in Section 3 depends on how each of a 299 host's addresses is generated and used. In some scenarios, a host 300 configures a single global address and uses it for all 301 communications. In other scenarios, a host configures multiple 302 addresses using different mechanisms and may use any or all of them. 304 [RFC3041] (later obsoleted by [RFC4941]) sought to address some of 305 the problems described in Section 3 by defining "temporary addresses" 306 for outbound connections. Temporary addresses are meant to 307 supplement the other addresses that a device might use, not to 308 replace them. They use IIDs that are randomly generated and change 309 daily by default. The idea was for temporary addresses to be used 310 for outgoing connections (e.g., web browsing) while maintaining the 311 ability to use a stable address when more address stability is 312 desired (e.g., in DNS advertisements). 314 [RFC3484] originally specified that stable addresses be used for 315 outbound connections unless an application explicitly prefers 316 temporary addresses. The default preference for stable addresses was 317 established to avoid applications potentially failing due to the 318 short lifetime of temporary addresses or the possibility of a reverse 319 look-up failure or error. However, [RFC3484] allowed that 320 "implementations for which privacy considerations outweigh these 321 application compatibility concerns MAY reverse the sense of this 322 rule" and instead prefer by default temporary addresses rather than 323 stable addresses. Indeed most implementations (notably including 324 Windows) chose to default to temporary addresses for outbound 325 connections since privacy was considered more important (and few 326 applications supported IPv6 at the time, so application compatibility 327 concerns were minimal). [RFC6724] then obsoleted [RFC3484] and 328 changed the default to match what implementations actually did. 330 The envisioned relationship in [RFC3484] between stability of an 331 address and its use in "public" can be misleading when conducting 332 privacy analysis. The stability of an address and the extent to 333 which it is linkable to some other public identifier are independent 334 of one another. For example, there is nothing that prevents a host 335 from publishing a temporary address in a public place, such as the 336 DNS. Publishing both a stable address and a temporary address in the 337 DNS or elsewhere where they can be linked together by a public 338 identifier allows the host's activities when using either address to 339 be correlated together. 341 Moreover, because temporary addresses were designed to supplement 342 other addresses generated by a host, the host may still configure a 343 more stable address even if it only ever intentionally uses temporary 344 addresses (as source addresses) for communication to off-link 345 destinations. An attacker can probe for the stable address even if 346 it is never used as such a source address or advertised (e.g., in DNS 347 or SIP) outside the link. 349 This section compares the privacy and security properties of a 350 variety of IID generation mechanisms and their possible usage 351 scenarios, including scenarios in which a single mechanism is used to 352 generate all of a host's IIDs and those in which temporary addresses 353 are used together with addresses generated using a different IID 354 generation mechanism. The analysis of the exposure of each IID type 355 to correlation assumes that IPv6 prefixes are shared by a reasonably 356 large number of nodes. As [RFC4941] notes, if a very small number of 357 nodes (say, only one) use a particular prefix for an extended period 358 of time, the prefix itself can be used to correlate the host's 359 activities regardless of how the IID is generated. For example, 360 [RFC3314] recommends that prefixes be uniquely assigned to mobile 361 handsets where IPv6 is used within GPRS. In cases where this advice 362 is followed and prefixes persist for extended periods of time (or get 363 reassigned to the same handsets whenever those handsets reconnect to 364 the same network router), hosts' activities could be correlatable for 365 longer periods than the analysis below would suggest. 367 The table below provides a summary of the whole analysis. 369 +--------------+-------------+----------+-------------+-------------+ 370 | Mechanism(s) | Correlation | Location | Address | Device | 371 | | | tracking | scanning | exploits | 372 +--------------+-------------+----------+-------------+-------------+ 373 | IEEE | For device | For | Possible | Possible | 374 | identifier | lifetime | device | | | 375 | | | lifetime | | | 376 | | | | | | 377 | Static | For address | For | Depends on | Depends on | 378 | manual | lifetime | address | generation | generation | 379 | | | lifetime | mechanism | mechanism | 380 | | | | | | 381 | Constant, | For address | For | No | No | 382 | semantically | lifetime | address | | | 383 | opaque | | lifetime | | | 384 | | | | | | 385 | CGA | For | No | No | No | 386 | | lifetime of | | | | 387 | | (modifier | | | | 388 | | block + | | | | 389 | | public key) | | | | 390 | | | | | | 391 | Stable, | Within | No | No | No | 392 | semantically | single | | | | 393 | opaque | network | | | | 394 | | | | | | 395 | Temporary | For temp | No | No | No | 396 | | address | | | | 397 | | lifetime | | | | 398 | | | | | | 399 | DHCPv6 | For lease | No | Depends on | No | 400 | | lifetime | | generation | | 401 | | | | mechanism | | 402 +--------------+-------------+----------+-------------+-------------+ 404 Table 1: Privacy and security properties of IID generation mechanisms 406 4.1. IEEE-identifier-based IIDs 408 As discussed in Section 3, addresses that use IIDs based on IEEE 409 identifiers are vulnerable to all four threats. They allow 410 correlation and location tracking for the lifetime of the device 411 since IEEE identifiers last that long and their structure makes 412 address scanning and device exploits possible. 414 4.2. Static, manually configured IIDs 416 Because static, manually configured IIDs are stable, both correlation 417 and location tracking are possible for the life of the address. 419 The extent to which location tracking can be successfully performed 420 depends, to a some extent, on the uniqueness of the employed 421 Interface ID. For example, one would expect "low byte" Interface IDs 422 to be more widely reused than, for example, Interface IDs where the 423 whole 64-bits follow some pattern that is unique to a specific 424 organization. Widely reused Interface IDs will typically lead to 425 false positives when performing location tracking. 427 Whether manually configured addresses are vulnerable to address 428 scanning and device exploits depends on the specifics of how the IIDs 429 are generated. 431 4.3. Constant, semantically opaque IIDs 433 Although a mechanism to generate a constant, semantically opaque IID 434 has not been standardized, it has been in wide use for many years on 435 at least one platform (Windows). Windows uses the [RFC4941] random 436 generation mechanism in lieu of generating an IEEE-identifier-based 437 IID. This mitigates the device-specific exploitation and address 438 scanning attacks, but still allows correlation and location tracking 439 because the IID is constant across networks and time. 441 4.4. Cryptographically generated IIDs 443 Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of 444 the host's public key to an IPv6 address in the SEcure Neighbor 445 Discovery (SEND) [RFC3971] protocol. CGAs may be regenerated for 446 each subnet prefix, but this is not required given that they are 447 computationally expensive to generate. A host using a CGA can be 448 correlated for as long as the lifetime of the combination of the 449 public key and the chosen modifier block, since it is possible to 450 rotate modifier blocks without generating new public keys. Because 451 the cryptographic hash of the host's public key uses the subnet 452 prefix as an input, even if the host does not generate a new public 453 key or modifier block when it moves to a different network, its 454 location cannot be tracked via the IID. CGAs do not allow device- 455 specific exploitation or address scanning attacks. 457 4.5. Stable, semantically opaque IIDs 459 [RFC7217] specifies an algorithm that generates, for each network 460 interface, a unique random IID per network. The aforementioned 461 algorithm is employed not only for global unicast addresses, but also 462 for unique local unicast addresses and link-local unicast addresses, 463 since these addresses may leak out via application protocols (e.g., 464 IPv6 addresses embedded in email headers). 466 A host that stays connected to the same network could therefore be 467 tracked at length, whereas a mobile host's activities could only be 468 correlated for the duration of each network connection. Location 469 tracking is not possible with these addresses. They also do not 470 allow device-specific exploitation or address scanning attacks. 472 4.6. Temporary IIDs 474 A host that uses only a temporary address mitigates all four threats. 475 Its activities may only be correlated for the lifetime a single 476 temporary address. 478 A host that configures both an IEEE-identifier-based IID and 479 temporary addresses makes the host vulnerable to the same attacks as 480 if temporary addresses were not in use, although the viability of 481 some of them depends on how the host uses each address. An attacker 482 can correlate all of the host's activities for which it uses its 483 IEEE-identifier-based IID. Once an attacker has obtained the IEEE- 484 identifier-based IID, location tracking becomes possible on other 485 networks even if the host only makes use of temporary addresses on 486 those other networks; the attacker can actively probe the other 487 networks for the presence of the IEEE-identifier-based IID. Device- 488 specific vulnerabilities can still be exploited. Address scanning is 489 also still possible because the IEEE-identifier-based address can be 490 probed. 492 If the host instead generates a constant, semantically opaque IID to 493 use in a stable address for server-like connections together with 494 temporary addresses for outbound connections (as is the default in 495 Windows), it sees some improvements over the previous scenario. The 496 address scanning and device-specific exploitation attacks are no 497 longer possible because the OUI is no longer embedded in any of the 498 host's addresses. However, correlation of some activities across 499 time and location tracking are both still possible because the 500 semantically opaque IID is constant. And once an attacker has 501 obtained the host's semantically opaque IID, location tracking is 502 possible on any network by probing for that IID, even if the host 503 only uses temporary addresses on those networks. However, if the 504 host generates but never uses a constant, semantically opaque IID, it 505 mitigates all four threats. 507 When used together with temporary addresses, the stable, semantically 508 opaque IID generation mechanism [RFC7217] improves upon the previous 509 scenario by limiting the potential for correlation to the lifetime of 510 the stable address (which may still be lengthy for hosts that are not 511 mobile) and by eliminating the possibility for location tracking 512 (since a different IID is generated for each subnet prefix). As in 513 the previous scenario, a host that configures but does not use a 514 stable, semantically opaque address mitigates all four threats. 516 4.7. DHCPv6 generation of IIDs 518 The security/privacy implications of DHCPv6-based addresses will 519 typically depend on the specific DHCPv6 server software being 520 employed. We note that recent releases of most popular DHCPv6 server 521 software typically lease random addresses with a similar lease time 522 as that of IPv4. Thus, these addresses can be considered to be 523 "stable, semantically opaque". 524 [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that 525 can be employed by DHCP servers to generate "stable, semantically 526 opaque" addresses. 528 On the other hand, some DHCPv6 software leases sequential addresses 529 (typically low-byte addresses). These addresses can be considered to 530 be stable addresses. The drawback of this address generation scheme 531 compared to "stable, semantically opaque" addresses is that, since 532 they follow specific patterns, they enable IPv6 address scans. 534 4.8. Transition/co-existence technologies 536 Addresses specified based on transition/co-existence technologies 537 that embed an IPv4 address within an IPv6 address are not included in 538 Table 1 because their privacy and security properties are inherited 539 from the embedded address. For example, Teredo [RFC4380] specifies a 540 means to generate an IPv6 address from the underlying IPv4 address 541 and port, leaving many other bits set to zero. This makes it 542 relatively easy for an attacker to scan for IPv6 addresses by 543 guessing the Teredo client's IPv4 address and port (which for many 544 NATs is not randomized). For this reason, popular implementations 545 (e.g., Windows), began deviating from the standard by including 12 546 random bits in place of zero bits. This modification was later 547 standardized in [RFC5991]. 549 5. Miscellaneous Issues with IPv6 addressing 551 5.1. Network Operation 553 It is generally agreed that IPv6 addresses that vary over time in a 554 specific network tend to increase the complexity of event logging, 555 trouble-shooting, enforcement of access controls and quality of 556 service, etc. As a result, some organizations disable the use of 557 temporary addresses [RFC4941] even at the expense of reduced privacy 558 [Broersma]. 560 5.2. Compliance 562 Some IPv6 compliance testing suites required (and might still 563 require) implementations to support MAC-derived suffixes in order to 564 be approved as compliant. This document recommends that compliance 565 testing suites be relaxed to allow other forms of address generation 566 that are more amenable to privacy. 568 5.3. Intellectual Property Rights (IPRs) 570 Some IPv6 addressing techniques might be covered by Intellectual 571 Property rights, which might limit their implementation in different 572 Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on 573 CGAs. 575 6. Security Considerations 577 This whole document concerns the privacy and security properties of 578 different IPv6 address generation mechanisms. 580 7. IANA Considerations 582 This document does not require actions by IANA. 584 8. Acknowledgements 586 The authors would like to thank Bernard Aboba, Brian Carpenter, Tim 587 Chown, Lorenzo Colitti, Rich Draves, Robert Moskowitz, Erik Nordmark, 588 and James Woodyatt for providing valuable comments on earlier 589 versions of this document. 591 9. References 593 9.1. Normative References 595 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 596 Packets over Ethernet Networks", RFC 1972, August 1996. 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 602 Autoconfiguration", RFC 2462, December 1998. 604 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 605 Networks", RFC 2464, December 1998. 607 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 608 Stateless Address Autoconfiguration in IPv6", RFC 3041, 609 January 2001. 611 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 612 Generation Partnership Project (3GPP) Standards", RFC 613 3314, September 2002. 615 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 616 and M. Carney, "Dynamic Host Configuration Protocol for 617 IPv6 (DHCPv6)", RFC 3315, July 2003. 619 [RFC3484] Draves, R., "Default Address Selection for Internet 620 Protocol version 6 (IPv6)", RFC 3484, February 2003. 622 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 623 Neighbor Discovery (SEND)", RFC 3971, March 2005. 625 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 626 RFC 3972, March 2005. 628 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 629 Network Address Translations (NATs)", RFC 4380, February 630 2006. 632 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 633 Extensions for Stateless Address Autoconfiguration in 634 IPv6", RFC 4941, September 2007. 636 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 637 Security Updates", RFC 5991, September 2010. 639 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 640 April 2011. 642 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 643 "Default Address Selection for Internet Protocol Version 6 644 (IPv6)", RFC 6724, September 2012. 646 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 647 Interface Identifiers", RFC 7136, February 2014. 649 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 650 Interface Identifiers with IPv6 Stateless Address 651 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 653 9.2. Informative References 655 [Broersma] 656 Broersma, R., "IPv6 Everywhere: Living with a Fully 657 IPv6-enabled environment", Australian IPv6 Summit 2010, 658 Melbourne, VIC Australia, October 2010, October 2010, 659 . 662 [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. 664 [I-D.ietf-dhc-stable-privacy-addresses] 665 Gont, F. and W. Will, "A Method for Generating 666 Semantically Opaque Interface Identifiers with Dynamic 667 Host Configuration Protocol for IPv6 (DHCPv6)", draft- 668 ietf-dhc-stable-privacy-addresses-01 (work in progress), 669 February 2015. 671 [I-D.ietf-opsec-ipv6-host-scanning] 672 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 673 Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in 674 progress), February 2015. 676 [KAME-CGA] 677 KAME, "The KAME IPR policy and concerns of some 678 technologies which have IPR claims", 2005, 679 . 681 [Microsoft] 682 Microsoft, "IPv6 interface identifiers", 2013, . 686 [Panopticlick] 687 Electronic Frontier Foundation, "Panopticlick", 2011, 688 . 690 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 691 Morris, J., Hansen, M., and R. Smith, "Privacy 692 Considerations for Internet Protocols", RFC 6973, July 693 2013. 695 [RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu, 696 A., and A. Yourtchenko, "Analysis of the 64-bit Boundary 697 in IPv6 Addressing", RFC 7421, January 2015. 699 Authors' Addresses 701 Alissa Cooper 702 Cisco 703 707 Tasman Drive 704 Milpitas, CA 95035 705 US 707 Phone: +1-408-902-3950 708 Email: alcoop@cisco.com 709 URI: https://www.cisco.com/ 711 Fernando Gont 712 Huawei Technologies 713 Evaristo Carriego 2644 714 Haedo, Provincia de Buenos Aires 1706 715 Argentina 717 Phone: +54 11 4650 8472 718 Email: fgont@si6networks.com 719 URI: http://www.si6networks.com 721 Dave Thaler 722 Microsoft 723 Microsoft Corporation 724 One Microsoft Way 725 Redmond, WA 98052 727 Phone: +1 425 703 8835 728 Email: dthaler@microsoft.com