idnits 2.17.1 draft-ietf-6man-ipv6-address-generation-privacy-08.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 (September 23, 2015) is 3131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Duplicate reference: RFC3972, mentioned in 'CGA-IPR', was also mentioned in 'RFC3972'. -- Obsolete informational reference (is this intentional?): RFC 1971 (Obsoleted by RFC 2462) -- Obsolete informational reference (is this intentional?): RFC 1972 (Obsoleted by RFC 2464) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 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: March 26, 2016 Huawei Technologies 6 D. Thaler 7 Microsoft 8 September 23, 2015 10 Privacy Considerations for IPv6 Address Generation Mechanisms 11 draft-ietf-6man-ipv6-address-generation-privacy-08.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 March 26, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . 13 74 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 [RFC2464] 115 * Cryptographically generated [RFC3972] 117 * Temporary (also known as "privacy addresses") [RFC4941] 119 * Constant, semantically opaque (also known as random) 120 [Microsoft] 122 * Stable, semantically opaque [RFC7217] 124 o DHCPv6-based [RFC3315] 126 o Specified by transition/co-existence technologies 128 * Derived from an IPv4 address (e.g., [RFC5214], [RFC6052]) 130 * Derived from an IPv4 address and port set ID (e.g., [RFC7596], 131 [RFC7597], [RFC7599]) 133 * Derived from an IPv4 address and port (e.g., [RFC4380]) 135 Deriving the IID from a globally unique IEEE identifier [RFC2464] 136 [RFC4862] was one of the earliest mechanisms developed (and 137 originally specified in [RFC1971] and [RFC1972]). A number of 138 privacy and security issues related to the IIDs derived from IEEE 139 identifiers were discovered after their standardization, and many of 140 the mechanisms developed later aimed to mitigate some or all of these 141 weaknesses. This document identifies four types of threats against 142 IEEE-identifier-based IIDs, and discusses how other existing 143 techniques for generating IIDs do or do not mitigate those threats. 145 2. Terminology 147 This section clarifies the terminology used throughout this document. 149 Public address: 150 An address that has been published in a directory or other public 151 location, such as the DNS, a SIP proxy [RFC3261], an application- 152 specific DHT, or a publicly available URI. A host's public 153 addresses are intended to be discoverable by third parties. 155 Stable address: 156 An address that does not vary over time within the same IPv6 link. 157 Note that [RFC4941] refers to these as "public" addresses, but 158 "stable" is used here for reasons explained in Section 4. 160 Temporary address: 161 An address that varies over time within the same IPv6 link. 163 Constant IID: 164 An IPv6 interface identifier that is globally stable. That is, 165 the Interface ID will remain constant even if the node moves from 166 one IPv6 link to another. 168 Stable IID: 169 An IPv6 interface identifier that is stable within some specified 170 context. For example, an Interface ID can be globally stable 171 (constant), or could be stable per IPv6 link (meaning that the 172 Interface ID will remain unchanged as long as a the node stays on 173 the same IPv6 link, but may change when the node moves from one 174 IPv6 link to another). 176 Temporary IID: 177 An IPv6 interface identifier that varies over time. 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in 182 [RFC2119]. These words take their normative meanings only when they 183 are presented in ALL UPPERCASE. 185 3. Weaknesses in IEEE-identifier-based IIDs 187 There are a number of privacy and security implications that exist 188 for hosts that use IEEE-identifier-based IIDs. This section 189 discusses four generic attack types: correlation of activities over 190 time, location tracking, address scanning, and device-specific 191 vulnerability exploitation. The first three of these rely on the 192 attacker first gaining knowledge of the IID of the target host. This 193 could be achieved by a number of different entities: the operator of 194 a server to which the host connects, such as a web server or a peer- 195 to-peer server; an entity that connects to the same IPv6 link as the 196 target (such as a conference network or any public network); a 197 passive observer of traffic that the host broadcasts; or an entity 198 that is on-path to the destinations with which the host communicates, 199 such as a network operator. 201 3.1. Correlation of activities over time 203 As with other identifiers, an IPv6 address can be used to correlate 204 the activities of a host for at least as long as the lifetime of the 205 address. The correlation made possible by IEEE-identifier-based IIDs 206 is of particular concern since they last roughly for the lifetime of 207 a device's network interface, allowing correlation on the order of 208 years. 210 As [RFC4941] explains, 212 "[t]he use of a non-changing interface identifier to form 213 addresses is a specific instance of the more general case where a 214 constant identifier is reused over an extended period of time and 215 in multiple independent activities. Anytime the same identifier 216 is used in multiple contexts, it becomes possible for that 217 identifier to be used to correlate seemingly unrelated activity. 218 ... The use of a constant identifier within an address is of 219 special concern because addresses are a fundamental requirement of 220 communication and cannot easily be hidden from eavesdroppers and 221 other parties. Even when higher layers encrypt their payloads, 222 addresses in packet headers appear in the clear." 224 IP addresses are just one example of information that can be used to 225 correlate activities over time. DNS names, cookies [RFC6265], 226 browser fingerprints [Panopticlick], and application-layer usernames 227 can all be used to link a host's activities together. Although IEEE- 228 identifier-based IIDs are likely to last at least as long or longer 229 than these other identifiers, IIDs generated in other ways may have 230 shorter or longer lifetimes than these identifiers depending on how 231 th ey are generated. Therefore, the extent to which a host's 232 activities can be correlated depends on whether the host uses 233 multiple identifiers together and the lifetimes of all of those 234 identifiers. Frequently refreshing an IPv6 address may not mitigate 235 correlation if an attacker has access to other longer lived 236 identifiers for a particular host. This is an important caveat to 237 keep in mind throughout the discussion of correlation in this 238 document. For further discussion of correlation, see Section 5.2.1 239 of [RFC6973]. 241 As noted in [RFC4941], in some cases correlation is just as feasible 242 for a host using an IPv4 address as for a host using an IEEE 243 identifier to generate its IID in its IPv6 address. Hosts that use 244 static IPv4 addressing or who are consistently allocated the same 245 address via DHCPv4 can be tracked as described above. However, the 246 widespread use of both NAT and DHCPv4 implementations that assign the 247 same host a different address upon lease expiration mitigates this 248 threat in the IPv4 case as compared to the IEEE identifier case in 249 IPv6. 251 3.2. Location tracking 253 Because the IPv6 address structure is divided between a topological 254 portion and an interface identifier portion, an interface identifier 255 that remains constant when a host connects to different IPv6 links 256 (as an IEEE-identifier-based IID does) provides a way for observers 257 to track the movements of that host. In a passive attack on a mobile 258 host, a server that receives connections from the same host over time 259 would be able to determine the host's movements as its prefix 260 changes. 262 Active attacks are also possible. An attacker that first learns the 263 host's interface identifier by being connected to the same IPv6 link, 264 running a server that the host connects to, or being on-path to the 265 host's communications could subsequently probe other networks for the 266 presence of the same interface identifier by sending a probe packet 267 (ICMPv6 Echo Request, or any other probe packet). Even if the host 268 does not respond, the first hop router will usually respond with an 269 ICMP Destination Unreachable/Address Unreachable (type 1, code 3) 270 when the host is not present, and be silent when the host is present. 272 Location tracking based on IP address is generally not possible in 273 IPv4 since hosts get assigned wholly new addresses when they change 274 networks. 276 3.3. Address scanning 278 The structure of IEEE-based identifiers used for address generation 279 can be leveraged by an attacker to reduce the target search space 280 [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally 281 Unique Identifier (OUI) of MAC addresses, together with the fixed 282 value (0xff, 0xfe) used to form a Modified EUI-64 interface 283 identifier, greatly help to reduce the search space, making it easier 284 for an attacker to scan for individual addresses using widely-known 285 popular OUIs. This erases much of the protection against address 286 scanning that the larger IPv6 address space could provide as compared 287 to IPv4. 289 3.4. Device-specific vulnerability exploitation 291 IPv6 addresses that embed IEEE identifiers leak information about the 292 device (Network Interface Card vendor, or even Operating System and/ 293 or software type), which could be leveraged by an attacker with 294 knowledge of device/software-specific vulnerabilities to quickly find 295 possible targets. Attackers can exploit vulnerabilities in hosts 296 whose IIDs they have previously obtained, or scan an address space to 297 find potential targets. 299 4. Privacy and security properties of address generation mechanisms 301 Analysis of the extent to which a particular host is protected 302 against the threats described in Section 3 depends on how each of a 303 host's addresses is generated and used. In some scenarios, a host 304 configures a single global address and uses it for all 305 communications. In other scenarios, a host configures multiple 306 addresses using different mechanisms and may use any or all of them. 308 [RFC3041] (later obsoleted by [RFC4941]) sought to address some of 309 the problems described in Section 3 by defining "temporary addresses" 310 for outbound connections. Temporary addresses are meant to 311 supplement the other addresses that a device might use, not to 312 replace them. They use IIDs that are randomly generated and change 313 daily by default. The idea was for temporary addresses to be used 314 for outgoing connections (e.g., web browsing) while maintaining the 315 ability to use a stable address when more address stability is 316 desired (e.g., for IPv6 addresses published in the DNS). 318 [RFC3484] originally specified that stable addresses be used for 319 outbound connections unless an application explicitly prefers 320 temporary addresses. The default preference for stable addresses was 321 established to avoid applications potentially failing due to the 322 short lifetime of temporary addresses or the possibility of a reverse 323 look-up failure or error. However, [RFC3484] allowed that 324 "implementations for which privacy considerations outweigh these 325 application compatibility concerns MAY reverse the sense of this 326 rule" and instead prefer by default temporary addresses rather than 327 stable addresses. Indeed most implementations (notably including 328 Windows) chose to default to temporary addresses for outbound 329 connections since privacy was considered more important (and few 330 applications supported IPv6 at the time, so application compatibility 331 concerns were minimal). [RFC6724] then obsoleted [RFC3484] and 332 changed the default to match what implementations actually did. 334 The envisioned relationship in [RFC3484] between stability of an 335 address and its use in "public" can be misleading when conducting 336 privacy analysis. The stability of an address and the extent to 337 which it is linkable to some other public identifier are independent 338 of one another. For example, there is nothing that prevents a host 339 from publishing a temporary address in a public place, such as the 340 DNS. Publishing both a stable address and a temporary address in the 341 DNS or elsewhere where t hey can be linked together by a public 342 identifier allows the host's activities when using either address to 343 be correlated together. 345 Moreover, because temporary addresses were designed to supplement 346 other addresses generated by a host, the host may still configure a 347 more stable address even if it only ever intentionally uses temporary 348 addresses (as source addresses) for communication to off-link 349 destinations. An attacker can probe for the stable address even if 350 it is never used as such a source address or advertised (e.g., in DNS 351 or SIP) outside the link. 353 This section compares the privacy and security properties of a 354 variety of IID generation mechanisms and their possible usage 355 scenarios, including scenarios in which a single mechanism is used to 356 generate all of a host's IIDs and those in which temporary addresses 357 are used together with addresses generated using a different IID 358 generation mechanism. The analysis of the exposure of each IID type 359 to correlation assumes that IPv6 prefixes are shared by a reasonably 360 large number of nodes. As [RFC4941] notes, if a very small number of 361 nodes (say, only one) use a particular prefix for an extended period 362 of time, the prefix itself can be used to correlate the host's 363 activities regardless of how the IID is generated. For example, 364 [RFC3314] recommends that prefixes be uniquely assigned to mobile 365 handsets where IPv6 is used within GPRS. In cases where this advice 366 is followed and prefixes persist for extended periods of time (or get 367 reassigned to the same handsets whenever those hand sets reconnect to 368 the same network router), hosts' activities could be correlatable for 369 longer periods than the analysis below would suggest. 371 The table below provides a summary of the whole analysis. A "No" 372 entry indicates that the attack is prevented from being carried out 373 on the basis of the IID, but the host may still be vulnerable 374 depending on how it employs other protocols. 376 +--------------+-------------+----------+-------------+-------------+ 377 | Mechanism(s) | Correlation | Location | Address | Device | 378 | | | tracking | scanning | exploits | 379 +--------------+-------------+----------+-------------+-------------+ 380 | IEEE | For device | For | Possible | Possible | 381 | identifier | lifetime | device | | | 382 | | | lifetime | | | 383 | | | | | | 384 | Static | For address | For | Depends on | Depends on | 385 | manual | lifetime | address | generation | generation | 386 | | | lifetime | mechanism | mechanism | 387 | | | | | | 388 | Constant, | For address | For | No | No | 389 | semantically | lifetime | address | | | 390 | opaque | | lifetime | | | 391 | | | | | | 392 | CGA | For | No | No | No | 393 | | lifetime of | | | | 394 | | (modifier | | | | 395 | | block + | | | | 396 | | public key) | | | | 397 | | | | | | 398 | Stable, | Within | No | No | No | 399 | semantically | single IPv6 | | | | 400 | opaque | link | | | | 401 | | | | | | 402 | Temporary | For temp | No | No | No | 403 | | address | | | | 404 | | lifetime | | | | 405 | | | | | | 406 | DHCPv6 | For lease | No | Depends on | No | 407 | | lifetime | | generation | | 408 | | | | mechanism | | 409 +--------------+-------------+----------+-------------+-------------+ 411 Table 1: Privacy and security properties of IID generation mechanisms 413 4.1. IEEE-identifier-based IIDs 415 As discussed in Section 3, addresses that use IIDs based on IEEE 416 identifiers are vulnerable to all four threats. They allow 417 correlation and location tracking for the lifetime of the device 418 since IEEE identifiers last that long and their structure makes 419 address scanning and device exploits possible. 421 4.2. Static, manually configured IIDs 423 Because static, manually configured IIDs are stable, both correlation 424 and location tracking are possible for the life of the address. 426 The extent to which location tracking can be successfully performed 427 depends, to a some extent, on the uniqueness of the employed IID. 428 For example, one would expect "low byte" IIDs to be more widely 429 reused than, for example, IIDs where the whole 64-bits follow some 430 pattern that is unique to a specific organization. Widely reused 431 IIDs will typically lead to false positives when performing location 432 tracking. 434 Whether manually configured addresses are vulnerable to address 435 scanning and device exploits depends on the specifics of how the IIDs 436 are generated. 438 4.3. Constant, semantically opaque IIDs 440 Although a mechanism to generate a constant, semantically opaque IID 441 has not been standardized, it has been in wide use for many years on 442 at least one platform (Windows). Windows uses the [RFC4941] random 443 generation mechanism in lieu of generating an IEEE-identifier-based 444 IID. This mitigates the device-specific exploitation and address 445 scanning attacks, but still allows correlation and location tracking 446 because the IID is constant across IPv6 links and time. 448 4.4. Cryptographically generated IIDs 450 Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of 451 the host's public key to an IPv6 address in the SEcure Neighbor 452 Discovery (SEND) [RFC3971] protocol. CGAs may be regenerated for 453 each subnet prefix, but this is not required given that they are 454 computationally expensive to generate. A host using a CGA can be 455 correlated for as long as the lifetime of the combination of the 456 public key and the chosen modifier block, since it is possible to 457 rotate modifier blocks without generating new public keys. Because 458 the cryptographic hash of the host's public key uses the subnet 459 prefix as an input, even if the host does not generate a new public 460 key or modifier block when it moves to a different IPv6 link, its 461 location cannot be tracked via the IID. CGAs do not allow device- 462 specific exploitation or address scanning attacks. 464 4.5. Stable, semantically opaque IIDs 466 [RFC7217] specifies an algorithm that generates, for each network 467 interface, a unique random IID per IPv6 link. The aforementioned 468 algorithm is employed not only for global unicast addresses, but also 469 for unique local unicast addresses and link-local unicast addresses, 470 since these addresses may leak out via application protocols (e.g., 471 IPv6 addresses embedded in email headers). 473 A host that stays connected to the same IPv6 link could therefore be 474 tracked at length, whereas a mobile host's activities could only be 475 correlated for the duration of each network connection. Location 476 tracking is not possible with these addresses. They also do not 477 allow device-specific exploitation or address scanning attacks. 479 4.6. Temporary IIDs 481 A host that uses only a temporary address mitigates all four threats. 482 Its activities may only be correlated for the lifetime a single 483 temporary address. 485 A host that configures both an IEEE-identifier-based IID and 486 temporary addresses makes the host vulnerable to the same attacks as 487 if temporary addresses were not in use, although the viability of 488 some of them depends on how the host uses each address. An attacker 489 can correlate all of the host's activities for which it uses its 490 IEEE-identifier-based IID. Once an attacker has obtained the IEEE- 491 identifier-based IID, location tracking becomes possible on other 492 IPv6 links even if the host only makes use of temporary addresses on 493 those other IPv6 links; the attacker can actively probe the other 494 IPv6 links for the presence of the IEEE-identifier-based IID. 495 Device-specific vulnerabilities can still be exploited. Address 496 scanning is also still possible because the IEEE-identifier-based 497 address can be probed. 499 If the host instead generates a constant, semantically opaque IID to 500 use in a stable address for server-like connections together with 501 temporary addresses for outbound connections (as is the default in 502 Windows), it sees some improvements over the previous scenario. The 503 address scanning and device-specific exploitation attacks are no 504 longer possible because the OUI is no longer embedded in any of the 505 host's addresses. However, correlation of some activities across 506 time and location tracking are both s till possible because the 507 semantically opaque IID is constant. And once an attacker has 508 obtained the host's semantically opaque IID, location tracking is 509 possible on any network by probing for that IID, even if the host 510 only uses temporary addresses on those networks. However, if the 511 host generates but never uses a constant, semantically opaque IID, it 512 mitigates all four threats. 514 When used together with temporary addresses, the stable, semantically 515 opaque IID generation mechanism [RFC7217] improves upon the previous 516 scenario by limiting the potential for correlation to the lifetime of 517 the stable address (which may still be lengthy for hosts that are not 518 mobile) and by eliminating the possibility for location tracking 519 (since a different IID is generated for each subnet prefix). As in 520 the previous scenario, a host that configures but does not use a 521 stable, semant ically opaque address mitigates all four threats. 523 4.7. DHCPv6 generation of IIDs 525 The security/privacy implications of DHCPv6-based addresses will 526 typically depend on whether the client requests an IA_NA (Identity 527 Association for Non-temporary Addresses) or an IA_TA ( Identity 528 Association for Temporary Addresses) [RFC3315] and the specific 529 DHCPv6 server software being employed. 531 DHCPv6 temporary addresses have the same properties as SLAAC 532 temporary addresses Section 4.6 [RFC4941]. On the other hand, the 533 properties of DHCPv6 non-temporary addresses typically depend on the 534 specific DHCPv6 server software being employed. Recent releases of 535 most popular DHCPv6 server software typically lease random addresses 536 with a similar lease time as that of IPv4. Thus, these addresses can 537 be considered to be "stable, semantically opaque". 538 [I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that 539 can be employed by DHCPv6 servers to generate "stable, semantically 540 opaque" addresses. 542 On the other hand, some DHCPv6 software leases sequential addresses 543 (typically low-byte addresses). These addresses can be considered to 544 be stable addresses. The drawback of this address generation scheme 545 compared to "stable, semantically opaque" addresses is that, since 546 they follow specific patterns, they enable IPv6 address scans. 548 4.8. Transition/co-existence technologies 550 Addresses specified based on transition/co-existence technologies 551 that embed an IPv4 address within an IPv6 address are not included in 552 Table 1 because their privacy and security properties are inherited 553 from the embedded address. For example, Teredo [RFC4380] specifies a 554 means to generate an IPv6 address from the underlying IPv4 address 555 and port, leaving many other bits set to zero. This makes it 556 relatively easy for an attacker to scan for IPv6 addresses by 557 guessing the Teredo client's IPv4 address and port (which for many 558 NATs is not randomized). For this reason, popular implementations 559 (e.g., Windows), began deviating from the standard by including 12 560 random bits in place of zero bits. This modification was later 561 standardized in [RFC5991]. 563 Some other transition technologies (e.g., [RFC5214], [RFC6052]) 564 specify means to generate an IPv6 address from an underlying IPv4 565 address without a port. Such mechanisms thus make it much easier for 566 an attacker to conduct an address scan than for mechanisms that 567 require finding a port number as well. 569 Finally, still other mechanisms (e.g., [RFC7596], [RFC7597], 570 [RFC7599]) are somewhere in between, using an IPv4 address and a port 571 set ID (which for many NATs is not randomized). In general, such 572 mechanisms are thus typically as easy to scan as in the Teredo 573 example above without the 12-bit mitigation. 575 5. Miscellaneous Issues with IPv6 addressing 577 5.1. Network Operation 579 It is generally agreed that IPv6 addresses that vary over time in a 580 specific IPv6 link tend to increase the complexity of event logging, 581 trouble-shooting, enforcement of access controls and quality of 582 service, etc. As a result, some organizations disable the use of 583 temporary addresses [RFC4941] even at the expense of reduced privacy 584 [Broersma]. 586 5.2. Compliance 588 Some IPv6 compliance testing suites required (and might still 589 require) implementations to support IEEE-identifier-based IIDS in 590 order to be approved as compliant. This document recommends that 591 compliance testing suites be relaxed to allow other forms of address 592 generation that are more amenable to privacy. 594 5.3. Intellectual Property Rights (IPRs) 596 Some IPv6 addressing techniques might be covered by Intellectual 597 Property rights, which might limit their implementation in different 598 Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on 599 CGAs. 601 6. Security Considerations 603 This whole document concerns the privacy and security properties of 604 different IPv6 address generation mechanisms. 606 7. IANA Considerations 608 This document does not require actions by IANA. 610 8. Acknowledgements 612 The authors would like to thank Bernard Aboba, Brian Carpenter, Tim 613 Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz, 614 Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for 615 providing valuable comments on earlier versions of this document. 617 9. References 619 9.1. Normative References 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, 623 DOI 10.17487/RFC2119, March 1997, 624 . 626 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 627 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 628 . 630 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 631 C., and M. Carney, "Dynamic Host Configuration Protocol 632 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 633 2003, . 635 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 636 "SEcure Neighbor Discovery (SEND)", RFC 3971, 637 DOI 10.17487/RFC3971, March 2005, 638 . 640 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 641 RFC 3972, DOI 10.17487/RFC3972, March 2005, 642 . 644 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 645 Network Address Translations (NATs)", RFC 4380, 646 DOI 10.17487/RFC4380, February 2006, 647 . 649 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 650 Address Autoconfiguration", RFC 4862, 651 DOI 10.17487/RFC4862, September 2007, 652 . 654 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 655 Extensions for Stateless Address Autoconfiguration in 656 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 657 . 659 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 660 Security Updates", RFC 5991, DOI 10.17487/RFC5991, 661 September 2010, . 663 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 664 "Default Address Selection for Internet Protocol Version 6 665 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 666 . 668 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 669 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, 670 February 2014, . 672 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 673 Interface Identifiers with IPv6 Stateless Address 674 Autoconfiguration (SLAAC)", RFC 7217, 675 DOI 10.17487/RFC7217, April 2014, 676 . 678 9.2. Informative References 680 [Broersma] 681 Broersma, R., "IPv6 Everywhere: Living with a Fully 682 IPv6-enabled environment", Australian IPv6 Summit 2010, 683 Melbourne, VIC Australia, October 2010, October 2010, 684 . 687 [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005, 688 . 690 [I-D.ietf-dhc-stable-privacy-addresses] 691 Gont, F. and S. LIU, "A Method for Generating Semantically 692 Opaque Interface Identifiers with Dynamic Host 693 Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- 694 stable-privacy-addresses-02 (work in progress), April 695 2015. 697 [I-D.ietf-opsec-ipv6-host-scanning] 698 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 699 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 700 progress), August 2015. 702 [KAME-CGA] 703 KAME, "The KAME IPR policy and concerns of some 704 technologies which have IPR claims", 2005, 705 . 707 [Microsoft] 708 Microsoft, "IPv6 interface identifiers", 2013, . 712 [Panopticlick] 713 Electronic Frontier Foundation, "Panopticlick", 2011, 714 . 716 [RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address 717 Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August 718 1996, . 720 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 721 Packets over Ethernet Networks", RFC 1972, 722 DOI 10.17487/RFC1972, August 1996, 723 . 725 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 726 Stateless Address Autoconfiguration in IPv6", RFC 3041, 727 DOI 10.17487/RFC3041, January 2001, 728 . 730 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 731 A., Peterson, J., Sparks, R., Handley, M., and E. 732 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 733 DOI 10.17487/RFC3261, June 2002, 734 . 736 [RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third 737 Generation Partnership Project (3GPP) Standards", 738 RFC 3314, DOI 10.17487/RFC3314, September 2002, 739 . 741 [RFC3484] Draves, R., "Default Address Selection for Internet 742 Protocol version 6 (IPv6)", RFC 3484, 743 DOI 10.17487/RFC3484, February 2003, 744 . 746 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 747 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 748 DOI 10.17487/RFC5214, March 2008, 749 . 751 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 752 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 753 DOI 10.17487/RFC6052, October 2010, 754 . 756 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 757 DOI 10.17487/RFC6265, April 2011, 758 . 760 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 761 Morris, J., Hansen, M., and R. Smith, "Privacy 762 Considerations for Internet Protocols", RFC 6973, 763 DOI 10.17487/RFC6973, July 2013, 764 . 766 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 767 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 768 Boundary in IPv6 Addressing", RFC 7421, 769 DOI 10.17487/RFC7421, January 2015, 770 . 772 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 773 Farrer, "Lightweight 4over6: An Extension to the Dual- 774 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 775 July 2015, . 777 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 778 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 779 Port with Encapsulation (MAP-E)", RFC 7597, 780 DOI 10.17487/RFC7597, July 2015, 781 . 783 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 784 and T. Murakami, "Mapping of Address and Port using 785 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 786 2015, . 788 Authors' Addresses 790 Alissa Cooper 791 Cisco 792 707 Tasman Drive 793 Milpitas, CA 95035 794 US 796 Phone: +1-408-902-3950 797 Email: alcoop@cisco.com 798 URI: https://www.cisco.com/ 799 Fernando Gont 800 Huawei Technologies 801 Evaristo Carriego 2644 802 Haedo, Provincia de Buenos Aires 1706 803 Argentina 805 Phone: +54 11 4650 8472 806 Email: fgont@si6networks.com 807 URI: http://www.si6networks.com 809 Dave Thaler 810 Microsoft 811 Microsoft Corporation 812 One Microsoft Way 813 Redmond, WA 98052 815 Phone: +1 425 703 8835 816 Email: dthaler@microsoft.com