idnits 2.17.1 draft-gont-6man-address-usage-recommendations-05.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 (March 9, 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-12) exists of draft-ietf-6man-rfc4941bis-07 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-11 == 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: Informational G. Gont 5 Expires: September 10, 2020 SI6 Networks 6 C. Huitema 7 Private Octopus Inc. 8 March 9, 2020 10 Problem Statement Regarding IP Address Usage 11 draft-gont-6man-address-usage-recommendations-05 13 Abstract 15 This document analyzes the security and privacy implications of IPv6 16 addresses based on a number of properties (such as address scope, 17 stability, and usage type), and identifies gaps that currently 18 prevent systems and applications from leveraging the increased 19 flexibility and availability of IPv6 addresses. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 10, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. IPv6 Address Properties . . . . . . . . . . . . . . . . . . . 4 59 4.1. Address Scope Considerations . . . . . . . . . . . . . . 4 60 4.2. Address Stability Considerations . . . . . . . . . . . . 5 61 4.3. Usage Type Considerations . . . . . . . . . . . . . . . . 6 62 5. Default Address Selection in IPv6 . . . . . . . . . . . . . . 8 63 6. Current Possible Approaches for IPv6 Address Usage . . . . . 9 64 6.1. Incoming communications . . . . . . . . . . . . . . . . . 9 65 6.2. Outgoing communications . . . . . . . . . . . . . . . . . 10 66 7. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 10 67 7.1. Issues Associated with Sub-optimal IPv6 Address Usage . . 10 68 7.1.1. Correlation of Network Activity . . . . . . . . . . . 10 69 7.1.2. Testing for the Presence of Node in the Network . . . 11 70 7.1.3. Unexpected Address Discovery . . . . . . . . . . . . 11 71 7.1.4. Availability Outside the Expected Scope . . . . . . . 12 72 7.2. Current Limitations in the Address Selection APIs . . . . 12 73 7.3. Sub-optimal IPv6 Address Configuration . . . . . . . . . 13 74 7.4. Sub-optimal IPv6 Address Usage . . . . . . . . . . . . . 13 75 7.5. Operational Considerations . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 11.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 IPv6 addresses may differ in a number of properties, such as address 87 scope (e.g. link-local vs. global), stability (e.g. stable addresses 88 vs. temporary addresses), and intended usage type (outgoing 89 communications vs. incomming communications). While often 90 overlooked, these properties have impact on areas such as security, 91 privacy, and performance. 93 IPv6 hosts typically configure a number of IPv6 addresses of 94 different properties. For example, a host may configure one stable 95 and one temporary address per each autoconfiguration prefix 96 advertised on the local network. Currently, the addresses to be 97 configured typically depend on local system policy, with the 98 aforementioned policy being static and irrespective of the network 99 the host attaches to. This "one size fits all" approach limits the 100 ability of systems and applications of fully-leveraging the increased 101 flexibility and availability of IPv6 addresses. 103 Each application running on a given system may have its own set of 104 requirements or expectations for the properties of the IPv6 addresses 105 to be employed. For example, an application meaning to offer a 106 public service might expect to employ global stable addresses for 107 such purpose, while a privacy-sensible client application might 108 prefer short-lived temporary addresses, or might even expect to 109 employ single-use ("throw-away") IPv6 addresses when connecting to 110 public servers. However, the subtetlies associated with IPv6 111 addresses (and associated properties) are often ignored by 112 application programmers and, in any case, current APIs (such as the 113 BSD Sockets API) tend to be very limited in the amount of control 114 they give applications to select the most appropriate IPv6 addresses 115 for a given task, thus limiting a programmer's ability to leverage 116 IPv6 address availability and properties. 118 This document analyzes the impact of a number of properties of IPv6 119 addresses on areas such as security and privacy, and analyzes how 120 IPv6 addresses are curently generated and employed by different 121 operating systems and applications. Finally, it provides a problem 122 statement by identifying and analyzing gaps that prevent systems and 123 applications from fully-leveraging IPv6 addressing capabilities, 124 setting the basis for new work that could fill those gaps. 126 2. Terminology 128 This document employs the definitions of "public address", "stable 129 address", and "temporary address" from Section 2 of [RFC7721]. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 3. Background 137 Predictable IPv6 addresses result in a number of security and privacy 138 implications. For example, [Barnes2012] discusses how patterns in 139 network prefixes can be leveraged for IPv6 address scanning. On the 140 other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security 141 and privacy implications of predictable IPv6 Interface Identifiers 142 (IIDs). 144 Given the aforementioned previous work in this area, and the formal 145 specification update produced by [RFC8064], we expect (and assume in 146 the rest of this document) that implementations have replaced any 147 schemes that produce predictable addresses with alternative schemes 148 that avoid such patterns (e.g., RFC7217 in replacement of the 149 traditional SLAAC addresses that embed link-layer addresses). 151 4. IPv6 Address Properties 153 There are three parameters that affect the security and privacy 154 properties of an IPv6 address: 156 o Scope 158 o Stability 160 o Usage type (client-like "outgoing connections" vs. server-like 161 "incoming connections") 163 Section 4.1, Section 4.2, and Section 4.3 discuss the security and 164 privacy implications (and associated tradeoffs) of the scope, 165 stability and usage type properties of IPv6 addresses, respectively. 167 Additionally, IPv6 address usage has a number of operational 168 considerations; these are discussed n Section 7.5. 170 4.1. Address Scope Considerations 172 The IPv6 address scope can, in some scenarios, limit the attack 173 exposure of a node as a result of the implicit isolation provided by 174 a non-global address scope. For example, a node that only employs 175 link-local addresses may, in principle, only be exposed to attack 176 from other nodes in the local link. Hosts employing only Unique 177 Local Addresses (ULAs) may be more isolated from attack than those 178 employing Global Unicast Addresses (GUAs), assuming that proper 179 packet filtering is enforced at the network edge. 181 The potential protection provided by a non-global addresses should 182 not be regarded as a complete security strategy, but rather as a form 183 of "prophylactic" security (see 184 [I-D.gont-opsawg-firewalls-analysis]). 186 We note that the use of non-global addresses is usually limited to a 187 reduced type of applications/protocols that e.g. are only meant to 188 operate on a reduced scope, and hence their applicability may be 189 limited. 191 A discussion of ULA usage considerations can be found in 192 [I-D.ietf-v6ops-ula-usage-considerations]. 194 4.2. Address Stability Considerations 196 The stability of an address has two associated security/privacy 197 implications: 199 o Ability of an attacker to correlate network activity 201 o Exposure to attack 203 For obvious reasons, an address that is employed for multiple 204 communication instances allows the aforementioned network activities 205 to be correlated. The longer an address is employed (i.e., the more 206 stable it is), the longer such correlation will be possible. In the 207 worst-case scenario, a stable address that is employed for multiple 208 communication instances over time will allow all such activities to 209 be correlated. On the other hand, if a host were to generate (and 210 eventually "throw away") one new address for each communication 211 instance (e.g., TCP connection), network activity correlation would 212 be mitigated. 214 NOTE: 215 The use of constant IIDs (as in traditional SLAAC) result in 216 addresses that, while not constant as a whole (since the prefix 217 changes), contain a globally-unique value that leaks out the node 218 "identity". Such addresses result in the worst possible security 219 and privacy implications, and their use has been deprecated by 220 [RFC8064]. 222 Typically, when it comes to attack exposure, the longer an address is 223 employed the longer an attacker is exposed to attacks (e.g. an 224 attacker has more time to find the address in the first place 225 [RFC7707]). While such exposure is traditionally associated with the 226 stability of the address, the usage type of the address (see 227 Section 4.3) may also have an impact on attack exposure. 229 A popular approach to mitigate network activity correlation is the 230 use of "temporary addresses" [RFC4941]. Temporary addresses are 231 typically configured and employed along with stable addresses, with 232 the temporary addresses employed for outgoing communications, and the 233 stable addresses employed for incoming communications. 235 NOTE: 236 Ongoing work [I-D.gont-6man-non-stable-iids] aims at updating 237 [RFC4941] such that temporary addresses can be employed without 238 the need to configure stable addresses. 240 We note that the extent to which temporary addresses provide improved 241 mitigation of network activity correlation and/or reduced attack 242 exposure may be questionable and/or limited in some scenarios. For 243 example, a temporary address that is reachable for, say, a few hours 244 has a questionable "reduced exposure" (particularly when automated 245 attack tools do not typically require such a long period of time to 246 complete their task). Similarly, if network activity can be 247 correlated for the life of such address (e.g., on the order of 248 several hours), such period of time might be long enough for the 249 attacker to correlate all the network activity he is meaning to 250 correlate. 252 In order to better mitigate network activity correlation and/or 253 possibly reduce host exposure, an implementation might want to either 254 reduce the preferred lifetime of a temporary address, or even better, 255 generate one new temporary address for each new transport protocol 256 instance. However, the associated lifetime/stability of an address 257 may have a negative impact on the network. For example, if a node 258 were to employ "throw away" IPv6 addresses, or employ temporary 259 addresses [RFC4941] with a short preferred lifetime, local nodes 260 might need to maintain too many entries in their Neighbor Cache, and 261 a number of devices (possibly enforcing security policies) might also 262 need to cope with such additional state. 264 Additionally, enforcing a maximum lifetime on IPv6 addresses may 265 cause long-lived TCP connections to fail. For example, an address 266 becoming "Invalid" (after transitioning through the "Preferred" and 267 "Deprecated" states) would cause the TCP connections employing them 268 to break. This, in turn, would cause e.g. long-lived SSH sessions to 269 break/fail. 271 In some scenarios, attack exposure may be reduced by limiting the 272 usage of temporary addresses to outgoing connections, and prevent 273 such addresses from being used for incoming connections (please see 274 Section 4.3). 276 4.3. Usage Type Considerations 278 A node that employs one of its addresses to communicate with an 279 external server (i.e., to perform an "outgoing connection") may cause 280 such address to become exposed to attack. For example, once the 281 external server receives an incoming connection, the corresponding 282 server might launch an attack against the aforementioned address. A 283 real-world instance of this type of scenario has been documented in 284 [Hein]. 286 However, we note that employing an IPv6 address for outgoing 287 communications need not increase the exposure of local services to 288 other parties. For example, nodes could employ temporary addresses 289 only for outgoing connections, but not for incoming connections. 290 Thus, external nodes that learn about client's addresses could not 291 really leverage such addresses for actively contacting the clients. 293 There are multiple ways in which this could possibly be achieved, 294 with different implications. Namely: 296 o Run a host-based or network-based firewall 298 o Bind services to specific (explicit) addresses 300 o Bind services only to stable addresses 302 A client could simply run a host-based firewall that only allows 303 incoming connections on the stable addresses. This is clearly more 304 of an operational way of achieving the desired functionality, and may 305 require good firewall/host integration (e.g., the firewall should be 306 able to tell stable vs. temporary addresses), may require the client 307 to run additional firewall software for this specific purpose, etc. 308 In other scenarios, a network-based firewall could be configured to 309 allow outgoing communications from all internal addresses, but only 310 allow incoming communications to stable addresses. For obvious 311 reasons, this is generally only applicable to networks where incoming 312 communications are allowed to a limited number of hosts/servers. 314 Services could be bound to specific (explicit) addresses, rather than 315 to all locally-configured addresses. However, there are a number of 316 short-comings associated with this approach. Firstly, an application 317 would need to be able to learn all of its addresses and associated 318 stability properties, something that tends to be non-trivial and non- 319 portable, and that also makes applications protocol-dependent, 320 unnecessarily. Secondly, the BSD Sockets API does not really allow a 321 socket to be bound to a subset of the node's addresses. That is, 322 sockets can be bound to a single address or to all available 323 addresses (wildcard), but not to a subset of all the configured 324 addresses. 326 Binding services only to stable addresses provides a clean separation 327 between addresses employed for client-like outgoing connections and 328 server-like incoming connections. However, we currently lack an 329 appropriate API for nodes to be able to specify that a socket should 330 only be bound to stable addresses. 332 5. Default Address Selection in IPv6 334 Applications use system API's to select the IPv6 addresses that will 335 be used for incoming and outgoing connections. These choices have 336 consequences in terms of privacy, security, stability and 337 performance. 339 Default Address Selection for IPv6 is specified in [RFC6724]. The 340 selection starts with a set of potential destination addresses, such 341 as returned by getaddrinfo(), and the set of potential source 342 addresses currently configured for the selected interfaces. For each 343 potential destination address, the algorithm will select the source 344 address that provides the best route to the destination, while 345 choosing the appropriate scope and preferring temporary addresses. 346 The algorithm will then select the destination address, while giving 347 a preference to reachable addresses with the smallest scope. The 348 selection may be affected by system settings. We note that [RFC6724] 349 only applies for outgoing connections, such as those made by clients 350 trying to use services offered by other hosts. 352 We note that [RFC6724] selects IPv6 addresses from all the currently 353 available addresses on the host, and there is currently no way for an 354 application to indicate expected or desirable properties for the IPv6 355 source addresses employed for such outgoing communications. For 356 example, a privacy-sensitive application might want that each 357 outgoing communication instance employs a new, single-use IPv6 358 address, or to employ a new reusable address that is not employed or 359 reusable by any other application on the host. Reuse of an IPv6 360 address by an application would allow the correlation of all network 361 activities corresponding to such application as being performed by 362 the same host, while reuse of an IPv6 address by multiple different 363 applications would allow the correlation of all such network 364 activities as being performed by the host with such IPv6 address. 366 When devices provide a service, the common pattern is to just wait 367 for connections over all addresses configured on the device. For 368 example, applications using the BSD Sockets API will commonly bind() 369 the listening socket to the undefined address. This long-established 370 behavior is appropriate for devices providing public services, but 371 may have unexpected results for devices providing semi-private 372 services, such as various forms of peer-to-peer or local-only 373 applications. 375 This behavior leads to three problems: device tracking, discussed in 376 Section 7.1.2; unexpected address discovery, discussed in 377 Section 7.1.3; and availability outside the expected scope, discussed 378 in Section 7.1.4. These problems are caused in part by the 379 limitations of available address selection API, presented in 380 Section 7.2. 382 6. Current Possible Approaches for IPv6 Address Usage 384 6.1. Incoming communications 386 There are a number of ways in which a system or network may affect 387 which address (and how) may be employed for different services and 388 cases. Namely, 390 o TCP/IP stack address filtering 392 o Application-based address filtering 394 o Firewall-based address filtering 396 Clearly, the most elegant approach for address selection is for 397 applications to be able to specify the properties of the addresses 398 they are willing to employ by means of an API, such the TCP/IP stack 399 itself can "filter" which addresses are allowed to be employed for 400 the given service/application. This relieves the application from 401 dealing with low level details of networking, improves portability, 402 and avoids duplicate code in applications. However, constraints in 403 the current APIs (see Section 7.2) may limit the ability of 404 application progremmers for leveraging this technique. 406 Another possible approach is for applications to e.g. bind services 407 to all available addresses, and perform the associated selection/ 408 filtering at the application level. While possible this has a number 409 of drawbacks. Firstly, it would require applications to deal with 410 low-level networking details, require that all the associated code be 411 duplicated in all applications, and also negatively affect 412 portability. Besides, performing address/selection filtering at the 413 application level may not mitigate some possible threats. For 414 example, port scanning will still be possible, since the 415 aforementioned filtering will only be performed e.g. once UDP packets 416 are received or TCP connections are established. 418 Finally, a firewall may be employed to filter addresses based on 419 their intended usage. For example, a firewall may block incoming 420 requests to all addresses except to some whitelisted addresses (such 421 as the stable addresses of the node). This technique not only 422 requires the use of a firewall (which may or may not be present), but 423 also implies knowledge of the firewall regarding the desired 424 properties of the addresses that each application/service is intended 425 to use. 427 6.2. Outgoing communications 429 An application might be able to obtain the list of currently- 430 configured addresses, and subsequently select an address with desired 431 properties, and explicitly "bind" the address to the socket, to 432 override the default source address selection. 434 However, this approach is problematic for a number of reasons. 435 Firstly, there is no portable way of obtaining the list of currently- 436 configured addresses on the local node, and even less to check for 437 properties such "valid lifetime". Secondly, as discussed in 438 Section 6.1, it would require application programmers to understand 439 all the subtetiles associated with IPv6 addressing, and would also 440 lead to duplicate code on all applications. Finally, applications 441 would be limited to use already-configured addresses and unable to 442 trigger the generation of new addresses where desirable (e.g. the 443 genration of a new temporary address for this application instance or 444 communication instance). 446 7. Problem Statement 448 This section elaborates the problem statement on IPv6 address usage. 449 Section 7.1 describes the security and privacy implications of 450 improper IPv6 address usage, while Section 7.2, Section 7.4, 451 Section 7.3, analyze the possible root of such improper address 452 usage, suggesting possible future work. 454 7.1. Issues Associated with Sub-optimal IPv6 Address Usage 456 7.1.1. Correlation of Network Activity 458 As discussed in [RFC7721], a node that reuses an IPv6 address for 459 multiple communication instances would allow the correlation of such 460 network activities. This could be the case when the same IPv6 461 address is employed by several instances of the same application 462 (e.g., a browser in "privacy" mode and a browser in "normal" mode), 463 or when the same IPv6 address is employed by two different 464 applications on the same node (e.g., a browser in "privacy" mode, and 465 an email client). 467 Particularly for privacy-sensitive applications, an application or 468 system might want to limit the usage of a given IPv6 address to a 469 single communication instance, a single application, a single user on 470 the system, etc. However, given current APIs, this is practically 471 impossible. 473 7.1.2. Testing for the Presence of Node in the Network 475 The stable addresses recommended in [RFC8064] use stable IIDs defined 476 in [RFC7217]. One key part of that algorithm is that if a device 477 connects to a given network at different times, it will always 478 configure the same IPv6 addresses on that network. If the device 479 hosts a service ready to accept connections on that stable address, 480 adversaries can test the presence of the device on the network by 481 attempting connections to that stable address. Stable addresses used 482 by listening services will thus enable testing whether a specific 483 device is returning to a particular network, which in a number of 484 cases might be considered a privacy issue. 486 7.1.3. Unexpected Address Discovery 488 Systems like DNS-Based Service Discovery [RFC6763] allow clients to 489 discover services within a limited scope, that can be defined by a 490 domain name. These services are not advertised outside of that 491 scope, and thus do not expect to be discovered by random parties on 492 the Internet. However, such services may be easily discoverable if 493 they listen for connections to IPv6 addresses that a client process 494 also uses as source address when connecting to remote servers. 496 NOTE: 497 An example of such unexpected discovery is described in [Hein]. A 498 network manager observed scanning traffic directed at the 499 temporary addresses of local devices. The analysis in [Hein] 500 shows that the scanners learned the addresses by observing the 501 device contact an NTP service ([RFC5905]). The remote scanning 502 was possible because the local devices were also accepting 503 connections directed to the temporary addresses. 505 It is obvious from the example that the "attack surface" of the 506 services is increased because they are bond to the same IPv6 507 addresses that are also used by clients for outgoing communications 508 with remote systems. But the overlap between "client" and "server" 509 addresses is only one part of the problem. Suppose that a device 510 hosts both a video game and a home automation application. The video 511 game users will be able to discover the IPv6 address of the game 512 server. If the home automation server listens to the same IPv6 513 addresses, it is now exposed to connection attempts by all these 514 users. That, too, increases the attack surface of the home 515 automation server. 517 7.1.4. Availability Outside the Expected Scope 519 The IPv6 addressing architecture [RFC4291] defines multiple address 520 scopes. In practice, devices are often configured with globally 521 reachable unicast addresses, link local addresses, and Unique Local 522 IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the 523 expected scope happens when a service is expected to be only 524 available in some local scope, but inadvertently becomes available to 525 remote parties. That could happen for example if a service is meant 526 to be available only on a given link, but becomes reachable through 527 ULA or through globally reachable addresses, or if a service is meant 528 to be available only inside some organization's perimeter and becomes 529 reachable through globally reachable addresses. It will happen in 530 particular if a service intended for some local scope is programmed 531 to bind to "unspecified" addresses, which in practice means every 532 address configured for the device (please see Section 7.2). 534 7.2. Current Limitations in the Address Selection APIs 536 Application developers using the BSD Sockets API can "bind" a 537 listening socket to a specific address, and ensure that the 538 application is only reachable through that address. In theory, 539 careful selection of the binding address could mitigate the problems 540 described in Section 7.1. Binding services to temporary addresses 541 could mitigate the ability of an attacker from testing for the 542 presence of the node in the network. Binding different services to 543 different addresses could mitigate unexpected discovery. Binding 544 services to link local addresses or ULA could mitigate availability 545 outside the expected scope. However, explicitly managing addresses 546 adds significant complexity to the application development. It 547 requires that application developers master addressing architecture 548 subtleties, and implement logic that reacts adequately to 549 connectivity events and address changes. Experience shows that 550 application developers would probably prefer some much simpler 551 solution. 553 In addition, we should note that many application developers use high 554 level APIs that listen to TLS, HTTP, or some other application 555 protocol. These high level APIs seldom provide detailed access to 556 specific IP addresses, and typically default to listening to all 557 available addresses. 559 A more advanced API could allow an application programmer to select 560 desired properties in an address (scope, lifespan, etc.), such that 561 the best-suitable addresses are selected, while relieving the 562 application for low-level IPv6 addressing details. Such API might 563 also trigger the generation of new IPv6 addresses when the specified 564 properties would require so. 566 7.3. Sub-optimal IPv6 Address Configuration 568 Most operating systems configure the same types of addresses 569 regardless of the current "operating mode" or "profile" of the device 570 (e.g., device connected to enterprise network vs roaming across 571 untrusted networks). For example, many operating systems configure 572 both stable [RFC8064] and temporary [RFC4941] addresses on all 573 network interfaces. However, this "one size fits all" approach tends 574 to be sub-optimal or inappropriate for some scenarios. For example, 575 enterprise networks typically prefer usage of only stable address, 576 thus meaning that a network administator needs to find the means for 577 disabling the generation of temporary addresses on all those systems 578 that would otherwise generate them. On the other hand, some mobile 579 devices configure both stable and temporary addresses, even when 580 their usage pattern (client-like operation, as opposed to offering 581 services to other nodes) would allow for the more privacy-sensible 582 option of configuring only temporary addresses. 584 The lack of better tuned address configuration policies has helped 585 the "one size fits all" approach that, as noted, may lead to 586 suboptimal results. Advice in this area might help achieve more 587 optional address generation policies such that IPv6 addressing 588 capabilities are fully leveraged. 590 NOTE: 591 One might envision a document that provides advice regarding the 592 address generation for different typical scenarios (e.g., when to 593 configure stable-only, temporary-only, or stable+temporary). In 594 the most simple analysis, one might expect nodes in a typical 595 enterprise network to employ only stable addresses. General- 596 purpose nodes in a home or "trusted" network may want to employ 597 both stable and temporary addresses. Finally, mobile nodes (e.g. 598 when roaming across non-trusted networks) may want to employ only 599 temporary addresses). 601 7.4. Sub-optimal IPv6 Address Usage 603 An application programmer, left with the question of which are the 604 most appropriate addresses for a given usage type and application, 605 typically resorts to the Default IPv6 Address Selection for IPv6 (see 606 Section 5) for outgoing communications, and to accepting incoming 607 communications on all available addresses for incoming 608 communications. As discussed throughout this document, this leads to 609 sub-optimal results. Besides, all applications on a node share the 610 same pool of configured addresses, and applications are also 611 prevented from triggering the generation of new addresses (e.g. to be 612 employed for a particular application or communcation instance). 614 Guidance in this area is warranted such that applications and systems 615 fully-leverage IPv6 addressing. 617 NOTE: 618 Such guidance would elaborate, among other things, on the usage of 619 IPv6 addresses when offering network services and when performing 620 client-like communications. For example, for incomming 621 communications, hosts might want to employ only the smallest-scope 622 applicable addresses (if available) and, if stable addresses are 623 available, they might want to accept incoming connections only on 624 such addresses (but *not* on temporary addresses). For client- 625 like communications, hosts might prefer temporary addresses, 626 unless the coresponding communication instances are expected to be 627 long-lived (e.g., SSH sessions). 629 7.5. Operational Considerations 631 The desires of protecting individual privacy versus the desire to 632 effectively maintain and debug a network can conflict with each 633 other. Having clients e.g. use addresses that change over time will 634 make it more difficult to track down and isolate operational 635 problems. For example, when looking at packet traces, it could 636 become more difficult to determine whether one is seeing behavior 637 caused by a single errant machine, or by a number of them. 639 Network deployments are currently recommended to provide multiple 640 IPv6 addresses from each prefix to general-purpose hosts [RFC7934]. 641 However, in some scenarios, use of a large number of IPv6 addresses 642 may have negative implications on network devices that need to 643 maintain entries for each IPv6 address in some data structures (e.g., 644 [RFC7039]). Additionally, concurrent active use of multiple IPv6 645 addresses will increase neighbour discovery traffic if Neighbour 646 Caches in network devices are not large enough to store all addresses 647 on the link. This can impact performance and energy efficiency on 648 networks on which multicast is expensive (e.g. 649 [I-D.ietf-mboned-ieee802-mcast-problems]). 651 8. IANA Considerations 653 There are no IANA registries within this document. The RFC-Editor 654 can remove this section before publication of this document as an 655 RFC. 657 9. Security Considerations 659 The security and privacy implications associated with the 660 predictability and lifetime of IPv6 addresses has been analyzed in 661 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 662 extends the aforementioned analysis by considering other IPv6 663 properties such as the address scope and address usage type, and the 664 associated tradeoffs. Finally, it describes possible future 665 standards-track work to allow for greater flexibility in IPv6 address 666 usage. 668 10. Acknowledgements 670 The authors would like to thank (in alphabetical order) Francis 671 Dupont, Tatuya Jinmei, and Dave Thaler for providing valuable 672 comments on earlier versions of this document. 674 Section 7.5 borrows text from [I-D.ietf-6man-rfc4941bis] co-authored 675 by Fernando Gont, Suresh Krishnan, Thomas Narten, and Richard Draves. 677 11. References 679 11.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, 683 DOI 10.17487/RFC2119, March 1997, 684 . 686 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 687 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 688 . 690 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 691 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 692 2006, . 694 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 695 Extensions for Stateless Address Autoconfiguration in 696 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 697 . 699 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 700 "Network Time Protocol Version 4: Protocol and Algorithms 701 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 702 . 704 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 705 "Default Address Selection for Internet Protocol Version 6 706 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 707 . 709 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 710 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 711 . 713 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 714 Interface Identifiers with IPv6 Stateless Address 715 Autoconfiguration (SLAAC)", RFC 7217, 716 DOI 10.17487/RFC7217, April 2014, 717 . 719 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 720 "Host Address Availability Recommendations", BCP 204, 721 RFC 7934, DOI 10.17487/RFC7934, July 2016, 722 . 724 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 725 "Recommendation on Stable IPv6 Interface Identifiers", 726 RFC 8064, DOI 10.17487/RFC8064, February 2017, 727 . 729 11.2. Informative References 731 [Barnes2012] 732 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 733 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 734 Workshop on Active Internet Measurements, February 2012, 735 . 738 [Hein] Hein, B., "The Rising Sophistication of Network 739 Scanning", January 2016, 740 . 743 [I-D.gont-6man-non-stable-iids] 744 Gont, F., Huitema, C., Krishnan, S., Gont, G., and M. 745 Corbo, "Recommendation on Temporary IPv6 Interface 746 Identifiers", draft-gont-6man-non-stable-iids-04 (work in 747 progress), March 2018. 749 [I-D.gont-opsawg-firewalls-analysis] 750 Gont, F. and F. Baker, "On Firewalls in Network Security", 751 draft-gont-opsawg-firewalls-analysis-02 (work in 752 progress), February 2016. 754 [I-D.ietf-6man-rfc4941bis] 755 Gont, F., Krishnan, S., Narten, T., and R. Draves, 756 "Privacy Extensions for Stateless Address 757 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-07 758 (work in progress), February 2020. 760 [I-D.ietf-mboned-ieee802-mcast-problems] 761 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 762 Zuniga, "Multicast Considerations over IEEE 802 Wireless 763 Media", draft-ietf-mboned-ieee802-mcast-problems-11 (work 764 in progress), December 2019. 766 [I-D.ietf-v6ops-ula-usage-considerations] 767 Liu, B. and S. Jiang, "Considerations For Using Unique 768 Local Addresses", draft-ietf-v6ops-ula-usage- 769 considerations-02 (work in progress), March 2017. 771 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 772 "Source Address Validation Improvement (SAVI) Framework", 773 RFC 7039, DOI 10.17487/RFC7039, October 2013, 774 . 776 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 777 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 778 . 780 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 781 Considerations for IPv6 Address Generation Mechanisms", 782 RFC 7721, DOI 10.17487/RFC7721, March 2016, 783 . 785 Authors' Addresses 787 Fernando Gont 788 SI6 Networks / UTN-FRH 789 Evaristo Carriego 2644 790 Haedo, Provincia de Buenos Aires 1706 791 Argentina 793 Phone: +54 11 4650 8472 794 Email: fgont@si6networks.com 795 URI: http://www.si6networks.com 796 Guillermo Gont 797 SI6 Networks 798 Evaristo Carriego 2644 799 Haedo, Provincia de Buenos Aires 1706 800 Argentina 802 Phone: +54 11 4650 8472 803 Email: ggont@si6networks.com 804 URI: https://www.si6networks.com 806 Christian Huitema 807 Private Octopus Inc. 808 Friday Harbor, WA 98250 809 U.S.A. 811 Email: huitema@huitema.net 812 URI: http://privateoctopus.com