Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=229218783
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.
When the CEO asks about your plan, will you have a good answer?
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.
4 Steps To Take Now
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.
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.
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.
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.
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. 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. Predeployment testing for standards compliance and system interoperability reduces the number of surprises you'll encounter.
Brave New World
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, at information week.com/analytics/ipv6, includes sample case studies for these orgs, as well as a healthcare provider. So don't just sit there--start assembling your team.
Jeff Doyle is a consultant specializing in routing protocols, IPv6, MPLS, and networking best practices. Write to us at email@example.com.