Protocol Duties

In 1995, the Internet Engineering Task Force (IETF) chose IPv6 as the successor to IPv4. Initially, this was not an issue that raised much interest. But this changed when Microsoft added IPv6 support to its Windows Vista and Windows Server platforms in 2007. Linux in all its variants and Apple's Mac OS X followed suit; thus, the new protocol spread with each new installation. On all of these computers today, IPv6 is active by default, communicating in unsolicited dual-stack operations using IPv4 and IPv6. Moreover, Microsoft's operating systems introduced transition technologies, which use IPv4 as a link-layer protocol for IPv6 use. This happens autonomously and, in some cases, long before admins organize normal IPv6 operations – which is exactly where the latent threat lies.

Dual-Stack on the LAN

The most common operating systems on the LAN are Windows, Linux, and Mac OS X. They all run IPv6 in parallel with IPv4. IPv6 is enabled and active by default, and the systems on the network communicate via dual-stack operations (Figure 1). The overview in Table 1 shows the default settings for current operating system versions.

The iOS versions for iPhone and iPad also have the IPv6 protocol enabled as a factory default, and the same applies to smartphones and tablet PCs based on Android. In both worlds, no administrative interface is available to the user for modifying the IPv6 configuration.

Autoconfiguration

RFC 2462, "IPv6 Stateless Address Autoconfiguration" [1], describes Stateless Address Autoconfiguration (SLAAC) within the IPv6 standard. The implementation of SLAAC autoconfiguration technology is mandatory for any host on an IPv6 network. Other methods are optional and can configure the host interface with other IPv6 addresses (see the "Autoconfiguration Process" box).

The autoconfiguration process on the local network has several weaknesses, which, if not protected by security measures, can be exploited both unintentionally and maliciously. This puts the local network at risk long before regular IPv6 operations start.

The biggest risk is that of rogue routers. Rogue routers maliciously or accidentally manipulate the communications of the local link. By sending an initial router solicitation (Figure 2) to the link-local multicast address FF02::2, hosts try to obtain IPv6 prefixes that are valid throughout the enterprise or worldwide in the scope of SLAAC; the prefixes are then combined with the interface identifier to create a full 128-bit IPv6 address. This enables communication across subnet boundaries. In normal circumstances the regular IPv6 router responds to the request by sending a router advertisement (RA) to the link-local multicast address FF02::1 (all nodes; Figure 3). The payload of this message includes all valid IPv6 prefixes on the local subnet and other flags that allow a sophisticated configuration. The RA message is also repeated periodically.

Rogue Routers

If a rogue router is active and sends an RA to the multicast group FF02::1 (Figure 4), the network configuration of the hosts is manipulated; now, the IP addresses and routing tables do not match the administrative requirements. This scenario often occurs in real life because technologies like Windows Internet Connection Sharing (ICS), software routers in Linux derivatives (radvd), or various tools on the Internet from known tool collections distribute RAs to local communication partners without any substantial manual effort. If these activities are not monitored, the rogue router establishes itself as the IPv6 default gateway. Additionally, it can use certain flags in the RA to control the DNS configurations of the hosts.

DNS and LLMNR

Applications typically use an RFC 3484 – Default Address Selection for Internet Protocol version 6 (IPv6) – compliant [2] resolver library. Because IPv4 is used as a matter of course, whereas IPv6 is often used unintentionally, this causes interference with personal firewalls on the respective end nodes, as well as with network monitoring because these safeguards currently focus on IPv4.

Figure 5 shows Wireshark resolving the hostname ibm-R52 using the link-local multicast name resolution (LLMNR) protocol. If DNS resolution does not return an IP address, LLMNR is used by newer Microsoft operating systems as a supplement. Because the source and target addresses are part of the link-local scope (fe80::/10), the transport protocol is IPv6. Since IPv6 is enabled and LLMNR provides name resolution, the pending messages are now also transported via IPv6.

RFC 3484 requires the implementation of an administrative interface for controlling the preferred network protocol and the address selection on the respective host operating system. Microsoft administrators can change this policy with netsh commands. Linux admins edit the /etc/gai.conf file. Only Mac OS X fails to comply with the RFC.

The selection criteria are defined and shown line-by-line in Table 2. According to RFC 3484 an address is allocated in the selection process to the line with the best possible match (prefix).

The Precedence column assigns a value of 40 to an IPv6 global unicast address and a value of 50 to the IPv6 loopback address. The placeholder for possible IPv4 addresses is the ::ffff:0:0/96 entry with a precedence of 10. Because of the higher precedence, IPv6 is preferred. In this process, the source address and target address are selected so that the scope (global or link-local) matches. The Label column controls the assignment of a source address to a target address if multiple addresses are available for selection.

As mentioned previously, the flags set in the RA have a direct influence on the DNS configuration of the hosts. Figure 6 shows an RA, in which the "Other" flag stipulates that more configuration parameters need to be obtained using stateless DHCPv6. This means that the host DNS configuration can be managed or manipulated. Alternatively, RFC 5006 [3] offers a newer method, wherein the DNS server is announced in the RA (recursive DNS server option). However, a potential attacker can bypass the regular DNS infrastructure using the techniques described here. This applies to mapping the hostname to both IPv4 addresses and IPv6 addresses.

Because of dynamic DNS updates in Active Directory and the 6to4 tunnel presented below, communication can unintentionally be routed via IPv6 in the Microsoft world.

Transition Technologies

Latent risks are carried onto the communications networks by the tunneling technologies automatically enabled by Microsoft, such as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, and Teredo. Making IPv4 a link layer technology for IPv6, the tunnel technologies disclose the vast interactions between IPv6 and its predecessor because the new protocol is tunneled in IPv4. (Figure 7). Microsoft operating systems prefer ISATAP if no native IPv6 configuration is determined by the SLAAC process. The ISATAP router contacted on the IPv4 network plays an important role. The essential step is the resolution of the hostname isatap to a valid IPv4 router address. Then, router solicitation and RAs are used to perform the necessary IPv6 initialization steps. However, one important difference is that this IPv6 initialization is transmitted as an IPv4 unicast (IP protocol 41) on the network. When initialized, ISATAP hosts are adjacent to all native IPv6 networks.

If neither SLAAC nor ISATAP provide successful IPv6 connectivity, 6to4 is selected as the tunneling technology. Each host on an intranet with official IPv4 addresses (Class A/B/C) can generate a 6to4 address that consists of the prefix 2002::/16 and the official IPv4 address of the host. Thus, all hosts on an intranet are locally adjacent and also have access to the global IPv6 network via IPv4 protocol 41. Central security measures, such as firewalls that do not prevent transportation of the protocol, are thus also incapable of sufficiently ensuring the security of the network. The additional potential this mechanism possesses is revealed in the combination of ICS and 6to4: If a Windows user enables ICS, the system becomes a 6to4 host router and sends RAs on the local network, which makes this system an active IPv6 router on the local network that can set up a connection between the intranet and the Internet.

Teredo and Miredo

The transition technology of last resort, described in RFC 4380, is Teredo [4]. As an open source solution, Miredo is available. If an IPv6 target address is explicitly specified, bubble packets are exchanged with external servers, which in turn cause the necessary ports to be opened on the NAT devices. This means that all hosts can be reached as IPv6 systems, and NAT is no longer a barrier between the local network and the Internet. This is transmitted on the local IPv4 network as a UDP datagram on port 3544. The IPv4 information encoded in the client's IPv6 address (IPv4 address of the server/NAT-type/external IPv4 Port/external IPv4 address) supports a bi-directional traffic flow using IPv4 UDP from the client via a relay to the external IPv6 computer. Collaborative file-sharing protocols can use a Teredo-based transfer.

In addition to these mechanisms, tunnel brokers (e.g., SixXS, Hurricane Electric) provide further possibilities for IPv6 connections. Often the transmission variants are based on UDP or 6in4 accessing a relay hosted by the respective vendor. Within a corporate network, there is a risk that inexperienced users will set up connections between the local network and the global IPv6 Internet. The tunnel brokers usually assign a generous range of IPv6 prefixes to the customer after registration. They can, in turn, be distributed by a rogue router on the local network; with their valid global addresses, any host can then communicate globally on the IPv6 network.

The tunnel mechanisms clearly show that transmission in IPv4 makes communication relationships difficult to analyze. Point-to-point connections thus need to be re-evaluated in the firewall rules and regulations to avoid unintentionally created worldwide adjacencies undermining a well-established security policy. If various conditions, such as unmanaged name resolution, a misconfigured host, and Windows ICS collide with a firewall policy aligned to IPv4 only, the consequences can be serious. This culminates in a potential man-in-the-middle attack resulting from unintended or deliberate traffic diversion.

Solutions

The basic concepts of IPv6 lack security precautions, resulting in the risks described herein, which admins need to counteract by taking adequate measures. The RIPE 501 document [5] mandatorily calls for RA filter mechanisms on Layer 2 switches. Initial experience shows that even leading manufacturers are unfortunately only implementing this feature in the latest hardware and software. If Layer 2 devices can enable an access control list per port, this is an effective barrier against rogue routers and rogue DHCPv6 advertisements. The RFC 6104 "Rogue IPv6 RA Statement" [6] provides a comprehensive overview of the complex problem. Currently, manufacturers are working on solutions, under the First Hop Security umbrella, to Secure stateless address autoconfiguration. In the future, features such as IPv6 RA Guard, IPv6 ND Inspection, and Device Tracking will be essential.

Defense

The RAmond tool (University of Southampton) can generate RAs in response to rogue RAs and discard the configuration parameters from stateless address autoconfiguration (SLAAC). To do this, the router and the preferred lifetime in the RA must have a value of zero. Of course, all the addresses (Layer 2 and Layer 3) in this advertisement are spoofed. A host receiving such an RA discards the corresponding IPv6 addresses and routing entries. The Access Control Lists (ACLs) described in the previous section prevent malicious use of the tool.

Subnets that only have IPv4 functionality can install a Neighbor Discovery Protocol Monitor (NDPMon) server. This NDPMon maintains a history of RFC 3041 IPv6 address assignments and MAC addresses and can warn the admin about rogue RAs, among other things.

Personal firewalls should be configured in line with the recommendations of RFC 4890, "Recommendations for filtering ICMPv6 messages in Firewalls" [7]. On Microsoft operating systems, Microsoft's own firewall is recommended because it offers stateful inspection for IPv4 and IPv6 traffic and correctly handles transition technologies. One potential improvement would be a further development of existing network discovery to set up a persistent binding between the addresses (Layer 2 and Layer3) of a regular router and the Windows Firewall once-only per subnet. Linux administrators have also had a stateful inspection firewall since kernel 2.6 in the form of ip6tables.

IPv6 operations managed on this basis also provide the first solution against the presented transition technologies because these technologies only become active if there is no native IPv6 deployment. Otherwise, it is advisable to disable these technologies for Microsoft operating systems: Working as the system administrator, run

netsh interface ipv6 6to4
set state disabled undoonstop=disabled
netsh interface ipv6 isatap
set state disabled
netsh interface ipv6 set teredo
disable

and reboot. In an Active Directory (AD) environment, the settings can be managed centrally. In Computer Configuration | Policies | Administrative Templates | Network | IPv6 configuration, select the IPv6 settings shown in "IPv6 Settings in AD" box.

Additionally, the 6in4 protocol and Teredo communication should be blocked on firewalls and routers.

Conclusions

On the basis of experience from local corporate networks, IPv6 is initially no more than an additional burden for the network administrator. Additionally, the latent risk and de facto use of the protocol give rise to a need for administrator and user training. On top of this, a centrally coordinated introduction of the new protocol is of great importance for trouble-free operations. Because of the complexity, you should not underestimate the time factor: Start planning at an early stage. Simply ignoring IPv6 is just plain dangerous. For more information on living with IPv6, check out ADMIN magazine's IPv6 digital special [8].