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