On June 6, World IPv6 Day participants, including Akamai, AT&T, Facebook, and Google, will turn IPv6 support on and leave it on. IPv4 will still work, of course, but what happens when your enterprise applications or websites no longer perform well for customers or remote employees? It's the nature of any major transition: Problems will arise, sooner if you have a global customer or user base, later for SMBs. But eventually, a site or service will get glitchy, and IT will get the call.
It's unfortunate, then, that our new InformationWeek IPv6 Survey shows a negligible increase in the number of companies actively preparing. In our May poll of 681 respondents, 38% say they have no plans to run IPv6 in the foreseeable future, down a mere point from 39% among 632 respondents in June 2011. Just 5% already run IPv6 in most of their networks, up from 4%. A big roadblock: Just 10% say their IT teams are very knowledgeable on IPv6. Clearly, we need to get some education going. At this point, skip the theoretical--jump right to tools and exercises using the operating systems and networking equipment you run your business on.
Once you gain an overall view of the areas where IPv6 will make an impact in your network, set priorities. For instance, do you need to get IPv6 to desktops? What about telecommuting and mobile employees? Do you have insight into what your service providers are doing? And what about security?
We advise prioritizing IPv6 support for externally facing systems, such as websites, streaming services, and firewalls, because many users of these services will be IPv6-capable in short order. For instance, in China, where IPv4 addresses are scarce and expensive, networks will be switching to IPv6 and end users will be unable to connect to publicly facing sites that are not IPv6-compliant. In our full report, at informationweek.com/reports/ ipv6priority, we cover bringing IPv6 to the desktop, supporting remote offices and telecommuters, upgrading websites and externally facing properties, and installing IPv6 on enterprise applications while also taking a first look at our latest trending research. For now, though, let's discuss why "head in the sand" shouldn't be an option.
From a design standpoint, unlike with IPv4, every device in your network, from servers to printers, will eventually get a unique IPv6 address; that's a key reason for including IPv6 in buying decisions. The first priority is ensuring that websites and Internet-facing applications answer IPv6 requests. As IPv6 becomes more prevalent, your site will start to lose customers if it hasn't been upgraded. While it's true that you may be able to run a local load balancer to solve this problem, it isn't an optimal solution because this setup requires that all IPv6 packets be rewritten to IPv4, and that spells CPU overhead and delay.
Most companies will run a dual-stack setup; that is, make their networks both IPv4- and IPv6-capable. However, dual stacking can be a huge project. Your ISP or IP transit provider will have to provide you with IPv6 addresses, your DNS server will need to accept both A and AAAA records, firewalls and access control lists (ACLs) need to be upgraded, and all of your servers must support IPv6. That last step can be the most time consuming, because, depending on which version of Windows, Linux, or Unix you're running, IPv6 may or may not be reliable. We have found a number of oddities--for example, standard IPv4 firewall ACLs used on IPv6 blocks. The network provider allowed local IPv6 discovery traffic to go through, thereby making every server in the data center visible. Had we not run a security scan, hundreds of servers would have been vulnerable.
There are stopgap measures you can take, but you need to get moving, especially if you have employees or customers in Asia. Schedule training, review applications and network equipment, and prioritize. The transition to IPv6 doesn't have to be daunting. But it does have to be done.
Andrew Lientz is VP of managed services at EdgeCast, a global content delivery network. You can write to us at email@example.com.