Even though IPv6 is not establishing itself as expected, it is still making progress. More and more systems on the Internet, as well as on enterprise networks, can communicate and are accessible via IPv6. Mechanisms such as auto-configuration and automatic tunneling mean that IPv6-capable nodes will attempt to establish connections using IPv6. Filtering of IPv6 traffic or the lack of end-to-end connectivity can cause the connection to fail. In this case, the node either cancels the communication action or it tries after failing – and typically after a timeout – to use IPv4 as a fallback mechanism to reach its target, resulting in pronounced delays and unsatisfactory behavior of the IT infrastructure.

Two IPv6 security experts, Fernando Gont (SI6 Networks) and Will Liu (Huawei Technologies), summarized important principles for securing IPv4-only networks in RFC 7123 (Security Implications of IPv6 on IPv4 Networks) [1]. This request for comment still has an "Informational" status, and is thus intended as a basis for discussion and as a guideline for practical applications. In contrast to standard-track RFCs, it is not mandatory.

IPv6 in IPv4-Only Networks

Ever since Windows Vista, IPv6 has been integrated into the Windows TCP/IP stack and enabled by default. To put this another way: Windows always runs in dual-stack mode first, with IPv4 and IPv6 running in parallel (Figure 1). The Linux kernel has supported IPv6 for many years, and nearly all distributors enable it by default. Because of various IPv6 features, such as automatic configuration, transition, and translation technologies (in particular, automatic tunneling), attackers can exploit IPv6 traffic on dual-stack nodes.

Figure 1: Even if IPv6 is not actively used, the system will often automatically configure native IPv6 addresses and tunnel addresses.

This particularly becomes a danger if an admin has no plans to receive IPv6 traffic at this point in time and, thus, has no IPv6-specific security measures in place. Even if the enterprise already has plans for migrating to IPv6, these may only be implemented step-by-step over the course of several years, depending on the size of the enterprise. During the migration phase, therefore, parts of the IT infrastructure still exist that exclusively use IPv4.

Attack Scenarios

RFC 7123 describes various scenarios and examples in which a lack of IPv6 awareness, missing configurations, or missing support for the appropriate IPv6 functions can lead to vulnerabilities. They include:

• Network-based intrusion detection systems (NIDS) that are incapable of detecting the same attack patterns in IPv6 that they would easily detect in IPv4. The danger in particular is known exploits that are simply not detected via IPv6. The same principle applies to intrusion prevention systems.
• Firewalls that have an IPv4 ruleset but do not apply the same rules for IPv6 traffic. The specific problem is detecting and blocking tunneled traffic.
• NIDS and firewalls that may be incapable, from a technological point of view, of implementing the same security policies in IPv6 that they implement for IPv4. Even though vendors often promise full IPv6 support, checking the details often reveals differences in the supported features – especially in the case of extended firewall functions.
• Migration technologies such as tunnels and NAT that make internal hosts that should only have restricted IPv4 connectivity globally accessible using IPv6. This scenario becomes particularly important in the case of technologies designed to work around NAT (e.g.,, the Teredo tunneling technology), which can lead to internal hosts being accessible from the Internet without any protection, simply by using IPv6.
• VPNs that can provide an IPv6-based attack vector in dual-stack scenarios if the VPN software does not support IPv6. Firewalls play a key role in managing these scenarios. Most attack vectors can be closed down by blocking undesirable native IPv6 traffic and tunnel traffic and by disabling IPv6 functionality on the IPv4-only nodes in question.

The Problem with Native IPv6 Support

Popular operating systems support IPv6 natively and enable it by default. Therefore, IPv6 is latently active on an IPv4 network. An IPv6 interface has at least one link-local address enabled. Even if this address is initially restricted to the local link (i.e., the local subnet), communication by this kind of host can be extended in specific situations.

If attackers manage to compromise the router, they can configure it for IPv6 and, say, enable router advertisements. If the attackers configure a prefix that is routed into the local site, the IPv4 nodes, in which dual-stack is enabled, create global unicast addresses, which can then be used to access the Internet (Figure 2).

Figure 2: Router advertisements lead to the automatic creation of an IPv6 address; the nodes can then use this address to communicate with the Internet.

The biggest problem here is stateless auto-configuration (SLAAC), which is enabled by default on popular operating systems. When an IPv6-enabled endpoint receives a router advertisement with a prefix option (containing a 64-bit IPv6 prefix), it uses this prefix to generate a complete IPv6 address based on specific rules; under some circumstances, this address can be globally unique. To do this, the endpoint uses either the extended EUI 64 format (which is based on the MAC address of the interface) to create the interface ID or the privacy extensions as per RFC 4941 [2].

Alternatively, Windows uses a one-off randomized identifier. In any of these cases, the address is unique, and if the router also has a connection to the enterprise's IPv6 infrastructure, or directly to the Internet, the dual-stack node, which you actually only want to communicate using IPv4, can go online with its IPv6 address.

Even if an IPv6-enabled node does not receive any router advertisements, most operating systems attempt to set up an IPv6 configuration on IPv6-capable interfaces using DHCPv6. If an attacker manages to set up a rogue DHCPv6 server, the nodes can use it to set up a full IPv6 address. The challenge for the attacker is that DHCPv6 currently has no option for setting the node's default gateway, so it either has to be configured via router advertisements or manually.