idnits 2.17.1 draft-cooper-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 (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-iab-privacy-considerations-03 == Outdated reference: A later version (-17) exists of draft-ietf-6man-stable-privacy-addresses-10 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-01 -- 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: January 16, 2014 Huawei Technologies 6 D. Thaler 7 Microsoft 8 July 15, 2013 10 Privacy Considerations for IPv6 Address Generation Mechanisms 11 draft-cooper-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 January 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4 59 3.1. Correlation of activities over time . . . . . . . . . . . 4 60 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Device-specific vulnerability exploitation . . . . . . . 6 63 4. Privacy and security properties of address generation 64 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Single-address scenarios . . . . . . . . . . . . . . . . 7 66 4.1.1. Static, manually configured address only . . . . . . 8 67 4.1.2. Cryptographically generated address only . . . . . . 8 68 4.1.3. Temporary address only . . . . . . . . . . . . . . . 8 69 4.1.4. Persistent random address only . . . . . . . . . . . 8 70 4.1.5. Random-per-network address only . . . . . . . . . . . 9 71 4.1.6. DHCPv6 address only . . . . . . . . . . . . . . . . . 9 72 4.2. Multiple-address scenarios . . . . . . . . . . . . . . . 9 73 4.2.1. Temporary addresses and IEEE-identifier-based address 10 74 4.2.2. Temporary addresses and persistent random address . . 11 75 4.2.3. Temporary addresses and random-per-network addresses 11 76 5. Other Privacy Issues . . . . . . . . . . . . . . . . . . . . 11 77 6. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 78 6.1. Network Operation . . . . . . . . . . . . . . . . . . . . 12 79 6.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 12 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 84 10. Informative References . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 88 IPv6 was designed to improve upon IPv4 in many respects, and 89 mechanisms for address assignment were one such area for improvement. 90 In addition to static address assignment and DHCP, stateless 91 autoconfiguration was developed as a less intensive, fate-shared 92 means of performing address assignment. With stateless 93 autoconfiguration, routers advertise on-link prefixes and hosts 94 generate their own interface identifiers (IIDs) to complete their 95 addresses. Over the years, many interface identifier generation 96 techniques have been defined, both standardized and non-standardized: 98 o Manual configuration 100 * IPv4 address 102 * Service port 104 * Wordy 106 * Low-byte 108 o Stateless Address Auto-Cofiguration (SLAAC) 110 * IEEE 802 48-bit MAC or IEEE EUI-64 identifier 111 [RFC1972][RFC2464] 113 * Cryptographically generated [RFC3972] 115 * Persistent random [Microsoft] 117 * Temporary (also known as "privacy addresses") [RFC4941] 119 * Random-per-network (also known as "stable privacy addresses") 120 [I-D.ietf-6man-stable-privacy-addresses] 122 o DHCPv6-based [RFC3315] 124 o Specified by transition/co-existence technologies 126 * IPv4 address and port [RFC4380] 128 Deriving the IID from a globally unique IEEE identifier [RFC2462] was 129 one of the earliest mechanisms developed. A number of privacy and 130 security issues related to the interface IDs derived from IEEE 131 identifiers were discovered after their standardization, and many of 132 the mechanisms developed later aimed to mitigate some or all of these 133 weaknesses. This document identifies four types of threats against 134 IEEE-identifier-based IIDs, and discusses how other existing 135 techniques for generating IIDs do or do not mitigate those threats. 137 2. Terminology 139 This section clarifies the terminology used throughout this document. 141 Stable address: 142 An address that does not vary over time within the same network. 143 Note that [RFC4941] refers to these as "public" addresses, but 144 "stable" is used here for reasons explained in Section 4.2. 146 Temporary address: 147 An address that varies over time within the same network. 149 Public address: 150 An address that has been published on some sort of directory 151 service, such as the DNS [RFC1034]. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 [RFC2119]. These words take their normative meanings only when they 157 are presented in ALL UPPERCASE. 159 3. Weaknesses in IEEE-identifier-based IIDs 161 There are a number of privacy and security implications that exist 162 for hosts that use IEEE-identifier-based IIDs. This section 163 discusses four generic attack types: correlation of activities over 164 time, location tracking, device-specific vulnerability exploitation, 165 and address scanning. The first three of these rely on the attacker 166 first gaining knowledge of the target host's IID. This can be 167 achieved by a number of different attackers: the operator of a server 168 to which the host connects, such as a web server or a peer-to-peer 169 server; an entity that connects to the same network as the target 170 (such as a conference network or any public network); or an entity 171 that is on-path to the destinations with which the host communicates, 172 such as a network operator. 174 3.1. Correlation of activities over time 176 As with other identifiers, an IPv6 address can be used to correlate 177 the activities of a host for at least as long as the lifetime of the 178 address. The correlation made possible by IEEE-identifier-based IIDs 179 is of particular concern because MAC addresses are much more 180 permanent than, say, DHCP leases. MAC addresses tend to last roughly 181 the lifetime of a device's network interface, allowing correlation on 182 the order of years, compared to days for DHCP. 184 As [RFC4941] explains, 185 "[t]he use of a non-changing interface identifier to form 186 addresses is a specific instance of the more general case where a 187 constant identifier is reused over an extended period of time and 188 in multiple independent activities. Anytime the same identifier 189 is used in multiple contexts, it becomes possible for that 190 identifier to be used to correlate seemingly unrelated activity. 191 ... The use of a constant identifier within an address is of 192 special concern because addresses are a fundamental requirement of 193 communication and cannot easily be hidden from eavesdroppers and 194 other parties. Even when higher layers encrypt their payloads, 195 addresses in packet headers appear in the clear." 197 IP addresses are just one example of information that can be used to 198 correlate activities over time. DNS names, cookies [RFC6265], 199 browser fingerprints [Panopticlick], and application-layer usernames 200 can all be used to link a host's activities together. Although IEEE- 201 identifier-based IIDs are likely to last at least as long or longer 202 than these other identifiers, IIDs generated in other ways may have 203 shorter or longer lifetimes than these identifiers depending on how 204 they are generated. Therefore, the extent to which a host's 205 activities can be correlated depends on whether the host uses 206 multiple identifiers together and the lifetimes of all of those 207 identifiers. Frequently refreshing an IPv6 address may not mitigate 208 correlation if an attacker has access to other longer lived 209 identifiers for a particular host. This is an important caveat to 210 keep in mind throughout the discussion of correlation in this 211 document. For further discussion of correlation, see Section 5.2.1 212 of [I-D.iab-privacy-considerations]. 214 3.2. Location tracking 216 Because the IPv6 address structure is divided between a topological 217 portion and an interface identifier portion, an interface identifier 218 that remains constant when a host connects to different networks (as 219 an IEEE-identifier-based IID does) provides a way for observers to 220 track the movements of that host. In a passive attack on a mobile 221 host, a server that receives connections from the same host over time 222 would be able to determine the host's movements as its prefix 223 changes. 225 Active attacks are also possible. An attacker that first learns the 226 host's interface identifier by being connected to the same network 227 segment, running a server that the host connects to, or being on-path 228 to the host's communications could subsequently probe other networks 229 for the presence of the same interface identifier by sending a probe 230 packet (ICMPv6 Echo Request, or any other probe packet). Even if the 231 host does not respond, the first hop router will usually respond with 232 an ICMP Address Unreachable when the host is not present, and be 233 silent when the host is present. 235 3.3. Address scanning 237 The structure of IEEE-based identifiers used for address generation 238 can be leveraged by an attacker to reduce the target search space 239 [I-D.ietf-opsec-ipv6-host-scanning]. The 24-bit Organizationally 240 Unique Identifier (OUI) of MAC addresses, together with the fixed 241 value (0xff, 0xfe) used to form a Modified EUI-64 Interface 242 Identifier, greatly help to reduce the search space, making it easier 243 for an attacker to scan for individual addresses using widely-known 244 popular OUIs. 246 3.4. Device-specific vulnerability exploitation 248 IPv6 addresses that embed IEEE identifiers leak information about the 249 device (Network Interface Card vendor, or even Operating System and/ 250 or software type), which could be leveraged by an attacker with 251 knowledge of device/software-specific vulnerabilities to quickly find 252 possible targets. Attackers can exploit vulnerabilities in hosts 253 whose IIDs they have previously obtained, or scan an address space to 254 find potential targets. 256 4. Privacy and security properties of address generation mechanisms 258 Analysis of the extent to which a particular host is protected 259 against the threats described in Section 3 depends on how each of a 260 host's IIDs is generated and used. In some scenarios, a host 261 configures a single global address and uses it for all 262 communications. In other scenarios, a host configures multiple 263 addresses using different mechanisms and may use any or all of them. 264 This section compares the privacy and security properties of a 265 variety of IID generation/use scenarios. The scenarios are grouped 266 according to whether one or more addresses are configured. The table 267 below provides a summary of the analysis. 269 +--------------+-------------+------------+------------+------------+ 270 | Mechanism(s) | Correlation | Location | Address | Device | 271 | | | tracking | scanning | exploits | 272 +--------------+-------------+------------+------------+------------+ 273 | Static | For address | For | NP | Depends on | 274 | manual only | lifetime | address | | generation | 275 | | | lifetime | | mechanism | 276 | | | | | | 277 | CGA only | Within | NP | NP | NP | 278 | | single | | | | 279 | | network | | | | 280 | | | | | | 281 | Temporary | NP | NP | NP | NP | 282 | only | | | | | 283 | | | | | | 284 | Persistent | For address | For | NP | NP | 285 | random only | lifetime | address | | | 286 | | | lifetime | | | 287 | | | | | | 288 | Random-per- | Within | NP | NP | NP | 289 | network only | single | | | | 290 | | network | | | | 291 | | | | | | 292 | Temporary | When IEEE- | Possible | Possible | Possible | 293 | and IEEE- | based is in | | | | 294 | based | use, or for | | | | 295 | | temp | | | | 296 | | address | | | | 297 | | lifetime | | | | 298 | | | | | | 299 | Temporary | When random | Possible | Possible | Possible | 300 | and | is in use, | | | | 301 | persistent | or for temp | | | | 302 | random | address | | | | 303 | | lifetime | | | | 304 | | | | | | 305 | Temporary | Within | NP | NP | NP | 306 | and random- | single | | | | 307 | per-network | network, or | | | | 308 | | for temp | | | | 309 | | address | | | | 310 | | lifetime | | | | 311 +--------------+-------------+------------+------------+------------+ 313 Legend: NP = Not possible 315 Table 1: Privacy and security properties of IPv6 address generation 316 mechanisms 318 4.1. Single-address scenarios 319 4.1.1. Static, manually configured address only 321 Because static, manually configured addresesses are persistent, both 322 correlation and location tracking are possible for the life of the 323 address. 325 The extent to which location tracking can be successfully performed 326 depends, to a some extent, on the uniqueness of the employed 327 Intarface ID. For example, one would expect "low byte" Interface IDs 328 to be more widely reused than, for example, Interface IDs where the 329 whole 64-bits follow some pattern that is unique to a specific 330 organization. Widely reused Interface IDs will typically lead to 331 false positives when performing location tracking. 333 Because they do not embed OUIs, manually configured addresses are not 334 vulnerable to device-specific exploitation. Whether they are 335 vulnerable to address scanning depends on the specifics of how they 336 are generated. 338 4.1.2. Cryptographically generated address only 340 Cryptographically generated addresses (CGAs) [RFC3972] bind a hash of 341 the host's public key to an IPv6 address in the SEcure Neighbor 342 Discovery (SEND) [RFC3971] protocol. CGAs are uniquely generated for 343 each subnet prefix, which means that correlation is possible within a 344 single network only. A host that stays connected to the same network 345 could therefore be tracked at length, whereas a mobile host's 346 activities could only be correlated for the duration of each network 347 connection. Location tracking is not possible with CGAs. CGAs also 348 do not allow device-specific exploitation or address scanning 349 attacks. 351 4.1.3. Temporary address only 353 A host that uses only a temporary address mitigates all four threats. 354 Its activities may only be correlated for the lifetime a single 355 address. 357 4.1.4. Persistent random address only 359 Although a mechanism to generate a static, random IID has not been 360 standardized, it has been in wide use for many years on at least one 361 platform (Windows). Windows uses the [RFC4941] random generation 362 mechanism in lieu of generating an IEEE-identifier-based IID. This 363 mitigates the device-specific exploitation and address scanning 364 attacks, but still allows correlation and location tracking because 365 the address is persistent across networks and time. 367 4.1.5. Random-per-network address only 369 [I-D.ietf-6man-stable-privacy-addresses] specifies a mechanism that 370 generates a unique random IID for each network. A host that stays 371 connected to the same network could therefore be tracked at length, 372 whereas a mobile host's activities could only be correlated for the 373 duration of each network connection. Location tracking is not 374 possible with these addresses. They also do not allow device- 375 specific exploitation or address scanning attacks. 377 4.1.6. DHCPv6 address only 379 TBD 381 4.2. Multiple-address scenarios 383 [RFC3041] (later obsoleted by [RFC4941]) sought to address some of 384 the problems described in Section 3 by defining "temporary addresses" 385 (commonly referred to as "privacy addresses") for outbound 386 connections. Temporary addresses are meant to supplement the other 387 IIDs that a device might use, not to replace them. They are randomly 388 generated and change daily by default. The idea was for temporary 389 addresses to be used for outgoing connections (e.g. web browsing) 390 while maintaining the ability to use a stable address when more 391 address stability is desired (e.g., in DNS advertisements). 393 [RFC3484] originally specified that stable addresses be used for 394 outbound connections unless an application explicitly prefers 395 temporary addresses. The default preference for stable addresses was 396 established to avoid applications potentially failing due to the 397 short lifetime of temporary addresses or the possibility of a reverse 398 look-up failure or error. However, [RFC3484] allowed that 399 "implementations for which privacy considerations outweigh these 400 application compatibility concerns MAY reverse the sense of this 401 rule" and instead prefer by default temporary addresses rather than 402 stable addresses. Indeed most implementations (notably including 403 Windows) chose to default to temporary addresses for outbound 404 connections since privacy was considered more important (and few 405 applications supported IPv6 at the time, so application compatibility 406 concerns were minimal). [RFC6724] then obsoleted [RFC3484] and 407 changed the default to match what implementations actually did. 409 The envisioned relationship in [RFC3484] between stability of an 410 address and its use in "public" can be misleading when conducting 411 privacy analysis. The stability of an address and the extent to 412 which it is linkable to some other public identifier are independent 413 of one another. For example, there is nothing that prevents a host 414 from publishing a temporary address in a public place, such as the 415 DNS. Publishing both a stable address and a temporary address in the 416 DNS or elsewhere where they can be linked together by a public 417 identifier allows the host's activities when using either address to 418 be correlated together. 420 Moreover, because temporary addresses were designed to supplement 421 other addresses generated by a host, the host may still configure a 422 more stable address even if it only ever intentionally uses temporary 423 addresses (as source addresses) for communication to off-link 424 destinations. An attacker can probe for the stable address even if 425 it is never used as such a source address or advertised (e.g., in DNS 426 or SIP) outside the link. 428 The scenarios in this section describe the privacy and security 429 properties in cases where a host configures both a temporary address 430 and an address generated via another mechanism. The analysis 431 distinguishes between cases when both addresses are used as source 432 addresses or are advertised off-link and cases where only the 433 temporary address is used in those manners. 435 [TO DO: Add in Temporary + manual, Temporary + DHCP, Temporary + 436 other link-layer-derived, Temporary + CGA, and perhaps re-arrange 437 this section to avoid repetition.] 439 4.2.1. Temporary addresses and IEEE-identifier-based address 441 By using an IEEE-identifier-based IID and temporary addresses, a host 442 can be vulnerable to the same attacks as if temporary addresses were 443 not in use, although the viability of some of them depends on how the 444 host uses each address. An attacker can correlate all of the host's 445 activities for which it uses its IEEE-identifier-based IID. Once an 446 attacker has obtained the IEEE-identifier-based IID, location 447 tracking becomes possible on other networks even if the host only 448 makes use of temporary addresses on those other networks; the 449 attacker can actively probe the other networks for the presence of 450 the IEEE-identifier-based IID. Device-specific vulnerabilities can 451 still be exploited. Address scanning is also still possible because 452 the IEEE-identifier-based address can be probed. 454 A host that configures but does not use an IEEE-identifier-based IID 455 is vulnerable to address scanning because the address can be probed 456 even if the IEEE-identifier-based address is otherwise never used. 457 Once an attacker has received such a response, it can exploit device- 458 specific vulnerabilities or probe other networks over time to track 459 the location of the host. Correlation over time, however, is 460 significantly mitigated, since the temporary addresses that the host 461 routinely uses on the network refresh often. 463 4.2.2. Temporary addresses and persistent random address 465 Using a persistent, random address as a stable address for server- 466 like connections together with temporary addresses for outbound 467 connections presents some improvements over the previous scenario. 468 The address scanning and device-specific exploitation attacks are no 469 longer possible because the OUI is no longer embedded in any of the 470 host's addresses. However, correlation of some activities across 471 time and location tracking are both still possible because the random 472 IID is persistent. As in Section 4.2.1, once an attacker has 473 obtained the host's random IID, location tracking is possible on any 474 network by probing for that IID, even if the host only uses temporary 475 addresses on those networks. 477 A host that configures but does not use a persistent random address 478 mitigates all four threats. Correlation is only possible for the 479 lifetime of a temporary address. The persistent random address 480 cannot be easily discovered in an address scan (although it is 481 available to an on-link adversary), which prevents an attacker from 482 using it for location tracking or device-specific exploitation. 484 4.2.3. Temporary addresses and random-per-network addresses 486 When used together with temporary addresses, the random-per-network 487 mechanism [I-D.ietf-6man-stable-privacy-addresses] improves upon the 488 previous scenario by limiting the potential for correlation to the 489 lifetime of the random-per-network address (which may still be 490 lengthy for hosts that are not mobile) and eliminating the 491 possibility for location tracking (since a different IID is generated 492 for each subnet prefix). 494 As in the previous scenario, a host that configures but does not use 495 a random-per-network address mitigates all four threats. 497 5. Other Privacy Issues 499 Since IPv6 subnets have unique prefixes, they reveal some information 500 about the location of the subnet, just as IPv4 addresses do. Hiding 501 this information is one motivation for usng NAT in IPv6 (see RFC 5902 502 section 2.4). 504 Teredo [RFC4380] specifies a means to generate an IPv6 address from 505 the underlying IPv4 address and port, leaving many other bits set to 506 zero. This makes it relatively easy for an attacker to scan for IPv6 507 addresses by guessing the Teredo client's IPv4 address and port 508 (which for many NATs is not randomized). For this reason, popular 509 implementations (e.g., Windows), began deviating from the standard by 510 including 12 random bits in place of zero bits. This modification 511 was later standardized in [RFC5991]. 513 6. Miscellaneous Issues with IPv6 addressing 515 6.1. Network Operation 517 It is generally agreed that IPv6 addresses that vary over time in a 518 specific network tend to increase the complexity of event logging, 519 trouble-shooting, enforcement of access controls and quality of 520 service, etc. As a result, some organizations disable the use of 521 temporary addresses [RFC4941] even at the expense of reduced privacy 522 [Broersma]. 524 6.2. Compliance 526 Major IPv6 compliance testing suites required (and still require) 527 implementations to support MAC-derived suffixes in order to be 528 approved as compliant. Implementations that fail to support MAC- 529 derived suffixes are therefore largely not eligible to receive the 530 benefits of compliance certification (e.g., use of the IPv6 logo, 531 eligibility for government contracts, etc.). This document 532 recommends that these be relaxed to allow other forms of address 533 generation that are more amenable to privacy. 535 6.3. Intellectual Property Rights (IPRs) 537 Some IPv6 addressing techniques might be covered by Intellectual 538 Property rights, which might limit their implementation in different 539 Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on 540 CGAs. 542 7. Security Considerations 544 This whole document concerns the privacy and security properties of 545 different IPv6 address generation mechanisms. 547 8. IANA Considerations 549 This document does not require actions by IANA. 551 9. Acknowledgements 553 The authors would like to thank Bernard Aboba and Rich Draves. 555 10. Informative References 557 [Broersma] 558 Broersma, R., "IPv6 Everywhere: Living with a Fully 559 IPv6-enabled environment", Australian IPv6 Summit 2010, 560 Melbourne, VIC Australia, October 2010, October 2010, 561 . 564 [CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005. 566 [I-D.iab-privacy-considerations] 567 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 568 Morris, J., Hansen, M., and R. Smith, "Privacy 569 Considerations for Internet Protocols", draft-iab-privacy- 570 considerations-03 (work in progress), July 2012. 572 [I-D.ietf-6man-stable-privacy-addresses] 573 Gont, F., "A method for Generating Stable Privacy-Enhanced 574 Addresses with IPv6 Stateless Address Autoconfiguration 575 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-10 576 (work in progress), June 2013. 578 [I-D.ietf-opsec-ipv6-host-scanning] 579 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 580 Networks", draft-ietf-opsec-ipv6-host-scanning-01 (work in 581 progress), April 2013. 583 [KAME-CGA] 584 KAME, "The KAME IPR policy and concerns of some 585 technologies which have IPR claims", 2005. 587 [Microsoft] 588 Microsoft, "IPv6 interface identifiers", 2013. 590 [Panopticlick] 591 Electronic Frontier Foundation, "Panopticlick", 2011. 593 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 594 STD 13, RFC 1034, November 1987. 596 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6 597 Packets over Ethernet Networks", RFC 1972, August 1996. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 603 Autoconfiguration", RFC 2462, December 1998. 605 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 606 Networks", RFC 2464, December 1998. 608 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 609 Stateless Address Autoconfiguration in IPv6", RFC 3041, 610 January 2001. 612 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 613 and M. Carney, "Dynamic Host Configuration Protocol for 614 IPv6 (DHCPv6)", RFC 3315, July 2003. 616 [RFC3484] Draves, R., "Default Address Selection for Internet 617 Protocol version 6 (IPv6)", RFC 3484, February 2003. 619 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 620 Neighbor Discovery (SEND)", RFC 3971, March 2005. 622 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 623 RFC 3972, March 2005. 625 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 626 Network Address Translations (NATs)", RFC 4380, February 627 2006. 629 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 630 Extensions for Stateless Address Autoconfiguration in 631 IPv6", RFC 4941, September 2007. 633 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 634 Security Updates", RFC 5991, September 2010. 636 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 637 April 2011. 639 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 640 "Default Address Selection for Internet Protocol Version 6 641 (IPv6)", RFC 6724, September 2012. 643 Authors' Addresses 645 Alissa Cooper 646 CDT 647 1634 Eye St. NW, Suite 1100 648 Washington, DC 20006 649 US 651 Phone: +1-202-637-9800 652 Email: acooper@cdt.org 653 URI: http://www.cdt.org/ 655 Fernando Gont 656 Huawei Technologies 657 Evaristo Carriego 2644 658 Haedo, Provincia de Buenos Aires 1706 659 Argentina 661 Phone: +54 11 4650 8472 662 Email: fgont@si6networks.com 663 URI: http://www.si6networks.com 665 Dave Thaler 666 Microsoft 667 Microsoft Corporation 668 One Microsoft Way 669 Redmond, WA 98052 671 Phone: +1 425 703 8835 672 Email: dthaler@microsoft.com