IPv6 Adoption Risks and Pitfalls
By Karl A. Siil
Chief Architect, Lumeta Corporation

IPv6 is destined to become the dominant networking protocol, but this won't happen overnight. In fact, the early days of transition, i.e., now, will be fraught with peril. There will be those who leap into IPv6 with both feet, not taking the necessary precautions required with the enterprise-wide adoption of any new technology. There will be those who think they are only putting their toe in the water, only to find that they're up to their necks from a lack of planning and/or understanding the technology's capabilities. What follows is an examination of this author's lessons learned from both studying IPv6 and from running contained (or so he thought, in some cases) implementations of the protocol.

The phrase, "We're not running IPv6" will become the "The check is in the mail" of IP networking, for the next few years, at least. Enterprises that know they must adopt IPv6, e.g., the Federal government, have already completed or will soon complete their transition plans and start execution to meet their June 2008 mandates. What they won't realize is, no matter what dates are on those transition plans for IPv6 adoption, the transition is already well underway. IPv6, both in hardware and software, is already prevalent. To quote Jack Nicholson's Joker, when it comes to acquiring IPv6-capable equipment, organizations will find, "Well that's the gag, folks! Chances are you've bought 'em already!"

Most mainstream network and end devices already support IPv6. These include the routers manufactured by all the major players, along with all the mainstream operating systems. Windows, Linux, Solaris, and a plethora of others have had IPv6 capabilities for some time. Windows Vista, out now, prefers to network using IPv6 out of the box. If a Vista system can find a router with IPv6 interfaces, it will form a network. Vista will likely be a primary driver in making IPv6 a ubiquitous, if not the dominant, networking protocol.

The key reason that the IPv6 transition will occur much faster than anyone expects is the protocol's innate ability to auto-configure, whether it's "managed" or not. This presents enormous risks to the entire enterprise, both the nascent IPv6 network and the existing IPv4 network. And, if this comes as a surprise to anyone in computer networking, there are already attacks to exploit the flaws in IPv6, both in its native form and tunneled within IPv4.
IPv6 can stand up a network with no administrator participation. IPv6 devices seek out other IPv6 devices & routers. Scoped addresses ease sending to "all routers" in a network. Neighbor Discovery and Duplicate Address Detection look for other systems, the latter to assure a lack of collisions in the address space. Multicast Listener Discovery Version 2 (MLDv2) joins up groups with little or no outside help.

So, that's enough FUD. What are the real risks of unmanaged transition? Here's an example of a small network of fewer than 200 systems, with only three running IPv6 (or so we thought). In gathering data on Windows Vista's use of IPv6, we found three additional devices not in the sanctioned IPv6 network. All were FreeBSD boxes. One was in a development LAN, one was a QA box, and one was a customer training box. Each was running link-local addresses and searching for routers with which to pair up. From personal knowledge, I know this to be a well-managed network, and remember – it contained fewer than 200 machines. That doesn't bode well for the 200,000-system enterprise networks. Installing one IPv6 router for testing purposes (and thinking it was the only IPv6 device) would have instantly created a 5-address IPv6 network. Would the border router's ACLs have been close to correct? Fortunately for that network, the answer is "yes." That's because the network managers followed the guidelines outlined below.

So, what protections are necessary? First of all, if you're not officially running IPv6, make sure it's turned off. The template images, sometimes referred to as golden masters or ghost images, from which your systems are created, should all have their IPv6 components disabled. This includes turning off IP protocol #41, i.e., IPv6 over IPv4. What's the risk of protocol #41? Here's the scenario:

1. An external attacker targets your organization's registered IPv4 addresses.
2. A "benign" IPv4 packet passes your firewall headed for a legitimate target.
3. At the target, the IPv6 payload is extracted (if IPv6 is enabled).
4. The IPv6 packet is routed to the ultimate target(s), e.g., an easily-constructed EUI-64 address based on some popular MAC addresses.
5. Should any of these secondary targets have IPv6 enabled and also have whatever bug the attacker is seeking to exploit, e.g., buffer overflows, those targets now become an "owned system" and an attack launch point behind your perimeter!

The preceding addresses attacks launched from the outside. What about insider attacks? Depending on whom you believe, insiders constitute 75% to 95% of the threats to a network. The following is a real-world example of a group of employees, not happy with their company's IT policies, who hid within the enterprise network on a totally independent IPv6 infrastructure. This group of people found the network operations staff a bit too overzealous about controlling user activities, i.e., no more than a very-limited number of personal e-mails per day. Several users colluded to use IPv6 and stood up a covert network using link-local addresses. Nobody was monitoring IPv6 traffic, so these activities went on unnoticed.

The lesson learned above: monitor both IPv4 and IPv6 traffic. That's a tall order, considering the state of IPv6 IDS and IPS products. There is hardly anything out there, aside from home-grown solutions. The only thing that will drive companies to make those IPv6 products is user demand. So, network administrators, operators, security staff, CIOs – start demanding.

Recall I mentioned there is already an IPv6 Attack Toolkit. It's billed as the first comprehensive attack toolkit for IPv6. The toolkit comes with the following capabilities, to name a few:

• ICMP neighbor solicitation/advertisement spoofing
• Fake router announcer
• Man-in-the-middle sniffing with a icmp6 redirect spoofing
• Fake announcer for multicast groups

It includes a packet-crafting library to create new tools. The toolkit is available at www.thc.org. Why am I telling you this? Because, I believe the best defense comes from understanding the offense. The attackers already knew about the toolkit. Now you do, too.

If there's an attack kit, then network administrators have to deal with it. The fundamentals for doing this are not new. IPv6 is just a new protocol. The cause of all the fuss about it comes partly from its location so far down in the network stack. When Skype or any other business-unfriendly applications protocols came along, the administrators were simply told to block it. Similar effective countermeasures for IPv6 exist, and they include:

• For networks that are only running IPv4 (for now):
• Block IPv6 and IPv6-over-IPv4 on all routers.
• Disable IPv6 on all servers, desktops, laptops, etc.
• This should be part of standard provisioning/upgrade.
• Configure any capable IDSs / IPSs to alert on suspicious IPv6 traffic.
• Enterprises experimenting and/or transitioning to IPv6:
• Make sure you know where it can go in your enterprise.
• Take the steps above for where it's not allowed.

More specific to IPv6, network administrators should also consider:

• Have devices ignore any redirects that don't make sense, e.g., if there's only one router on the LAN, there should be no re-directs.
• Encryption mitigates man-in-the-middle attacks.
• While deploying IPv6, deploy IPSec, too.
• Adopt Secure Neighbor Discovery, as it develops.

In conclusion, an important point to take away from the preceding is that there's some work to be done in transitioning to IPv6 – even if you're not transitioning right away. Start sooner, rather than later, on that preparation, because your network is doing it anyway…with or without you!