IPv6 security on IPv4-only networks

Slippery Floor

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] teredo.ipv6.microsoft.com . 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.

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=