Title: The first steps in IPv6 adoption – having a plan
If you are like the majority of IT professionals who are operating networks and maintaining systems today you likely haven’t implemented IPv6 at all. Most companies have not had the time, money nor need to get IPv6 deployed and have stayed on IPv4. Therefore IPv6 adoption is further behind than many other technologies that were developed along a comparable time line. Now that IPv6 is rising rapidly as a technology people should pay attention to and know (for a variety of reasons: see some previous posts here, here and here), what can you do to get started? What are the critical things you need to know?
To begin with, IPv6 is no different than any other project you might have as an IT professional (though perhaps a bit bigger in scope and impact). Like all projects it requires a plan to lay out a roadmap of how you are going to successfully deploy IPv6. Let’s cover at a high level what sort of strategy you would adopt to get a plan developed as well as how you might go about working with IPv6 in a bigger context.
An IPv6 project will require, at a minimum, the follow general categories of phases to be accomplished:
1. An assessment
You should do an assessment to determine what your environment can and cannot support from an IPv6 perspective. This means evaluating software, hardware and providers. It means doing detailed analysis and perhaps some testing to determine if a software application that’s critical to your business will actually work over IPv6. Many companies choose to do an assessment as the second phase of their plan because they want their own teams to be trained-up and knowledgeable about IPv6 first.
2. Training
Training is key to understanding what IPv6 will or will not impact. It also establishes the baseline of knowledge within your teams about IPv6 and what is needed from your hardware, software and providers. Sometimes an initial training phase is done to establish a baseline of knowledge then an assessment is started. For more specific, in-depth knowledge trainings are scheduled. Things like networking (routing, load balancing, and transition technologies) or security (firewalls, vpn, access controls) are common as specific, in-depth training topics.
3. Planning and Design
You will need to cover several aspects of planning and design. Specifically, network address planning, network design (L2 and L3), transition technologies (translation, tunneling, etc.), hardware upgrade planning, software upgrade planning, provider upgrade planning and other design and deployment issues that may be specific to your company and operation. For instance, if your company utilizes an MPLS service you can either request that your provider upgrade to have IPv6 support, change providers if they do not have the support or use a transition technology to design around their limitations. You have tradeoffs in all those choices and ultimately your value is helping your company navigate the options to determine the best one. (There are lots of different parameters you can use to figure out what that “best” choice really is but that is an entire article on its own.)
4. Proof of Concept
Often a Proof of Concept or POC is useful in evaluating hardware, software and skill sets to determine IPv6 viability. It is the opportunity to do a small contained configuration of IPv6 that hopefully will have a limited impact on the company’s performance in case something does not go well. It is not uncommon to run into challenges getting IPv6 operational and a POC is a great way for IT staff to learn some of these issues first hand. With a POC all sorts of possibilities become available. For instance, you can test hardware specific devices, software application behaviors and even operational debug and testing capabilities of both your equipment and staff. A POC is invaluable in gaining the real world experience a team needs before going live with a large-scale IPv6 deployment.
5. Deployment
Some of the greatest challenges with IPv6 are around deployment and how much planning and time it will take to do it properly. Keep in mind, if you have tunneling or transition technologies in place to do IPv4 to IPv6 or the reverse you will have to have a plan in place to eventually phase those solutions out. Remember, the end goal for deployment is an IPv6-only environment. You are only halfway done in a dual-stack deployment. Eventually you will need to remove IPv4. It might take years, decades even but it will happen. You need to plan as part of your deployment what is likely to happen then. Taking that into consideration might change your design, methods and architecture so doing at least some planning around an eventual IPv6-only deployment is important.
6. Operate
Having an ongoing operational plan for supporting IPv6 is really important. It is so easy to slip back into old IPv4-only habits for purchasing, testing and validating things. If IPv6 isn’t understood as an operational requirement you will likely fail in your goal to successfully run a dual-stack network. Long term, as mentioned in the deployment planning section, you will want to run an IPv6-only network. Until then, you need to have a plan for those that operate your network to become skilled in both IPv4 and IPv6. Helpdesk, IT staff, security and many other teams besides the network team need to understand IPv6 and its impact on the operations of the business and infrastructure.
So as with any project for a company, planning is key. IPv6 is no exception. Don’t make the mistake of not having some sort of plan and roadmap for IPv6. Use tools that support both IPv4 and IPv6 and build up the skill sets of your teams to learn and support IPv6.
– Ed
