idnits 2.17.1 draft-gont-6man-address-usage-recommendations-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 477, but not defined ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-04) exists of draft-gont-6man-non-stable-iids-01 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 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 SI6 Networks / UTN-FRH 4 Intended status: Best Current Practice G. Gont 5 Expires: January 4, 2018 SI6 Networks 6 M. Garcia Corbo 7 SITRANS 8 C. Huitema 9 Private Octopus Inc. 10 July 3, 2017 12 IPv6 Address Usage Recommendations 13 draft-gont-6man-address-usage-recommendations-03 15 Abstract 17 This document analyzes the security and privacy implications of IPv6 18 addresses based on a number of properties such as address scope, 19 stability, and usage type. It analyzes what properties are desirable 20 for some popular scenarios, and provides advice regarding the 21 configuration and usage of such addresses. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Issues Associated with Sub-optimal IPv6 Address Usage . . 4 62 4.1.1. Testing for the Presence of Node in the Network . . . 4 63 4.1.2. Unexpected Address Discovery . . . . . . . . . . . . 4 64 4.1.3. Availability Outside the Expected Scope . . . . . . . 5 65 4.2. Current Limitations in the Address Selection API . . . . 5 66 5. IPv6 Address Considerations . . . . . . . . . . . . . . . . . 6 67 5.1. Address Scope Considerations . . . . . . . . . . . . . . 6 68 5.2. Address Stability Considerations . . . . . . . . . . . . 6 69 5.3. Usage Type Considerations . . . . . . . . . . . . . . . . 8 70 6. Possible Approaches for IPv6 Address Usage . . . . . . . . . 9 71 7. Advice on IPv6 Address Configuration . . . . . . . . . . . . 10 72 8. Advice on IPv6 Address Usage . . . . . . . . . . . . . . . . 10 73 9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 13.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 IPv6 hosts typically configure a number of IPv6 addresses, which may 85 differ in multiple aspects, such as address scope and stability (e.g. 86 stable addresses vs. temporary addresses). For example, a host may 87 configure one stable and one temporary address per each 88 autoconfiguration prefix advertised on the local network. The 89 addresses to be configured typically depend on local system policy 90 configuration, with the aforementioned policy being static and 91 irrespective of the network the host attaches to. 93 There are three parameters that affect the security and privacy 94 properties of an address: 96 o Scope 97 o Stability 99 o Usage type (client-like "outgoing connections" vs. server-like 100 "incoming connections") 102 Section 5.1, Section 5.2, and Section 5.3 discuss the security and 103 privacy implications (and associated tradeoffs) of the scope, 104 stability and usage type properties of IPv6 addresses, respectively. 106 2. Terminology 108 This document employs the definitions of "public address", "stable 109 address", and "temporary address" from Section 2 of [RFC7721]. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 3. Background 117 Predictable IPv6 addresses result in a number of security and privacy 118 implications. For example, [Barnes2012] discusses how patterns in 119 network prefixes can be leveraged for IPv6 address scanning. On the 120 other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security 121 and privacy implications of predictable IPv6 Interface Identifiers 122 (IIDs). 124 Given the aforementioned previous work in this area, and the formal 125 specification update produced by [RFC8064], we expect (and assume in 126 the rest of this document) that implementations have replaced any 127 schemes that produce predictable addresses with alternative schemes 128 that avoid such patterns (e.g., RFC7217 in replacement of the 129 traditional SLAAC addresses that embed link-layer addresses). 131 4. Problem Statement 133 Applications use system API's to select the IPv6 addresses that will 134 be used for incoming and outgoing connections. This choices have 135 consequences in terms of privacy, security, stability and 136 performance. 138 Default Address Selection for IPv6 is specified in [RFC6724]. The 139 selection starts with a set of potential destination addresses, such 140 as returned by getaddrinfo(), and the set of potential source 141 addresses currently configured for the selected interfaces. For each 142 potential destination address, the algorithm will select the source 143 address that provides the best route to the destination, while 144 choosing the appropriate scope and preferring temporary addresses. 146 The algorithm will then select the destination address, while giving 147 a preference to reachable addresses with the smallest scope. The 148 selection may be affected by system settings. 150 We note that [RFC6724] only applies for outgoing connections, such as 151 those made by clients trying to use services offered by other hosts. 152 When devices provide a service, the common pattern is to just wait 153 for connections over all addresses configured on the device. For 154 example, applications using the Sockets API will commonly bind() the 155 listening socket to undefined address. This long-established 156 behavior is appropriate for devices providing public services, but 157 may have unexpected results for devices providing semi-private 158 services, such as various forms of peer-to-peer or local-only 159 applications. 161 This behavior leads to three problems: device tracking, discussed in 162 Section 4.1.1; unexpected address discovery, discussed in 163 Section 4.1.2; and availability outside the expected scope, discussed 164 in Section 4.1.3. These problems are caused in part by the 165 limitations of available address selection API, presented in 166 Section 4.2. 168 4.1. Issues Associated with Sub-optimal IPv6 Address Usage 170 4.1.1. Testing for the Presence of Node in the Network 172 The stable addresses recommended in [RFC8064] use stable IID defined 173 in [RFC7217]. One key part of that algorithm is that if a device 174 connects to a given network at different times, it will always 175 configure the same IPv6 addresses on that network. If the device 176 hosts a service ready to accept connections on that stable address, 177 adversaries can test the presence of the device on the network by 178 attempting connections to that stable address. Stable addresses used 179 by listening services will thus enable testing whether a specific 180 device is returning to a particular network, which in a number of 181 cases will be considered a privacy issue. 183 4.1.2. Unexpected Address Discovery 185 Systems like DNS-Based Service Discovery [RFC6763] allow clients to 186 discover services within a limited scope, that can be defined by a 187 domain name. These services are not advertised outside of that 188 scope, and thus do not expect to be discovered by random parties on 189 the Internet. Yet it appears that such services are easily 190 discoverable if they listen for connections to IPv6 addresses that a 191 client process also uses as source address when connecting to remote 192 servers. 194 NOTE: 195 An example of such unexpected discovery is described in [Hein]. A 196 network manager observed scanning traffic directed at the 197 temporary addresses of local devices. Analysis shows that the 198 scanners learned the addresses by observing the device contact an 199 NTP service ([RFC5905]). The remote scanning was possible because 200 the local devices were also accepting connections directed to the 201 temporary addresses. 203 It is obvious from the example that the "attack surface" of the 204 services is increased because they are bond to the same IPv6 205 addresses that are also used by clients for outgoing communications 206 with remote systems. But the overlap between "client" and "server" 207 addresses is only one part of the problem. Suppose that a devices 208 hosts both a video game and a home automation application. The video 209 game users will be able to discover the IPv6 address of the game 210 server. If the home automation server listens to the same IPv6 211 addresses, it is now exposed to connection attempts by all these 212 users. That, too, increases the attack surface of the home 213 automation server. 215 4.1.3. Availability Outside the Expected Scope 217 The IPv6 addressing architecture [RFC4291] defines multiple address 218 scopes. In practice, devices are often configured with globally 219 reachable unicast addresses, link local addresses, and Unique Local 220 IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the 221 expected scope happens when a service is expected to be only 222 available in some local scope, but inadvertently becomes available to 223 remote parties. That could happen for example if a service is meant 224 to be available only on a given link, but becomes reachable through 225 ULA or through globally reachable addresses, or if a service is meant 226 to be available only inside some organization's perimeter and becomes 227 reachable through globally reachable addresses. It will happen in 228 particular if a service intended for some local scope is programmed 229 to bind to "unspecified" addresses, which in practice means every 230 address configured for the device. 232 4.2. Current Limitations in the Address Selection API 234 Application developers using the Sockets API can "bind" a listening 235 socket to a specific address, and ensure that the application is only 236 reachable through that address. In theory, careful selection of the 237 binding address could mitigate the three problems mentioned above. 238 Binding services to temporary address could mitigate device tracking. 239 Binding different services to different addresses could mitigate 240 unexpected discovery. Binding services to link local addresses or 241 ULA could mitigate availability outside the expected scope. However, 242 explicitly managing addresses adds significant complexity to the 243 application development. It requires that application developers 244 master addressing architectures subtleties, and implement logic that 245 reacts adequately to connectivity events and address changes. 246 Experience shows that application developers would probably prefer 247 some much simpler solution. 249 In addition, we should note that many application developers use high 250 level APIs that listen to TLS, HTTP, or some other application 251 protocol. These high level APIs seldom provide detailed access to 252 specific IP addresses, and typically default to listening to all 253 available addresses. 255 5. IPv6 Address Considerations 257 5.1. Address Scope Considerations 259 The IPv6 address scope can, in some scenarios, limit the attack 260 exposure of a node as a result of the implicit isolation provided by 261 a non-global address scope. For example, a node that only employs 262 link-local addresses may, in principle, only be exposed to attack 263 from other nodes in the local link. Hosts employing only Unique 264 Local Addresses (ULAs) may be more isolated from attack than those 265 employing Global Unicast Addresses (GUAs), assuming that proper 266 packet filtering is enforced at the network edge. 268 The potential protection provided by a non-global addresses should 269 not be regarded as a complete security strategy, but rather as a form 270 of "prophylactic" security (see 271 [I-D.gont-opsawg-firewalls-analysis]). 273 We note that the use of non-global addresses is usually limited to a 274 reduced type of applications/protocols that e.g. are only meant to 275 operate on a reduced scope, and hence their applicability may be 276 limited. 278 A discussion of ULA usage considerations can be found in 279 [I-D.ietf-v6ops-ula-usage-considerations]. 281 5.2. Address Stability Considerations 283 The stability of an address has two associated security/privacy 284 implications: 286 o Ability of an attacker to correlate network activity 288 o Exposure to attack 289 For obvious reasons, an address that is employed for multiple 290 communication instances allows the aforementioned network activities 291 to be correlated. The longer an address is employed (i.e., the more 292 stable it is), the longer such correlation will be possible. In the 293 worst-case scenario, a stable address that is employed for multiple 294 communication instances over time will allow all such activities to 295 be correlated. On the other hand, if a host were to generate (and 296 eventually "throw away") one new address for each communication 297 instance (e.g., TCP connection), network activity correlation would 298 be mitigated. 300 NOTE: 301 the use of constant IIDs (as in traditional SLAAC) result in 302 addresses that, while not constant as a whole (since the prefix 303 changes), contain a globally-unique value that leaks out the node 304 "identity". Such addresses result in the worst possible security 305 and privacy implications, and their use has been deprecated by 306 [RFC8064]. 308 Typically, when it comes to attack exposure, the longer an address is 309 employed the longer an attacker is exposed to attacks (e.g. an 310 attacker has more time to find the address in the first place 311 [RFC7707]). While such exposure is traditionally associated with the 312 stability of the address, the usage type of the address (see 313 Section 5.3) may also have an impact on attack exposure. 315 A popular approach to mitigate network activity correlation is the 316 use of "temporary addresses" [RFC4941]. Temporary addresses are 317 typically configured and employed along with stable addresses, with 318 the temporary addresses employed for outgoing communications, and the 319 stable addresses employed for incoming communications. 321 NOTE: 322 Ongoing work [I-D.gont-6man-non-stable-iids] aims at updating 323 [RFC4941] such that temporary addresses can be employed without 324 the need to configure stable addresses. 326 We note that the extent to which temporary addresses provide improved 327 mitigation of network activity correlation and/or reduced attack 328 exposure may be questionable and/or limited in some scenarios. For 329 example, a temporary address that is reachable for, say, a few hours 330 has a questionable "reduced exposure" (particularly when automated 331 attack tools do not typically require such a long period of time to 332 complete their task). Similarly, if network activity can be 333 correlated for the life of such address (e.g., on the order of 334 several hours), such period of time might be long enough for the 335 attacker to correlate all the network activity he is meaning to 336 correlate. 338 In order to better mitigate network activity correlation and/or 339 possibly reduce host exposure, an implementation might want to either 340 reduce the preferred lifetime of a temporary address, or even better, 341 generate one new temporary address for each new transport protocol 342 instance. However, the associated lifetime/stability of an address 343 may have a negative impact on the network. For example, if a node 344 were to employ "throw away" IPv6 addresses, or employ temporary 345 addresses [RFC4941] with a short preferred lifetime, local nodes 346 might need to maintain too many entries in their Neighbor Cache, and 347 a number of devices (possibly enforcing security policies) might also 348 need to keep such additional state. 350 Additionally, enforcing a maximum lifetime on IPv6 addresses may 351 cause long-lived TCP connections to fail. For example, an address 352 becoming "Invalid" (after transitioning through the "Preferred" and 353 "Deprecated" states) would cause the TCP connections employing them 354 to break. This, in turn, would cause e.g. long-lived SSH sessions to 355 break/fail. 357 In some scenarios, attack exposure may be reduced by limiting the 358 usage of temporary addresses to outbound connections, and prevent 359 such addresses from being used for inbound connections (please see 360 Section 5.3). 362 5.3. Usage Type Considerations 364 A node that employs one of its addresses to communicate with an 365 external server (i.e., to perform an "outgoing connection") may cause 366 such address to become exposed to attack. For example, once the 367 external server receives an incoming connection, the corresponding 368 server might launch an attack against the aforementioned address. A 369 real-world instance of this type of scenario has been documented in 370 [Hein]. 372 However, we note that employing an IPv6 address for an outgoing 373 communications need not increase the exposure of local services to 374 other parties. For example, nodes could employ temporary addresses 375 only for outgoing connections, but not for incoming connections. 376 Thus, external nodes that learn about client's addresses could not 377 really leverage such addresses for actively contacting the clients. 379 There are multiple ways in which this could possibly be achieved, 380 with different implications. Namely: 382 o Run a host-based or network-based firewall 384 o Bind services to specific (explicit) addresses 385 o Bind services only to stable addresses 387 A client could simply run a host-based firewall that only allows 388 incoming connections on the stable addresses. This is clearly more 389 of an operational way of achieving the desired functionality, and may 390 require good firewall/host integration (e.g., the firewall should be 391 able to tell stable vs. temporary addresses), may require the client 392 to run additional firewall software for this specific purpose, etc. 393 In other scenarios, a network-based firewall could be configured to 394 allow outgoing communications from all internal addresses, but only 395 allow incoming communications to stable addresses. For obvious 396 reasons, this is generally only applicable to networks where incoming 397 communications are allowed to a limited number of hosts/servers. 399 Services could be bound to specific (explicit) addresses, rather than 400 to all locally-configured addresses. However, there are a number of 401 short-comings associated with this approach. Firstly, an application 402 would need to be able to learn all of its addresses and associated 403 stability properties, something that tends to be non-trivial and non- 404 portable, and that also makes applications protocol-dependent, 405 unnecessarily. Secondly, the Sockets API does not really allow a 406 socket to be bound to a subset of the node's addresses. That is, 407 sockets can be bound to a single address or to all available 408 addresses (wildcard), but not to a subset of all the configured 409 addresses. 411 Binding services only to stable addresses provides a clean separation 412 between addresses employed for client-like outgoing connections and 413 server-like incoming connections. However, we currently lack an 414 appropriate API for nodes to be able to specify that a socket should 415 only be bound to stable addresses. Development of such an API should 416 be considered for future work. 418 6. Possible Approaches for IPv6 Address Usage 420 There are a number of ways in which a system or network may affect 421 which address (and how) may be employed for different services and 422 cases. Namely, 424 o TCP/IP stack address filtering 426 o Application-based address filtering 428 o Firewall-based address filtering 430 Clearly, the most elegant approach for address selection is for 431 applications to be able to specify the properties of the addresses 432 they are willing to employ by means of an API, such the TCP/IP stack 433 itself can "filter" which addresses are allowed to be employed for 434 the given service/application. This relieves the application from 435 dealing with low level details of networking, improves portability, 436 and avoids duplicate code in applications. However, constraints in 437 the current APIs (see Section 4.2) may limit the ability of 438 application progremmers form leveraging this technique. 440 Another possible approach is for applications to e.g. bind services 441 to all available addresses, and perform the associated selection/ 442 filtering at the application level. While possible this has a number 443 of drawbacks. Firstly, it would require applications to deal with 444 low-level networking details, require that all the associated code be 445 duplicated in all applications, and also negatively affect 446 portability. Besides, performing address/selection filtering at the 447 application level may not mitigate some possible threats. For 448 example, port scanning will still be possible, since the 449 aforementioned filtering will only be performed e.g. once UDP packets 450 are received or TCP connections are established. 452 Finally, a firewall may be employed to filter addresses based on 453 their intended usage. For example, a firewall may block incoming 454 requests to all addresses except to some whitelisted addresses (such 455 as the stable addresses of the node). This technique not only 456 requires the use of a firewall (which may or may not be present), but 457 also implies knowledge of the firewall regarding the desired 458 properties of the addresses that each application/service is intended 459 to use. 461 7. Advice on IPv6 Address Configuration 463 [TBD] 465 TODO: This section is expected to provide advice regarding the 466 configuration of different addresses for different typical scenarios. 467 e.g., when nodes may want to configure stable-only, temporary-only, 468 or stable+temporary. In the most simple analysis, one might expect 469 nodes in a typical enterprise network to employ only stable 470 addresses. General-purpose nodes in a home or "trusted" network may 471 want to employ both stable and temporary addresses. Finally, mobile 472 nodes (e.g. when roaming across non-trusted networks) may want to 473 employ only temporary addresses). 475 8. Advice on IPv6 Address Usage 477 [TBD] 479 TODO: This section is expected to provide recommendations regarding 480 the usage of IPv6 addresses. Among others, it is expected to provide 481 recommendations regarding the usage of IPv6 addresses when providing 482 network services. In the mos simple form, one argue that nodes may 483 want to employ only the smallest-scope applicable addresses (if 484 available) and, if stable addresses are available, nodes may want to 485 accept incoming connections on such addresses but *not* on temporary 486 addresses. 488 9. Future Work 490 Some of the discussion in this document suggest that in order to 491 fully benefit from the IPv6 addresses (in terms of e.g. increased 492 availability of addresses and address types) additional work may be 493 required in this areas: 495 o Sockets API: The API may need to be extended such that a node may 496 bind() only a subset of the available addresses, possibly by 497 specifying a criteria (e.g. "only stable addresses", "only 498 global", "only local", etc.). 500 The aforementioned work may be carried out in this document, or as a 501 result of spin off documents. 503 10. IANA Considerations 505 There are no IANA registries within this document. The RFC-Editor 506 can remove this section before publication of this document as an 507 RFC. 509 11. Security Considerations 511 The security and privacy implications associated with the 512 predictability and lifetime of IPv6 addresses has been analyzed in 513 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 514 extends the aforementioned analysis by considering other IPv6 515 properties such as the address scope and address usage type. 517 This document also analyzes what properties are desirable for some 518 popular scenarios, and provides advice regarding the configuration 519 and usage of such addresses. Finally, it describes possible future 520 standards-track work to allow for greater flexibility in IPv6 address 521 usage. 523 12. Acknowledgements 525 The authors would like to thank (in alphabetical order) Francis 526 Dupont, Tatuya Jinmei, and Dave Thaler for providing valuable 527 comments on earlier versions of this document. 529 13. References 531 13.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 539 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 540 . 542 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 543 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 544 2006, . 546 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 547 Extensions for Stateless Address Autoconfiguration in 548 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 549 . 551 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 552 "Network Time Protocol Version 4: Protocol and Algorithms 553 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 554 . 556 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 557 "Default Address Selection for Internet Protocol Version 6 558 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 559 . 561 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 562 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 563 . 565 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 566 Interface Identifiers with IPv6 Stateless Address 567 Autoconfiguration (SLAAC)", RFC 7217, 568 DOI 10.17487/RFC7217, April 2014, 569 . 571 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 572 "Recommendation on Stable IPv6 Interface Identifiers", 573 RFC 8064, DOI 10.17487/RFC8064, February 2017, 574 . 576 13.2. Informative References 578 [Barnes2012] 579 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 580 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 581 Workshop on Active Internet Measurements, February 2012, 582 . 585 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", 586 January 2016, . 589 [I-D.gont-6man-non-stable-iids] 590 Gont, F., Huitema, C., Gont, G., and M. Corbo, 591 "Recommendation on Temporary IPv6 Interface Identifiers", 592 draft-gont-6man-non-stable-iids-01 (work in progress), 593 March 2017. 595 [I-D.gont-opsawg-firewalls-analysis] 596 Gont, F. and F. Baker, "On Firewalls in Network Security", 597 draft-gont-opsawg-firewalls-analysis-02 (work in 598 progress), February 2016. 600 [I-D.ietf-v6ops-ula-usage-considerations] 601 Liu, B. and S. Jiang, "Considerations For Using Unique 602 Local Addresses", draft-ietf-v6ops-ula-usage- 603 considerations-02 (work in progress), March 2017. 605 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 606 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 607 . 609 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 610 Considerations for IPv6 Address Generation Mechanisms", 611 RFC 7721, DOI 10.17487/RFC7721, March 2016, 612 . 614 Authors' Addresses 615 Fernando Gont 616 SI6 Networks / UTN-FRH 617 Evaristo Carriego 2644 618 Haedo, Provincia de Buenos Aires 1706 619 Argentina 621 Phone: +54 11 4650 8472 622 Email: fgont@si6networks.com 623 URI: http://www.si6networks.com 625 Guillermo Gont 626 SI6 Networks 627 Evaristo Carriego 2644 628 Haedo, Provincia de Buenos Aires 1706 629 Argentina 631 Phone: +54 11 4650 8472 632 Email: ggont@si6networks.com 633 URI: https://www.si6networks.com 635 Madeleine Garcia Corbo 636 Servicios de Informacion del Transporte 637 Neptuno 358 638 Havana City 10400 639 Cuba 641 Email: madelen.garcia16@gmail.com 643 Christian Huitema 644 Private Octopus Inc. 645 Friday Harbor, WA 98250 646 U.S.A. 648 Email: huitema@huitema.net 649 URI: http://privateoctopus.com