Implications of IPv6 Addressing on Security Operations

The main driver for the adoption of the IPv6 protocol suite is its increased address space, which can provide a virtually unlimited number of public addresses for every device attached to the public Internet. 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). IPv6 hosts may configure and use multiple addresses with different combinations of the aforementioned properties, depending on the local host policy and the local network policy. For example, in network where SLAAC is employed for address configuration, host will typically configure one stable address and one (or more) temporary addresses per network interface, for each prefix advertised advertised for address configuration. On the other hand, for networks that employ stateful configuration, it is quite common for hosts to configure one address per network interface. discusses the semantics of IPv6 addresses in terms of the entity or entities the identify, according to the deployed Internet. discusses the usage of IPv6 addresses in security operations. discusses the implications of IPv6 addressing on security operations.

As noted in , IPv6 hosts typically configure multiple addresses with different properties. One of the most common deployment scenarios is that in which the subnet employs SLAAC for address configuration, and where hosts configure both stable and temporary addresses. From this perspective, it is clear that multiple addresses may correspond to the same IPv6 host. While rather uncommon for legitimate use cases, an IPv6 host may actually employ a larger address block. For example, it is common for ISPs to lease a /56 or /48 to each subscriber, and thus a skilled user could readily employ the leased prefix in a single or multiple IPv6 hosts (whether virtual or not). On the other hand, while one might assume an IPv6 address would correspond to at most one host (strictly speaking, to one network interface of a host), this is not necessarily the case in the deployed Internet since e.g. deployments that employ "Network Address Port Translation + Protocol Translation" (NAPT-PT) for IPv6 are not uncommon, whether along with technologies such as Kubernetes, or in IPv6-enabled VPNs. Thus, a single IPv6 address may actually correspond to or identify multiple IPv6 systems.

It is common for network deployments to implement any of these types of ACLs: Allow-lists Block-lists Allow-lists are typically employed as part of a defense-in-depth strategy, where access to specific resources is allowed only when requests originate from specific IP addresses or prefixes. For example, an organization may employ a Virtual Private Network (VPN), and require that certain resources be accessed via the VPN, by enforcing that requests originate from the IP address (or addresses) of the VPN concentrator. On the other hand, block-lists are typically implemented to mitigate threats. For example, a network firewall might be fed with an IP reputation block-list that is dynamically updated to reflect the IP address (or addresses) of known or suspected attackers. Both types of ACLs have a similar challenge in common: identifying the minimum set of addresses that should be employed in the ACLs definition such that the ACLs can successfully enforce the controls they are expected to enforce. For example, in the case of allow-lists, the corresponding ACLs should encompass possible legitimate changes in the set of "valid"/allowed addresses, thus avoiding false negatives (i.e., incorrectly preventing access to legitimate users). On the other hand, in the case of block-lists, the ACLs should encompass the attacker's ability to use different addresses (or vantage points), while minimizing false positives (i.e., incorrectly blocking legitimate users).

Another fundamental aspect of security operations is that of network activity correlation (at times with the goal of attribution). That is, an analyst may want or need to infer the relationship among different network activities, and possibly assess whether they can be attributed to the same entity or attacker. This may be necessary for security investigations, but also to e.g. subsequently mitigate a threat by enforcing ACLs that block the alleged attacker.

When implementing an allow-list, it may be necessary to specify it with a granularity of /64 -- that is, an entire /64 might need to be "allowed", since the target host(s) might employ multiple addresses from the same /64 over time (e.g., as a result of temporary addresses ). However, since sunch IPv6 prefix would be shared by other hosts in the same subnet, this would mean that the ACL would have coarse-granularity (i.e., all hosts (or none) would be part of the allow-list -- which is probably unacceptable in many cases. In some scenarios, a network administrator might be able to disable the use of temporary addresses via e.g. group policies , or request/enforce the use of DHCPv6 , thus having more control on the addresses employed by local hosts. In these specific cases, it might be possible to implement an allow-list for a host by specifying a single IPv6 address (i.e., a /128). On the other hand, implementing block-lists can be tricky. For example IP reputation lists (whether commercial or not) are commonly employed in the deployed Internet. However, these lists generally specify offending addresses as /128, as opposed to a network prefix. This means that an attacker could simply regularly change his/her IPv6 address, thus reducing the effectiveness of these lists. Additionally, a side effect of an attacker regularly changing his/her address is that the block-list might grow to such an extent that the list might have to be trimmed (as a result of implementation constraints), with the aforementioned transient addresses consuming available "slots" in the IP reputation block-list. Similarly, tools of the kind of are commonly employed by system administrators to mitigate e.g. brute-force authentication attacks by banning IP addresses after a certain number of failed authentication attempts. These tools might ban IPv6 addresses on a /128 granularity, thus meaning that an attacker could easily circumvent these controls by changing the attacking address every few attempts (e.g. before an address becomes blocked). Additionally, as with the IP reputation lists previously discussed, an attacker performing a brute force attack *and* regularly changing his/her address could make the block-list grow to an extent where it might negatively affect the system enforcing the block-list, or might cause other valid entries to be discarded in favor of the transient IPv6 addresses. One might envision that IPv6 reputation lists might aggregate a large number of offending IPv6 addresses into a prefix that encompasses them. However, this practice is really not widespread, and might also increase the number of false positives. Thus, it is possibly a topic for further research.

Performing IPv6 network activity correlation can be very tricky, since the semantics of an IPv6 address in terms of what it might correspond to (see ) can be complex. As discussed before, a single IPv6 address could correspond to either a single host, or multiple hosts behind an IPv6 NAPT-PT device -- in a way, this being similar to IPv4 scenarios. However, multiple IPv6 addresses might or might not represent multiple systems. In some cases, some heuristics might help infer whether a group of addresses belonging to a /64 correspond to the same node. However, as the addresses become more sparse (e.g., a user or attacker leverages a /48), this may be more challenging. And, while some heuristics could be employed to perform network activity correlation across multiple addresses, most tools commonly used in the deployed Internet do not implement this kind of features.

This entire document is about the implications of IPv6 addressing on Security Operations. It analyzes the impact of IPv6 addressing on a number of security operations areas, raising awareness about the associated challenges, and hopefully fostering developments in these areas.

The authors of this document would like to thank (in alphabetical order) [TBD] for providing valuable comments on earlier versions of this document. This document borrows some text and analysis from , authored by Fernando Gont and Guillermo Gont. Fernando would also like to Nelida Garcia and Jorge Oscar Gont for their love and support.