Slippery Floor

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:

• To begin, disable any IPv6 features you do not use; that is, either disable IPv6 completely or at least disable automatic configuration to ensure that the node does not create any IPv6 addresses and that it reliably ignores any router advertisements.
• Network-based protection should be implemented by configuring appropriate filter rules on the packet filters. Even if the enterprise already supports IPv6 communication in some parts of the infrastructure, the components that currently rely exclusively on IPv4 for communication can be blocked for IPv6 traffic with appropriately restrictive filter rules. Again, the typical approach for firewalls applies: as much as necessary, as little as possible. The decisive thing here is that you take a holistic approach to integrating IPv6 into your security planning.
• To provide protection against undesirable IPv6 routers and DHCPv6 servers, you can use features such as RA-Guard (RFC 6105) [3] and DHCPv6-Shield [4]. These functions are implemented on switches and referred to as First Hop Security. SEND (Secure Neighbor Discovery) [5] is an approach that relies on cryptographically generated addresses (CGAs) to provide protection against unauthorized routers and other systems. That said, SEND does require complex configuration on all communication partners and is thus not the approach of choice for protecting IPv4-only networks. However, if you do take the trouble of implementing SEND, you will probably already have enabled IPv6 communication up front.

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:

• 6to4: A tunnel technology designed for communication between IPv6 nodes across the IPv4 Internet.
• ISATAP: The Intra-Site Automatic Tunnel Addressing Protocol is used in particular by Microsoft; it is primarily designed for communication between IPv6 nodes using Intranet structures within an enterprise.
• Teredo: Named after a mollusk, Teredo's specialty is that it can communicate across NAT structures that cause difficulties for other tunnel technologies [6].

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.

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:

• 6in4 and 6over4: These mechanisms require manual tunnel configuration.
• 6rd: Based on 6to4, 6rd does not use a fixed prefix and can thus principally only be detected by packet filters via the Protocol field of the IPv4 header.
• 6to4: In addition to a value of 41 in the Protocol field, 6to4 uses a prefix of 2002::/16. This prefix can be filtered by appropriate IPv6 firewalls in the IPv6 infrastructure area. However, it often proves more effective to filter for 6to4 relays on the Internet that use the IPv4 Anycast address 192.88.99.1. On your IPv4 Internet gateways, you can thus filter for this target address outgoing, and for this sender address incoming.
• ISATAP: This mechanism does not use any well-known prefix and is actually designed for communication within an enterprise network (intranet). Nevertheless, filtering on Protocol 41 (IPv6 over IPv4) still provides effective protection.