The number one question in our IPv6 training courses is always about where to start an IPv6 implementation plan. When an engineer thinks of implementing IPv6, it can feel like climbing Mount Everest – something that is so huge, you best stay away from it unless you are a real expert.
This is why we recommend getting a project manager involved and breaking the project down into smaller parts. Remember that not everything has to be done in one week.
We start with a basic project management framework:
A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the IPv6 project, and it is important to identify the stakeholders in your project as the first step. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly.
Examples of stakeholders are:
The next step is to identify your project goals with your stakeholders in mind. This is the most important step in the planning process, as the success or failure of the entire project depends on it! The clearer the goals, the better. It's also important to include timelines for major milestones. For example:
Don't make your milestones too big – it is better to have many smaller milestones than a few large ones. This way, it will be easier to measure your progress. Also, there should be some logic in the sequence of milestones in your project plan. For example, you have to have an IPv6 addressing plan in place before you can configure a router. Our step-by-step guide will help take you through the major milestones in a logical order.
In this phase, you will have to make a list of tasks for every milestone. For a large enterprise, it may take several iterations to really understand the level of effort required. Depending on the required schedule, it may be useful to roll IPv6 projects into other architectural upgrades, which can be an excellent way to improve your network and reduce costs. However, by increasing the scope of projects, the schedule is often affected. For instance, a major systems upgrade may take a year to complete, whereas just patching existing systems may take only a few months.
The assessment phase is all about analysing the extent to which your network and applications are ready for IPv6. RFC 7381 sections 2.2.1 and 2.2.2 have some very good recommendations.
In this phase, you will make an inventory of the hardware and software involved. Do you need to upgrade? Do you need to replace the hardware? Can the equipment or software already do what you need it to do for your IPv6 deployment?
In case you are not sure whether the equipment or software is IPv6 capable, RIPE Document ripe-554, “Requirements for IPv6 in ICT Equipment”, might be very useful.
A training colleague at AFRINIC wrote an excellent example of a preparation list for the IPv6 readiness of an IPv6 web server, which may also be useful. Below are the main steps for deploying IPv6 on web servers:
When all of the milestones are complete, and the ultimate goal is achieved, don't forget to celebrate the success with the entire team!
This is another very important step for the successful implementation of IPv6, because it's at this state that the costs, time resources and risks are defined. This is the stage at which your managers need to give their approval for the project, including the goals and milestones.
First, you need to create a human resources plan in which you will identify the names and/or roles of everyone involved and assign tasks to people or departments. Make sure you describe the estimated duration for each task.
The second plan you will need to develop is the communications plan. Which stakeholders need to be informed before the project even begins? Who should be kept up to date throughout the implementation, and at which stages? What channels of communication will you use? Are you going to send regular progress reports? What should be included, and when will you send them?
Last, but certainly not least, is the risk management plan. Many people are worried that IPv6 is not as secure as IPv4, or that things might break in the process. In this plan, you describe the potential risks, assess them, and plan how you are going to mitigate them. For example, how you are going to set up test environments and what specific risks are associated with running two protocols? Here are a few examples of potential risks:
Set up a meeting with your management and explain why it is important to start the implementation of IPv6. These guidelines may be useful as a starting point.
Also, make sure you come prepared. For example, in this meeting you should know how many IPv4 addresses your organisation still has, when you expect to run out, whether you will have to buy IPv4 from the transfer market and the potential cost of doing so, etc.
You should also be extremely familiar with the project plan.
This is a very exciting step. This is when all of the actual configuration and testing work is done. In case you come across something strange or you need an expert's advice, there are some groups you can go to for support:
This list is a forum for people who are actually deploying IPv6 on the Internet. Its focus is on operational issues (especially BGP routing) and development of the production IPv6 Internet. A wealth of information can be found in the list's archives.
There is an IPv6 group on Facebook with over 4,300 members who help each other answer questions about IPv6 and keep each other up to date on their deployments.
The IPv6 Working Group exists to promote IPv6 adoption. Its activities include:
The working group cooperates with operators and others, both inside and outside the networking industry, to share resources and combine efforts.
The RIPE NCC offers one- or two-day IPv6 training courses to its members.
You can find all the information and training material online.
Although this step is often neglected, it is important to make sure the project is closed properly. Many projects do not have a clear end-point because there is no formal sign-off. It is important to get an agreement that the project has ended, and no more work will be carried out beyond the scope that was agreed upon. Once closed, the project manager should review the project and record the good and bad points, so that in the future, successes can be repeated and failures avoided. A project that is not closed will continue to consume resources. A good idea is to present at a local Network Operator Group (NOG) or RIPE Meeting about your operational or other IPv6 experiences. That way, others can learn from your project.