IPv6 security on IPv4-only networks

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

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • IPv6 tunnel technologies
    Now that IPv6 is the official Internet protocol, all that remains is the simple task of migrating all the machines on the Internet. Until that happens, tunnel technologies provide an interim solution.
  • Neglected IPv6 Features

    IPv6 is establishing itself in everyday IT life, and all modern operating systems from Windows, through Mac OS X, to Linux have it on board; but if you let IPv6 introduce itself into your environment, you could be in for some unpleasant surprises.

  • IPv6 Tables
    We design a basic set of ip6tables rules for an IPv6 firewall.
  • Successful protocol analysis in modern network structures
    Virtual networks and server structures require additional mechanisms to ensure visibility of data streams. We show how to monitor and analyze network functions, even when virtualization is involved.
  • Migrating your network to IPv6
    Abraham Lincoln once said, "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." The transition to IPv6 is a big step for many organizations. Careful planning and a systematic approach are critical to a successful migration.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=