IPv6 Operations Working Group (v6ops) F. Gont Internet-Draft G. Gont Intended status: Informational SI6 Networks Expires: June 14, 2021 December 11, 2020 IPv6 Addressing Considerations draft-gont-v6ops-ipv6-addressing-considerations-00 Abstract IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 14, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Gont & Gont Expires June 14, 2021 [Page 1] Internet-Draft IPv6 Addressing Considerations December 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Legacy Specifications and Schemes . . . . . . . . . . . . 4 3.2. Unique Local IPv6 Unicast Addresses (ULAs) . . . . . . . 5 4. IPv6 Address Properties . . . . . . . . . . . . . . . . . . . 5 4.1. Address Scope Considerations . . . . . . . . . . . . . . 6 4.2. Provider Dependency . . . . . . . . . . . . . . . . . . . 7 4.3. Address Reachability . . . . . . . . . . . . . . . . . . 8 4.4. Address Stability Considerations . . . . . . . . . . . . 9 5. IPv6 Address Usage . . . . . . . . . . . . . . . . . . . . . 11 5.1. Default Address Selection . . . . . . . . . . . . . . . . 11 5.2. Usage Type Considerations . . . . . . . . . . . . . . . . 12 5.3. Current Alternatives for IPv6 Address Usage . . . . . . . 12 5.3.1. Incoming communications . . . . . . . . . . . . . . . 12 5.3.2. Outgoing communications . . . . . . . . . . . . . . . 14 6. Current Issues . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Sub-optimal IPv6 Address Usage . . . . . . . . . . . . . 14 6.1.1. Correlation of Network Activity . . . . . . . . . . . 14 6.1.2. Passive Host Tracking . . . . . . . . . . . . . . . . 15 6.1.3. Unintended Service Disclosure . . . . . . . . . . . . 15 6.1.4. Availability Outside the Expected Scope . . . . . . . 16 6.2. Sub-optimal Address Configuration . . . . . . . . . . . . 16 6.2.1. Number of Addresses . . . . . . . . . . . . . . . . . 16 6.2.2. SLAAC/DHCPv6 Interaction . . . . . . . . . . . . . . 17 6.3. Operation of Multi-Prefix/Multi-Address/Multi-Router Networks . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3.1. Implications of Addresses . . . . . . . . . . . . . . 17 6.3.2. Legitimate Network Activity Correlation . . . . . . . 17 6.3.3. Routing in Multi-Prefix/Multi-Router Networks . . . . 18 6.3.4. Renumbering . . . . . . . . . . . . . . . . . . . . . 18 7. Current Gaps that Prevent Leveraging IPv6 Addressing . . . . 19 7.1. Better Address Selection APIs . . . . . . . . . . . . . . 19 7.2. Universal Support of Multi-prefix/Multi-router Networks . 20 7.3. Profile-based IPv6 Address Configuration . . . . . . . . 20 7.4. Protocol Improvements to Deal with Many Addresses . . . . 21 7.5. Support for Firewall Traversal in CE Routers . . . . . . 21 7.6. Advice on IPv6 Address Usage . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 Gont & Gont Expires June 14, 2021 [Page 2] Internet-Draft IPv6 Addressing Considerations December 2020 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction IPv6 addresses can differ in a number of properties, such as address scope (e.g. link-local vs. global), stability (e.g. stable addresses vs. temporary addresses), and intended usage type (outgoing communications vs. incoming communications). While often overlooked, these properties have direct impact on areas such as security, privacy, interoperability, and network operations. IPv6 hosts typically configure addresses based on local system policy, which tends to be static and irrespective of the specific network the host attaches to. For example, most IPv6 host implementations configure one link-local address for each network interface, and one stable and one (or more) temporary addresses per each autoconfiguration prefix advertised via Stateless Address Auto- configuration (SLAAC) [RFC4862] for each network interface. Additionally, in scenarios where the network provides address configuration via both SLAAC and DHCPv6, host typically configure addresses using both protocols; as a result, hosts will typically add one DHPv6-leased address per local prefix to the set of configured addresses. Each application on a given system could have its own set of requirements or expectations for the properties of the underlying IPv6 addresses. For example, an application meaning to offer a public service might expect to employ addresses that are both globally-reachable [RFC8190] and stable [RFC7721] [RFC8064], while a privacy-sensible client application might prefer short-lived temporary addresses [I-D.ietf-6man-rfc4941bis], or might even expect to employ single-use ("throw-away") IPv6 addresses when connecting to public servers. However, the subtleties associated with IPv6 addresses are often ignored or overlooked by application programmers and network administrators, and thus hosts could end up making suboptimal choices when configuring addresses, while applications could fail to signal their requirements and preferences to the underlying system. Additionally, limitations in the current Application Programming Interfaces (APIs) along with implementation constraints in some network devices can also limit the ability of applications to leverage the increased flexibility of IPv6 addressing. This not only results in a failure to leverage the increased addressing flexibility provided by IPv6 but, at times, also in unintended consequences. Gont & Gont Expires June 14, 2021 [Page 3] Internet-Draft IPv6 Addressing Considerations December 2020 This document identifies a set of properties that can be associated with IPv6 addresses (such as scope and stability), and analyzes the impact of these properties on areas ranging from security and privacy to network operations, with the goal of providing guidance about IPv6 address usage, and identifying challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. 2. Terminology This document employs the definitions of "public address", "stable address", and "temporary address" from Section 2 of [RFC7721]. This document employs the definition of "globally reachable" from Section 2.1 of [RFC8190]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Conventions 3.1. Legacy Specifications and Schemes IPv6 SLAAC has traditionally employed schemes for generating Interface Identifiers (IIDs) that have negatively affected the security and privacy properties of IPv6 addresses. For example, IPv6 SLAAC originally generated stable addresses by embedding the underlying link-layer address in the IPv6 Interface Identifier (IID), thus negatively affecting the security and privacy properties of IPv6 addresses [RFC7721] [RFC7707]. Similarly, IPv6 temporary addresses [RFC4941] reused the same randomized IID for multiple auto- configuration prefixes [RFC4941], thus allowing for network activity correlation across different addresses of the same host. These schemes have become formally superseded by other schemes, such as [RFC7217] and [I-D.ietf-6man-rfc4941bis], that mitigate the issues present in the legacy schemes. Therefore, does not discuss any implications arising from legacy IID generation algorithms. NOTE: The security and privacy implications of such schemes are discussed in [RFC7721], [RFC7707], and [RFC7217]. Gont & Gont Expires June 14, 2021 [Page 4] Internet-Draft IPv6 Addressing Considerations December 2020 3.2. Unique Local IPv6 Unicast Addresses (ULAs) Unique Local IPv6 Unicast Addresses (ULAs) are considered to have global scope, but non-global reachability. However, the only reasons for which these addresses are considered to have "global scope" are: o given two different networks that employ ULAs, it's unlikely that they will employ the same ULA prefix o the ULA address block formally belongs to the Global Unicast Address (GUA) address block The ULA prefixes of two different networks that e.g. need to be merged will be (statistically) different *if* sites generate their ULA prefixes following the recommendations in [RFC4193] -- i.e., randomize the ULA prefix. However, this is not enforceable, and there exists anecdotal evidence that some sites employ non-randomized ULA prefixes, possibly in the hope of employing prefixes that are easier to express via the IPv6 address notation (e.g. fd00::/48). The ULA address block has been carved out of the GUA address block, without updating the IPv6 Addressing Architecture ([RFC4291]) to define the ULA address block as a different address type (e.g. "IPv6 private address space"). However, [RFC4193] notes that ULAs are not expected to be globally-routable, and the ULA prefix is commonly included in "bogon filters" typically enforced by network operators and administrators, thus limiting the reachability of these addresses. Therefore, ULAs are not globally meaningful and thus, for most (if not all) practical purposes, ULAs can be considered to have non- global scope. For this reason, ULAs are treated as non-global scope addresses, even when from a specifications point of view they have global scope. 4. IPv6 Address Properties There are, at least, four properties that can be associated with every IPv6 address: o Scope o Reachability o Stability o Provider Dependency Gont & Gont Expires June 14, 2021 [Page 5] Internet-Draft IPv6 Addressing Considerations December 2020 The address scope essentially represents the area of the network where an address can be expected to uniquely identify a system or set of systems, or conceptually, the area of the network where an given address is meaningful. For example, link-local addresses are only meaningful within a given network link, and are expected to be unique only within such network link. Address reachability represents the area of the network, where an address can be expected to be used for receiving and transmitting packets. Besides the semantics of specific address types, reachability can be affected by network devices: for example, Customer Edge Routers (CE Routers) that enforce a filtering policy of "only allowing outgoing communications" can render otherwise globally reachable addresses as "unreachable from the public Internet, unless communication is initiated from the customer's network". The stability of an address is associated with the invariance of an address over time. For example, a manually-configured address will typically remain stable while the node remains attached to the same subnet, while a temporary address will, by definition, change over time. While address stability does depend on the inherent properties of a given address (e.g. stable vs. temporary), it also depends on other factors, such as provider dependency: if a network employs a prefix that is assigned/leased by an upstream provider, then the overall stability of the addresses will also depend on the stability of the network prefix leased/assigned by the upstream. Provider-dependency is typically discussed in the context of Global Unicast Addresses, where the address space may be allocated by an Internet Service Provider (ISP) (and hence "provider aggregatable") or by a Regional Internet Registry (RIR) (and hence "provider independent"). However, this document considers "provider dependency" in a more general way: "provider aggregatable" address space is assigned or leased by the upstream (which may or may not be an ISP) from the provider's address space, and thus has a topological relationship with the upstream's address space, whereas "provider independent" address space is "owned" by the network in question and does not necessarily have a topological relationship with the upstream. 4.1. Address Scope Considerations The IPv6 address scope [RFC4007] has a direct implication on address reachability: the address scope essentially limits reachability. For example, addresses that have a non-global scope are not, in principle, globally reachable. NOTE: Gont & Gont Expires June 14, 2021 [Page 6] Internet-Draft IPv6 Addressing Considerations December 2020 This assumption becomes invalid if technologies such as Network Prefix Translation (NPT) [RFC6296] are employed, though. However, strictly speaking, in these scenarios the non-global addresses are still not globally reachable, but rather the middle-box acts as an interface to the "external realm" via globally-reachable addresses (i.e., the middle-box has an interface within the scope of the non-global addresses, and globally-reachables address that are used to communicate with the "external realm"). The IPv6 address scope can, in some scenarios, limit the attack exposure of a node as a result of the implicit isolation provided by a non-global address scopes. For example, a node that only employs link-local addresses will, in principle, only be exposed to attacks from other nodes on the same local link. The potential protection provided by a non-global-scope addresses should not be regarded as a complete security strategy, but rather as a form of "prophylactic" security (see [I-D.gont-opsawg-firewalls-analysis]). We note that non-global scope addresses are normally only of use for limited number of applications/protocols that operate on a limited scope (e.g., mDNS), or deployments where the intended participants have been deployed in a limited area of the network topology (e.g., OpenSSH client and server attached to the same link, both employing link-local addresses). The address scope can at times be somewhat related with the provider dependency property. For example, link-local addresses are, by definition, provider independent. In the same light, a ULA prefix generated by a local router will be, by definition, provider independent. However, a router might also be leased an ULA sub- prefix from its upstream, in which case this prefix would be "provider dependent". 4.2. Provider Dependency Provider-dependency is typically discussed in the context of Global Unicast Addresses, where the address space may be allocated by an Internet Service Provider (ISP) (and hence "provider agregatable") or by a Regional Internet Registry (RIR) (and hence "provider independent"). However, this document considers "provider dependency" in a more general way: "provider agregatable" address space is assigned or leased by the upstream (which may or may not be an ISP) from the provider's address space, and thus has a topological relationship with the upstream's address space, whereas "provider independent" address space is "owned" by the network in question and Gont & Gont Expires June 14, 2021 [Page 7] Internet-Draft IPv6 Addressing Considerations December 2020 does not necessarily have a topological relationship with the upstream. An implicit consequence of PA address space is that its use is tied to the specific provider/upstream that has assigned/leased the address space. This means that multi-homing (employing the address space with multiple providers/upstreams) is not possible, and that a renumbering event at the upstream could lead to a renumbering event of the local network. As a result, provider-dependency can affect address stability, with PI address space generally having better stability properties. For example, a home network could internally employ both ULAs and GUAs, where a ULA prefix is locally generated by the Customer Edge Router (CE Router), and global prefix is leased by the ISP via DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415]. If for some reason there was an outage involving the connection with the upstream ISP, the prefix lease time would eventually expire, and therefore addresses configured for such prefix would need to be invalidated. Similarly, if upon prefix lease expiration the ISP were to lease a new IPv6 prefix rather than renew the previously employed prefix, the network would need to be renumbered. On the other hand, ULA prefixes locally generated and advertised by the CE Router will not require renewal from the ISP, since they are locally generated by the CE Router. NOTE: As noted above, while strictly speaking ULAs belong to the global unicast address space, they can be considered non-global addresses for all practical purposes. Similarly, an organizational network that employs PI address space obtained from a RIR would be able to keep the same address space, even if the upstream network is renumbered. 4.3. Address Reachability Address reachability represents the area of the network (and the associated conditions), where an address can be expected to be used for receiving and transmitting packets. As noted in Section 4.1, the address scope has a direct implication on address reachability, since address reachability is limited to a subset of the address scope. For example, only global-scope addresses can be globally reachable. However, besides the reachability semantics of each address type, network filtering policies may also affect address reachability. For example, there is widespread deployment of Customer Edge Routers that implement a (stateful) filtering policy of "only allowing outgoing communications" -- mimicking the filtering policy enforced (as a Gont & Gont Expires June 14, 2021 [Page 8] Internet-Draft IPv6 Addressing Considerations December 2020 side-effect) by IPv4 NATs. In such scenarios, even otherwise globally-reachable addresses become unreachable, unless: o communication is initiated from the internal network, or, o the CE Router is manually configured override the default filtering policy, or, o a technology to dynamically override the filtering policy (such as UPnP [UPnP] or PCP [RFC6887]) is employed. Address reachability is what ultimately determines the application architecture that may be employed by an IPv6 node. NOTE: Ironically, an IPv6-only host (with global-scope addresses) attached to a home network where the CE Router "only allows outgoing communications" and does not implement a protocol such as UPnP [UPnP] or PCP [RFC6887], will normally have a harder time using peer-to-peer (P2P) applications than an IPv4-only host (with a private address) attached to a home network where the CE Router employs NAT but implements a protocol such as UPnP or PCP. Address reachability has a direct impact on security, since the ability to attack a system normally relies on the ability of the attacker to reach the system in the first place. Firewalls [I-D.gont-opsawg-firewalls-analysis] are, indeed, devices that are specifically devoted to administer address reachability. 4.4. Address Stability Considerations The stability of an address has two associated security/privacy implications: o Ability of an attacker to correlate network activity o Exposure to attack For obvious reasons, an address that is employed for multiple communication instances allows the aforementioned network activities to be correlated. The longer an address is employed (i.e., the more stable it is), the longer such correlation will be possible. In the worst-case scenario, a stable address that is employed for multiple communication instances over time will allow all such activities to be correlated. On the other hand, if a host were to generate (and eventually "throw away") one new address for each communication instance (e.g., TCP connection), network activity correlation would be mitigated. Gont & Gont Expires June 14, 2021 [Page 9] Internet-Draft IPv6 Addressing Considerations December 2020 NOTE: The security and privacy implications of predictable addresses are discussed in [RFC7721] and [RFC7707]. Typically, when it comes to attack exposure, the longer an address is employed the longer an attacker is exposed to attacks. While such exposure is traditionally associated with the stability of the address, the usage type of the address may also have an impact on attack exposure (see Section 5.2). A popular approach to mitigate network activity correlation is the use of "temporary addresses" [RFC4941]. Temporary addresses are typically auto-configured and employed along with stable addresses, with the temporary addresses employed for outgoing communications, and the stable addresses employed for incoming communications. NOTE: Ongoing work [I-D.ietf-6man-rfc4941bis] aims at updating [RFC4941] such that temporary addresses can be employed without the need to configure stable addresses. We note that the extent to which temporary addresses provide improved mitigation of network activity correlation and/or reduced attack exposure may be questionable and/or limited in some scenarios. For example, a temporary address that is reachable for, say, a few hours has a questionable "reduced exposure" (particularly when automated attack tools do not typically require such a long period of time to complete their task). Similarly, if network activity can be correlated for the life of such address (e.g., on the order of several hours), such period of time might be long enough for the attacker to correlate all the network activity he is meaning to correlate. However, they do introduce a limit to the attack window, and the amount of time during which address-based network activity correlation can be performed. In order to better mitigate network activity correlation and/or possibly reduce host exposure, an implementation might want to either reduce the preferred lifetime of a temporary address, or even better, generate one new temporary address for each new transport protocol instance. However, the associated lifetime/stability of an address may have a negative impact on the network (please see Section 6.3. Additionally, enforcing a maximum lifetime on IPv6 addresses may cause long-lived TCP connections to fail. For example, an address becoming "Invalid" (after transitioning through the "Preferred" and "Deprecated" states) would cause the TCP connections employing them to break, which would in turn cause e.g. long-lived SSH sessions to break/fail. Gont & Gont Expires June 14, 2021 [Page 10] Internet-Draft IPv6 Addressing Considerations December 2020 In some scenarios, attack exposure may be mitigated by limiting the usage of temporary addresses to outgoing connections, and prevent such addresses from being used for incoming connections (please see Section 5.2). 5. IPv6 Address Usage 5.1. Default Address Selection Applications use system API's to select the IPv6 addresses that will be used for incoming and outgoing connections. These choices have consequences in terms of privacy, security, stability and performance. Default Address Selection for IPv6 is specified in [RFC6724]. The selection starts with a set of potential destination addresses, such as returned by getaddrinfo(), and the set of potential source addresses currently configured for the selected interfaces. For each potential destination address, the algorithm will select the source address that provides the best route to the destination, while choosing the appropriate scope and preferring temporary addresses. The algorithm will then select the destination address, while giving a preference to reachable addresses with the smallest scope. The selection may be affected by system settings. We note that [RFC6724] only applies for outgoing connections, such as those made by clients trying to use services offered by other hosts. We note that [RFC6724] selects IPv6 addresses from all the currently available addresses on the host, and there is currently no way for an application to indicate expected or desirable properties for the IPv6 source addresses employed for such outgoing communications. For example, a privacy-sensitive application might want that each outgoing communication instance employs a new, single-use IPv6 address, or to employ a new reusable address that is not employed or reusable by any other application on the host. Reuse of an IPv6 address by an application would allow the correlation of all network activities corresponding to such application as being performed by the same host, while reuse of an IPv6 address by multiple different applications would allow the correlation of all such network activities as being performed by the host with such IPv6 address. When devices provide a service, the common pattern is to just wait for connections over all addresses configured on the device. For example, applications using the BSD Sockets API will commonly bind() the listening socket to the undefined address. This long-established behavior is appropriate for devices providing public services, but can have unexpected results for devices providing semi-private Gont & Gont Expires June 14, 2021 [Page 11] Internet-Draft IPv6 Addressing Considerations December 2020 services, such as various forms of peer-to-peer or local-only applications. This behavior leads to three problems: device tracking, discussed in Section 6.1.2; unexpected address discovery, discussed in Section 6.1.3; and availability outside the expected scope, discussed in Section 6.1.4. These problems are caused in part by the limitations of available address selection API, discussed in Section 7.1. 5.2. Usage Type Considerations IPv6 hosts can both stable [RFC8064] and/or temporary [RFC4941] addresses, in which case stable addresses are typically employed for incoming (server-like) communications, while temporary addresses are employed for outgoing (client-like) communications. That is, the stability properties of an address have an implicitly associated usage type. A node that employs one of its addresses to communicate with an external server (i.e., to perform an "outgoing connection") will expose that address to the other communicating system. For example, once the external server receives an incoming connection, the corresponding server might launch an attack against the aforementioned address. A real-world instance of this type of scenario has been documented in [Hein]. However, we note that employing an IPv6 address for outgoing communications need not increase the exposure of local services to other parties. For example, nodes could employ temporary addresses only for outgoing communications, and disallow their use for incoming communications. Thus, external nodes that learn about a client's addresses could not really leverage such addresses for actively contacting clients. Section 5 discusses current IPv6 address usage, along with possible improvements. 5.3. Current Alternatives for IPv6 Address Usage 5.3.1. Incoming communications There are a number of ways in which a system or network may affect which addresses (and how) may be employed for different services and cases. Namely, o TCP/IP stack address filtering Gont & Gont Expires June 14, 2021 [Page 12] Internet-Draft IPv6 Addressing Considerations December 2020 o Application-based address filtering o Firewall-based address filtering Clearly, the most elegant approach for address selection would be for applications to be able to specify the properties of the addresses they are willing to employ by means of an API, such the TCP/IP stack itself could "filter" which addresses are allowed for the given service/application. For example, an application could specify the stability and scope properties of the addresses on which incoming communications should be accepted, such that the application can be relieved from dealing with low-level networking details, portability is improved, and duplicate code in applications is avoided. However, constraints in the current APIs (see Section 7.1) limit the ability of application programmers for leveraging this technique. Alternatively, services could be bound to specific (explicit) addresses, rather than to all locally-configured addresses. However, there are a number of short-comings associated with this approach. Firstly, an application would need to be able to learn all of its addresses and associated properties, something that tends to be non- trivial and non-portable, and that also makes applications protocol- dependent, unnecessarily. Secondly, the BSD Sockets API does not allow a socket to be bound to a subset of the node's addresses. That is, sockets can be bound to a single address or to all available addresses (wildcard), but not to a subset of all the configured addresses. Another possible approach would be for applications to e.g. bind services to all available addresses, and perform the associated selection/filtering at the application level. While possible, this would have a number of drawbacks. Firstly, it would require applications to deal with low-level networking details, lead to duplicated code in all applications, and also negatively affect portability. Secondly, performing address/selection filtering at the application level may not mitigate some possible attacks. For example, port scanning will still be possible, since the aforementioned filtering would only be performed once e.g. UDP packets are received or TCP connections are established. A client could simply run a host-based firewall that only allows incoming connections on the stable addresses. This would be clearly more of an operational approach for achieving the desired functionality, and would require good firewall/host integration (e.g., the firewall should be able to tell stable vs. temporary addresses), would require the client to run additional firewall software for this specific purpose, etc. In other scenarios, a network-based firewall could be configured to allow outgoing communications from all internal addresses, but only allow incoming Gont & Gont Expires June 14, 2021 [Page 13] Internet-Draft IPv6 Addressing Considerations December 2020 communications to stable addresses (i.e., allow such addresses either manually, or via a helper protocol such as [UPnP] or PCP [RFC6887]). For obvious reasons, this is generally only applicable to networks where incoming communications are allowed to a limited number of hosts/servers. 5.3.2. Outgoing communications An application might be able to obtain the list of currently- configured addresses, and subsequently select an address with desired properties, and explicitly "bind" the address to the socket, to override the default source address selection. However, this approach is problematic for a number of reasons. Firstly, there is no portable way of obtaining the list of currently- configured addresses on the local node, and even less to check for address properties such "valid lifetime". Secondly, as discussed in Section 5.3.1, it would require application programmers to understand all the subtleties associated with IPv6 addressing, and would also lead to duplicate code on all applications. Finally, applications would be limited to use already-configured addresses and unable to trigger the generation of new addresses where desirable (e.g. the generation of a new single-use address for this application instance or communication instance). 6. Current Issues 6.1. Sub-optimal IPv6 Address Usage 6.1.1. Correlation of Network Activity As discussed in [RFC7721], a node that reuses an IPv6 address for multiple communication instances will enable the correlation of such network activities. This could be the case when the same IPv6 address is employed by several instances of the same application (e.g., a browser in "privacy" mode and a browser in "normal" mode), or when the same IPv6 address is employed by two different applications on the same node (e.g., a browser in "privacy" mode, and an email client). Particularly for privacy-sensitive applications, an application or system might want to limit the usage of a given IPv6 address to a single communication instance, a single application, a single user on the system, etc. However, given current APIs, this is practically impossible. Gont & Gont Expires June 14, 2021 [Page 14] Internet-Draft IPv6 Addressing Considerations December 2020 6.1.2. Passive Host Tracking The stable addresses recommended in [RFC8064] use stable IIDs defined in [RFC7217]. One key part of that algorithm is that if a device connects to a given network at different times, it will always configure the same IPv6 addresses on that network. If the device hosts a service ready to accept connections on that stable address, adversaries can test the presence of the device on the network by attempting connections to that stable address. Stable addresses used by listening services will thus enable testing whether a specific device is returning to a particular network, which in a number of cases might be considered a privacy issue. 6.1.3. Unintended Service Disclosure Systems like DNS-Based Service Discovery [RFC6763] allow clients to discover services within a limited scope, that can be defined by a domain name. These services are not advertised outside of that scope, and thus do not expect to be discovered by random parties on the Internet. However, such services may be easily discoverable if they listen for connections to IPv6 addresses that a client process also uses as source address when connecting to remote servers. NOTE: An example of such service disclosure is described in [Hein]. A network manager observed scanning traffic directed at the temporary addresses of local devices. The analysis in [Hein] shows that the scanners learned the addresses by observing the device contact an NTP service ([RFC5905]). The remote scanning was possible because the local services were accepting connections on all configured addresses, including temporary addresses. It is obvious from this example that local services are disclosed because they are bond to the same IPv6 addresses that are also used by clients for outgoing communications with remote systems. But the overlap between "client" and "server" addresses is only one part of the problem. Suppose that a device hosts both a video game and a home automation application. The video game users will be able to discover the IPv6 address of the game server. If the home automation server listens to the same IPv6 addresses, it is now exposed to connection attempts by all these users. That, too, increases the exposure of the home automation server. We note that a host or network that wants to limit access to local services should filter incoming connection attempts by affecting address reachability (see Section 4.3) via firewalls [I-D.gont-opsawg-firewalls-analysis] and/or the use of IPv6 addresses of appropriate scope (see Section 4.1). However, it is also prudent Gont & Gont Expires June 14, 2021 [Page 15] Internet-Draft IPv6 Addressing Considerations December 2020 to avoid unintended service disclosure by suboptimal reuse of IPv6 addresses, as discussed in this section. 6.1.4. Availability Outside the Expected Scope The IPv6 addressing architecture [RFC4291] defines multiple address scopes, with devices often configured with globally reachable unicast addresses, link local addresses, and Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Availability outside the expected scope happens when a service is expected to be available only in some local scope, but inadvertently becomes available from outside of that scope. That could happen, for example, if a service is meant to be available only on a given link, but becomes reachable through ULA or through globally reachable addresses, or if a service is meant to be available only inside some organization's perimeter and becomes reachable through globally reachable addresses. This will commonly happen if a service intended for some local scope is programmed to bind() to the "unspecified" addresses, which in practice means every address configured for the device (please see Section 7.1). 6.2. Sub-optimal Address Configuration 6.2.1. Number of Addresses Two mechanisms exist for automatic network configuration: SLAAC and DHCPv6. DHCPv6 centralizes network configuration and address assignment, and may thus prevent hosts from leveraging the increased flexibility and availability of IPv6 addresses. On the other hand, SLAAC may also result in network configuration anarchy, where hosts may e.g. configure and use addresses in a way that may render the network virtually unusable (please see Section 6.3.1). Most of the challenges associated with the use of multiple addresses can be addressed by allocating one /64 per host via mechanisms such as DHCPv6-PD. However, support for such mechanisms in host implementations and e.g. the LAN-side of CE Routers is not widespread, and thus is currently unfeasible. On the other hand, SLAAC lacks the means for the network to convey information about e.g., the number of addresses per host the network is able or willing to support. NOTE: Use of a /64 prefix per host could render techniques such as temporary addresses [RFC4941] ineffective, since hosts would become identified by corresponding /64 prefix. Gont & Gont Expires June 14, 2021 [Page 16] Internet-Draft IPv6 Addressing Considerations December 2020 6.2.2. SLAAC/DHCPv6 Interaction Many CE Routers offer address configuration via both SLAAC and DHCPv6, by including Prefix Information Options (PIOs) in Router Advertisement messages, and also setting the "M" such messages. This has a number of implications: o The outcome of the configuration process is non-deterministic, difficulting network troubleshooting (see [I-D.ietf-v6ops-dhcpv6-slaac-problem]). o Nodes end up configuring more addresses than needed (or even used), normally configuring multiple stable addresses for each autoconfiguration prefix, with at least one address for each configuration mechanism (SLAAC and DHCPv6). o A host can end up employing stable and predictable addresses resulting configured via DHCPv6, even when effort has been made to mitigate security and privacy issues associated with IPv6 addresses for the SLAAC-configured addresses (i.e., [RFC7217] and [RFC4941]). 6.3. Operation of Multi-Prefix/Multi-Address/Multi-Router Networks 6.3.1. Implications of Addresses Network deployments are currently recommended to provide multiple IPv6 addresses to general-purpose hosts [RFC7934]. However, in some scenarios, use of a large number of IPv6 addresses may have negative implications on network devices that need to maintain entries for each IPv6 address in network data structures (e.g., [RFC7039]). Additionally, concurrent active use of multiple IPv6 addresses will normally increase neighbour discovery traffic if Neighbour Caches in network devices are not large enough to store all addresses on the link. This can impact performance and energy efficiency on networks on which multicast is expensive (e.g. [I-D.ietf-mboned-ieee802-mcast-problems]). Finally, network devices may interpret the use of a number of addresses above a certain threshold as a security event, and block the offending device from using the network. 6.3.2. Legitimate Network Activity Correlation The desires of protecting individual privacy versus the desire to effectively maintain and debug a network can conflict with each other. For example, having clients use addresses that change over time will make it more difficult to track down and isolate operational problems. For example, when looking at packet traces, it Gont & Gont Expires June 14, 2021 [Page 17] Internet-Draft IPv6 Addressing Considerations December 2020 could become more difficult to determine whether one is seeing behavior caused by a single errant machine, or by a number of them. 6.3.3. Routing in Multi-Prefix/Multi-Router Networks If the network is provided with multiple upstreams via different routers, each of the upstream will provide its PA address space (see Section 4.2) and local hosts will typically configure addresses for each of such prefixes. In this scenarios, packets sourced from a given prefix should only employ the local router that announced that prefix, since otherwise the packets might be dropped as a result of ingress/egress filtering [RFC2827]. Unfortunately, the traditional Neighbor Discovery [RFC4861] can advertise routes only with a per- destination granularity, irrespective of the source address/prefix. [RFC8028] finally addressed the most important challenges associated with these scenarios. However, [RFC8028] is not widely implemented. As a result, operating a multi-prefix/multi-router IPv6 network represents a major challenge -- if at all possible. 6.3.4. Renumbering The challenges posed by network renumbering have been known for a very long time [RFC5887], with renumbering being analyzed with the assumption that the network topology remains stable and the network is renumbered. However, in scenarios where a host is moved to a different network without the host detecting the network disattach/re-attach event, or where the network a host attaches to is moved to a different point of the network topology, the aforementioned host will also perceive a renumbering event. In an era in which moving virtual machines, containers, and networks around a network topology is commonplace, and where mobile systems changing network connectivity to and from e.g. WiFi and 4G is also commonplace, renumbering events are anything but rare. One of the challenges represented by network renumbering is how hosts can infer that an existing network prefix and associated address(es) have become stale and should be removed and replaced by new prefixes and addresses. In scenarios where the network topology does not change and the network is renumbered, network elements may be aware about the renumbering event and signal this condition to attached systems (i.e., signal that existing network configuration information should be removed and replaced). However, in scenarios where it is the host, virtual machine or container (or the network they are attached to) that move around the network topology, the network will not be able to signal the "renumbering event", and the renumbered Gont & Gont Expires June 14, 2021 [Page 18] Internet-Draft IPv6 Addressing Considerations December 2020 host, virtual machine, or container might or might not be able to detect the event (e.g., via link-down/link-up events). Unfortunately, both SLAAC and DHCPv6 assume network configuration information to be somewhat stable. SLAAC has traditionally employed long lifetimes for network configuration information, meaning that stale information could be employed for an unacceptably long period of time. DCHPv6 has traditionally suffered from the same problem but, in addition, there is no widespread support for RECONFIGURE messages, so even if the network were in a position to signal a renumbering event, in practice hosts would normally have to rely on expiration of lease times for stale information to be cleared up. Some of these problems have been discussed in detail in [I-D.ietf-v6ops-slaac-renum], and there is ongoing work [I-D.ietf-6man-slaac-renum] [I-D.ietf-v6ops-cpe-slaac-renum] to mitigate their effects. 7. Current Gaps that Prevent Leveraging IPv6 Addressing 7.1. Better Address Selection APIs Application developers using the BSD Sockets API can "bind()" a listening socket to a specific address, and ensure that the application is only reachable through that address. In theory, careful selection of the binding address could mitigate the problems described in Section 6.1. Binding services to temporary addresses could mitigate the ability of an attacker from testing for the presence of the node in the network. Binding different services to different addresses could mitigate unexpected discovery. Binding services to non-global addresses (e.g. link-local addresses or ULAs) could mitigate availability outside the expected scope. However, explicitly managing addresses adds significant complexity to the application development. It requires that application developers master addressing architecture subtleties, and implement logic that reacts adequately to connectivity events and address changes. Experience shows that application developers would probably prefer some much simpler solution. In addition, we note that many application developers use high level APIs that listen to TLS, HTTP, or some other application protocol. These high level APIs seldomly provide detailed access to specific IP addresses, and typically default to listening to all available addresses. A more advanced API could allow application programmers to select desired properties in an address (scope, stability, etc.), such that the best-suitable addresses are selected, while relieving the Gont & Gont Expires June 14, 2021 [Page 19] Internet-Draft IPv6 Addressing Considerations December 2020 application from low-level IPv6 addressing details. Such API could also trigger the generation of new IPv6 addresses if/when the specified properties required so. 7.2. Universal Support of Multi-prefix/Multi-router Networks To put it bluntly, multi-prefix/multi-router networks cannot possibly work properly without implementation of [RFC8028]. Unfortunately, [RFC8028] is not widely implemented. On the protocol standardization side, the IETF should consider elevating the requirement to support RFC8028 in the IPv6 Node Requirements RFC [RFC8504] from "SHOULD" to "MUST". 7.3. Profile-based IPv6 Address Configuration Most operating systems configure the same type of addresses regardless of the current "operating mode" or "profile" of the device (e.g., device connected to an enterprise network vs roaming across untrusted networks). For example, many operating systems configure both stable [RFC8064] and temporary [RFC4941] addresses for all network interfaces. However, this "one size fits all" approach tends to be sub-optimal or inappropriate for some scenarios. For example, enterprise networks typically prefer usage of only stable addresses, thus meaning that a network administrator needs to find the means for disabling the generation of temporary addresses on all those systems that would otherwise generate them. On the other hand, some mobile devices normally configure both stable and temporary addresses, even when their usage type (client-like operation) would allow for the more privacy-sensible option of configuring only temporary addresses. The lack of better-tuned address configuration policies has helped establish the "one size fits all" approach that, as noted, usually leads to suboptimal results. Advice in this area might help achieve more optional address configuration policies such that IPv6 addressing capabilities are fully leveraged. NOTE: One might envision a document that provides advice regarding the address generation for different typical scenarios (e.g., when to configure stable-only, temporary-only, or stable+temporary). In the most simple analysis, one might expect nodes in a typical enterprise network to employ only stable addresses. General- purpose nodes in a home or "trusted" network might want to employ both stable and temporary addresses. Finally, mobile nodes (e.g. when roaming across non-trusted networks) might want to employ only temporary addresses). Gont & Gont Expires June 14, 2021 [Page 20] Internet-Draft IPv6 Addressing Considerations December 2020 7.4. Protocol Improvements to Deal with Many Addresses Possible improvements to IPv6 SLAAC should be evaluated, including: o Enabling IPv6 routers to convey information about network constraints such as maximum number of addressees per node o Enabling hosts to register/de-register configured addresses, such that e.g. routers need not tie resources to addresses that are no longer used If a /64 prefix is to be assigned for each host in order to leverage IPv6 address availability while mitigating the possible effects on network elements of employing large numbers of addresses, widespread support for DHCPv6-PD (or some proposed alternative mechanism) should be considered. 7.5. Support for Firewall Traversal in CE Routers Customer Edge Routers that implement a default filtering policy of "only allowing outgoing communications" need to support helper protocols such as [UPnP] or PCP [RFC6887], so that applications can punch holes in the CE Router firewall for applications that need to receive incoming communications. Otherwise, P2P applications that currently work in IPv4 will not function properly in IPv6-only networks. Support for these protocols is particularly important for IPv6 deployments since, as hosts will normally employ "provider aggregatable" addresses (see Section 4.2), renumbering events will result in host address changes, and thus static firewall rules will become invalid/outdated. Additionally, use of temporary addresses [RFC4941] will also lead to changing IPv6 addresses, which will require that the associated firewall rules be updated. 7.6. Advice on IPv6 Address Usage An application programmer, left with the question of which are the most appropriate addresses for a given usage type and application, typically resorts to the Default IPv6 Address Selection for IPv6 (see Section 5.1) for outgoing communications, and to accepting incoming communications on all available addresses for incoming communications. As discussed throughout this document, this leads to sub-optimal results. Besides, all applications on a node share the same pool of configured addresses, and applications are also prevented from triggering the generation of new addresses (e.g. to be employed for a particular application or communication instance). Gont & Gont Expires June 14, 2021 [Page 21] Internet-Draft IPv6 Addressing Considerations December 2020 Guidance in this area is warranted such that applications and systems fully-leverage IPv6 addressing. NOTE: Such guidance would elaborate, among other things, on the usage of IPv6 addresses when offering network services and when performing client-like communications. For example, for incoming communications, hosts might want to employ only the smallest-scope applicable addresses (if available) and, if stable addresses are available, they might want to accept incoming connections only on such addresses (but *not* on temporary addresses). For client- like communications, hosts might prefer temporary addresses, unless the corresponding communication instances are expected to be long-lived (e.g., SSH sessions). 8. IANA Considerations There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC. 9. Security Considerations The security and privacy implications associated with the predictability and lifetime of IPv6 addresses has been analyzed in [RFC7217] [RFC7721], and [RFC7707]. This document complements and extends the aforementioned analysis by considering other IPv6 properties such as the address scope and address reachability, and the associated trade-offs. 10. Acknowledgements The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Fred Baker, Owen DeLong, Francis Dupont, Tatuya Jinmei, and Dave Thaler for providing valuable comments on earlier versions of this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Gont & Gont Expires June 14, 2021 [Page 22] Internet-Draft IPv6 Addressing Considerations December 2020 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . Gont & Gont Expires June 14, 2021 [Page 23] Internet-Draft IPv6 Addressing Considerations December 2020 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . 11.2. Informative References [Barnes2012] Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great Void Smarter scanning for IPv6", ISMA 2012 AIMS-4 - Workshop on Active Internet Measurements, February 2012, . Gont & Gont Expires June 14, 2021 [Page 24] Internet-Draft IPv6 Addressing Considerations December 2020 [Hein] Hein, B., "The Rising Sophistication of Network Scanning", January 2016, . [I-D.gont-opsawg-firewalls-analysis] Gont, F. and F. Baker, "On Firewalls in Network Security", draft-gont-opsawg-firewalls-analysis-02 (work in progress), February 2016. [I-D.ietf-6man-rfc4941bis] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", draft-ietf-6man-rfc4941bis-12 (work in progress), November 2020. [I-D.ietf-6man-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", draft-ietf-6man-slaac- renum-01 (work in progress), August 2020. [I-D.ietf-mboned-ieee802-mcast-problems] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", draft-ietf-mboned-ieee802-mcast-problems-12 (work in progress), October 2020. [I-D.ietf-v6ops-cpe-slaac-renum] Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving the Reaction of Customer Edge Routers to Renumbering Events", draft-ietf-v6ops-cpe-slaac-renum-05 (work in progress), September 2020. [I-D.ietf-v6ops-dhcpv6-slaac-problem] Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey, "DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-07 (work in progress), August 2016. [I-D.ietf-v6ops-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work in progress), November 2020. Gont & Gont Expires June 14, 2021 [Page 25] Internet-Draft IPv6 Addressing Considerations December 2020 [I-D.ietf-v6ops-ula-usage-considerations] Liu, B. and S. Jiang, "Considerations For Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- considerations-02 (work in progress), March 2017. [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May 2010, . [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, . [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, . [UPnP] UPnP, "UPnP Device Architecture 2.0", April 17, 2020, . Authors' Addresses Fernando Gont SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com Gont & Gont Expires June 14, 2021 [Page 26] Internet-Draft IPv6 Addressing Considerations December 2020 Guillermo Gont SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Email: ggont@si6networks.com URI: https://www.si6networks.com Gont & Gont Expires June 14, 2021 [Page 27]