Four Steps On The Path To IPv6

IPv6 MUSTS

Focus on IP address design and management. Start the IPv6 prefix assignment application process now. Stop worrying about conserving addresses and start thinking about adding meaning to individual hex digits. And ditch the spreadsheet to track all this.

Update network support systems Do you have an internal DNS infrastructure? Can nameservers support both IPv4 A and IPv6 AAAA records? If they're dual stacked, how do they respond to a name query when there are both IPv4 and IPv6 addresses assigned?

Budget for security updates and expertise End-to-end IPsec notwithstanding, security systems tend to be the problem children in IPv6 deployments. Not everything will survive the transition, so allocate some funds here.

Understand the lingo Tools for monitoring, logging, alarms, configuration management, and change management have to understand IPv6, not speak it.

Have end-to-end training Don't limit IPv6 education to IT. Going all-IPv6 positions your company as a technology leader. Make sure customer-facing personnel can tell the story.

Does this remind you of Y2K? The hard reality that the Internet is running out of IPv4 addresses recently hit the Wall Street Journal and New York Times. You know what comes next: business executives get to wondering just how this IPv6 thing will impact their businesses.

You'd better, because the companies that provide your customers with Internet access are on the move. Broadband service providers--cable, DSL, and mobile--depend on a steady flow of new IP addresses as they grow, and they are actively implementing IPv6. Because of these initiatives, a tremendous number of IPv6-equipped end users will be coming online over the next few years.

While top content providers, including Facebook, Google, and Yahoo, are adding IPv6 capabilities to their sites to ensure their services will be available to both IPv6 and IPv4 users, broadband providers understand that, for the foreseeable future, most Internet content will remain IPv4. The dilemma, then, is that they have only IPv6 addresses for their new customers but must ensure that those customers can still reach IPv4 content. The methods they use to solve this problem can affect your business in some surprising ways.

One solution is for providers to deploy centralized network address translators (NATs, either NAT444 or DS-Lite) that allow ISPs to "dual-stack" new customers with a public IPv6 address and a private IPv4 address. The other option is to use a protocol translator (NAT64) that allows an IPv6-only device to talk to an IPv4-only device. Neither method is ideal--both are known to break some applications, such as VoIP, Universal Plug-and-Play, and many online gaming apps. They also can hurt performance and create a single point of failure. Also, applications that identify users by IP address will no longer work if the user is behind a centralized NAT. Because these systems use a pool of public IPv4 addresses rather than public addresses at the individual customer edge, a single public IPv4 address can represent thousands of users.

Where a company could run into problems is when its content or Web applications no longer work correctly because a broadband provider serving its customers is using one of these transitional technologies. The customer doesn't understand the nature of the networks he's using; he only understands that a site he wants to access is not working correctly. Sure, it may be the service provider's fault, but you can bet he'll blame the one running the Web site--yep, that means you.Potential damage to the user experience is the main reason for beginning an IPv6 deployment plan. Once you get the go-ahead to begin transitioning to IPv6:

The key to "selling" your project in the boardroom is to emphasize that an IPv6 deployment is an infrastructure problem. Specifically, your network is running out of an essential resource. Imagine that all of the bandwidth you currently have, all of the server capacity you currently have, and all of the routers and switches you currently own are all you can ever get. This is the business case for IPv6.

Sounds straightforward, but including a simple "IPv6-capable" check box on a requirements list isn't enough. Each system in your network has specific protocol, performance, scaling, and security quirks. Some might require support of DHCPv6, or VRRPv6, or DNS AAAA (IPv6) Records, or certain IPv6 routing protocols. Others may not. Some might need to filter on specific details of IPv6 packet headers, and others won't. Some systems might need to process IPv6 packets in hardware. You get the point.

This is where your IPv6 team structure, reaching into every corner of your network, is invaluable. A detailed, system-specific list of IPv6 requirements not only reduces project risks, it's appreciated by most vendors. The more they understand your needs, the better they can recommend the right product or, in some cases, refine their development road maps.

Important elements in your deployment plan include:

There's no going back to IPv4--and that's a good thing, because IPv6 will enable growth. Planning for IPv6 now doesn't necessarily mean deploying it now. It means you have a clear perspective on the future of your network, and your business.

We predict that most companies have about a year before push comes to shove; exceptions are federal government agencies, federal contractors, and multinationals. Our full report Best Practices: IPv6 Transition  includes sample case studies for these orgs, as well as a healthcare provider. So don't just sit there--start assembling your team.