Nuts and Bolts IPv6 on IPv4 Security Lead image: Lead Image © foottoo,
Lead Image © foottoo,

IPv6 security on IPv4-only networks

Slippery Floor

Even though corporations are looking to move to IPv6, in some situations networks still rely exclusively on IPv4. We discuss ways to minimize delays and unsatisfactory behavior in mixed IPv4/IPv6 IT environments. By Eric Amberg

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.

Even if IPv6 is not actively used, the system will often automatically configure native IPv6 addresses and tunnel addresses.
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:

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).

Router advertisements lead to the automatic creation of an IPv6 address; the nodes can then use this address to communicate with the Internet.
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.

Security for Native IPv6 Traffic

During the migration phase to IPv6, you need to control IPv6 traffic. The most effective protection against undesirable, native IPv6 traffic is provided by a multi-tiered approach:

Other protections relate to security devices such as VPN gateways or network IDs/network IPs (NIDS/NIPS). You will want to configure them for IPv6 awareness, too.

Undesirable Tunnel Traffic

In the scope of IPv6 migration, tunnel technologies provide an option for connecting IPv6 islands across an IPv4-only infrastructure. They provide transmission mechanisms that will be replaced at some time in the future by native IPv6 communication. The problem with some tunnel technologies is that they are automatically enabled in some circumstances: They specifically include:

What all of these tunnel technologies have in common is that IPv6 packets are encapsulated in IPv4 headers and then forwarded as IPv4 packets (Figure 3), making it very easy for undesirable traffic to pass through firewalls and other security systems that do not correctly validate the content of the IPv4 packets.

An IPv6 packet is encapsulated in IPv4 at a certain point and forwarded as an IPv4 packet.
Figure 3: An IPv6 packet is encapsulated in IPv4 at a certain point and forwarded as an IPv4 packet.

Some tunnel mechanisms, such as 6to4 and Teredo, use predefined prefixes, and the algorithm for generating the complete IPv6 tunnel address is designed so that globally unique addresses are created automatically. Therefore, the system that uses the tunnel addresses may be easily accessible from the outside.

Filtering Tunnel Traffic with the Protocol Field

You can quite easily check IPv6 in IPv4 tunneling mechanisms using your (IPv4) firewalls by investigating the Protocol field in the IPv4 header: It regularly has a value of 41 when transporting an IPv6 packet. If your firewall filters this type of packet, tunnel mechanisms are ruled out as an attack vector. You can use this approach to block the following internal mechanisms:

Filtering Tunnel Traffic with Other Mechanisms

Some tunnel variants cannot be identified by looking for Protocol 41 because they use UDP or TCP as their transport protocol and thus either have 17 (UDP) or 6 (TCP) in the Protocol field. One of these variants is Teredo.

This mechanism uses UDP port 3544 to establish the tunnel to the Teredo server. If this port is blocked, Teredo cannot establish the initial connection. Of course, you cannot rule out the possibility of attackers setting up their own Teredo server on the Internet that does not use the default port. For this reason, it can be useful to filter by other criteria.

If your packet filter is capable of inspection, you can filter for an incoming or outgoing IPv4/UDP packet transporting an IPv6 packet with a value of 16 the version field of the header and whose sender or receiver address uses the Teredo prefix 2001::/32. That said, RFC 7123 [7] points out that this approach can lead to false positives if the firewall does not implement these features correctly. In this case, an IPv4/UDP packet would still be blocked, even if it did not contain any Teredo traffic.

Another filtering option is to control DNS traffic. For example, Windows requests the IPv4 host entry (address record A) [8] This can be checked by your DNS server or filter device, as can the request issued by Windows systems that look for the name isatap.<localdomain>, to discover the ISATAP router.

Another approach for enabling IPv6 traffic through IPv4-only networks relies on tunnel brokers. Tunnel brokers are IPv6 gateways on the Internet that are addressed by a client installed on a dual-stack node. A tunnel is set up between the node and the gateway (server). The dual-stack node communicates using IPv6 through the tunnel with the IPv6 Internet. The decisive difference from other tunnel mechanisms is the explicit installation of an appropriate client.

IPv6 tunnel brokers are described in RFC 3053 [9] and often use the Tunnel Setup Protocol (TSP) defined in RFC 5572 [10]. TSP can use either TCP or UDP as its transport protocol. In both cases, TSP uses port number 3653 to communicate with the server; the port was reserved by the Internet Assigned Numbers Authority (IANA) for this purpose.

The Anything In Anything (AYIYA) tunnel technology has not yet been standardized as a RFC, although it is still fairly widespread because it is designed for communicating through NAPT devices, that is, NAT systems that perform Port Address Translation. For example, AYIYA, used by the well-known tunnel broker SixXS, can be blocked at the IPv4 gateway by filtering outgoing traffic on ports 5072/UDP or 5072/TCP.


Although filtering native IPv6 and tunnel traffic is not particularly difficult from a technical point of view, the first challenge is to identify the problem. With filters, the "as much as necessary and as little as possible" approach always applies. Problems filtering IPv6 traffic that result in failed connections and delays can be mitigated by returning a TCP-RST segment (with the reset flag set) to internal nodes.

Beyond explicit attack scenarios, such as hijacking an IPv6-capable router and manipulating IPv6-capable nodes that are only intended to communicate on IPv4, automatic tunneling mechanisms represent the greatest source of danger in terms of uncontrolled communication of systems with the Internet. Aggravating this situation is that IPv6 is preferred by the popular operating systems, and IPv6 communication is established, even if it is only possible by using a tunnel mechanism.

Another possibility, beyond disabling IPv6 functionality on the endpoints, is to configure the DNS server so that requests from the IPv4-only network for AAAA RR (IPv6 resource records) [11] are either ignored or get a DNS RCODE response of 0 (NOERROR) as per RFC 1035. This ensures that nodes from the IPv4-only network exclusively receive A records (i.e., IPv4 addresses) in the response from the DNS server.

In the long term, the solution is obviously widespread migration to native IPv6 connectivity. One hopes that the current upward trend in IPv6 will lead to IPv6 migration taking the highest priority in the enterprise and thus restricting these transition scenarios and the problems they can cause to the shortest possible period of time.