idnits 2.17.1 draft-gont-v6ops-ipv6-addressing-considerations-00.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 (December 11, 2020) is 1233 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Barnes2012' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-ula-usage-considerations' is defined on line 1190, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-07) exists of draft-ietf-6man-slaac-renum-01 == 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-05 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-02 Summary: 1 error (**), 0 flaws (~~), 8 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: June 14, 2021 December 11, 2020 7 IPv6 Addressing Considerations 8 draft-gont-v6ops-ipv6-addressing-considerations-00 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 June 14, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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. Unique Local IPv6 Unicast Addresses (ULAs) . . . . . . . 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 Address Selection . . . . . . . . . . . . . . . . 11 69 5.2. Usage Type Considerations . . . . . . . . . . . . . . . . 12 70 5.3. Current Alternatives for IPv6 Address Usage . . . . . . . 12 71 5.3.1. Incoming communications . . . . . . . . . . . . . . . 12 72 5.3.2. Outgoing communications . . . . . . . . . . . . . . . 14 73 6. Current Issues . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Sub-optimal IPv6 Address Usage . . . . . . . . . . . . . 14 75 6.1.1. Correlation of Network Activity . . . . . . . . . . . 14 76 6.1.2. Passive Host Tracking . . . . . . . . . . . . . . . . 15 77 6.1.3. Unintended Service Disclosure . . . . . . . . . . . . 15 78 6.1.4. Availability Outside the Expected Scope . . . . . . . 16 79 6.2. Sub-optimal Address Configuration . . . . . . . . . . . . 16 80 6.2.1. Number of Addresses . . . . . . . . . . . . . . . . . 16 81 6.2.2. SLAAC/DHCPv6 Interaction . . . . . . . . . . . . . . 17 82 6.3. Operation of Multi-Prefix/Multi-Address/Multi-Router 83 Networks . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.3.1. Implications of Addresses . . . . . . . . . . . . . . 17 85 6.3.2. Legitimate Network Activity Correlation . . . . . . . 17 86 6.3.3. Routing in Multi-Prefix/Multi-Router Networks . . . . 18 87 6.3.4. Renumbering . . . . . . . . . . . . . . . . . . . . . 18 88 7. Current Gaps that Prevent Leveraging IPv6 Addressing . . . . 19 89 7.1. Better Address Selection APIs . . . . . . . . . . . . . . 19 90 7.2. Universal Support of Multi-prefix/Multi-router Networks . 20 91 7.3. Profile-based IPv6 Address Configuration . . . . . . . . 20 92 7.4. Protocol Improvements to Deal with Many Addresses . . . . 21 93 7.5. Support for Firewall Traversal in CE Routers . . . . . . 21 94 7.6. Advice on IPv6 Address Usage . . . . . . . . . . . . . . 21 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 100 11.2. Informative References . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 IPv6 addresses can differ in a number of properties, such as address 106 scope (e.g. link-local vs. global), stability (e.g. stable addresses 107 vs. temporary addresses), and intended usage type (outgoing 108 communications vs. incoming communications). While often overlooked, 109 these properties have direct impact on areas such as security, 110 privacy, interoperability, and network operations. 112 IPv6 hosts typically configure addresses based on local system 113 policy, which tends to be static and irrespective of the specific 114 network the host attaches to. For example, most IPv6 host 115 implementations configure one link-local address for each network 116 interface, and one stable and one (or more) temporary addresses per 117 each autoconfiguration prefix advertised via Stateless Address Auto- 118 configuration (SLAAC) [RFC4862] for each network interface. 119 Additionally, in scenarios where the network provides address 120 configuration via both SLAAC and DHCPv6, host typically configure 121 addresses using both protocols; as a result, hosts will typically add 122 one DHPv6-leased address per local prefix to the set of configured 123 addresses. 125 Each application on a given system could have its own set of 126 requirements or expectations for the properties of the underlying 127 IPv6 addresses. For example, an application meaning to offer a 128 public service might expect to employ addresses that are both 129 globally-reachable [RFC8190] and stable [RFC7721] [RFC8064], while a 130 privacy-sensible client application might prefer short-lived 131 temporary addresses [I-D.ietf-6man-rfc4941bis], or might even expect 132 to employ single-use ("throw-away") IPv6 addresses when connecting to 133 public servers. However, the subtleties associated with IPv6 134 addresses are often ignored or overlooked by application programmers 135 and network administrators, and thus hosts could end up making 136 suboptimal choices when configuring addresses, while applications 137 could fail to signal their requirements and preferences to the 138 underlying system. Additionally, limitations in the current 139 Application Programming Interfaces (APIs) along with implementation 140 constraints in some network devices can also limit the ability of 141 applications to leverage the increased flexibility of IPv6 142 addressing. This not only results in a failure to leverage the 143 increased addressing flexibility provided by IPv6 but, at times, also 144 in unintended consequences. 146 This document identifies a set of properties that can be associated 147 with IPv6 addresses (such as scope and stability), and analyzes the 148 impact of these properties on areas ranging from security and privacy 149 to network operations, with the goal of providing guidance about IPv6 150 address usage, and identifying challenges and gaps that currently 151 prevent systems and applications from leveraging the increased 152 flexibility and availability of IPv6 addresses. 154 2. Terminology 156 This document employs the definitions of "public address", "stable 157 address", and "temporary address" from Section 2 of [RFC7721]. 159 This document employs the definition of "globally reachable" from 160 Section 2.1 of [RFC8190]. 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 3. Conventions 170 3.1. Legacy Specifications and Schemes 172 IPv6 SLAAC has traditionally employed schemes for generating 173 Interface Identifiers (IIDs) that have negatively affected the 174 security and privacy properties of IPv6 addresses. For example, IPv6 175 SLAAC originally generated stable addresses by embedding the 176 underlying link-layer address in the IPv6 Interface Identifier (IID), 177 thus negatively affecting the security and privacy properties of IPv6 178 addresses [RFC7721] [RFC7707]. Similarly, IPv6 temporary addresses 179 [RFC4941] reused the same randomized IID for multiple auto- 180 configuration prefixes [RFC4941], thus allowing for network activity 181 correlation across different addresses of the same host. 183 These schemes have become formally superseded by other schemes, such 184 as [RFC7217] and [I-D.ietf-6man-rfc4941bis], that mitigate the issues 185 present in the legacy schemes. Therefore, does not discuss any 186 implications arising from legacy IID generation algorithms. 188 NOTE: 189 The security and privacy implications of such schemes are 190 discussed in [RFC7721], [RFC7707], and [RFC7217]. 192 3.2. Unique Local IPv6 Unicast Addresses (ULAs) 194 Unique Local IPv6 Unicast Addresses (ULAs) are considered to have 195 global scope, but non-global reachability. However, the only reasons 196 for which these addresses are considered to have "global scope" are: 198 o given two different networks that employ ULAs, it's unlikely that 199 they will employ the same ULA prefix 201 o the ULA address block formally belongs to the Global Unicast 202 Address (GUA) address block 204 The ULA prefixes of two different networks that e.g. need to be 205 merged will be (statistically) different *if* sites generate their 206 ULA prefixes following the recommendations in [RFC4193] -- i.e., 207 randomize the ULA prefix. However, this is not enforceable, and 208 there exists anecdotal evidence that some sites employ non-randomized 209 ULA prefixes, possibly in the hope of employing prefixes that are 210 easier to express via the IPv6 address notation (e.g. fd00::/48). 212 The ULA address block has been carved out of the GUA address block, 213 without updating the IPv6 Addressing Architecture ([RFC4291]) to 214 define the ULA address block as a different address type (e.g. "IPv6 215 private address space"). However, [RFC4193] notes that ULAs are not 216 expected to be globally-routable, and the ULA prefix is commonly 217 included in "bogon filters" typically enforced by network operators 218 and administrators, thus limiting the reachability of these 219 addresses. 221 Therefore, ULAs are not globally meaningful and thus, for most (if 222 not all) practical purposes, ULAs can be considered to have non- 223 global scope. For this reason, ULAs are treated as non-global scope 224 addresses, even when from a specifications point of view they have 225 global scope. 227 4. IPv6 Address Properties 229 There are, at least, four properties that can be associated with 230 every IPv6 address: 232 o Scope 234 o Reachability 236 o Stability 238 o Provider Dependency 239 The address scope essentially represents the area of the network 240 where an address can be expected to uniquely identify a system or set 241 of systems, or conceptually, the area of the network where an given 242 address is meaningful. For example, link-local addresses are only 243 meaningful within a given network link, and are expected to be unique 244 only within such network link. 246 Address reachability represents the area of the network, where an 247 address can be expected to be used for receiving and transmitting 248 packets. Besides the semantics of specific address types, 249 reachability can be affected by network devices: for example, 250 Customer Edge Routers (CE Routers) that enforce a filtering policy of 251 "only allowing outgoing communications" can render otherwise globally 252 reachable addresses as "unreachable from the public Internet, unless 253 communication is initiated from the customer's network". 255 The stability of an address is associated with the invariance of an 256 address over time. For example, a manually-configured address will 257 typically remain stable while the node remains attached to the same 258 subnet, while a temporary address will, by definition, change over 259 time. While address stability does depend on the inherent properties 260 of a given address (e.g. stable vs. temporary), it also depends on 261 other factors, such as provider dependency: if a network employs a 262 prefix that is assigned/leased by an upstream provider, then the 263 overall stability of the addresses will also depend on the stability 264 of the network prefix leased/assigned by the upstream. 266 Provider-dependency is typically discussed in the context of Global 267 Unicast Addresses, where the address space may be allocated by an 268 Internet Service Provider (ISP) (and hence "provider aggregatable") 269 or by a Regional Internet Registry (RIR) (and hence "provider 270 independent"). However, this document considers "provider 271 dependency" in a more general way: "provider aggregatable" address 272 space is assigned or leased by the upstream (which may or may not be 273 an ISP) from the provider's address space, and thus has a topological 274 relationship with the upstream's address space, whereas "provider 275 independent" address space is "owned" by the network in question and 276 does not necessarily have a topological relationship with the 277 upstream. 279 4.1. Address Scope Considerations 281 The IPv6 address scope [RFC4007] has a direct implication on address 282 reachability: the address scope essentially limits reachability. For 283 example, addresses that have a non-global scope are not, in 284 principle, globally reachable. 286 NOTE: 288 This assumption becomes invalid if technologies such as Network 289 Prefix Translation (NPT) [RFC6296] are employed, though. However, 290 strictly speaking, in these scenarios the non-global addresses are 291 still not globally reachable, but rather the middle-box acts as an 292 interface to the "external realm" via globally-reachable addresses 293 (i.e., the middle-box has an interface within the scope of the 294 non-global addresses, and globally-reachables address that are 295 used to communicate with the "external realm"). 297 The IPv6 address scope can, in some scenarios, limit the attack 298 exposure of a node as a result of the implicit isolation provided by 299 a non-global address scopes. For example, a node that only employs 300 link-local addresses will, in principle, only be exposed to attacks 301 from other nodes on the same local link. 303 The potential protection provided by a non-global-scope addresses 304 should not be regarded as a complete security strategy, but rather as 305 a form of "prophylactic" security (see 306 [I-D.gont-opsawg-firewalls-analysis]). 308 We note that non-global scope addresses are normally only of use for 309 limited number of applications/protocols that operate on a limited 310 scope (e.g., mDNS), or deployments where the intended participants 311 have been deployed in a limited area of the network topology (e.g., 312 OpenSSH client and server attached to the same link, both employing 313 link-local addresses). 315 The address scope can at times be somewhat related with the provider 316 dependency property. For example, link-local addresses are, by 317 definition, provider independent. In the same light, a ULA prefix 318 generated by a local router will be, by definition, provider 319 independent. However, a router might also be leased an ULA sub- 320 prefix from its upstream, in which case this prefix would be 321 "provider dependent". 323 4.2. Provider Dependency 325 Provider-dependency is typically discussed in the context of Global 326 Unicast Addresses, where the address space may be allocated by an 327 Internet Service Provider (ISP) (and hence "provider agregatable") or 328 by a Regional Internet Registry (RIR) (and hence "provider 329 independent"). However, this document considers "provider 330 dependency" in a more general way: "provider agregatable" address 331 space is assigned or leased by the upstream (which may or may not be 332 an ISP) from the provider's address space, and thus has a topological 333 relationship with the upstream's address space, whereas "provider 334 independent" address space is "owned" by the network in question and 335 does not necessarily have a topological relationship with the 336 upstream. 338 An implicit consequence of PA address space is that its use is tied 339 to the specific provider/upstream that has assigned/leased the 340 address space. This means that multi-homing (employing the address 341 space with multiple providers/upstreams) is not possible, and that a 342 renumbering event at the upstream could lead to a renumbering event 343 of the local network. 345 As a result, provider-dependency can affect address stability, with 346 PI address space generally having better stability properties. For 347 example, a home network could internally employ both ULAs and GUAs, 348 where a ULA prefix is locally generated by the Customer Edge Router 349 (CE Router), and global prefix is leased by the ISP via DHCPv6 Prefix 350 Delegation (DHCPv6-PD) [RFC8415]. If for some reason there was an 351 outage involving the connection with the upstream ISP, the prefix 352 lease time would eventually expire, and therefore addresses 353 configured for such prefix would need to be invalidated. Similarly, 354 if upon prefix lease expiration the ISP were to lease a new IPv6 355 prefix rather than renew the previously employed prefix, the network 356 would need to be renumbered. On the other hand, ULA prefixes locally 357 generated and advertised by the CE Router will not require renewal 358 from the ISP, since they are locally generated by the CE Router. 360 NOTE: 361 As noted above, while strictly speaking ULAs belong to the global 362 unicast address space, they can be considered non-global addresses 363 for all practical purposes. 365 Similarly, an organizational network that employs PI address space 366 obtained from a RIR would be able to keep the same address space, 367 even if the upstream network is renumbered. 369 4.3. Address Reachability 371 Address reachability represents the area of the network (and the 372 associated conditions), where an address can be expected to be used 373 for receiving and transmitting packets. As noted in Section 4.1, the 374 address scope has a direct implication on address reachability, since 375 address reachability is limited to a subset of the address scope. 376 For example, only global-scope addresses can be globally reachable. 378 However, besides the reachability semantics of each address type, 379 network filtering policies may also affect address reachability. For 380 example, there is widespread deployment of Customer Edge Routers that 381 implement a (stateful) filtering policy of "only allowing outgoing 382 communications" -- mimicking the filtering policy enforced (as a 383 side-effect) by IPv4 NATs. In such scenarios, even otherwise 384 globally-reachable addresses become unreachable, unless: 386 o communication is initiated from the internal network, or, 388 o the CE Router is manually configured override the default 389 filtering policy, or, 391 o a technology to dynamically override the filtering policy (such as 392 UPnP [UPnP] or PCP [RFC6887]) is employed. 394 Address reachability is what ultimately determines the application 395 architecture that may be employed by an IPv6 node. 397 NOTE: 398 Ironically, an IPv6-only host (with global-scope addresses) 399 attached to a home network where the CE Router "only allows 400 outgoing communications" and does not implement a protocol such as 401 UPnP [UPnP] or PCP [RFC6887], will normally have a harder time 402 using peer-to-peer (P2P) applications than an IPv4-only host (with 403 a private address) attached to a home network where the CE Router 404 employs NAT but implements a protocol such as UPnP or PCP. 406 Address reachability has a direct impact on security, since the 407 ability to attack a system normally relies on the ability of the 408 attacker to reach the system in the first place. Firewalls 409 [I-D.gont-opsawg-firewalls-analysis] are, indeed, devices that are 410 specifically devoted to administer address reachability. 412 4.4. Address Stability Considerations 414 The stability of an address has two associated security/privacy 415 implications: 417 o Ability of an attacker to correlate network activity 419 o Exposure to attack 421 For obvious reasons, an address that is employed for multiple 422 communication instances allows the aforementioned network activities 423 to be correlated. The longer an address is employed (i.e., the more 424 stable it is), the longer such correlation will be possible. In the 425 worst-case scenario, a stable address that is employed for multiple 426 communication instances over time will allow all such activities to 427 be correlated. On the other hand, if a host were to generate (and 428 eventually "throw away") one new address for each communication 429 instance (e.g., TCP connection), network activity correlation would 430 be mitigated. 432 NOTE: 433 The security and privacy implications of predictable addresses are 434 discussed in [RFC7721] and [RFC7707]. 436 Typically, when it comes to attack exposure, the longer an address is 437 employed the longer an attacker is exposed to attacks. While such 438 exposure is traditionally associated with the stability of the 439 address, the usage type of the address may also have an impact on 440 attack exposure (see Section 5.2). 442 A popular approach to mitigate network activity correlation is the 443 use of "temporary addresses" [RFC4941]. Temporary addresses are 444 typically auto-configured and employed along with stable addresses, 445 with the temporary addresses employed for outgoing communications, 446 and the stable addresses employed for incoming communications. 448 NOTE: 449 Ongoing work [I-D.ietf-6man-rfc4941bis] aims at updating [RFC4941] 450 such that temporary addresses can be employed without the need to 451 configure stable addresses. 453 We note that the extent to which temporary addresses provide improved 454 mitigation of network activity correlation and/or reduced attack 455 exposure may be questionable and/or limited in some scenarios. For 456 example, a temporary address that is reachable for, say, a few hours 457 has a questionable "reduced exposure" (particularly when automated 458 attack tools do not typically require such a long period of time to 459 complete their task). Similarly, if network activity can be 460 correlated for the life of such address (e.g., on the order of 461 several hours), such period of time might be long enough for the 462 attacker to correlate all the network activity he is meaning to 463 correlate. However, they do introduce a limit to the attack window, 464 and the amount of time during which address-based network activity 465 correlation can be performed. 467 In order to better mitigate network activity correlation and/or 468 possibly reduce host exposure, an implementation might want to either 469 reduce the preferred lifetime of a temporary address, or even better, 470 generate one new temporary address for each new transport protocol 471 instance. However, the associated lifetime/stability of an address 472 may have a negative impact on the network (please see Section 6.3. 474 Additionally, enforcing a maximum lifetime on IPv6 addresses may 475 cause long-lived TCP connections to fail. For example, an address 476 becoming "Invalid" (after transitioning through the "Preferred" and 477 "Deprecated" states) would cause the TCP connections employing them 478 to break, which would in turn cause e.g. long-lived SSH sessions to 479 break/fail. 481 In some scenarios, attack exposure may be mitigated by limiting the 482 usage of temporary addresses to outgoing connections, and prevent 483 such addresses from being used for incoming connections (please see 484 Section 5.2). 486 5. IPv6 Address Usage 488 5.1. Default Address Selection 490 Applications use system API's to select the IPv6 addresses that will 491 be used for incoming and outgoing connections. These choices have 492 consequences in terms of privacy, security, stability and 493 performance. 495 Default Address Selection for IPv6 is specified in [RFC6724]. The 496 selection starts with a set of potential destination addresses, such 497 as returned by getaddrinfo(), and the set of potential source 498 addresses currently configured for the selected interfaces. For each 499 potential destination address, the algorithm will select the source 500 address that provides the best route to the destination, while 501 choosing the appropriate scope and preferring temporary addresses. 502 The algorithm will then select the destination address, while giving 503 a preference to reachable addresses with the smallest scope. The 504 selection may be affected by system settings. We note that [RFC6724] 505 only applies for outgoing connections, such as those made by clients 506 trying to use services offered by other hosts. 508 We note that [RFC6724] selects IPv6 addresses from all the currently 509 available addresses on the host, and there is currently no way for an 510 application to indicate expected or desirable properties for the IPv6 511 source addresses employed for such outgoing communications. For 512 example, a privacy-sensitive application might want that each 513 outgoing communication instance employs a new, single-use IPv6 514 address, or to employ a new reusable address that is not employed or 515 reusable by any other application on the host. Reuse of an IPv6 516 address by an application would allow the correlation of all network 517 activities corresponding to such application as being performed by 518 the same host, while reuse of an IPv6 address by multiple different 519 applications would allow the correlation of all such network 520 activities as being performed by the host with such IPv6 address. 522 When devices provide a service, the common pattern is to just wait 523 for connections over all addresses configured on the device. For 524 example, applications using the BSD Sockets API will commonly bind() 525 the listening socket to the undefined address. This long-established 526 behavior is appropriate for devices providing public services, but 527 can have unexpected results for devices providing semi-private 528 services, such as various forms of peer-to-peer or local-only 529 applications. 531 This behavior leads to three problems: device tracking, discussed in 532 Section 6.1.2; unexpected address discovery, discussed in 533 Section 6.1.3; and availability outside the expected scope, discussed 534 in Section 6.1.4. These problems are caused in part by the 535 limitations of available address selection API, discussed in 536 Section 7.1. 538 5.2. Usage Type Considerations 540 IPv6 hosts can both stable [RFC8064] and/or temporary [RFC4941] 541 addresses, in which case stable addresses are typically employed for 542 incoming (server-like) communications, while temporary addresses are 543 employed for outgoing (client-like) communications. That is, the 544 stability properties of an address have an implicitly associated 545 usage type. 547 A node that employs one of its addresses to communicate with an 548 external server (i.e., to perform an "outgoing connection") will 549 expose that address to the other communicating system. For example, 550 once the external server receives an incoming connection, the 551 corresponding server might launch an attack against the 552 aforementioned address. A real-world instance of this type of 553 scenario has been documented in [Hein]. 555 However, we note that employing an IPv6 address for outgoing 556 communications need not increase the exposure of local services to 557 other parties. For example, nodes could employ temporary addresses 558 only for outgoing communications, and disallow their use for incoming 559 communications. Thus, external nodes that learn about a client's 560 addresses could not really leverage such addresses for actively 561 contacting clients. 563 Section 5 discusses current IPv6 address usage, along with possible 564 improvements. 566 5.3. Current Alternatives for IPv6 Address Usage 568 5.3.1. Incoming communications 570 There are a number of ways in which a system or network may affect 571 which addresses (and how) may be employed for different services and 572 cases. Namely, 574 o TCP/IP stack address filtering 575 o Application-based address filtering 577 o Firewall-based address filtering 579 Clearly, the most elegant approach for address selection would be for 580 applications to be able to specify the properties of the addresses 581 they are willing to employ by means of an API, such the TCP/IP stack 582 itself could "filter" which addresses are allowed for the given 583 service/application. For example, an application could specify the 584 stability and scope properties of the addresses on which incoming 585 communications should be accepted, such that the application can be 586 relieved from dealing with low-level networking details, portability 587 is improved, and duplicate code in applications is avoided. However, 588 constraints in the current APIs (see Section 7.1) limit the ability 589 of application programmers for leveraging this technique. 590 Alternatively, services could be bound to specific (explicit) 591 addresses, rather than to all locally-configured addresses. However, 592 there are a number of short-comings associated with this approach. 593 Firstly, an application would need to be able to learn all of its 594 addresses and associated properties, something that tends to be non- 595 trivial and non-portable, and that also makes applications protocol- 596 dependent, unnecessarily. Secondly, the BSD Sockets API does not 597 allow a socket to be bound to a subset of the node's addresses. That 598 is, sockets can be bound to a single address or to all available 599 addresses (wildcard), but not to a subset of all the configured 600 addresses. 602 Another possible approach would be for applications to e.g. bind 603 services to all available addresses, and perform the associated 604 selection/filtering at the application level. While possible, this 605 would have a number of drawbacks. Firstly, it would require 606 applications to deal with low-level networking details, lead to 607 duplicated code in all applications, and also negatively affect 608 portability. Secondly, performing address/selection filtering at the 609 application level may not mitigate some possible attacks. For 610 example, port scanning will still be possible, since the 611 aforementioned filtering would only be performed once e.g. UDP 612 packets are received or TCP connections are established. 614 A client could simply run a host-based firewall that only allows 615 incoming connections on the stable addresses. This would be clearly 616 more of an operational approach for achieving the desired 617 functionality, and would require good firewall/host integration 618 (e.g., the firewall should be able to tell stable vs. temporary 619 addresses), would require the client to run additional firewall 620 software for this specific purpose, etc. In other scenarios, a 621 network-based firewall could be configured to allow outgoing 622 communications from all internal addresses, but only allow incoming 623 communications to stable addresses (i.e., allow such addresses either 624 manually, or via a helper protocol such as [UPnP] or PCP [RFC6887]). 625 For obvious reasons, this is generally only applicable to networks 626 where incoming communications are allowed to a limited number of 627 hosts/servers. 629 5.3.2. Outgoing communications 631 An application might be able to obtain the list of currently- 632 configured addresses, and subsequently select an address with desired 633 properties, and explicitly "bind" the address to the socket, to 634 override the default source address selection. 636 However, this approach is problematic for a number of reasons. 637 Firstly, there is no portable way of obtaining the list of currently- 638 configured addresses on the local node, and even less to check for 639 address properties such "valid lifetime". Secondly, as discussed in 640 Section 5.3.1, it would require application programmers to understand 641 all the subtleties associated with IPv6 addressing, and would also 642 lead to duplicate code on all applications. Finally, applications 643 would be limited to use already-configured addresses and unable to 644 trigger the generation of new addresses where desirable (e.g. the 645 generation of a new single-use address for this application instance 646 or communication instance). 648 6. Current Issues 650 6.1. Sub-optimal IPv6 Address Usage 652 6.1.1. Correlation of Network Activity 654 As discussed in [RFC7721], a node that reuses an IPv6 address for 655 multiple communication instances will enable the correlation of such 656 network activities. This could be the case when the same IPv6 657 address is employed by several instances of the same application 658 (e.g., a browser in "privacy" mode and a browser in "normal" mode), 659 or when the same IPv6 address is employed by two different 660 applications on the same node (e.g., a browser in "privacy" mode, and 661 an email client). 663 Particularly for privacy-sensitive applications, an application or 664 system might want to limit the usage of a given IPv6 address to a 665 single communication instance, a single application, a single user on 666 the system, etc. However, given current APIs, this is practically 667 impossible. 669 6.1.2. Passive Host Tracking 671 The stable addresses recommended in [RFC8064] use stable IIDs defined 672 in [RFC7217]. One key part of that algorithm is that if a device 673 connects to a given network at different times, it will always 674 configure the same IPv6 addresses on that network. If the device 675 hosts a service ready to accept connections on that stable address, 676 adversaries can test the presence of the device on the network by 677 attempting connections to that stable address. Stable addresses used 678 by listening services will thus enable testing whether a specific 679 device is returning to a particular network, which in a number of 680 cases might be considered a privacy issue. 682 6.1.3. Unintended Service Disclosure 684 Systems like DNS-Based Service Discovery [RFC6763] allow clients to 685 discover services within a limited scope, that can be defined by a 686 domain name. These services are not advertised outside of that 687 scope, and thus do not expect to be discovered by random parties on 688 the Internet. However, such services may be easily discoverable if 689 they listen for connections to IPv6 addresses that a client process 690 also uses as source address when connecting to remote servers. 692 NOTE: 693 An example of such service disclosure is described in [Hein]. A 694 network manager observed scanning traffic directed at the 695 temporary addresses of local devices. The analysis in [Hein] 696 shows that the scanners learned the addresses by observing the 697 device contact an NTP service ([RFC5905]). The remote scanning 698 was possible because the local services were accepting connections 699 on all configured addresses, including temporary addresses. 701 It is obvious from this example that local services are disclosed 702 because they are bond to the same IPv6 addresses that are also used 703 by clients for outgoing communications with remote systems. But the 704 overlap between "client" and "server" addresses is only one part of 705 the problem. Suppose that a device hosts both a video game and a 706 home automation application. The video game users will be able to 707 discover the IPv6 address of the game server. If the home automation 708 server listens to the same IPv6 addresses, it is now exposed to 709 connection attempts by all these users. That, too, increases the 710 exposure of the home automation server. 712 We note that a host or network that wants to limit access to local 713 services should filter incoming connection attempts by affecting 714 address reachability (see Section 4.3) via firewalls 715 [I-D.gont-opsawg-firewalls-analysis] and/or the use of IPv6 addresses 716 of appropriate scope (see Section 4.1). However, it is also prudent 717 to avoid unintended service disclosure by suboptimal reuse of IPv6 718 addresses, as discussed in this section. 720 6.1.4. Availability Outside the Expected Scope 722 The IPv6 addressing architecture [RFC4291] defines multiple address 723 scopes, with devices often configured with globally reachable unicast 724 addresses, link local addresses, and Unique Local IPv6 Unicast 725 Addresses (ULA) [RFC4193]. Availability outside the expected scope 726 happens when a service is expected to be available only in some local 727 scope, but inadvertently becomes available from outside of that 728 scope. That could happen, for example, if a service is meant to be 729 available only on a given link, but becomes reachable through ULA or 730 through globally reachable addresses, or if a service is meant to be 731 available only inside some organization's perimeter and becomes 732 reachable through globally reachable addresses. This will commonly 733 happen if a service intended for some local scope is programmed to 734 bind() to the "unspecified" addresses, which in practice means every 735 address configured for the device (please see Section 7.1). 737 6.2. Sub-optimal Address Configuration 739 6.2.1. Number of Addresses 741 Two mechanisms exist for automatic network configuration: SLAAC and 742 DHCPv6. DHCPv6 centralizes network configuration and address 743 assignment, and may thus prevent hosts from leveraging the increased 744 flexibility and availability of IPv6 addresses. On the other hand, 745 SLAAC may also result in network configuration anarchy, where hosts 746 may e.g. configure and use addresses in a way that may render the 747 network virtually unusable (please see Section 6.3.1). 749 Most of the challenges associated with the use of multiple addresses 750 can be addressed by allocating one /64 per host via mechanisms such 751 as DHCPv6-PD. However, support for such mechanisms in host 752 implementations and e.g. the LAN-side of CE Routers is not 753 widespread, and thus is currently unfeasible. On the other hand, 754 SLAAC lacks the means for the network to convey information about 755 e.g., the number of addresses per host the network is able or willing 756 to support. 758 NOTE: 759 Use of a /64 prefix per host could render techniques such as 760 temporary addresses [RFC4941] ineffective, since hosts would 761 become identified by corresponding /64 prefix. 763 6.2.2. SLAAC/DHCPv6 Interaction 765 Many CE Routers offer address configuration via both SLAAC and 766 DHCPv6, by including Prefix Information Options (PIOs) in Router 767 Advertisement messages, and also setting the "M" such messages. This 768 has a number of implications: 770 o The outcome of the configuration process is non-deterministic, 771 difficulting network troubleshooting (see 772 [I-D.ietf-v6ops-dhcpv6-slaac-problem]). 774 o Nodes end up configuring more addresses than needed (or even 775 used), normally configuring multiple stable addresses for each 776 autoconfiguration prefix, with at least one address for each 777 configuration mechanism (SLAAC and DHCPv6). 779 o A host can end up employing stable and predictable addresses 780 resulting configured via DHCPv6, even when effort has been made to 781 mitigate security and privacy issues associated with IPv6 782 addresses for the SLAAC-configured addresses (i.e., [RFC7217] and 783 [RFC4941]). 785 6.3. Operation of Multi-Prefix/Multi-Address/Multi-Router Networks 787 6.3.1. Implications of Addresses 789 Network deployments are currently recommended to provide multiple 790 IPv6 addresses to general-purpose hosts [RFC7934]. However, in some 791 scenarios, use of a large number of IPv6 addresses may have negative 792 implications on network devices that need to maintain entries for 793 each IPv6 address in network data structures (e.g., [RFC7039]). 794 Additionally, concurrent active use of multiple IPv6 addresses will 795 normally increase neighbour discovery traffic if Neighbour Caches in 796 network devices are not large enough to store all addresses on the 797 link. This can impact performance and energy efficiency on networks 798 on which multicast is expensive (e.g. 799 [I-D.ietf-mboned-ieee802-mcast-problems]). Finally, network devices 800 may interpret the use of a number of addresses above a certain 801 threshold as a security event, and block the offending device from 802 using the network. 804 6.3.2. Legitimate Network Activity Correlation 806 The desires of protecting individual privacy versus the desire to 807 effectively maintain and debug a network can conflict with each 808 other. For example, having clients use addresses that change over 809 time will make it more difficult to track down and isolate 810 operational problems. For example, when looking at packet traces, it 811 could become more difficult to determine whether one is seeing 812 behavior caused by a single errant machine, or by a number of them. 814 6.3.3. Routing in Multi-Prefix/Multi-Router Networks 816 If the network is provided with multiple upstreams via different 817 routers, each of the upstream will provide its PA address space (see 818 Section 4.2) and local hosts will typically configure addresses for 819 each of such prefixes. In this scenarios, packets sourced from a 820 given prefix should only employ the local router that announced that 821 prefix, since otherwise the packets might be dropped as a result of 822 ingress/egress filtering [RFC2827]. Unfortunately, the traditional 823 Neighbor Discovery [RFC4861] can advertise routes only with a per- 824 destination granularity, irrespective of the source address/prefix. 826 [RFC8028] finally addressed the most important challenges associated 827 with these scenarios. However, [RFC8028] is not widely implemented. 828 As a result, operating a multi-prefix/multi-router IPv6 network 829 represents a major challenge -- if at all possible. 831 6.3.4. Renumbering 833 The challenges posed by network renumbering have been known for a 834 very long time [RFC5887], with renumbering being analyzed with the 835 assumption that the network topology remains stable and the network 836 is renumbered. 838 However, in scenarios where a host is moved to a different network 839 without the host detecting the network disattach/re-attach event, or 840 where the network a host attaches to is moved to a different point of 841 the network topology, the aforementioned host will also perceive a 842 renumbering event. In an era in which moving virtual machines, 843 containers, and networks around a network topology is commonplace, 844 and where mobile systems changing network connectivity to and from 845 e.g. WiFi and 4G is also commonplace, renumbering events are 846 anything but rare. 848 One of the challenges represented by network renumbering is how hosts 849 can infer that an existing network prefix and associated address(es) 850 have become stale and should be removed and replaced by new prefixes 851 and addresses. In scenarios where the network topology does not 852 change and the network is renumbered, network elements may be aware 853 about the renumbering event and signal this condition to attached 854 systems (i.e., signal that existing network configuration information 855 should be removed and replaced). However, in scenarios where it is 856 the host, virtual machine or container (or the network they are 857 attached to) that move around the network topology, the network will 858 not be able to signal the "renumbering event", and the renumbered 859 host, virtual machine, or container might or might not be able to 860 detect the event (e.g., via link-down/link-up events). 862 Unfortunately, both SLAAC and DHCPv6 assume network configuration 863 information to be somewhat stable. SLAAC has traditionally employed 864 long lifetimes for network configuration information, meaning that 865 stale information could be employed for an unacceptably long period 866 of time. DCHPv6 has traditionally suffered from the same problem 867 but, in addition, there is no widespread support for RECONFIGURE 868 messages, so even if the network were in a position to signal a 869 renumbering event, in practice hosts would normally have to rely on 870 expiration of lease times for stale information to be cleared up. 872 Some of these problems have been discussed in detail in 873 [I-D.ietf-v6ops-slaac-renum], and there is ongoing work 874 [I-D.ietf-6man-slaac-renum] [I-D.ietf-v6ops-cpe-slaac-renum] to 875 mitigate their effects. 877 7. Current Gaps that Prevent Leveraging IPv6 Addressing 879 7.1. Better Address Selection APIs 881 Application developers using the BSD Sockets API can "bind()" a 882 listening socket to a specific address, and ensure that the 883 application is only reachable through that address. In theory, 884 careful selection of the binding address could mitigate the problems 885 described in Section 6.1. Binding services to temporary addresses 886 could mitigate the ability of an attacker from testing for the 887 presence of the node in the network. Binding different services to 888 different addresses could mitigate unexpected discovery. Binding 889 services to non-global addresses (e.g. link-local addresses or ULAs) 890 could mitigate availability outside the expected scope. However, 891 explicitly managing addresses adds significant complexity to the 892 application development. It requires that application developers 893 master addressing architecture subtleties, and implement logic that 894 reacts adequately to connectivity events and address changes. 895 Experience shows that application developers would probably prefer 896 some much simpler solution. 898 In addition, we note that many application developers use high level 899 APIs that listen to TLS, HTTP, or some other application protocol. 900 These high level APIs seldomly provide detailed access to specific IP 901 addresses, and typically default to listening to all available 902 addresses. 904 A more advanced API could allow application programmers to select 905 desired properties in an address (scope, stability, etc.), such that 906 the best-suitable addresses are selected, while relieving the 907 application from low-level IPv6 addressing details. Such API could 908 also trigger the generation of new IPv6 addresses if/when the 909 specified properties required so. 911 7.2. Universal Support of Multi-prefix/Multi-router Networks 913 To put it bluntly, multi-prefix/multi-router networks cannot possibly 914 work properly without implementation of [RFC8028]. Unfortunately, 915 [RFC8028] is not widely implemented. On the protocol standardization 916 side, the IETF should consider elevating the requirement to support 917 RFC8028 in the IPv6 Node Requirements RFC [RFC8504] from "SHOULD" to 918 "MUST". 920 7.3. Profile-based IPv6 Address Configuration 922 Most operating systems configure the same type of addresses 923 regardless of the current "operating mode" or "profile" of the device 924 (e.g., device connected to an enterprise network vs roaming across 925 untrusted networks). For example, many operating systems configure 926 both stable [RFC8064] and temporary [RFC4941] addresses for all 927 network interfaces. However, this "one size fits all" approach tends 928 to be sub-optimal or inappropriate for some scenarios. For example, 929 enterprise networks typically prefer usage of only stable addresses, 930 thus meaning that a network administrator needs to find the means for 931 disabling the generation of temporary addresses on all those systems 932 that would otherwise generate them. On the other hand, some mobile 933 devices normally configure both stable and temporary addresses, even 934 when their usage type (client-like operation) would allow for the 935 more privacy-sensible option of configuring only temporary addresses. 937 The lack of better-tuned address configuration policies has helped 938 establish the "one size fits all" approach that, as noted, usually 939 leads to suboptimal results. Advice in this area might help achieve 940 more optional address configuration policies such that IPv6 941 addressing capabilities are fully leveraged. 943 NOTE: 944 One might envision a document that provides advice regarding the 945 address generation for different typical scenarios (e.g., when to 946 configure stable-only, temporary-only, or stable+temporary). In 947 the most simple analysis, one might expect nodes in a typical 948 enterprise network to employ only stable addresses. General- 949 purpose nodes in a home or "trusted" network might want to employ 950 both stable and temporary addresses. Finally, mobile nodes (e.g. 951 when roaming across non-trusted networks) might want to employ 952 only temporary addresses). 954 7.4. Protocol Improvements to Deal with Many Addresses 956 Possible improvements to IPv6 SLAAC should be evaluated, including: 958 o Enabling IPv6 routers to convey information about network 959 constraints such as maximum number of addressees per node 961 o Enabling hosts to register/de-register configured addresses, such 962 that e.g. routers need not tie resources to addresses that are no 963 longer used 965 If a /64 prefix is to be assigned for each host in order to leverage 966 IPv6 address availability while mitigating the possible effects on 967 network elements of employing large numbers of addresses, widespread 968 support for DHCPv6-PD (or some proposed alternative mechanism) should 969 be considered. 971 7.5. Support for Firewall Traversal in CE Routers 973 Customer Edge Routers that implement a default filtering policy of 974 "only allowing outgoing communications" need to support helper 975 protocols such as [UPnP] or PCP [RFC6887], so that applications can 976 punch holes in the CE Router firewall for applications that need to 977 receive incoming communications. Otherwise, P2P applications that 978 currently work in IPv4 will not function properly in IPv6-only 979 networks. 981 Support for these protocols is particularly important for IPv6 982 deployments since, as hosts will normally employ "provider 983 aggregatable" addresses (see Section 4.2), renumbering events will 984 result in host address changes, and thus static firewall rules will 985 become invalid/outdated. Additionally, use of temporary addresses 986 [RFC4941] will also lead to changing IPv6 addresses, which will 987 require that the associated firewall rules be updated. 989 7.6. Advice on IPv6 Address Usage 991 An application programmer, left with the question of which are the 992 most appropriate addresses for a given usage type and application, 993 typically resorts to the Default IPv6 Address Selection for IPv6 (see 994 Section 5.1) for outgoing communications, and to accepting incoming 995 communications on all available addresses for incoming 996 communications. As discussed throughout this document, this leads to 997 sub-optimal results. Besides, all applications on a node share the 998 same pool of configured addresses, and applications are also 999 prevented from triggering the generation of new addresses (e.g. to be 1000 employed for a particular application or communication instance). 1002 Guidance in this area is warranted such that applications and systems 1003 fully-leverage IPv6 addressing. 1005 NOTE: 1006 Such guidance would elaborate, among other things, on the usage of 1007 IPv6 addresses when offering network services and when performing 1008 client-like communications. For example, for incoming 1009 communications, hosts might want to employ only the smallest-scope 1010 applicable addresses (if available) and, if stable addresses are 1011 available, they might want to accept incoming connections only on 1012 such addresses (but *not* on temporary addresses). For client- 1013 like communications, hosts might prefer temporary addresses, 1014 unless the corresponding communication instances are expected to 1015 be long-lived (e.g., SSH sessions). 1017 8. IANA Considerations 1019 There are no IANA registries within this document. The RFC-Editor 1020 can remove this section before publication of this document as an 1021 RFC. 1023 9. Security Considerations 1025 The security and privacy implications associated with the 1026 predictability and lifetime of IPv6 addresses has been analyzed in 1027 [RFC7217] [RFC7721], and [RFC7707]. This document complements and 1028 extends the aforementioned analysis by considering other IPv6 1029 properties such as the address scope and address reachability, and 1030 the associated trade-offs. 1032 10. Acknowledgements 1034 The authors would like to thank (in alphabetical order) Mikael 1035 Abrahamsson, Fred Baker, Owen DeLong, Francis Dupont, Tatuya Jinmei, 1036 and Dave Thaler for providing valuable comments on earlier versions 1037 of this document. 1039 11. References 1041 11.1. Normative References 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, 1045 DOI 10.17487/RFC2119, March 1997, 1046 . 1048 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1049 Defeating Denial of Service Attacks which employ IP Source 1050 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1051 May 2000, . 1053 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1054 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1055 DOI 10.17487/RFC4007, March 2005, 1056 . 1058 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1059 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1060 . 1062 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1063 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1064 2006, . 1066 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1067 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1068 DOI 10.17487/RFC4861, September 2007, 1069 . 1071 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1072 Address Autoconfiguration", RFC 4862, 1073 DOI 10.17487/RFC4862, September 2007, 1074 . 1076 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1077 Extensions for Stateless Address Autoconfiguration in 1078 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1079 . 1081 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1082 "Network Time Protocol Version 4: Protocol and Algorithms 1083 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1084 . 1086 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1087 "Default Address Selection for Internet Protocol Version 6 1088 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1089 . 1091 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1092 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1093 . 1095 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1096 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1097 DOI 10.17487/RFC6887, April 2013, 1098 . 1100 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1101 Interface Identifiers with IPv6 Stateless Address 1102 Autoconfiguration (SLAAC)", RFC 7217, 1103 DOI 10.17487/RFC7217, April 2014, 1104 . 1106 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 1107 "Host Address Availability Recommendations", BCP 204, 1108 RFC 7934, DOI 10.17487/RFC7934, July 2016, 1109 . 1111 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 1112 Hosts in a Multi-Prefix Network", RFC 8028, 1113 DOI 10.17487/RFC8028, November 2016, 1114 . 1116 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1117 "Recommendation on Stable IPv6 Interface Identifiers", 1118 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1119 . 1121 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1122 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1123 May 2017, . 1125 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1126 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1127 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1128 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1129 . 1131 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1132 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 1133 January 2019, . 1135 11.2. Informative References 1137 [Barnes2012] 1138 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 1139 Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - 1140 Workshop on Active Internet Measurements, February 2012, 1141 . 1144 [Hein] Hein, B., "The Rising Sophistication of Network 1145 Scanning", January 2016, 1146 . 1149 [I-D.gont-opsawg-firewalls-analysis] 1150 Gont, F. and F. Baker, "On Firewalls in Network Security", 1151 draft-gont-opsawg-firewalls-analysis-02 (work in 1152 progress), February 2016. 1154 [I-D.ietf-6man-rfc4941bis] 1155 Gont, F., Krishnan, S., Narten, T., and R. Draves, 1156 "Temporary Address Extensions for Stateless Address 1157 Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12 1158 (work in progress), November 2020. 1160 [I-D.ietf-6man-slaac-renum] 1161 Gont, F., Zorz, J., and R. Patterson, "Improving the 1162 Robustness of Stateless Address Autoconfiguration (SLAAC) 1163 to Flash Renumbering Events", draft-ietf-6man-slaac- 1164 renum-01 (work in progress), August 2020. 1166 [I-D.ietf-mboned-ieee802-mcast-problems] 1167 Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. 1168 Zuniga, "Multicast Considerations over IEEE 802 Wireless 1169 Media", draft-ietf-mboned-ieee802-mcast-problems-12 (work 1170 in progress), October 2020. 1172 [I-D.ietf-v6ops-cpe-slaac-renum] 1173 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 1174 the Reaction of Customer Edge Routers to Renumbering 1175 Events", draft-ietf-v6ops-cpe-slaac-renum-05 (work in 1176 progress), September 2020. 1178 [I-D.ietf-v6ops-dhcpv6-slaac-problem] 1179 Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, 1180 "DHCPv6/SLAAC Interaction Problems on Address and DNS 1181 Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-07 1182 (work in progress), August 2016. 1184 [I-D.ietf-v6ops-slaac-renum] 1185 Gont, F., Zorz, J., and R. Patterson, "Reaction of 1186 Stateless Address Autoconfiguration (SLAAC) to Flash- 1187 Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work 1188 in progress), November 2020. 1190 [I-D.ietf-v6ops-ula-usage-considerations] 1191 Liu, B. and S. Jiang, "Considerations For Using Unique 1192 Local Addresses", draft-ietf-v6ops-ula-usage- 1193 considerations-02 (work in progress), March 2017. 1195 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 1196 Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May 1197 2010, . 1199 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1200 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1201 . 1203 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1204 "Source Address Validation Improvement (SAVI) Framework", 1205 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1206 . 1208 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1209 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1210 . 1212 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1213 Considerations for IPv6 Address Generation Mechanisms", 1214 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1215 . 1217 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 1218 "Updates to the Special-Purpose IP Address Registries", 1219 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 1220 . 1222 [UPnP] UPnP, "UPnP Device Architecture 2.0", April 17, 2020, 1223 . 1226 Authors' Addresses 1228 Fernando Gont 1229 SI6 Networks 1230 Evaristo Carriego 2644 1231 Haedo, Provincia de Buenos Aires 1706 1232 Argentina 1234 Email: fgont@si6networks.com 1235 URI: https://www.si6networks.com 1236 Guillermo Gont 1237 SI6 Networks 1238 Evaristo Carriego 2644 1239 Haedo, Provincia de Buenos Aires 1706 1240 Argentina 1242 Email: ggont@si6networks.com 1243 URI: https://www.si6networks.com