idnits 2.17.1 draft-gont-v6ops-ipv6-addressing-considerations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (February 21, 2021) is 1157 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 (-07) exists of draft-ietf-6man-slaac-renum-02 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-12 == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-cpe-slaac-renum-06 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) F. Gont 3 Internet-Draft G. Gont 4 Intended status: Informational SI6 Networks 5 Expires: August 25, 2021 February 21, 2021 7 IPv6 Addressing Considerations 8 draft-gont-v6ops-ipv6-addressing-considerations-01 10 Abstract 12 IPv6 addresses can differ in a number of properties, such as scope, 13 stability, and intended usage type. This document analyzes the 14 impact of these properties on aspects such as security, privacy, 15 interoperability, and network operations. Additionally, it 16 identifies challenges and gaps that currently prevent systems and 17 applications from leveraging the increased flexibility and 18 availability of IPv6 addresses. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 25, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may not be modified, and derivative works of it may not 53 be created, and it may not be published except as an Internet-Draft. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Legacy Specifications and Schemes . . . . . . . . . . . . 4 61 3.2. Address Scope . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IPv6 Address Properties . . . . . . . . . . . . . . . . . . . 5 63 4.1. Address Scope Considerations . . . . . . . . . . . . . . 6 64 4.2. Provider Dependency . . . . . . . . . . . . . . . . . . . 7 65 4.3. Address Reachability . . . . . . . . . . . . . . . . . . 8 66 4.4. Address Stability Considerations . . . . . . . . . . . . 9 67 5. IPv6 Address Usage . . . . . . . . . . . . . . . . . . . . . 11 68 5.1. Default IPv6 Address Selection . . . . . . . . . . . . . 11 69 5.2. Usage Type Considerations . . . . . . . . . . . . . . . . 12 70 5.2.1. Incoming communications . . . . . . . . . . . . . . . 13 71 5.2.2. Outgoing communications . . . . . . . . . . . . . . . 14 72 6. Current Issues Associated with IPv6 Addressing . . . . . . . 15 73 6.1. Sub-optimal Address Configuration . . . . . . . . . . . . 15 74 6.1.1. Number of Addresses . . . . . . . . . . . . . . . . . 15 75 6.1.2. SLAAC/DHCPv6 Interaction . . . . . . . . . . . . . . 15 76 6.2. Sub-optimal IPv6 Address Usage . . . . . . . . . . . . . 16 77 6.2.1. Correlation of Network Activity . . . . . . . . . . . 16 78 6.2.2. Host Tracking . . . . . . . . . . . . . . . . . . . . 16 79 6.2.3. Unintended Service Disclosure . . . . . . . . . . . . 17 80 6.2.4. Availability of Service Outside the Expected Domain . 17 81 6.3. Operational Problems . . . . . . . . . . . . . . . . . . 18 82 6.3.1. Implications of Employing Multiple Addresses . . . . 18 83 6.3.2. Legitimate Network Activity Correlation . . . . . . . 18 84 6.3.3. Routing in Multi-Prefix/Multi-Router Networks . . . . 18 85 6.3.4. Renumbering . . . . . . . . . . . . . . . . . . . . . 19 86 7. Current Gaps that Prevent Leveraging IPv6 Addressing . . . . 20 87 7.1. Profile-based IPv6 Address Configuration . . . . . . . . 20 88 7.2. Advice on IPv6 Address Usage . . . . . . . . . . . . . . 21 89 7.3. Protocol Improvements to Deal with Many Addresses . . . . 21 90 7.4. Improved Address Selection APIs . . . . . . . . . . . . . 22 91 7.5. Universal Support of RFC 8028 . . . . . . . . . . . . . . 22 92 7.6. Support for Firewall Traversal in CE Routers . . . . . . 22 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 98 11.2. Informative References . . . . . . . . . . . . . . . . . 25 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 IPv6 addresses can differ in a number of properties, such as address 104 scope (e.g. link-local vs. global), stability (e.g. stable addresses 105 vs. temporary addresses), and intended usage type (outgoing 106 communications vs. incoming communications). While often overlooked, 107 these properties have direct impact on areas such as security, 108 privacy, interoperability, and network operations. 110 IPv6 hosts typically configure addresses based on local system 111 policy, which tends to be static and irrespective of the specific 112 network the host attaches to. For example, most IPv6 host 113 implementations configure one link-local address for each network 114 interface, and one stable and one (or more) temporary addresses per 115 each Stateless Address Auto-configuration (SLAAC) [RFC4862] prefix 116 for each network interface. However, this static policy for address 117 configuration might be inappropriate. For example, mobile nodes 118 might benefit from employing only temporary addresses, which 119 generally offer better privacy properties than stable addresses. On 120 the other hand, an enterprise network might prefer that local hosts 121 employ only stable addresses, which might be more convenient when 122 enforcing access control, performing network trouble-shooting, or 123 identifying hosts that might have been infected by malware. 125 On the other hand, Each application on a given host could have its 126 own set of requirements or expectations for the underlying IPv6 127 addresses. For example, an application meaning to offer a public 128 service might expect to employ addresses that are both globally- 129 reachable [RFC8190] and stable [RFC7721] [RFC8064], while a privacy- 130 sensible client application might prefer short-lived temporary 131 addresses [I-D.ietf-6man-rfc4941bis], or might even expect to employ 132 single-use ("ephemeral") IPv6 addresses when connecting to public 133 servers. However, the subtleties associated with IPv6 addresses are 134 often ignored or overlooked by application programmers. This means 135 that applications could fail to signal their requirements and 136 preferences to the underlying host, or that the addresses configured 137 by the underlying host might be inappropriate to satisfy the 138 requirements of the corresponding applications. 140 Finally, a number of limitations in components that range from 141 network devices to Application Programming Interfaces (APIs) could 142 also prevent hosts and applications from leveraging the increased 143 flexibility of IPv6 addressing. 145 This document identifies a set of properties that can be associated 146 with IPv6 addresses (such as scope and stability), and analyzes the 147 impact of these properties on areas ranging from security and privacy 148 to network operations, with the goal of providing guidance about IPv6 149 address usage. Additionally, it identifies challenges and gaps that 150 currently prevent systems and applications from leveraging the 151 increased flexibility and availability of IPv6 addresses. 153 2. Terminology 155 This document employs the definitions of "public address", "stable 156 address", and "temporary address" from Section 2 of [RFC7721]. 158 This document employs the definition of "globally reachable" from 159 Section 2.1 of [RFC8190]. 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 3. Conventions 169 3.1. Legacy Specifications and Schemes 171 IPv6 SLAAC has traditionally employed schemes for generating 172 Interface Identifiers (IIDs) that have negatively affected the 173 security and privacy properties of IPv6 addresses. For example, IPv6 174 SLAAC originally generated stable addresses by embedding the 175 underlying link-layer address in the IPv6 Interface Identifier (IID), 176 thus negatively affecting the security and privacy properties of IPv6 177 addresses [RFC7721] [RFC7707]. Similarly, IPv6 temporary addresses 178 [RFC4941] reused the same randomized IID for different auto- 179 configuration prefixes [RFC4941], thus allowing for network activity 180 correlation across different addresses of the same host. 182 These schemes have become formally superseded by other schemes, such 183 as [RFC7217] and [I-D.ietf-6man-rfc4941bis], that mitigate the 184 aforementioned issues. Therefore, this document does not discuss 185 issues arising from legacy IID generation algorithms. 187 NOTE: 188 The security and privacy implications of such schemes are 189 discussed in [RFC7721], [RFC7707], and [RFC7217]. 191 3.2. Address Scope 193 [RFC4007] defines the scope of an address as: 195 "[the] topological span within which the address may be used as a 196 unique identifier for an interface or set of interfaces" 198 And defines the "global scope" to be used for: 200 "uniquely identifying interfaces anywhere in the Internet" 202 However, the term "scope" is employed in conflicting ways in 203 different specifications (see [I-D.gont-6man-ipv6-ula-scope]). 204 Throughout this document, we employ the notion of "scope" defined in 205 [RFC4007]. As a result, addresses that do not uniquely identify 206 interfaces Internet-wide are considered to have "non-global" or 207 "limited" scope. Grouping addresses in such a way is simply useful 208 for the purpose of discussing address properties. 210 4. IPv6 Address Properties 212 There are, at least, four properties that can be associated with 213 every IPv6 address: 215 o Scope 217 o Reachability 219 o Stability 221 o Provider Dependency 223 The address scope essentially represents the topological span where 224 an address can be expected to uniquely identify an interface; i.e., 225 the topological span where an given address is meaningful. For 226 example, link-local addresses are only meaningful within a given 227 network link, and are expected to be unique only within such network 228 link. 230 Address reachability represents the topological span where an address 231 can be expected to be used for receiving and transmitting packets. 232 Reachability is implicitly constrained by the address scope, and may 233 also be affected by network devices: for example, Customer Edge 234 Routers (CE Routers) that enforce a filtering policy of "only 235 allowing outgoing communications" can render otherwise globally 236 reachable addresses as "unreachable from the public Internet, unless 237 communication is initiated from the customer's network". 239 The stability of an address is associated with the invariance of an 240 address over time. For example, a manually-configured address will 241 typically remain stable while the node remains attached to the same 242 subnet, while a temporary address will, by definition, change over 243 time. While address stability does depend on the inherent properties 244 of a given address (e.g. stable vs. temporary), it also depends on 245 other factors, such as provider dependency: if a network employs a 246 prefix that is assigned/leased by an upstream provider, then the 247 overall stability an address will also depend on the stability 248 corresponding network prefix. 250 Provider-dependency is typically discussed in the context of Global 251 Unicast Addresses, where the address space may be allocated by an 252 Internet Service Provider (ISP) (and hence "provider aggregatable") 253 or by a Regional Internet Registry (RIR) (and hence "provider 254 independent"). However, this document considers "provider 255 dependency" in a more general way: "provider aggregatable" address 256 space is assigned or leased by an upstream provider and carved out 257 from the provider's address space, and thus is topologically-related 258 to the upstream provider's address space; on the other hand, 259 "provider independent" address space is "owned" by the network in 260 question and thus is not necessarily topologically-related to the 261 upstream provider. 263 4.1. Address Scope Considerations 265 The IPv6 address scope [RFC4007] has a direct implication on address 266 reachability: the address scope essentially constrains address 267 reachability. For example, addresses that have a non-global/limited 268 scope are not, in principle, globally reachable. 270 NOTE: 271 This assumption becomes invalid if technologies such as Network 272 Prefix Translation (NPT) [RFC6296] are employed, though. However, 273 strictly speaking, in these scenarios the non-global addresses are 274 still not globally reachable, but rather the middle-box acts as an 275 interface with the "external realm" via globally-reachable 276 addresses (i.e., the middle-box provides an interface between two 277 topological spans). 279 The IPv6 address scope can, in some scenarios, limit the attack 280 exposure of a node as a result of the implicit isolation provided by 281 a non-global/limited address scopes. For example, a node that only 282 employs link-local addresses will, in principle, only be exposed to 283 attacks from other nodes on the same local link. 285 The potential protection provided by a non-global-scope addresses 286 should not be regarded as a complete security strategy, but rather as 287 a form of "prophylactic" security (see 288 [I-D.gont-opsawg-firewalls-analysis]). 290 We note that non-global scope addresses are normally only of use for 291 a limited number of applications/protocols that operate on a limited 292 scope (e.g., mDNS), or deployments where the intended participants 293 are known to operate in a limited domain [RFC8799] (e.g., OpenSSH 294 client and server attached to the same link and employing link-local 295 addresses, or mDNS hosts employing link-local addresses). 297 The address scope can at times be somewhat related with the provider 298 dependency property. For example, link-local addresses are, by 299 definition, provider independent. In the same light, a locally- 300 generated ULA prefix will be, by definition, provider independent. 301 However, a router might also employ a ULA prefix leased by an 302 upstream router, in which case this prefix would be "provider 303 dependent". The possible implications of the address scope on 304 "provider dependency" may also affect address stability: for example, 305 a locally-generated ULA prefix is "provider independent", and will 306 not be subject to renumbering events triggered by the upstream 307 provider. However, a router (e.g. CE Router) might, in some 308 circumstances, be unable to guarantee prefix stability -- as in the 309 case where the locally-generated ULA prefix is not recorded on stable 310 storage, and thus cannot be guaranteed to remain stable across power 311 outages. 313 4.2. Provider Dependency 315 Provider-dependency is typically discussed in the context of Global 316 Unicast Addresses, where the address space may be allocated by an 317 Internet Service Provider (ISP) (and hence "provider agreggatable") 318 or by a Regional Internet Registry (RIR) (and hence "provider 319 independent"). However, this document considers "provider 320 dependency" in a more general way: "provider aggregatable" address 321 space is assigned or leased by an upstream provider and carved out 322 from the provider's address space, and thus is topologically-related 323 to the upstream provider's address space; on the other hand, 324 "provider independent" address space is "owned" by the network in 325 question and thus is not necessarily topologically-related to the 326 upstream provider. 328 An implicit consequence of PA address space is that its use is tied 329 to the specific provider/upstream provider that provides the address 330 space. This has a number of consequences, including: 332 o Multi-homing (employing local address space with multiple upstream 333 providers) is not possible. 335 o A renumbering event at the upstream provider will typically cause 336 the local network to be renumbered. 338 Since PA space has a topological relationship with the upstream 339 provider, it will prevent multi-homing. This has led some 340 organizations to employ NPT [RFC6296] such that: 342 o The local network is isolated of renumbering events caused by the 343 upstream provider. 345 o The local network employs the same address space regardless of the 346 upstream provider employed to communicate with the external realm. 348 While PA space may impact address stability, PI address space 349 generally has better stability properties. For example, a home 350 network could internally employ both ULAs and GUAs, where a ULA 351 prefix is locally generated by the CE Router (and hence resulting in 352 PI space), and a global prefix is leased by the ISP via DHCPv6 Prefix 353 Delegation [RFC8415] (hence PA space). If for some reason there was 354 an outage involving the connection with the upstream ISP, the lease 355 time for the GUA prefix would eventually expire, and therefore 356 addresses configured for such prefix would need to be invalidated. 357 Similarly, if upon prefix lease expiration the ISP were to lease a 358 new GUA prefix (rather than renew the current prefix), the network 359 would need to be renumbered. On the other hand, locally-generated 360 ULA prefixes can be employed independently from the upstream ISP. 362 Similarly, an organizational network that employs PI global address 363 space obtained from a RIR would be able to employ the same address 364 space irrespective of renumbering events or outages involving the 365 upstream provider. 367 4.3. Address Reachability 369 Address reachability represents the area of the network (and the 370 associated conditions), where an address can be used for receiving 371 and transmitting packets. As noted in Section 4.1, the address scope 372 has a direct implication on address reachability, since it constrains 373 the network span where the address is reachable. 375 In addition to the reachability semantics of each address type, 376 network filtering policies may also affect address reachability. For 377 example, there is widespread deployment of Customer Edge Routers that 378 implement a (stateful) filtering policy of "only allowing outgoing 379 communications" -- mimicking the filtering policy enforced (as a 380 side-effect) by IPv4 NATs. In such scenarios, even otherwise 381 globally-reachable addresses become unreachable, unless: 383 o communication is initiated from the internal network, or, 385 o the CE Router is manually configured override the default 386 filtering policy, or, 388 o a technology to dynamically override the filtering policy (such as 389 UPnP [UPnP] or PCP [RFC6887]) is employed. 391 Address reachability is what ultimately determines the application 392 architecture that may be successfully employed by an IPv6 node. 394 NOTE: 395 Ironically, an IPv6-only host (with global-scope addresses) 396 attached to a home network where the CE Router "only allows 397 outgoing communications" and does not implement protocols such as 398 UPnP [UPnP] or PCP [RFC6887], will normally have a harder time 399 using peer-to-peer (P2P) applications than an IPv4-only host (with 400 a private address) attached to a home network where the CE Router 401 employs NAT but implements a protocols such as UPnP or PCP. 403 Address reachability has a direct impact on security, since the 404 ability to attack a system normally relies on the ability of the 405 attacker to reach the system in the first place. Firewalls 406 [I-D.gont-opsawg-firewalls-analysis] are, indeed, devices that are 407 specifically devoted to administer address reachability. 409 4.4. Address Stability Considerations 411 Address stability typically depends on two factors: 413 o Stability of the network prefix 415 o Inherent stability of address type 417 Depending on whether the local prefix is PI or PA (see Section 4.2) 418 and whether the prefix is stable or dynamic (see 419 [I-D.ietf-v6ops-slaac-renum]), the resulting addresses will have 420 different stability properties. Additionally, even in the presence 421 of stable prefixes, a host may configure stable addresses [RFC8064] 422 and/or temporary addresses [RFC4941]. 424 The stability of an address has two associated security/privacy 425 implications: 427 o Ability of an attacker to correlate network activity 429 o Exposure to attack 430 For obvious reasons, an address that is employed for multiple 431 communication instances allows the aforementioned network activities 432 to be correlated. The longer an address is employed (i.e., the more 433 stable it is), the longer such correlation will be possible. In the 434 worst-case scenario, a stable address that is employed for multiple 435 communication instances over time will allow all such activities to 436 be correlated. On the other hand, if a host were to generate (and 437 eventually remove) one new address for each communication instance 438 (e.g., TCP connection), network activity correlation would be 439 mitigated. 441 NOTE: 442 The security and privacy implications of predictable addresses are 443 discussed in [RFC7721] and [RFC7707]. 445 Typically, the longer an address is employed the longer the window of 446 exposure of a host as being accessible via an address that becomes 447 revealed as a result of active communication. While such exposure is 448 traditionally associated with the stability of the address, the usage 449 type of the address may also have an impact on attack exposure (see 450 Section 5.2). 452 A popular approach to mitigate network activity correlation is the 453 use of "temporary addresses" [RFC4941]. Temporary addresses are 454 typically auto-configured and employed along with stable addresses, 455 with the temporary addresses employed for outgoing communications, 456 and the stable addresses employed for incoming communications. 458 NOTE: 459 Ongoing work [I-D.ietf-6man-rfc4941bis] aims at updating [RFC4941] 460 such that temporary addresses can be employed without the need to 461 configure stable addresses. 463 We note that the extent to which temporary addresses provide improved 464 mitigation of network activity correlation and/or reduced attack 465 exposure may be questionable and/or limited in some scenarios. For 466 example, a temporary address that is reachable for, say, a few hours 467 has a questionable "reduced exposure" (particularly when automated 468 attack tools do not typically require such a long period of time to 469 complete their task). Similarly, if network activity can be 470 correlated for the life of such address (e.g., on the order of 471 several hours), such period of time might be long enough for the 472 attacker to correlate all the network activity of interest. However, 473 they temporary addresses do limit the attack window and the amount of 474 time during which address-based network activity correlation can be 475 performed. 477 In order to better mitigate network activity correlation and/or 478 possibly reduce host exposure, an implementation might want to either 479 reduce the preferred lifetime of temporary addresses or, even better, 480 generate one new IPv6 address for each application or new transport 481 protocol instance (sometimes referred to as "ephemeral addresses"). 482 However, reduced address lifetimes and the use of multiple IPv6 483 addresses may have a negative impact on the network (please see 484 Section 6.3). 486 Additionally, enforcing a maximum lifetime on IPv6 addresses may 487 cause long-lived TCP connections to fail. For example, an address 488 becoming "Invalid" (after transitioning through the "Preferred" and 489 "Deprecated" states) would cause the TCP connections employing them 490 to break, which would in turn cause e.g. long-lived SSH sessions to 491 break/fail. Traditionally, many application protocols have assumed 492 or expected address stability. However, in the light of mobile 493 roaming nodes that may frequently switch among different connections 494 (e.g. Wi-Fi, 4G, etc.) or that may be subject to renumbering events 495 (see [I-D.ietf-v6ops-slaac-renum]), robust applications should assume 496 and expect "ephemeral" IPv6 addresses (i.e., gracefully handle the 497 case where the underlying IPv6 addresses change over short periods of 498 time). 500 In some scenarios, attack exposure may be further mitigated by 501 limiting the usage of temporary addresses to outgoing connections, 502 and prevent such addresses from being used for incoming connections 503 (please see Section 5.2). 505 Finally, we note that on different single-use (i.e., "ephemeral") 506 IPv6 address is employed for each transport protocol instance, the 507 possibility of an attacker successfully performing off-path attacks 508 (such as the TCP reset attacks discussed in [RFC4953]) is reduced, 509 since the ephemeral IPv6 address will typically be unknown and 510 unpredictable to the off-path attacker. 512 5. IPv6 Address Usage 514 5.1. Default IPv6 Address Selection 516 Applications use system API's to implicitly or explicitly select the 517 IPv6 addresses that will be used for incoming and outgoing 518 connections. These choices have consequences in terms of privacy, 519 security, stability and performance. 521 Default Address Selection for IPv6 is specified in [RFC6724]. The 522 selection starts with a set of potential destination addresses, such 523 as returned by getaddrinfo(3), and the set of potential source 524 addresses currently configured for the selected interfaces. For each 525 potential destination address, the algorithm will select the source 526 address that provides the best route to the destination, while 527 choosing the appropriate scope and preferring temporary addresses. 528 The algorithm will then select the destination address, while giving 529 a preference to reachable addresses with the smallest scope. The 530 selection may be affected by system settings. We note that [RFC6724] 531 only applies for outgoing connections, such as those made by clients 532 trying to use services offered by other hosts. 534 We note that [RFC6724] selects IPv6 addresses from all the currently 535 available addresses on the host, and there is currently no way for an 536 application to indicate expected or desirable properties for the IPv6 537 source addresses employed for such outgoing communications. For 538 example, a privacy-sensitive application might want that each 539 outgoing communication instance employs a new, single-use IPv6 540 address, or to employ a new reusable address that is not employed or 541 reusable by any other application on the host. Reuse of an IPv6 542 address by an application would allow the correlation of all network 543 activities corresponding to such application as being performed by 544 the same host, while reuse of an IPv6 address by multiple different 545 applications would allow the correlation of all such network 546 activities as being performed by the host with such IPv6 address (see 547 Section 4.4 for further details). 549 When a host provides a service, the common pattern is to just wait 550 for incoming connections over all configured addresses. For example, 551 applications using the BSD Sockets API will commonly bind(2) the 552 listening socket to the undefined address. This long-established 553 behavior is appropriate for hosts providing public services, but can 554 have unexpected results for hosts providing semi-private services, 555 such as various forms of peer-to-peer or local-only applications 556 (e.g. mDNS). 558 This behavior leads to three problems: host tracking, discussed in 559 Section 6.2.2; unexpected address discovery, discussed in 560 Section 6.2.3; and availability outside the expected scope, discussed 561 in Section 6.2.4. These problems are caused in part by the 562 limitations of available address selection API, discussed in 563 Section 7.4. 565 5.2. Usage Type Considerations 567 IPv6 hosts may configure stable [RFC8064] and/or temporary [RFC4941] 568 addresses, where stable addresses are typically employed for incoming 569 (server-like) communications, and temporary addresses are employed 570 for outgoing (client-like) communications. That is, the stability 571 properties of an address have an implicitly associated usage type. 573 A host that employs one of its addresses to communicate with a remote 574 server (i.e., that performs an "outgoing connection") will expose 575 that address to the target server (and to on-path nodes). Once the 576 remote server receives an incoming connection, it could readily 577 launch an attack against the host via the exposed address. A real- 578 world instance of this type of scenario has been documented in 579 [Hein]. 581 However, we note that employing an IPv6 address for outgoing 582 communications need not increase the exposure of local services to 583 other parties. For example, nodes could employ temporary addresses 584 only for outgoing communications, and disallow their use for incoming 585 communications. Thus, nodes that learn about a client's addresses 586 could not really leverage such addresses for actively contacting 587 clients. Unfortunately, current APIs represent a challenge when 588 trying to leverage IPv6 addresses in this way (please see 589 Section 5.2.1 and Section 7.4 for further details). 591 The following subsections possible techniques that could be employed 592 by applications to better leverage IPv6 addresses for both incoming 593 and outgoing communications 595 5.2.1. Incoming communications 597 There are a number of ways in which a system or network may affect 598 which addresses (and how) may be employed for different services and 599 cases. Namely, 601 o TCP/IP stack address filtering 603 o Application-based address filtering 605 o Firewall-based address filtering 607 Clearly, the most elegant approach for address selection would be for 608 applications to be able to specify the properties of the addresses 609 they are willing to employ by means of an API, such the TCP/IP stack 610 itself could "filter" which addresses are allowed for the given 611 service/application. For example, an application could specify the 612 stability and scope properties of the addresses on which incoming 613 communications should be accepted, such that the application can be 614 relieved from dealing with low-level networking details, portability 615 is improved, and duplicate code in applications is avoided. However, 616 constraints in the current APIs (see Section 7.4) prevent application 617 programmers from leveraging this technique. Alternatively, services 618 could be bound to specific (explicit) addresses, rather than to all 619 locally-configured addresses. However, there are a number of short- 620 comings associated with this approach. Firstly, an application would 621 need to be able to learn all of its addresses and associated 622 properties, something that tends to be non-trivial and non-portable, 623 and that also makes applications protocol-dependent, unnecessarily. 624 Secondly, the BSD Sockets API does not allow a socket to be bound to 625 a subset of the node's addresses. That is, sockets can be bound to a 626 single address or to all available addresses (wildcard), but not to a 627 subset of all the configured addresses. 629 Another possible approach would be for applications to e.g. bind 630 services to all available addresses, and perform the associated 631 selection/filtering at the application level. While possible, this 632 would have a number of drawbacks. Firstly, it would require 633 applications to deal with low-level networking details, lead to 634 duplicated code in all applications, and also negatively affect 635 portability. Secondly, performing address/selection filtering at the 636 application level may not mitigate some possible attacks. For 637 example, port scanning would still be possible, since the 638 aforementioned filtering would be performed once UDP packets have 639 been received or TCP connections have been established. 641 A client could simply run a host-based firewall that only allows 642 incoming connections on the stable addresses. This would be more of 643 an operational approach for achieving the desired functionality, and 644 would require good firewall/host integration (e.g., the firewall 645 should be able to tell stable vs. temporary addresses), would require 646 the client to run additional firewall software for this specific 647 purpose, etc. In other scenarios, a network-based firewall could be 648 configured to allow outgoing communications from all internal 649 addresses, but only allow incoming communications to stable addresses 650 (either via manual configuration or via a helper protocol such as 651 [UPnP] or PCP [RFC6887]). For obvious reasons, this is generally 652 only applicable to networks where incoming communications are allowed 653 to a limited number of hosts/servers. 655 5.2.2. Outgoing communications 657 An application might be able to obtain the list of currently- 658 configured addresses, and subsequently select an address with desired 659 properties, and explicitly "bind" the address to the socket, to 660 override the default source address selection. 662 However, this approach is problematic for a number of reasons. 663 Firstly, there is no portable way of obtaining the list of currently- 664 configured addresses on the local node, and even less to check for 665 address properties such "valid lifetime". Secondly, as discussed in 666 Section 5.2.1, it would require application programmers to understand 667 all the subtleties associated with IPv6 addressing, and would also 668 lead to duplicate code on all applications. Finally, applications 669 would be limited to use already-configured addresses and unable to 670 trigger the generation of new addresses where desirable (e.g. the 671 generation of a new single-use address for this application instance 672 or communication instance). 674 6. Current Issues Associated with IPv6 Addressing 676 The following subsections discuss current problems associated with 677 IPv6 addresses, namely: 679 o Sub-optimal Address Configuration (Section 6.1) 681 o Sub-optimal IPv6 Address Usage (Section 6.2) 683 o Operational Problems (Section 6.3) 685 6.1. Sub-optimal Address Configuration 687 6.1.1. Number of Addresses 689 Two mechanisms exist for automatic network configuration: SLAAC 690 [RFC4862] and DHCPv6 [RFC8415]. DHCPv6 centralizes network 691 configuration and address assignment, and may thus prevent hosts from 692 leveraging the increased flexibility and availability of IPv6 693 addresses. On the other hand, SLAAC may result in network 694 configuration anarchy, where hosts may e.g. configure and use 695 addresses in a way that may negatively affect the network (please see 696 Section 6.3.1). 698 Most of the challenges associated with the use of multiple addresses 699 can be addressed by allocating one /64 per host via mechanisms such 700 as DHCPv6-PD [RFC8415]. However, support for such mechanisms in host 701 implementations and e.g. the LAN-side of CE Routers is rather 702 uncommon. On the other hand, SLAAC lacks the means for conveying 703 information about e.g., the number of addresses per host that the 704 network is able or willing to support. 706 NOTE: 707 Use of a /64 prefix per host could also render techniques such as 708 temporary addresses [RFC4941] ineffective, since hosts would 709 become identified by corresponding /64 prefix. 711 6.1.2. SLAAC/DHCPv6 Interaction 713 Many CE Routers offer address configuration via both SLAAC and 714 DHCPv6, by including Prefix Information Options (PIOs) with the "A" 715 flag set in Router Advertisement messages, and also setting the "M" 716 flag in such RA messages. This has a number of implications: 718 o The outcome of the configuration process is non-deterministic, 719 difficulting network troubleshooting (see 720 [I-D.ietf-v6ops-dhcpv6-slaac-problem]). 722 o Nodes end up configuring more addresses than needed (or even 723 used), normally configuring multiple stable addresses for each 724 autoconfiguration prefix, with at least one address for each 725 configuration mechanism (SLAAC and DHCPv6). 727 o A host may end up employing predictable addresses resulting from 728 DHCPv6, thus thwarting the security and privacy improvements of 729 SLAAC-configured addresses (i.e., [RFC7217] and [RFC4941]). 731 6.2. Sub-optimal IPv6 Address Usage 733 6.2.1. Correlation of Network Activity 735 As discussed in [RFC7721], a node that reuses an IPv6 address for 736 multiple communication instances will enable the correlation of such 737 network activities. This could be the case when the same IPv6 738 address is employed by several instances of the same application 739 (e.g., a browser in "privacy" mode and a browser in "normal" mode), 740 or when the same IPv6 address is employed by two different 741 applications on the same node (e.g., a browser in "privacy" mode, and 742 an email client). 744 Particularly in the case of privacy-sensitive applications, an 745 application or system might want to limit the usage of a given IPv6 746 address to a single communication instance, a single application, a 747 single user on the system, etc. However, as discussed in Section 5, 748 given current APIs, this is practically impossible. 750 6.2.2. Host Tracking 752 The stable addresses recommended in [RFC8064] use stable IIDs defined 753 in [RFC7217]. One key part of that algorithm is that if a device 754 connects to a given network at different times, it will always 755 configure the same IPv6 addresses on that network. If the device 756 hosts a service ready to accept connections on that stable address, 757 adversaries can test the presence of the device on the network by 758 attempting connections to that stable address. Stable addresses will 759 thus enable testing whether a specific device is returning to a 760 particular network, which in a number of cases might be considered a 761 privacy issue. 763 6.2.3. Unintended Service Disclosure 765 Systems like DNS-Based Service Discovery [RFC6763] allow clients to 766 discover services within a limited domain (e.g. a local link). These 767 services are not advertised outside of that domain, and thus do not 768 expect to be discovered by random parties on the Internet. However, 769 such services may be easily discoverable if they allow incoming 770 connections on IPv6 addresses that client processes also use when 771 connecting to remote servers. 773 NOTE: 774 An example of such service disclosure is described in [Hein]. A 775 network manager observed port scanning traffic directed at the 776 temporary addresses of local host. The analysis in [Hein] shows 777 that the scanners learned the addresses by observing the device 778 contact an NTP service ([RFC5905]). The remote scanning was 779 possible because the local services were accepting connections on 780 all configured addresses, including temporary addresses. 782 It is obvious from this example that local services are disclosed 783 because they are bond to the same IPv6 addresses that are also used 784 by clients for outgoing communications with remote systems. But the 785 overlap between "client" and "server" addresses is only one part of 786 the problem. Suppose that a host operates both a video game server 787 and a home automation application server. The video game users will 788 be able to discover the IPv6 address of the game server; if the home 789 automation server listens to the same IPv6 addresses, its address 790 will be revealed to all these users, thus increasing the exposure of 791 the home automation server. 793 We note that a host or network that wants to limit access to local 794 services should filter incoming connection attempts by affecting 795 address reachability (see Section 4.3) via firewalls 796 [I-D.gont-opsawg-firewalls-analysis] and/or the use of IPv6 addresses 797 of appropriate scope (see Section 4.1). However, it is also prudent 798 to avoid unintended service disclosure by avoiding the scenarios 799 discussed in this section. 801 6.2.4. Availability of Service Outside the Expected Domain 803 IPv6 defines [RFC4291] [RFC4007] multiple address scopes, with hosts 804 typically configuring Global Unicast Addresses (GUAs), link local 805 addresses, and Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193]. 806 Availability of a service outside the expected scope happens when a 807 service is expected to be available only in some limited domain, but 808 inadvertently becomes available from outside of that domain. This 809 could happen, for example, if a service is meant to be accessible 810 only within a given link, but becomes reachable from outside that 811 link via ULAs or GUAs, or if a service is meant to be accessible only 812 within some organization's perimeter but becomes accessible from the 813 public Internet via GUAs. This will commonly happen if a service 814 intended for a limited domain is implemented by bind()ing the 815 listening socket to the "unspecified" addresses (please see 816 Section 7.4). 818 6.3. Operational Problems 820 6.3.1. Implications of Employing Multiple Addresses 822 Network deployments are currently recommended to provide multiple 823 IPv6 addresses to general-purpose hosts [RFC7934]. However, in some 824 scenarios, use of a large number of IPv6 addresses may have negative 825 implications on network devices that need to maintain entries for 826 each IPv6 address in network data structures (e.g., [RFC7039]). 827 Additionally, concurrent active use of multiple IPv6 addresses will 828 normally increase neighbour discovery traffic if Neighbour Caches in 829 network devices are not large enough to store all addresses on the 830 link. This can impact performance and energy efficiency on networks 831 on which multicast is expensive (e.g. 832 [I-D.ietf-mboned-ieee802-mcast-problems]). Finally, network devices 833 may interpret the use of a number of addresses above a certain 834 threshold as a security event, and block the offending device from 835 using the network. 837 6.3.2. Legitimate Network Activity Correlation 839 The desires of protecting individual privacy versus the desire to 840 effectively maintain and debug a network can conflict with each 841 other. For example, having clients use addresses that change over 842 time will make it more difficult to track down and isolate 843 operational problems. When looking at packet traces, it could become 844 more difficult to determine whether one is seeing behavior caused by 845 a single errant machine, or by a number of them. 847 6.3.3. Routing in Multi-Prefix/Multi-Router Networks 849 If the network is provided with multiple upstream connections via 850 different providers and different local routers, each of them will 851 typically provide its own PA address space (see Section 4.2) and thus 852 local hosts will typically configure addresses for each of PA address 853 spaces. In this scenario, packets sourced from a given PA space 854 should only employ the local router of the corresponding upstream 855 provider, since otherwise packets might be dropped as a result of 856 ingress/egress filtering [RFC2827]. Unfortunately, traditional 857 Neighbor Discovery [RFC4861] can advertise routes only with a per- 858 destination granularity, irrespective of the source address/prefix. 860 [RFC8028] addresses the most important challenges associated with 861 these scenarios. However, [RFC8028] is not yet widely implemented. 862 As a result, operating a multi-prefix/multi-router IPv6 network 863 represents a major challenge -- if at all possible. 865 6.3.4. Renumbering 867 The challenges posed by network renumbering have been known for a 868 very long time [RFC5887], with network renumbering typically being 869 assumed to be performed in a planned manner. 871 However, in scenarios where a host is moved to a different network 872 without the host detecting the network re-attachment event, or where 873 the network a host attaches to is moved to a different point of the 874 network topology (i.e., the network itself is migrated/"moved"), the 875 aforementioned host will also experience a renumbering event. In an 876 era in which migrating virtual machines, containers, and networks 877 around a network topology is commonplace, and where mobile systems 878 changing network connectivity to and from e.g. WiFi and 4G is also 879 commonplace, renumbering events are anything but rare. 881 One of the challenges represented by network renumbering is how hosts 882 can infer that an existing network prefix and associated address(es) 883 have become stale (such that stale prefixes and addresses can be 884 removed and replaced by new prefixes and addresses). In scenarios 885 where the network topology does not change and the network is 886 renumbered, network elements may be aware of the renumbering event 887 and signal this condition to attached systems (i.e., signal that 888 existing network configuration information should be removed and 889 replaced). However, in scenarios where it is the host, virtual 890 machine, container or network that move around the network topology, 891 the network might not be able to signal the "renumbering event", and 892 these events might be harder to infer and react to. 894 Unfortunately, both SLAAC and DHCPv6 assume that network 895 configuration information is somewhat stable. SLAAC has 896 traditionally employed long lifetimes for network configuration 897 information, meaning that stale information could be employed for an 898 unacceptably long period of time. DCHPv6 operates on the same 899 premise, and lacks widespread support for RECONFIGURE messages -- so 900 even if the network were in a position to signal a renumbering event, 901 hosts will normally rely on expiration of lease times for stale 902 information to be cleared up. 904 Some of these problems have been discussed in detail in 905 [I-D.ietf-v6ops-slaac-renum], and there is ongoing work 906 [I-D.ietf-6man-slaac-renum] [I-D.ietf-v6ops-cpe-slaac-renum] to 907 mitigate this issue. 909 7. Current Gaps that Prevent Leveraging IPv6 Addressing 911 The following subsections identify and discuss areas where further 912 work is needed. Namely, 914 o Profile-based IPv6 Address Configuration (see Section 7.1) 916 o Advice on IPv6 Address Usage (see Section 7.2) 918 o Protocol Improvements to Deal with Many Addresses (see 919 Section 7.3) 921 o Improved Address Selection APIs (see Section 7.4) 923 o Universal Support of RFC 8028 (see Section 7.5) 925 o Support for Firewall Traversal in CE Routers (see Section 7.6) 927 7.1. Profile-based IPv6 Address Configuration 929 Most operating systems configure the same type of addresses 930 regardless of the current "operating mode" or "profile" of the device 931 (e.g., device connected to an enterprise network vs. roaming across 932 untrusted networks). For example, many operating systems configure 933 both stable [RFC8064] and temporary [RFC4941] addresses for all 934 network types. However, this "one size fits all" approach tends to 935 be sub-optimal or even inappropriate for some scenarios. For 936 example, enterprise networks typically prefer the use of only stable 937 addresses, thus requiring the network administrator to configure each 938 host to disable the use of temporary addresses. On the other hand, 939 mobile devices typically configure both stable and temporary 940 addresses, even when their operating mode (client-like operation) 941 would allow for the more privacy-sensible option of configuring only 942 temporary addresses. 944 The lack of fine-grained address configuration policies forces nodes 945 to rely on a "one size fits all" approach that, as noted, usually 946 leads to suboptimal results. Advice in this area might help achieve 947 profile-based address configuration policies such that IPv6 948 addressing capabilities are fully leveraged. 950 NOTE: 951 One might envision a document that provides advice regarding IPv6 952 address generation for different typical scenarios (e.g., when to 953 configure stable-only, temporary-only, or stable+temporary). In 954 the most simple analysis, one might expect nodes in a typical 955 enterprise network to employ only stable addresses. General- 956 purpose nodes in a home or "trusted" network might want to employ 957 both stable and temporary addresses. Finally, mobile nodes (e.g. 958 when roaming across non-trusted networks) might want to employ 959 only temporary addresses). 961 7.2. Advice on IPv6 Address Usage 963 An application programmers typically rely to the Default Source IPv6 964 Address Selection for IPv6 (see Section 5.1) for outgoing 965 communications, and to accepting incoming communications on all 966 configured addresses. As discussed throughout this document, this 967 leads to sub-optimal or undesirable results. Applications on a node 968 share the same pool of configured addresses, and currently available 969 APIs prevent applications from requesting the generation of new 970 addresses (e.g. to be employed for a particular application or 971 communication instance). 973 Guidance in this area is warranted such that applications and systems 974 can fully leverage IPv6 addressing. 976 NOTE: 977 Such guidance would elaborate, among other things, both on the 978 usage of IPv6 addresses when offering network services and when 979 performing client-like communications. For example, for incoming 980 communications, hosts might want to employ only the smallest-scope 981 applicable addresses (if available) and, if stable addresses are 982 available only accept incoming connections on such addresses. For 983 client-like communications, hosts might prefer temporary 984 addresses, unless the corresponding communication instances are 985 expected to be long-lived (e.g., SSH sessions). 987 7.3. Protocol Improvements to Deal with Many Addresses 989 Possible improvements to IPv6 SLAAC should be evaluated, including: 991 o Enabling IPv6 routers to convey information about network 992 constraints such as maximum number of addressees per node. 994 o Enabling hosts to register/de-register configured addresses, such 995 that e.g. routers need not tie resources to addresses that are no 996 longer used. 998 On the other hand, in order for DHCPv6-PD (or some alternative 999 protocol) to be employed to support the "one /64 per node" paradigm, 1000 widespread support for DHCPv6-PD (or an alternative protocol) would 1001 be necessary. 1003 7.4. Improved Address Selection APIs 1005 Application developers using the BSD Sockets API can "bind()" a 1006 listening socket to a specific address, and ensure that the 1007 application is only reachable through that address. In theory, 1008 careful selection of the binding address could mitigate the problems 1009 described in Section 6.2. Binding services to temporary addresses 1010 could mitigate the ability of an attacker from testing for the 1011 presence of the node in the network. Binding different services to 1012 different addresses could mitigate unexpected discovery. Binding 1013 services to non-globally-reachable addresses (e.g. link-local 1014 addresses or ULAs) could mitigate availability outside the expected 1015 domain. However, explicitly managing addresses adds significant 1016 complexity to application development. It requires that application 1017 developers master IPv6 addressing architecture subtleties, and 1018 implement logic that reacts adequately to connectivity events and 1019 address changes. Experience shows that application developers would 1020 probably prefer some much simpler solution. 1022 In addition, we note that many application developers use high level 1023 APIs that listen to TLS, HTTP, or some other application protocol. 1024 These high level APIs seldomly provide detailed access to specific 1025 IPv6 addresses, and typically default to listening to all available 1026 addresses. 1028 A more advanced API could allow application programmers to select 1029 desired properties in an address (scope, stability, etc.), such that 1030 the best-suitable addresses are selected, while relieving the 1031 application from low-level IPv6 addressing details. Such API could 1032 also trigger the generation of new IPv6 addresses if/when the 1033 specified properties require so. 1035 7.5. Universal Support of RFC 8028 1037 To put it bluntly, multi-prefix/multi-router networks cannot possibly 1038 work properly without implementation of [RFC8028]. Unfortunately, 1039 [RFC8028] is not widely implemented yet. On the protocol 1040 standardization side, the IETF should consider elevating the 1041 requirement to support RFC8028 in the IPv6 Node Requirements RFC 1042 [RFC8504] from "SHOULD" to "MUST". 1044 7.6. Support for Firewall Traversal in CE Routers 1046 Customer Edge Routers that implement a default filtering policy of 1047 "only allowing outgoing communications" need to support helper 1048 protocols such as [UPnP] or PCP [RFC6887], so that applications can 1049 open holes in the CE Router firewall to be able to receive incoming 1050 communications. Otherwise, P2P applications that currently work in 1051 IPv4 networks might not function in IPv6-only networks. 1053 Support for these protocols is particularly important for IPv6 1054 deployments since, as hosts will normally employ "provider 1055 aggregatable" addresses (see Section 4.2), renumbering events will 1056 result in host address changes, and thus static firewall rules will 1057 be harder to implement than for the IPv4 networks. Similarly, use of 1058 temporary addresses [RFC4941] will also lead to changing IPv6 1059 addresses, which will require that the associated firewall rules be 1060 updated. 1062 8. IANA Considerations 1064 This document has no IANA actions. 1066 9. Security Considerations 1068 The security and privacy implications associated with the 1069 predictability and lifetime of IPv6 addresses has been analyzed in 1070 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 1071 extends the aforementioned analysis by also considering other IPv6 1072 properties such as address scope and address reachability, and the 1073 associated trade-offs. 1075 10. Acknowledgements 1077 The authors would like to thank (in alphabetical order) Mikael 1078 Abrahamsson, Fred Baker, Brian Carpenter, Owen DeLong, Francis 1079 Dupont, Tatuya Jinmei, Ted Lemon, and Dave Thaler for providing 1080 valuable comments on earlier versions of this document. 1082 11. References 1084 11.1. Normative References 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", BCP 14, RFC 2119, 1088 DOI 10.17487/RFC2119, March 1997, 1089 . 1091 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1092 Defeating Denial of Service Attacks which employ IP Source 1093 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1094 May 2000, . 1096 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1097 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1098 DOI 10.17487/RFC4007, March 2005, 1099 . 1101 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1102 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1103 . 1105 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1106 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1107 2006, . 1109 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1110 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1111 DOI 10.17487/RFC4861, September 2007, 1112 . 1114 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1115 Address Autoconfiguration", RFC 4862, 1116 DOI 10.17487/RFC4862, September 2007, 1117 . 1119 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1120 Extensions for Stateless Address Autoconfiguration in 1121 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1122 . 1124 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1125 "Network Time Protocol Version 4: Protocol and Algorithms 1126 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1127 . 1129 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1130 "Default Address Selection for Internet Protocol Version 6 1131 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1132 . 1134 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1135 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1136 . 1138 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1139 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1140 DOI 10.17487/RFC6887, April 2013, 1141 . 1143 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1144 Interface Identifiers with IPv6 Stateless Address 1145 Autoconfiguration (SLAAC)", RFC 7217, 1146 DOI 10.17487/RFC7217, April 2014, 1147 . 1149 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 1150 "Host Address Availability Recommendations", BCP 204, 1151 RFC 7934, DOI 10.17487/RFC7934, July 2016, 1152 . 1154 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1155 Hosts in a Multi-Prefix Network", RFC 8028, 1156 DOI 10.17487/RFC8028, November 2016, 1157 . 1159 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1160 "Recommendation on Stable IPv6 Interface Identifiers", 1161 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1162 . 1164 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1165 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1166 May 2017, . 1168 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1169 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1170 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1171 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1172 . 1174 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1175 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1176 January 2019, . 1178 11.2. Informative References 1180 [Hein] Hein, B., "The Rising Sophistication of Network 1181 Scanning", January 2016, 1182 . 1185 [I-D.gont-6man-ipv6-ula-scope] 1186 Gont, F., "Scope of Unique Local IPv6 Unicast Addresses", 1187 draft-gont-6man-ipv6-ula-scope-00 (work in progress), 1188 January 2021. 1190 [I-D.gont-opsawg-firewalls-analysis] 1191 Gont, F. and F. Baker, "On Firewalls in Network Security", 1192 draft-gont-opsawg-firewalls-analysis-02 (work in 1193 progress), February 2016. 1195 [I-D.ietf-6man-rfc4941bis] 1196 Gont, F., Krishnan, S., Narten, T., and R. Draves, 1197 "Temporary Address Extensions for Stateless Address 1198 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12 1199 (work in progress), November 2020. 1201 [I-D.ietf-6man-slaac-renum] 1202 Gont, F., Zorz, J., and R. Patterson, "Improving the 1203 Robustness of Stateless Address Autoconfiguration (SLAAC) 1204 to Flash Renumbering Events", draft-ietf-6man-slaac- 1205 renum-02 (work in progress), January 2021. 1207 [I-D.ietf-mboned-ieee802-mcast-problems] 1208 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1209 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1210 Media", draft-ietf-mboned-ieee802-mcast-problems-12 (work 1211 in progress), October 2020. 1213 [I-D.ietf-v6ops-cpe-slaac-renum] 1214 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 1215 the Reaction of Customer Edge Routers to Renumbering 1216 Events", draft-ietf-v6ops-cpe-slaac-renum-06 (work in 1217 progress), December 2020. 1219 [I-D.ietf-v6ops-dhcpv6-slaac-problem] 1220 Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, 1221 "DHCPv6/SLAAC Interaction Problems on Address and DNS 1222 Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-07 1223 (work in progress), August 2016. 1225 [I-D.ietf-v6ops-slaac-renum] 1226 Gont, F., Zorz, J., and R. Patterson, "Reaction of 1227 Stateless Address Autoconfiguration (SLAAC) to Flash- 1228 Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work 1229 in progress), November 2020. 1231 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1232 RFC 4953, DOI 10.17487/RFC4953, July 2007, 1233 . 1235 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1236 Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May 1237 2010, . 1239 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1240 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1241 . 1243 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1244 "Source Address Validation Improvement (SAVI) Framework", 1245 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1246 . 1248 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1249 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1250 . 1252 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1253 Considerations for IPv6 Address Generation Mechanisms", 1254 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1255 . 1257 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 1258 "Updates to the Special-Purpose IP Address Registries", 1259 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 1260 . 1262 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 1263 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 1264 . 1266 [UPnP] UPnP, "UPnP Device Architecture 2.0", April 17, 2020, 1267 . 1270 Authors' Addresses 1272 Fernando Gont 1273 SI6 Networks 1274 Evaristo Carriego 2644 1275 Haedo, Provincia de Buenos Aires 1706 1276 Argentina 1278 Email: fgont@si6networks.com 1279 URI: https://www.si6networks.com 1280 Guillermo Gont 1281 SI6 Networks 1282 Evaristo Carriego 2644 1283 Haedo, Provincia de Buenos Aires 1706 1284 Argentina 1286 Email: ggont@si6networks.com 1287 URI: https://www.si6networks.com