IPv6 Address Usage Recommendations

A typical IPv6 host may have multiple IPv6 addresses available, which may differ in multiple aspects, such as address scope and address persistence (e.g. stable addresses vs. temporary addresses). Given previous work in this area , we expect (and assume in the rest of this document) that implementations have replaced any schemes that produce predictable addresses with alternative schemes that avoid such patterns (e.g., RFC7217 in replacement of the traditional SLAAC addresses that embed link-layer addresses). There are three parameters that affect the security and privacy properties of an address: Scope Stability Usage type (client-like "outgoing connections" vs. server-like "incoming connections") , , and discuss the security and privacy implications (and associated tradeoffs) of the scope, stability and usage type properties of IPv6 addresses, respectively.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

The IPv6 address scope can, in some scenarios, limit the attack exposure of a node as a result of the implicit isolation that may be implied by a non-global address scope. For example, a node that only employs link-local addresses may, in principle, only be reached exposed to attack to other nodes in the local link. Hosts employing only Unique Local Addresses (ULAs) may be more isolated from attack than those employing Global Unicast Addresses (GUAs), assuming that proper packet filtering is enforced on the network edge. The potential protection provided by a non-global addresses should not be regarded as a complete security strategy, but rather as a form of "prophylactic" security (see ). We note that the use of non-global addresses is usually limited to a reduced type of applications/protocol that e.g. are only meant to operate on a reduced scope, and hence their applicability may be limited. A discussion of ULA usage considerations can be found in .

The stability of an address has two associated security/privacy implications: Ability of an attacker to correlate network activity 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), 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. Typically, when it comes to attack exposure, the longer an address is employed the longer an attacker is exposed to attacks (e.g. an attacker has more time to find the address in the first place ). While such exposure is traditionally associated with the stability of the address, the usage type of the address (see ) may also have an impact on attack exposure. A popular approach to mitigate network activity correlation is that known as "temporary addresses". Temporary addresses are typically configured and employed along with stable addresses, with the temporary addresses being employed for outgoing communications. We note that the extent to which temporary addresses provide improved mitigation of network activity correlation and/or reduced attack exposure may be questionable in a number of 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., in the order of several hours), there are scenarios in which such period of time would be long enough for an attacker to correlate all the network activity he is meaning to correlate. NOTE: Ongoing work aims at updating such that temporary addresses can be employed without the need to configure stable addresses. 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. The associated lifetime/stability of an address typically may have a negative impact on the network. For example, if a node were to employ "throw away" connections, or employ temporary addresses with a short preferred lifetime, and the node were to use lots of outgoing connections, nodes might need to maintain too many entries in their Neighbor Cache, and a number of devices (possibly enforcing security policies) might also need to keep such additional state. Enforcing a maximum lifetime on IPv6 addresses may cause long-lived TCP connections to fail. For example, an address becoming "Invalid" (after transiting through the "Preferred" and "Deprecated" status) would cause the TCP connections employing them to break. This, in turn, would cause e.g. long-lived SSH sessions to break/fail. In some scenarios, attack exposure may be reduced by limiting the usage of temporary addresses to outbound connections, and prevent such addresses from being used for inbound connections (please see ).

A node that employs one of its addresses to communicate with an external server (i.e., to perform an "outgoing connection") may cause such address to become exposed to attack. For example, once the external server receives an incoming connection, the corresponding server may scan the client's address for network services. A real-world instance of this attack scenario has been documented in . However, employing an IPv6 address for an outgoing session/connection need not increase the exposure of local services to the parties to which the client connects. For example, nodes could employ temporary addresses only for outgoing connections, but not for incoming connections. Thus, external nodes that learn about client's addresses could not really leverage such addresses for actively contacting the clients. There are multiple ways in which this could possibly be achieved, with different implications. Namely: Run a host-based firewall Bind services to specific (explicit) addresses Bind services only to stable addresses A client could simply run a host-based firewall that only allows incoming connections on the stable addresses. This is clearly more of an operational way of achieving the desired functionality, and may require good firewall/host integration (e.g., the firewall should be able to tell stable vs. temporary addresses), may require the client to run additional firewall software for this specific purpose, etc. Services could be bound to specific (explicit) 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 stability properties, something that tends to be non-trivial, non-portable, and that makes the application unnecessarily protocol-dependent. Secondly, the Sockets API does not really 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 available addresses. Binding services only to stable addresses provides a clean separation between addresses employed for client-like outgoing connections and server-like incoming connections. However, we currently lack an appropriate API for nodes to be able to specify that a socket should only be bound t stable addresses. This could be considered for future work.

[TBD]

There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC.

This document discusses address usage considerations, and also describes possible future standards-track work to allow for greater flexibility in IPv6 address usage.

[TBD]