Earlier this year, the Internet Assigned Numbers Authority (IANA) allocated its last IPv4 address blocks to the regional internet registries (RIRs).
This signalled that IPv4 public address space exhaustion is coming closer, and that our plans to deal with this must be in place soon. In June 2011, World IPv6 Day took place. Companies including Microsoft, Google and Colt participated in the first global 'test flight' for IPv6.
The goal was to motivate organisations across the industry – ISPs, hardware makers, operating system vendors and web companies – to prepare their services for IPv6 and ensure a successful transition as unallocated public IPv4 addresses run out.
After years of work by the infrastructure vendors, content and service providers in constructing the routing and namespace frameworks, IPv6 Day came off successfully. It demonstrated end-to-end reachability for IPv6 services.
However, the traffic volumes demonstrated that there is a long way to go before many internet users have IPv6 access. But, one thing is certain: the volume of IPv6 traffic and the number of users and services generating it are set to grow.
This brings a new set of risks that must be considered and dealt with by security teams, which are already overstretched. Even if our tools do support IPv6, in some cases the features haven't been tested as extensively, so the likelihood of unforeseen issues is higher.
Also, some of the tools security professionals use to gain visibility of (and control over) traffic may not yet be available for IPv6; the ability of our equipment and tools to forward, switch and process IPv6 traffic does not necessarily mean that all of the other features we use to make our lives easier are there.
Furthermore, some IPv6 migration mechanisms that use tunnelling, for example, can make it harder to monitor exactly what is going in and out of our networks, allowing sensitive information and malware command-and-control traffic to cross the network perimeter undetected. Also, with longer addresses and new and unfamiliar protocols, there is more scope for a configuration error or omission to provide a route in for an attacker.
That is before we consider the possibility of a focused, malicious attack. While the proportion of IPv6 end-users and services is small, it is less likely that attacks will occur over IPv6. As more organisations and end-users begin using IPv6, the attack threat is likely to increase rapidly.
The majority of IPv4 attacks are still applicable. Furthermore, there have been numerous instances of malware tunnelling command-and-control traffic and potentially other sensitive information over IPv6, to reduce the chances of being detected. Some IPv6 experts have commented anecdotally that bit torrent is one of the most common uses of IPv6 tunnelling because tunnels are so effective at obscuring the bit torrent traffic.
It is likely that we'll start seeing new attacks using extension headers which are intended to derive a response or use resources within an intermediate node (router) or endpoint. Additionally, where users are able to obtain physical access to a local area network, intentional and unintentional 'rogue' router advertisements are a significant risk.
So how can businesses ensure they are prepared for the IPv6 switchover? Businesses should be looking toward building a clear plan as to what they are going to do internally for their LANs and externally for any internet-facing services they provide as they migrate to IPv6. The latter, of course, is predicated on the services their Internet service provider can offer, and understanding what is, and will be, available is key here.
The migration to IPv6 brings a host of new issues that have to be considered and understood if we are to maintain the security of our networks, data and businesses. We need to look at the migration mechanisms available and understand how our user-base will interact with them.
For example, network engineers should understand the issues regarding automatic and manually configured IPv6 tunnels. While the latest operating system releases may handle IPv6 tunnelling correctly, older releases may have issues that cause problems. Network engineers should confirm that their systems correctly handle adjusting the MTU to accommodate tunnels and that their network firewalls don't block ICMPv6 'packet too big' messages.
Importantly, we need to ensure that tools, routers and security devices support the same capabilities when processing IPv6 traffic as we would expect with IPv4. Now it is crucial for businesses to confirm that the hardware and software they are procuring fully supports IPv6. The business's inventory of networking products must be evaluated for current IPv6 functionality and upgrade plans put in place where necessary.
Also, businesses need to confirm the IPv6 capabilities of their Internet Service Providers, now and in the future. As with IPv4, large businesses, as well as those with multi-homed networks, should plan on acquiring IPv6 address blocks from their regional internet registry. For smaller businesses, it may be acceptable for them to use address space provided by their ISP.
Just a few years ago, it may have been interesting but not necessarily important to ask a vendor: Does your device support IPv6? Today, this question is an essential first step in determining that the product will meet requirements, as more internet users and services migrate to IPv6.
Darren Anstee is EMEA solutions architect at Arbor Networks