idnits 2.17.1 draft-ietf-6man-stable-privacy-addresses-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 (May 18, 2012) is 4362 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft UK CPNI 4 Intended status: Standards Track May 18, 2012 5 Expires: November 19, 2012 7 A method for Generating Stable Privacy-Enhanced Addresses with IPv6 8 Stateless Address Autoconfiguration (SLAAC) 9 draft-ietf-6man-stable-privacy-addresses-00 11 Abstract 13 This document specifies a method for generating IPv6 Interface 14 Identifiers to be used with IPv6 Stateless Address Autoconfiguration 15 (SLAAC), such that addresses configured using this method are stable 16 within each subnet, but the Interface Identifier changes when hosts 17 move from one network to another. The aforementioned method is meant 18 to be an alternative to generating Interface Identifiers based on 19 IEEE identifiers, such that the benefits of stable addresses can be 20 achieved without sacrificing the privacy of users. 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 November 19, 2012. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Design goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Algorithm specification . . . . . . . . . . . . . . . . . . . 6 59 4. Resolving Duplicate Address Detection (DAD) conflicts . . . . 9 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 66 Appendix A. Privacy issues still present with RFC 4941 . . . . . 15 67 A.1. Host tracking . . . . . . . . . . . . . . . . . . . . . . 15 68 A.1.1. Tracking hosts across networks #1 . . . . . . . . . . 15 69 A.1.2. Tracking hosts across networks #2 . . . . . . . . . . 16 70 A.1.3. Revealing the identity of a devices performing 71 server-like functions . . . . . . . . . . . . . . . . 16 72 A.2. Host scanning-attacks . . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 [RFC4862] specifies the Stateless Address Autoconfiguration (SLAAC) 78 for IPv6 [RFC2460], which typically results in hosts configuring one 79 or more "stable" addresses composed of a network prefix advertised by 80 a local router, and an Interface Identifier (IID) that typically 81 embeds a hardware address (e.g., using IEEE identifiers) [RFC4291]. 83 Generally, static addresses are thought to simplify network 84 management, since they simplify ACLs and logging. However, since 85 IEEE identifiers are typically globally unique, the resulting IPv6 86 addresses can be leveraged to track and correlate the activity of a 87 node over time and across multiple subnets and networks, thus 88 negatively affecting the privacy of users. 90 The "Privacy Extensions for Stateless Address Autoconfiguration in 91 IPv6" [RFC4941] were introduced to complicate the task of 92 eavesdroppers and other information collectors to correlate the 93 activities of a node, and basically result in temporary (and random) 94 Interface Identifiers that are typically more difficult to leverage 95 than those based on IEEE identifiers. When privacy extensions are 96 enabled, "privacy addresses" are employed for "outgoing 97 communications", while the traditional IPv6 addresses based on IEEE 98 identifiers are still used for "server" functions (i.e., receiving 99 incoming connections). 101 As noted in [RFC4941], "anytime a fixed identifier is used in 102 multiple contexts, it becomes possible to correlate seemingly 103 unrelated activity using this identifier". Therefore, since 104 "privacy addresses" [RFC4941] do not eliminate the use of fixed 105 identifiers for server-like functions, they only *partially* 106 mitigate the correlation of host activities (see Appendix A for 107 some example attacks that are still possible with privacy 108 addresses). Therefore, it is vital that the privacy 109 characteristics of "stable" addresses are improved such that the 110 ability of an attacker correlating host activities across networks 111 is reduced. 113 Another important aspect not mitigated by "Privacy Addresses" 114 [RFC4941] is that of host scanning. Since IPv6 addresses that 115 embed IEEE identifiers have specific patterns, an attacker could 116 leverage such patterns to greatly reduce the search space for 117 "live" hosts. Since "privacy addresses" do not eliminate the use 118 of IPv6 addresses that embed IEEE identifiers, host scanning 119 attacks are still feasible even if "privacy extensions" are 120 employed [Gont-DEEPSEC2011] [CPNI-IPv6]. This is yet another 121 motivation to improve the privacy characteristics of "stable" 122 addresses (currently embedding IEEE identifiers). 124 Privacy/temporary addresses can be challenging in a number of areas. 125 For example, from a network-management point of view, they tend to 126 increase the complexity of event logging, trouble-shooting, and 127 enforcing access controls and quality of service, etc. As a result, 128 some organizations disable the use of privacy addresses even at the 129 expense of reduced privacy [Broersma]. Also, they result in 130 increased complexity, which might not be possible or desirable in 131 some implementations (e.g., some embedded devices). 133 In scenarios in which "Privacy Extensions" are deliberately not used 134 (possibly for any of the aforementioned reasons), all a host is left 135 with is the addresses that have been generated using e.g. IEEE 136 identifiers, and this is yet another case in which it is also vital 137 that the privacy characteristics of these stable addresses are 138 improved. 140 We note that in most (if not all) of those scenarios in which 141 "Privacy Extensions" are disabled, there is usually no actual desire 142 to negatively affect user privacy, but rather a desire to simplify 143 operation of the network (simplify the use of ACLs, logging, etc.). 145 This document specifies a method to generate interface identifiers 146 that are stable/constant within each subnet, but that change as hosts 147 move from one network to another, thus keeping the "stability" 148 properties of the interface identifiers specified in [RFC4291], while 149 still mitigating host-scanning attacks and preventing correlation of 150 the activities of a node as it moves from one network to another. 152 For nodes that currently disable "Privacy extensions" [RFC4941] for 153 some of the reasons stated above, this mechanism provides stable 154 privacy-enhanced addresses which may already address most of the 155 privacy concerns related to addresses that embed IEEE identifiers 156 [RFC4291]. On the other hand, in scenarios in which "Privacy 157 Extensions" are employed, implementation of the mechanism described 158 in this document would mitigate host-scanning attacks and also 159 mitigate correlation of host activities. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 2. Design goals 167 This document specifies a method for selecting interface identifiers 168 to be used with IPv6 SLAAC, with the following goals: 170 o The resulting interface identifiers remain constant/stable for 171 each prefix used with SLAAC within each subnet. That is, the 172 algorithm generates the same interface identifier when configuring 173 an address belonging to the same prefix within the same subnet. 175 o The resulting interface identifiers do not depend on the 176 underlying hardware (e.g. link-layer address). This means that 177 e.g. replacing a Network Interface Card (NIC) will not have the 178 (generally undesirable) effect of changing the IPv6 addresses used 179 for that network interface. 181 o The resulting interface identifiers do change when addresses are 182 configured for different prefixes. That is, if different 183 autoconfiguration prefixes are used to configure addresses for the 184 same network interface card, the resulting interface identifiers 185 must be (statistically) different. 187 o It must be difficult for an outsider to predict the interface 188 identifiers that will be generated by the algorithm, even with 189 knowledge of the interface identifiers generated for configuring 190 other addresses. 192 o The aforementioned interface identifiers are meant to be an 193 alternative to those based on e.g. IEEE identifiers, such as 194 those specified in [RFC2464]. 196 We note that of use of the algorithm specified in this document is 197 (to a large extent) orthogonal to the use of "Privacy Extensions" 198 [RFC4941]. Hosts that do not implement/use "Privacy Extensions" 199 would have the benefit that they would not be subject to the host- 200 tracking and host scanning issues discussed in the previous section. 201 On the other hand, in the case of hosts employing "Privacy 202 Extensions", the method specified in this document would prevent host 203 scanning attacks and correlation of node activities across networks 204 (see Appendix A). 206 3. Algorithm specification 208 IPv6 implementations conforming to this specification MUST generate 209 interface identifiers using the algorithm specified in this section 210 in replacement of any other algorithms used for generating "stable" 211 addresses (such as that specified in [RFC2464]). The aforementioned 212 algorithm MUST be employed for generating the interface identifiers 213 for all of the IPv6 addresses configured with SLAAC for a given 214 interface, including IPv6 link-local addresses. Implementations 215 conforming to this specification SHOULD provide the means for a 216 system administrator to enable or disable the use of this algorithm 217 for generating Interface Identifiers. Implementations conforming to 218 this specification MAY employ the algorithm specified in [RFC4941] to 219 generate temporary addresses in addition to the addresses generated 220 with the algorithm specified in this document. 222 Unless otherwise noted, all of the parameters included in the 223 expression below MUST be included when generating an Interface ID. 225 1. Compute a random (but stable) identifier with the expression: 227 RID = F(Prefix, Interface_Index, Network_ID, DAD_Counter, 228 secret_key) 230 Where: 232 RID: 233 Random (but stable) identifier 235 F(): 236 A pseudorandom function (PRF) that is not computable from the 237 outside (without knowledge of the secret key). The PRF could 238 be implemented as a cryptographic hash of the concatenation of 239 each of the function parameters . 241 Prefix: 242 The prefix to be used for SLAAC, as learned from an ICMPv6 243 Router Advertisement message. 245 Interface_Index: 246 The interface index [RFC3493] [RFC3542] corresponding to this 247 network interface. 249 Network_ID: 250 Some network specific data that identifies the subnet to which 251 this interface is attached. For example the IEEE 802.11 SSID 252 corresponding to the network to which this interface is 253 associated. This parameter is OPTIONAL. 255 DAD_Counter: 256 A counter that is employed to resolve Duplicate Address 257 Detection (DAD) conflicts. It MUST be initialized to 0, and 258 incremented by 1 for each new tentative address that is 259 configured as a result of a DAD conflict. See Section 4 for 260 additional details. 262 secret_key: 263 A secret key that is not known by the attacker. The secret 264 key MUST be initialized at system installation time to the 265 concatenation of a pseudo-random number (see [RFC4086] for 266 randomness requirements for security) and the machine's serial 267 number. If the machine's serial number is not available, a 268 value of 0 should be used for it. An implementation MAY 269 provide the means for the user to change the secret key. 271 2. The Interface Identifier is finally obtained by taking the 272 leftmost 64 bits of the RID value computed in the previous step, 273 and and setting bit 6 (the leftmost bit is numbered 0) to zero. 274 This creates an interface identifier with the universal/local bit 275 indicating local significance only. 277 Note that the result of F() in the algorithm above is no more secure 278 than the secret key. If an attacker is aware of the PRF that is 279 being used by the victim (which we should expect), and the attacker 280 can obtain enough material (i.e. addresses configured by the victim), 281 the attacker may simply search the entire secret-key space to find 282 matches. To protect against this, the secret key should be of a 283 reasonable length. Key lengths of at least 128 bits should be 284 adequate. The secret key is initialized at installation time to the 285 concatenation of a pseudo-random number and the machine's serial 286 number. This allows this mechanism to be enabled/used automatically, 287 without user intervention. 289 The machine's serial number is concatenated to the pseudo-random 290 number, such that the entropy of the key is increased (since at 291 installation time the entropy of the Pseudo-Random Number 292 Generator might be reduced). 294 Including the SLAAC prefix in the PRF computation causes the 295 Interface ID to vary across networks that employ different prefixes, 296 thus mitigating host-tracking attacks and any other attacks that 297 benefit from predictable Interface IDs (such as host scanning). 299 Including the optional Network_ID parameter when computing the RID 300 value above would cause the algorithm to produce a different 301 Interface Identifier when connecting to different networks, even when 302 configuring addresses belonging to the same prefix. This means that 303 a host would employ a different Interface ID as it moves from one 304 network to another even for IPv6 link-local addresses or Unique Local 305 Addresses (ULAs). 307 Note that there are a number of ways in which these addresses 308 might leak out. For example, an attacker could use ICMPv6 Node 309 Information queries [RFC4620] to obtain such addresses. 311 4. Resolving Duplicate Address Detection (DAD) conflicts 313 If as a result of performing Duplicate Address Detection (DAD) 314 [RFC4862] a host finds that the tentative address generated with the 315 algorithm specified in Section 3 is a duplicate address, it MAY 316 resolve the address conflict by trying a new tentative address as 317 follows: 319 o DAD_Counter is incremented by 1. 321 o A new Interface ID is generated with the algorithm specified in 322 Section 3, using the incremented DAD_Counter value. 324 This procedure may be repeated a number of times until the address 325 conflict is resolved. However, hosts MUST limit the number of 326 tentative addresses that are tried (rather than indefinitely try a 327 new tentative address until the conflict is resolved). 329 In those (unlikely) scenarios in which duplicate addresses are 330 detected and in which the order in which the conflicting nodes 331 configure their addresses may vary (e.g., because they may be 332 bootstrapped in different order), the algorithm specified in this 333 section for resolving DAD conflicts could lead to addresses that are 334 not stable within the same subnet. In order to mitigate this 335 potential problem, nodes MAY record the DAD_Counter value employed 336 for a specific {Prefix, Interface_Index, Network_ID} tuple in non- 337 volatile memory, such that the same DAD_Counter value is employed 338 when configuring an address for the same Prefix and subnet at any 339 other point in time. 341 In the event that a DAD conflict cannot be solved (possibly after 342 trying a number of different addresses), address configuration would 343 fail. In those scenarios, nodes MUST NOT automatically fall back to 344 employing other algorithms for generating interface identifiers. 346 5. IANA Considerations 348 There are no IANA registries within this document. The RFC-Editor 349 can remove this section before publication of this document as an 350 RFC. 352 6. Security Considerations 354 This document specifies an algorithm for generating interface 355 identifiers to be used with IPv6 Stateless Address Autoconfiguration 356 (SLAAC), in replacement of e.g. interface identifiers that embed IEEE 357 identifiers (such as those specified in [RFC2464]). When compared to 358 such identifiers, the identifiers specified in this document have a 359 number of advantages: 361 o They prevent trivial host-tracking, since when a host moves from 362 one network to another the network prefix used for 363 autoconfiguration and/or the Network ID (e.g., IEEE 802.11 SSID) 364 will typically change, and hence the resulting interface 365 identifier will also change (see Appendix A. 367 o They mitigate host-scanning techniques which leverage predictable 368 interface identifiers (e.g., known Organizational Unique 369 Identifiers). 371 o They result in IPv6 addresses that are independent of the 372 underlying hardware (i.e. the resulting IPv6 addresses do not 373 change if a network interface card is replaced). 375 We note that this algorithm is meant to replace interface identifiers 376 such as those specified in [RFC2464], but not the temporary-addresses 377 such as those specified in [RFC4941]. Clearly, temporary addresses 378 may help to mitigate the correlation of activities of a node within 379 the same network, and may also reduce the attack exposure window 380 (since the lifetime of privacy/temporary IPv6 address is reduced when 381 compared to that of addresses generated with the method specified in 382 this document). We note that implementation of this algorithm would 383 still benefit those hosts employing "Privacy Addresses", since it 384 would mitigate host-tracking vectors still present when privacy 385 addresses are used (Appendix A, and would also mitigate host-scanning 386 techniques that leverage patterns in IPv6 addresses that embed IEEE 387 identifiers. 389 Finally, we note that the method described in this document may 390 mitigate most of the privacy concerns arising from the use of IPv6 391 addresses that embed IEEE identifiers, without the use of temporary 392 addresses, thus possibly offering an interesting trade-off for those 393 scenarios in which the use of temporary addresses is not feasible. 395 7. Acknowledgements 397 The author would like to thank (in alphabetical order) Karl Auer, 398 Steven Bellovin, Dominik Elsbroek, Bob Hinden, Christian Huitema, Ray 399 Hunter, Jong-Hyouk Lee, and Michael Richardson, for providing 400 valuable comments on earlier versions of this document. 402 This document is based on the technical report "Security Assessment 403 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 404 Fernando Gont on behalf of the UK Centre for the Protection of 405 National Infrastructure (CPNI). 407 Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for 408 their continued support. 410 8. References 412 8.1. Normative References 414 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 415 (IPv6) Specification", RFC 2460, December 1998. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 421 Requirements for Security", BCP 106, RFC 4086, June 2005. 423 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 424 Architecture", RFC 4291, February 2006. 426 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 427 Address Autoconfiguration", RFC 4862, September 2007. 429 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 430 Extensions for Stateless Address Autoconfiguration in 431 IPv6", RFC 4941, September 2007. 433 8.2. Informative References 435 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 436 Networks", RFC 2464, December 1998. 438 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 439 Stevens, "Basic Socket Interface Extensions for IPv6", 440 RFC 3493, February 2003. 442 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 443 "Advanced Sockets Application Program Interface (API) for 444 IPv6", RFC 3542, May 2003. 446 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 447 Queries", RFC 4620, August 2006. 449 [Gont-DEEPSEC2011] 450 Gont, "Results of a Security Assessment of the Internet 451 Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, 452 Vienna, Austria, November 2011, . 456 [Broersma] 457 Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- 458 enabled environment", Australian IPv6 Summit 2010, 459 Melbourne, VIC Australia, October 2010, 460 . 462 [CPNI-IPv6] 463 Gont, F., "Security Assessment of the Internet Protocol 464 version 6 (IPv6)", UK Centre for the Protection of 465 National Infrastructure, (available on request). 467 Appendix A. Privacy issues still present with RFC 4941 469 This aims to clarify the motivation of using the method specified in 470 this document even when privacy/temporary addresses are employed. It 471 has been incorporated in the document to clarify a number of 472 questions that arose during the presentation of this document at IETF 473 83 (Paris). This entire section might be removed prior to 474 publication of this document as an RFC. 476 A.1. Host tracking 478 Some 6man participants questioned the inclusion of the SLAAC prefix 479 in PRF function, and noted that the ID of "stable" addresses need not 480 change across networks, since privacy/temporary addresses already 481 mitigate host tracking. This section describes one possible attack 482 scenario that illustrates that host-tracking may still be possible 483 when privacy/temporary addresses are employed. 485 A.1.1. Tracking hosts across networks #1 487 A host configures the stable addresses without including the Prefix 488 in the F() (the PRF). The aforementioned host now runs any 489 application that needs to perform a server-like function (e.g. a 490 peer-to-peer application). As a result of that, an attacker/user 491 participating in the same application (e.g., P2P) would learn the 492 Interface-ID used for the stable address. 494 Some time later, the same host moves to a completely different 495 network, and uses the same P2P application, probably even with a 496 different user. The attacker now interacts with the same host again, 497 and hence can learn the "new" stable address. Since the interface ID 498 is the same as the one used before, the attacker can infer that it is 499 communicating with the same device as before. 501 Had the host included the Prefix when computing the Interface-ID 502 (with the hash function F()) as RECOMMENDED in this document, the 503 Interface-ID would have been different, and this privacy attack would 504 not have been possible. 506 This is just *one* possible attack scenario, which should remind us 507 that one should not disclose more than it is really needed for 508 achieving a specific goal (and an Interface-ID that is constant 509 across different networks does exactly that: it discloses more 510 information than is needed for providing a stable address). 512 A.1.2. Tracking hosts across networks #2 514 Once an attacker learns the fixed Interface-ID employed by the victim 515 host for its stable address, the attacker is able to "probe" a 516 network for the presence of such host at any given network. 518 See Appendix A.1.1 for just one example of how an attacker could 519 learn such prefix. Other examples include being able to share the 520 same network segment at some point in time (think about sharing a 521 conference network with 1000+ peers), etc. 523 For example, if an attacker learns that in one network the victim 524 used the prefix 1111:2222:3333:4444 for its stable addresses, then we 525 could subsequently probe for the presence of such device in the 526 network 2011:db8::/64 by sending a probe packet (ICMPv6 Echo Request, 527 or your favourite probe packet) to the address 2001:db8::1111:2222: 528 3333:4444. 530 A.1.3. Revealing the identity of a devices performing server-like 531 functions 533 Some devices may typically perform server-like functions and may be 534 usually moved from one network to another (e.g., from storage devices 535 to printers). Such devices are likely to simply disable (or not even 536 implement) privacy/temporary addresses [RFC4941]. If the 537 aforementioned devices employ Interface-IDs that are constant across 538 networks, it would be trivial for an attacker to tell whether the 539 same device is being used across networks by simply looking at the 540 Interface ID. Clearly, performing server-like should not imply that 541 a device discloses its identity (i.e., that the attacker can tell 542 whether it is the same device providing some function in two 543 different networks, at two different points in time. 545 The scheme proposed in this document prevents such information 546 leakage by causing nodes to generate different Interface-IDs when 547 moving to one network to another, thus mitigating this kind of 548 privacy attack. 550 A.2. Host scanning-attacks 552 While it is usually assumed that host-scanning attacks are 553 unfeasible, an attack can leverage patterns in IPv6 address 554 generation to greatly reduce the search space. 556 As noted earlier in this document, privacy/temporary addresses do not 557 eliminate the use of IPv6 addresses that embed IEEE identifiers, and 558 hence such hosts would still be vulnerable to host-scanning attacks 559 unless they eliminate the patterns introduced by embedding IEEE 560 identifiers in the Interface-ID. The method specified in this 561 document would mitigate the aforementioned host-scanning attacks. 563 Author's Address 565 Fernando Gont 566 UK CPNI 568 Email: fgont@si6networks.com 569 URI: http://www.cpni.gov.uk