idnits 2.17.1 draft-gont-taps-address-usage-problem-statement-01.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 11, 2019) is 1866 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 (-05) exists of draft-gont-6man-address-usage-recommendations-04 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Services (taps) Working Group F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational G. Gont 5 Expires: September 12, 2019 SI6 Networks 6 M. Garcia Corbo 7 SITRANS 8 C. Huitema 9 Private Octopus Inc. 10 March 11, 2019 12 Problem Statement Regarding IPv6 Address Usage 13 draft-gont-taps-address-usage-problem-statement-01 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), and identifies gaps that currently 20 prevent systems and applications from leveraging the increased 21 flexibility and availability of IPv6 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 https://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 September 12, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 (https://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. Disclaimer/Notes . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. IPv6 Address Properties . . . . . . . . . . . . . . . . . . . 4 62 5.1. Address Scope Considerations . . . . . . . . . . . . . . 4 63 5.2. Address Stability Considerations . . . . . . . . . . . . 5 64 5.3. Usage Type Considerations . . . . . . . . . . . . . . . . 6 65 6. Default Address Selection in IPv6 . . . . . . . . . . . . . . 8 66 7. Current Possible Approaches for IPv6 Address Usage . . . . . 9 67 7.1. Incoming communications . . . . . . . . . . . . . . . . . 9 68 7.2. Outgoing communications . . . . . . . . . . . . . . . . . 10 69 8. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Issues Associated with Sub-optimal IPv6 Address Usage . . 10 71 8.1.1. Correlation of Network Activity . . . . . . . . . . . 10 72 8.1.2. Testing for the Presence of Node in the Network . . . 11 73 8.1.3. Unexpected Address Discovery . . . . . . . . . . . . 11 74 8.1.4. Availability Outside the Expected Scope . . . . . . . 12 75 8.2. Current Limitations in the Address Selection APIs . . . . 12 76 8.3. Sub-optimal IPv6 Address Configuration . . . . . . . . . 13 77 8.4. Sub-optimal IPv6 Address Usage . . . . . . . . . . . . . 13 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 12.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 IPv6 addresses may differ in a number of properties, such as address 89 scope (e.g. link-local vs. global), stability (e.g. stable addresses 90 vs. temporary addresses), and intended usage type (outgoing 91 communications vs. incomming communications). While often 92 overlooked, these properties have impact on areas such as security, 93 privacy, and performance. 95 IPv6 hosts typically configure a number of IPv6 addresses of 96 different properties. For example, a host may configure one stable 97 and one temporary address per each autoconfiguration prefix 98 advertised on the local network. Currently, the addresses to be 99 configured typically depend on local system policy, with the 100 aforementioned policy being static and irrespective of the network 101 the host attaches to. This "one size fits all" approach limits the 102 ability of systems and applications of fully-leveraging the increased 103 flexibility and availability of IPv6 addresses. 105 Each application running on a given system may have its own set of 106 requirements or expectations for the properties of the IPv6 addresses 107 to be employed. For example, an application meaning to offer a 108 public service might expect to employ global stable addresses for 109 such purpose, while a privacy-sensible client application might 110 prefer short-lived temporary addresses, or might even expect to 111 employ single-use ("throw-away") IPv6 addresses when connecting to 112 public servers. However, the subtetlies associated with IPv6 113 addresses (and associated properties) are often ignored by 114 application programmers and, in any case, current APIs (such as the 115 BSD Sockets API) tend to be very limited in the amount of control 116 they give applications to select the most appropriate IPv6 addresses 117 for a given task, thus limiting a programmer's ability to leverage 118 IPv6 address availability and properties. 120 This document analyzes the impact of a number of properties of IPv6 121 addresses on areas such as security and privacy, and analyzes how 122 IPv6 addresses are curently generated and employed by different 123 operating systems and applications. Finally, it provides a problem 124 statement by identifying and analyzing gaps that prevent systems and 125 applications from fully-leveraging IPv6 addressing capabilities, 126 setting the basis for further work that could fill those gaps. 128 2. Disclaimer/Notes 130 This document is a verbatim copy of 131 [I-D.gont-6man-address-usage-recommendations], modulo minor changes. 132 The aforementioned document was targeted at the 6man working group, 133 and thus this document focuses only on IPv6 addresses. If this 134 document is deemed of interest to the TAPS working group, it might be 135 expanded to discuss properties of IPv4 addresses. 137 3. Terminology 139 This document employs the definitions of "public address", "stable 140 address", and "temporary address" from Section 2 of [RFC7721]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 4. Background 148 Predictable IPv6 addresses result in a number of security and privacy 149 implications. For example, [Barnes2012] discusses how patterns in 150 network prefixes can be leveraged for IPv6 address scanning. On the 151 other hand, [RFC7707], [RFC7721] and [RFC7217] discuss the security 152 and privacy implications of predictable IPv6 Interface Identifiers 153 (IIDs). 155 Given the aforementioned previous work in this area, and the formal 156 specification update produced by [RFC8064], we expect (and assume in 157 the rest of this document) that implementations have replaced any 158 schemes that produce predictable addresses with alternative schemes 159 that avoid such patterns (e.g., RFC7217 in replacement of the 160 traditional SLAAC addresses that embed link-layer addresses). 162 5. IPv6 Address Properties 164 There are three parameters that affect the security and privacy 165 properties of an IPv6 address: 167 o Scope 169 o Stability 171 o Usage type (client-like "outgoing connections" vs. server-like 172 "incoming connections") 174 Section 5.1, Section 5.2, and Section 5.3 discuss the security and 175 privacy implications (and associated tradeoffs) of the scope, 176 stability and usage type properties of IPv6 addresses, respectively. 178 5.1. Address Scope Considerations 180 The IPv6 address scope can, in some scenarios, limit the attack 181 exposure of a node as a result of the implicit isolation provided by 182 a non-global address scope. For example, a node that only employs 183 link-local addresses may, in principle, only be exposed to attack 184 from other nodes in the local link. Hosts employing only Unique 185 Local Addresses (ULAs) may be more isolated from attack than those 186 employing Global Unicast Addresses (GUAs), assuming that proper 187 packet filtering is enforced at the network edge. 189 The potential protection provided by a non-global addresses should 190 not be regarded as a complete security strategy, but rather as a form 191 of "prophylactic" security (see 192 [I-D.gont-opsawg-firewalls-analysis]). 194 We note that the use of non-global addresses is usually limited to a 195 reduced type of applications/protocols that e.g. are only meant to 196 operate on a reduced scope, and hence their applicability may be 197 limited. 199 A discussion of ULA usage considerations can be found in 200 [I-D.ietf-v6ops-ula-usage-considerations]. 202 5.2. Address Stability Considerations 204 The stability of an address has two associated security/privacy 205 implications: 207 o Ability of an attacker to correlate network activity 209 o Exposure to attack 211 For obvious reasons, an address that is employed for multiple 212 communication instances allows the aforementioned network activities 213 to be correlated. The longer an address is employed (i.e., the more 214 stable it is), the longer such correlation will be possible. In the 215 worst-case scenario, a stable address that is employed for multiple 216 communication instances over time will allow all such activities to 217 be correlated. On the other hand, if a host were to generate (and 218 eventually "throw away") one new address for each communication 219 instance (e.g., TCP connection), network activity correlation would 220 be mitigated. 222 NOTE: 223 The use of constant IIDs (as in traditional SLAAC) result in 224 addresses that, while not constant as a whole (since the prefix 225 changes), contain a globally-unique value that leaks out the node 226 "identity". Such addresses result in the worst possible security 227 and privacy implications, and their use has been deprecated by 228 [RFC8064]. 230 Typically, when it comes to attack exposure, the longer an address is 231 employed the longer an attacker is exposed to attacks (e.g. an 232 attacker has more time to find the address in the first place 233 [RFC7707]). While such exposure is traditionally associated with the 234 stability of the address, the usage type of the address (see 235 Section 5.3) may also have an impact on attack exposure. 237 A popular approach to mitigate network activity correlation is the 238 use of "temporary addresses" [RFC4941]. Temporary addresses are 239 typically configured and employed along with stable addresses, with 240 the temporary addresses employed for outgoing communications, and the 241 stable addresses employed for incoming communications. 243 NOTE: 244 Ongoing work [I-D.gont-6man-non-stable-iids] aims at updating 245 [RFC4941] such that temporary addresses can be employed without 246 the need to configure stable addresses. 248 We note that the extent to which temporary addresses provide improved 249 mitigation of network activity correlation and/or reduced attack 250 exposure may be questionable and/or limited in some scenarios. For 251 example, a temporary address that is reachable for, say, a few hours 252 has a questionable "reduced exposure" (particularly when automated 253 attack tools do not typically require such a long period of time to 254 complete their task). Similarly, if network activity can be 255 correlated for the life of such address (e.g., on the order of 256 several hours), such period of time might be long enough for the 257 attacker to correlate all the network activity he is meaning to 258 correlate. 260 In order to better mitigate network activity correlation and/or 261 possibly reduce host exposure, an implementation might want to either 262 reduce the preferred lifetime of a temporary address, or even better, 263 generate one new temporary address for each new transport protocol 264 instance. However, the associated lifetime/stability of an address 265 may have a negative impact on the network. For example, if a node 266 were to employ "throw away" IPv6 addresses, or employ temporary 267 addresses [RFC4941] with a short preferred lifetime, local nodes 268 might need to maintain too many entries in their Neighbor Cache, and 269 a number of devices (possibly enforcing security policies) might also 270 need to cope with such additional state. 272 Additionally, enforcing a maximum lifetime on IPv6 addresses may 273 cause long-lived TCP connections to fail. For example, an address 274 becoming "Invalid" (after transitioning through the "Preferred" and 275 "Deprecated" states) would cause the TCP connections employing them 276 to break. This, in turn, would cause e.g. long-lived SSH sessions to 277 break/fail. 279 In some scenarios, attack exposure may be reduced by limiting the 280 usage of temporary addresses to outgoing connections, and prevent 281 such addresses from being used for incoming connections (please see 282 Section 5.3). 284 5.3. Usage Type Considerations 286 A node that employs one of its addresses to communicate with an 287 external server (i.e., to perform an "outgoing connection") may cause 288 such address to become exposed to attack. For example, once the 289 external server receives an incoming connection, the corresponding 290 server might launch an attack against the aforementioned address. A 291 real-world instance of this type of scenario has been documented in 292 [Hein]. 294 However, we note that employing an IPv6 address for outgoing 295 communications need not increase the exposure of local services to 296 other parties. For example, nodes could employ temporary addresses 297 only for outgoing connections, but not for incoming connections. 298 Thus, external nodes that learn about client's addresses could not 299 really leverage such addresses for actively contacting the clients. 301 There are multiple ways in which this could possibly be achieved, 302 with different implications. Namely: 304 o Run a host-based or network-based firewall 306 o Bind services to specific (explicit) addresses 308 o Bind services only to stable addresses 310 A client could simply run a host-based firewall that only allows 311 incoming connections on the stable addresses. This is clearly more 312 of an operational way of achieving the desired functionality, and may 313 require good firewall/host integration (e.g., the firewall should be 314 able to tell stable vs. temporary addresses), may require the client 315 to run additional firewall software for this specific purpose, etc. 316 In other scenarios, a network-based firewall could be configured to 317 allow outgoing communications from all internal addresses, but only 318 allow incoming communications to stable addresses. For obvious 319 reasons, this is generally only applicable to networks where incoming 320 communications are allowed to a limited number of hosts/servers. 322 Services could be bound to specific (explicit) addresses, rather than 323 to all locally-configured addresses. However, there are a number of 324 short-comings associated with this approach. Firstly, an application 325 would need to be able to learn all of its addresses and associated 326 stability properties, something that tends to be non-trivial and non- 327 portable, and that also makes applications protocol-dependent, 328 unnecessarily. Secondly, the BSD Sockets API does not really allow a 329 socket to be bound to a subset of the node's addresses. That is, 330 sockets can be bound to a single address or to all available 331 addresses (wildcard), but not to a subset of all the configured 332 addresses. 334 Binding services only to stable addresses provides a clean separation 335 between addresses employed for client-like outgoing connections and 336 server-like incoming connections. However, we currently lack an 337 appropriate API for nodes to be able to specify that a socket should 338 only be bound to stable addresses. 340 6. Default Address Selection in IPv6 342 Applications use system API's to select the IPv6 addresses that will 343 be used for incoming and outgoing connections. These choices have 344 consequences in terms of privacy, security, stability and 345 performance. 347 Default Address Selection for IPv6 is specified in [RFC6724]. The 348 selection starts with a set of potential destination addresses, such 349 as returned by getaddrinfo(), and the set of potential source 350 addresses currently configured for the selected interfaces. For each 351 potential destination address, the algorithm will select the source 352 address that provides the best route to the destination, while 353 choosing the appropriate scope and preferring temporary addresses. 354 The algorithm will then select the destination address, while giving 355 a preference to reachable addresses with the smallest scope. The 356 selection may be affected by system settings. We note that [RFC6724] 357 only applies for outgoing connections, such as those made by clients 358 trying to use services offered by other hosts. 360 We note that [RFC6724] selects IPv6 addresses from all the currently 361 available addresses on the host, and there is currently no way for an 362 application to indicate expected or desirable properties for the IPv6 363 source addresses employed for such outgoing communications. For 364 example, a privacy-sensitive application might want that each 365 outgoing communication instance employs a new, single-use IPv6 366 address, or to employ a new reusable address that is not employed or 367 reusable by any other application on the host. Reuse of an IPv6 368 address by an application would allow the correlation of all network 369 activities corresponding to such application as being performed by 370 the same host, while reuse of an IPv6 address by multiple different 371 applications would allow the correlation of all such network 372 activities as being performed by the host with such IPv6 address. 374 When devices provide a service, the common pattern is to just wait 375 for connections over all addresses configured on the device. For 376 example, applications using the BSD Sockets API will commonly bind() 377 the listening socket to the undefined address. This long-established 378 behavior is appropriate for devices providing public services, but 379 may have unexpected results for devices providing semi-private 380 services, such as various forms of peer-to-peer or local-only 381 applications. 383 This behavior leads to three problems: device tracking, discussed in 384 Section 8.1.2; unexpected address discovery, discussed in 385 Section 8.1.3; and availability outside the expected scope, discussed 386 in Section 8.1.4. These problems are caused in part by the 387 limitations of available address selection API, presented in 388 Section 8.2. 390 7. Current Possible Approaches for IPv6 Address Usage 392 7.1. Incoming communications 394 There are a number of ways in which a system or network may affect 395 which address (and how) may be employed for different services and 396 cases. Namely, 398 o TCP/IP stack address filtering 400 o Application-based address filtering 402 o Firewall-based address filtering 404 Clearly, the most elegant approach for address selection is for 405 applications to be able to specify the properties of the addresses 406 they are willing to employ by means of an API, such the TCP/IP stack 407 itself can "filter" which addresses are allowed to be employed for 408 the given service/application. This relieves the application from 409 dealing with low level details of networking, improves portability, 410 and avoids duplicate code in applications. However, constraints in 411 the current APIs (see Section 8.2) may limit the ability of 412 application progremmers for leveraging this technique. 414 Another possible approach is for applications to e.g. bind services 415 to all available addresses, and perform the associated selection/ 416 filtering at the application level. While possible this has a number 417 of drawbacks. Firstly, it would require applications to deal with 418 low-level networking details, require that all the associated code be 419 duplicated in all applications, and also negatively affect 420 portability. Besides, performing address/selection filtering at the 421 application level may not mitigate some possible threats. For 422 example, port scanning will still be possible, since the 423 aforementioned filtering will only be performed e.g. once UDP packets 424 are received or TCP connections are established. 426 Finally, a firewall may be employed to filter addresses based on 427 their intended usage. For example, a firewall may block incoming 428 requests to all addresses except to some whitelisted addresses (such 429 as the stable addresses of the node). This technique not only 430 requires the use of a firewall (which may or may not be present), but 431 also implies knowledge of the firewall regarding the desired 432 properties of the addresses that each application/service is intended 433 to use. 435 7.2. Outgoing communications 437 An application might be able to obtain the list of currently- 438 configured addresses, and subsequently select an address with desired 439 properties, and explicitly "bind" the address to the socket, to 440 override the default source address selection. 442 However, this approach is problematic for a number of reasons. 443 Firstly, there is no portable way of obtaining the list of currently- 444 configured addresses on the local node, and even less to check for 445 properties such "valid lifetime". Secondly, as discussed in 446 Section 7.1, it would require application programmers to understand 447 all the subtetiles associated with IPv6 addressing, and would also 448 lead to duplicate code on all applications. Finally, applications 449 would be limited to use already-configured addresses and unable to 450 trigger the generation of new addresses where desirable (e.g. the 451 genration of a new temporary address for this application instance or 452 communication instance). 454 8. Problem Statement 456 This section elaborates the problem statement on IPv6 address usage. 457 Section 8.1 describes the security and privacy implications of 458 improper IPv6 address usage, while Section 8.2, Section 8.4, 459 Section 8.3, analyze the possible root of such improper address 460 usage, suggesting possible future work. 462 8.1. Issues Associated with Sub-optimal IPv6 Address Usage 464 8.1.1. Correlation of Network Activity 466 As discussed in [RFC7721], a node that reuses an IPv6 address for 467 multiple communication instances would allow the correlation of such 468 network activities. This could be the case when the same IPv6 469 address is employed by several instances of the same application 470 (e.g., a browser in "privacy" mode and a browser in "normal" mode), 471 or when the same IPv6 address is employed by two different 472 applications on the same node (e.g., a browser in "privacy" mode, and 473 an email client). 475 Particularly for privacy-sensitive applications, an application or 476 system might want to limit the usage of a given IPv6 address to a 477 single communication instance, a single application, a single user on 478 the system, etc. However, given current APIs, this is practically 479 impossible. 481 8.1.2. Testing for the Presence of Node in the Network 483 The stable addresses recommended in [RFC8064] use stable IIDs defined 484 in [RFC7217]. One key part of that algorithm is that if a device 485 connects to a given network at different times, it will always 486 configure the same IPv6 addresses on that network. If the device 487 hosts a service ready to accept connections on that stable address, 488 adversaries can test the presence of the device on the network by 489 attempting connections to that stable address. Stable addresses used 490 by listening services will thus enable testing whether a specific 491 device is returning to a particular network, which in a number of 492 cases might be considered a privacy issue. 494 8.1.3. Unexpected Address Discovery 496 Systems like DNS-Based Service Discovery [RFC6763] allow clients to 497 discover services within a limited scope, that can be defined by a 498 domain name. These services are not advertised outside of that 499 scope, and thus do not expect to be discovered by random parties on 500 the Internet. However, such services may be easily discoverable if 501 they listen for connections to IPv6 addresses that a client process 502 also uses as source address when connecting to remote servers. 504 NOTE: 505 An example of such unexpected discovery is described in [Hein]. A 506 network manager observed scanning traffic directed at the 507 temporary addresses of local devices. The analysis in [Hein] 508 shows that the scanners learned the addresses by observing the 509 device contact an NTP service ([RFC5905]). The remote scanning 510 was possible because the local devices were also accepting 511 connections directed to the temporary addresses. 513 It should be obvious from the example that the "attack surface" of 514 the services is increased because they are bond to the same IPv6 515 addresses that are also used by clients for outgoing communications 516 with remote systems. But the overlap between "client" and "server" 517 addresses is only one part of the problem. Suppose that a device 518 hosts both a video game and a home automation application. The video 519 game users will be able to discover the IPv6 address of the game 520 server. If the home automation server listens to the same IPv6 521 addresses, it is now exposed to connection attempts by all these 522 users. That, too, increases the attack surface of the home 523 automation server. 525 8.1.4. Availability Outside the Expected Scope 527 The IPv6 addressing architecture [RFC4291] defines multiple address 528 scopes. In practice, devices are often configured with globally 529 reachable unicast addresses, link local addresses, and Unique Local 530 IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the 531 expected scope happens when a service is expected to be only 532 available in some local scope, but inadvertently becomes available to 533 remote parties. That could happen for example if a service is meant 534 to be available only on a given link, but becomes reachable through 535 ULA or through globally reachable addresses, or if a service is meant 536 to be available only inside some organization's perimeter and becomes 537 reachable through globally reachable addresses. It will happen in 538 particular if a service intended for some local scope is programmed 539 to bind to "unspecified" addresses, which in practice means every 540 address configured for the device (please see Section 8.2). 542 8.2. Current Limitations in the Address Selection APIs 544 Application developers using the BSD Sockets API can "bind" a 545 listening socket to a specific address, and ensure that the 546 application is only reachable through that address. In theory, 547 careful selection of the binding address could mitigate the problems 548 described in Section 8.1. Binding services to temporary addresses 549 could mitigate the ability of an attacker from testing for the 550 presence of the node in the network. Binding different services to 551 different addresses could mitigate unexpected discovery. Binding 552 services to link local addresses or ULA could mitigate availability 553 outside the expected scope. However, explicitly managing addresses 554 adds significant complexity to the application development. It 555 requires that application developers master addressing architecture 556 subtleties, and implement logic that reacts adequately to 557 connectivity events and address changes. Experience shows that 558 application developers would probably prefer some much simpler 559 solution. 561 In addition, we should note that many application developers use high 562 level APIs that listen to TLS, HTTP, or some other application 563 protocol. These high level APIs seldom provide detailed access to 564 specific IP addresses, and typically default to listening to all 565 available addresses. 567 A more advanced API could allow an application programmer to select 568 desired properties in an address (scope, lifespan, etc.), such that 569 the best-suitable addresses are selected, while relieving the 570 application for low-level IPv6 addressing details. Such API might 571 also trigger the generation of new IPv6 addresses when the specified 572 properties would require so. 574 8.3. Sub-optimal IPv6 Address Configuration 576 Most operating systems configure the same types of addresses 577 regardless of the current "operating mode" or "profile" of the device 578 (e.g., device connected to enterprise network vs roaming across 579 untrusted networks). For example, many operating systems configure 580 both stable [RFC8064] and temporary [RFC4941] addresses on all 581 network interfaces. However, this "one size fits all" approach tends 582 to be sub-optimal or inappropriate for some scenarios. For example, 583 enterprise networks typically prefer usage of only stable address, 584 thus meaning that a network administator needs to find the means for 585 disabling the generation of temporary addresses on all those systems 586 that would otherwise generate them. On the other hand, some mobile 587 devices configure both stable and temporary addresses, even when 588 their usage pattern (client-like operation, as opposed to offering 589 services to other nodes) would allow for the more privacy-sensible 590 option of configuring only temporary addresses. 592 The lack of better tuned address configuration policies has helped 593 the "one size fits all" approach that, as noted, may lead to 594 suboptimal results. Advice in this area might help achieve more 595 optional address generation policies such that IPv6 addressing 596 capabilities are fully leveraged. 598 8.4. Sub-optimal IPv6 Address Usage 600 An application programmer, left with the question of which are the 601 most appropriate addresses for a given usage type and application, 602 typically resorts to the Default IPv6 Address Selection for IPv6 (see 603 Section 6) for outgoing communications, and to accepting incoming 604 communications on all available addresses for incoming 605 communications. As discussed throughout this document, this leads to 606 sub-optimal results. Besides, all applications on a node share the 607 same pool of configured addresses, and applications are also 608 prevented from triggering the generation of new addresses (e.g. to be 609 employed for a particular application or communcation instance). 611 Guidance in this area is warranted such that applications and systems 612 fully-leverage IPv6 addressing. 614 9. IANA Considerations 616 There are no IANA registries within this document. The RFC-Editor 617 can remove this section before publication of this document as an 618 RFC. 620 10. Security Considerations 622 The security and privacy implications associated with the 623 predictability and lifetime of IPv6 addresses has been analyzed in 624 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 625 extends the aforementioned analysis by considering other IPv6 626 properties such as the address scope and address usage type, and the 627 associated tradeoffs. 629 11. Acknowledgements 631 The authors would like to thank (in alphabetical order) Francis 632 Dupont, Tatuya Jinmei, Erik Kline, Tommy Pauly, and Dave Thaler for 633 providing valuable comments on earlier versions of this document. 635 Fernando Gont would like to thank Spencer Dawkins for his guidance. 637 12. References 639 12.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 647 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 648 . 650 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 651 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 652 2006, . 654 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 655 Extensions for Stateless Address Autoconfiguration in 656 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 657 . 659 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 660 "Network Time Protocol Version 4: Protocol and Algorithms 661 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 662 . 664 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 665 "Default Address Selection for Internet Protocol Version 6 666 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 667 . 669 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 670 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 671 . 673 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 674 Interface Identifiers with IPv6 Stateless Address 675 Autoconfiguration (SLAAC)", RFC 7217, 676 DOI 10.17487/RFC7217, April 2014, 677 . 679 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 680 "Recommendation on Stable IPv6 Interface Identifiers", 681 RFC 8064, DOI 10.17487/RFC8064, February 2017, 682 . 684 12.2. Informative References 686 [Barnes2012] 687 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 688 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 689 Workshop on Active Internet Measurements, February 2012, 690 . 693 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", 694 January 2016, . 697 [I-D.gont-6man-address-usage-recommendations] 698 Gont, F., Gont, G., Corbo, M., and C. Huitema, "Problem 699 Statement Regarding IPv6 Address Usage", draft-gont-6man- 700 address-usage-recommendations-04 (work in progress), 701 October 2017. 703 [I-D.gont-6man-non-stable-iids] 704 Gont, F., Huitema, C., Krishnan, S., Gont, G., and M. 705 Corbo, "Recommendation on Temporary IPv6 Interface 706 Identifiers", draft-gont-6man-non-stable-iids-04 (work in 707 progress), March 2018. 709 [I-D.gont-opsawg-firewalls-analysis] 710 Gont, F. and F. Baker, "On Firewalls in Network Security", 711 draft-gont-opsawg-firewalls-analysis-02 (work in 712 progress), February 2016. 714 [I-D.ietf-v6ops-ula-usage-considerations] 715 Liu, B. and S. Jiang, "Considerations For Using Unique 716 Local Addresses", draft-ietf-v6ops-ula-usage- 717 considerations-02 (work in progress), March 2017. 719 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 720 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 721 . 723 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 724 Considerations for IPv6 Address Generation Mechanisms", 725 RFC 7721, DOI 10.17487/RFC7721, March 2016, 726 . 728 Authors' Addresses 730 Fernando Gont 731 SI6 Networks / UTN-FRH 732 Evaristo Carriego 2644 733 Haedo, Provincia de Buenos Aires 1706 734 Argentina 736 Phone: +54 11 4650 8472 737 Email: fgont@si6networks.com 738 URI: http://www.si6networks.com 740 Guillermo Gont 741 SI6 Networks 742 Evaristo Carriego 2644 743 Haedo, Provincia de Buenos Aires 1706 744 Argentina 746 Phone: +54 11 4650 8472 747 Email: ggont@si6networks.com 748 URI: https://www.si6networks.com 750 Madeleine Garcia Corbo 751 Servicios de Informacion del Transporte 752 Neptuno 358 753 Havana City 10400 754 Cuba 756 Email: madelen.garcia16@gmail.com 757 Christian Huitema 758 Private Octopus Inc. 759 Friday Harbor, WA 98250 760 U.S.A. 762 Email: huitema@huitema.net 763 URI: http://privateoctopus.com