Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Four Steps On The Path To IPv6: Page 2 of 2

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:

  1. Appoint a team. In all but the smallest companies, planning for IPv6 is a cross-discipline effort. This is particularly true when there are multiple groups within your company that will be affected by the IPv6 project. For example, customer online account management, e-mail and Web sites, core network architecture, network security, and network management likely fall under different managers, but all have roles. Plus, an integrated team reduces the risk of the project being derailed by any one group or individual--a liability that, in our experience, has complicated many an IPv6 project.
  2. Create a business case. Executives naturally want to know what they're spending money on and will want to understand your IPv6 project's return on investment. They'll want to know what services can be built around IPv6, but it's really about being able to continue doing what you already do, and to continue adding new customers, who'll have IPv6.
  3. Include IPv6 in all purchasing decisions. IPv6 shouldn't be considered a "special feature" or an add-on to any network or end user device, application, or operating system you purchase. It's as essential to IP capability as IPv4, and any vendor that doesn't support IPv6 on par with IPv4 shouldn't be considered in your purchasing decisions. Period.
  4. Create a detailed deployment plan. Good planning is all about reducing cost and limiting risk. An analysis of the impacts of IPv4 address depletion on your ability to conduct Internet business, and the scope of an IPv6 deployment, prevents both the risks inherent in waiting too long and having to deploy in "panic mode" and the high costs from moving sooner than you need to.

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:

  • Knowledge of who your users and customers are. What content, services and applications do you make available to them? What is your forecast business growth over the next five years, and what parts of your network must support that growth?
  • Realistic project timelines. Most of the present challenges associated with IPv6 deployments are the direct result of stalling until IPv4 address depletion limits your options.
  • Evaluation and selection of best-fit IPv6 technologies. A large toolbox of IPv6 deployment technologies is available to you. There is simple dual stacking, which makes interfaces "bilingual," so that systems can respond to incoming packets of either IP version and originate packets of either version based on DNS responses. There are statically configured tunnels to a wide variety of automatic tunnels to full protocol translators. And there's a lot in between. Understanding the capabilities, applications, and limitations of the available technologies ensures that you're selecting the best options.
  • Testing. Trial runs are important with any new technology deployment, and that goes double for IPv6. Although IPv6 has been around for some time, its exposure in production networks is still limited. Because of this, consider the IPv6 code in systems immature until proven otherwise. Pre-deployment testing for standards compliance and system interoperability reduces the number of surprises you'll encounter.

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.