Anyone who reads this blog regularly knows that I not only advocate the implementation of IPv6, but that I attach a certain urgency to the need for implementation. It therefore surprises some of my consulting clients, convinced and looking for an implementation plan, when I counsel them to slow down a bit. An implementation plan (or transition plan, as most call it—I’ll talk about that in a later post) is not your first step.
First, you need to have a clear picture of where you are going, why you are going there, and what you might face along the way. What you need as a first step is a feasibility study.
In this post I’d like to provide a brief overview of the components of the IPv6 feasibility study.
[b]The Problem Statement[/b]
IPv6 is not an objective; it’s a potential solution to a problem. So the very first question to ask is, “What’s the problem I’m trying to solve?” The problem might be a dearth of available addresses, mobility, security, quality, service expansion, or any number of other issues to which IPv6 might be a solution.
Identifying the problem or problems to be solved gives you a concrete reference: You now know what you are hoping to get from IPv6. It also leads to another question to ask throughout your evaluation of IPv6 as a potential solution: “Is IPv6 the only solution to this problem?” A number of factors must be considered when weighing IPv6 against alternative solutions, such as:
- Cost
- Technological maturity
- In-house expertise
- Outsourced expertise
- Multi-problem solution (i.e., can one alternative solve multiple problems while the other solves only one?)
- Hardware and software support
[b]Change Assessment[/b]
The first of several assessments in the feasibility study is a rough determination of what must be changed in order to implement IPv6. You do not need great details here, just an estimate. Transition costs are distinctly influenced by the amount of change and the nature of the changes that must occur, and the costs in turn can affect the feasibility.
Factors to consider are:
- How much existing hardware or software would have to be upgraded for IPv6 support?
- What existing systems must be “touched” to enable IPv6?
- Would any new hardware or software need to be added just for IPv6 support?
- Do any network peering arrangements need to be changed? For example, if you depend on a carrier for interconnecting your network sites, can that carrier support IPv6, or will a change to another carrier be required?
- What is the current level of IPv6 knowledge of the engineering and operations staff?
[b]Standards Assessment[/b]
There should be one or more developed standards for the IPv6 features you have chosen, whether those standards come from IETF, IEEE, or some other body. First determine what standards are relevant to you; there are then a few things to verify. First, are there competing standards for the feature you need? If so, you may need to evaluate each for completeness, vendor support, and the best fit for your needs. Next, what is the level of development of the standards? If a standard is not yet complete, it poses a risk to you; for example, if you choose a pre-standard implementation and the standard changes, you can be left with interoperability problems.
[b]Vendor Assessment[/b]
With an understanding of what you want to accomplish, what needs to be changed in your network, and what standards support you require, you can now assess what vendors might meet your needs. A vendor selection should not be made in the feasibility study; evaluation and selection is a part of the implementation plan. Rather, at this stage the objective is to create a list of vendor candidates. In fact, a list of several or many vendors is desirable; if only a single vendor exists the risks of the project are raised considerably because of a dependency on that vendor.
[b]Risk Assessment[/b]
The change, standards, and vendor assessments should together give you a reliable expectation of the risks of transitioning to IPv6. No network migration is free from some level of risk, but a clear understanding of the potential shortcomings of the technologies, vendor support of the technologies, and the existing capabilities of your staff and your network give you assurance that you have properly identified the risks and determined if they are at an acceptable level. This risk assessment also helps you to perform proper planning to mitigate the risks as much as possible.
Factors to consider in the risk analysis include:
- In what areas could cost overruns occur?
- How much cost overrun can be absorbed by the project?
- Is there confidence that the underlying standards are unlikely to change?
- Are there dependencies on vendor roadmaps? What is the confidence level that a required service or function promised by a vendor will not “slip” on their schedule?
- If a vendor cannot deliver as promised, how difficult is it to switch to another vendor?
- Are there potential interoperability problems between vendors?
- Are there dependencies on partners such as content providers?
- Are there dependencies on service providers?
- Can backout plans be supported at every phase of the implementation project?
[b]Cost Rough-In[/b]
Based on the extent and nature of the changes required, you should be able to make a reasonable estimate of the costs you will be facing. This is a major factor in deciding whether or not to move forward; implementing IPv6 might be beneficial if it can be done for a reasonably low cost, while an expensive upgrade could negate any benefits. The cost might also influence timeframes. Rather than implementing within a year, you might decide to implement in four years; that gives you time to bring IPv6 capabilities into your network during equipment and software upgrades that would happen in the normal course of operations, and training can be phased in as a part of routine staff education. A longer timeline might also give your preferred vendors time to grow and mature their IPv6 feature list.
[b]Value Assessment[/b]
A value statement is often—and inexplicably—neglected in feasibility studies. And yet the true feasibility of any proposed project cannot be truly determined without understanding the value of the project. The value assessment also serves as a counterbalance to the cost estimate. For example, an implementation project expected to cost $400,000 over two years might appear to be prohibitive if only a cost analysis is performed. But a corresponding value assessment of the resulting changes might predict operational savings or corporate profit or both over five years that is many multiples of the cost; the $400,000 goes from an exorbitant expense to a good investment.
[b]Timeframe Rough-In[/b]
If all of the previous assessments and estimates have been completed, you should have all the data you need to make a good timeframe projection. Time can influence cost, as discussed in the previous section. Therefore cost is one of the most significant factors in estimating the time necessary to implement a given IPv6-based solution. Tied closely with this are confidence in the standards, confidence in the available vendors and their plans, the time necessary to bring identified risks down to an acceptable level. Human resources are also a major determinant for estimating both time to begin the project and time to completion. How much training of engineering and operations staff is required, and how long will it take given a projected training budget? What outside resources are available to help with project planning, implementation, and training?
[b]Feasibility Study Conclusions[/b]
The feasibility study is germane to the determination of whether there should be any further plans: The conclusion might be, “We’ve looked at IPv6 thoroughly, and have concluded that it does not profitably serve our needs in the foreseeable future.” But if the conclusions of the study are positive, it should provide you with a clear understanding of what the implementation plan entails in terms of change, cost, benefit, risk, and time. The feasibility study them serves two functions:
- The study makes the case for funding the implementation project
- The outputs of the study provide the inputs for the implementation plan
The next post looks at the elements of the implementation plan itself.
