In my previous post I went over the overall categories of phases that would have to be accomplished (at a minimum) for an IPv6 adoption plan. You can find that post here. I wanted to follow up and dive a bit deeper into each one of the phases, so in this post let’s talk about the assessment phase.
An assessment is going to be important for several reasons.
- First, it allows you to benchmark where you are at so you can accurately know how much progress (or lack of progress) you are making.
- Second, it provides an accurate picture from a technical standpoint of what obstacles you might have to overcome or address for your IPv6 adoption.
- Third, it is a good opportunity to get the learning process kick started for much of your team as they are likely unfamiliar with the IPv6 capabilities of their software, hardware or providers.
The information you gather in an assessment will become critical for making informed decisions around IPv6. This is important as you will have a much better idea of potential impacts. The breadth of the assessment might only be for your narrow area of expertise but it is advisable to have an overall picture which means aggregating all the assessment data to a single project owner. Someone having the big picture and who is setting the timeline and determining dependencies will become critical in the planning and design phases along with the deployment. Often these project owners may not be technically as deep as the members who are performing the assessment and this means they will need help in making accurate decisions.
To address the needs of having good technical decisions made I typically recommend that a small advisory team meet to review the independent findings and to help the project owner determine what is truly important. After one or two meetings it should be able to transition to an email list where the project owner can ask questions to get feedback. Alternately, for larger organizations it might be appropriate to have a tiger team focused on IPv6 or to have a committee that meets quarterly to go over IPv6 adoption and then provide a report of findings along with a specific plan of action.
So, what pieces of information are actually critical to gather in an IPv6 assessment? Obviously this will vary with your role within your company and what your technical expertise or business focus is but let’s do a high level breakdown.
Software support is critical and this can vary from core operating systems, commercial software applications, custom written software applications and finally software used for specialty hardware in the form of firmware. You will need to know what minimum version of software supports IPv6 and if an application is even impacted by IPv6 at all. For the firmware used for hardware you will also have to check compatibility with your specific hardware. You may be in a situation where your hardware lacks IPv6 support for its current firmware version(s). This will most likely require you to do a hardware upgrade.
Hardware support is a more difficult requirement from a design and planning standpoint. You will need to determine if all your hardware supports IPv6. Typically this category is network equipment of some type. Routers can normally support IPv6 with a simple software update but they may have line cards or specific ASICS that will not work with IPv6. Switches are a similar situation however due to the number of port ASICS (typically Ethernet) it can have a much larger impact. Firewalls, Application Delivery Controller (ADC), VPN, DDI and other network devices will vary in hardware impacts. It depends on whether or not the architecture of the device focuses on providing hardware acceleration and if that hardware will support IPv6. Hopefully IPv6 has been on your vendor evaluation criteria list for the last few years. Otherwise you may have been purchasing hardware that does not support IPv6 (or that has inadequate IPv6 support). If you do not have a vendor requirement of this type, it is time to adopt one.
Vendor Support
Scott Hogg (my fellow IPv6 COE member) had a really good point he pointed out to me in reviewing this post, one I thought worth mentioning.
“Since IPv6 has had so long to ‘incubate’ IPv6 has slowly crept into many products. During an assessment, people may be surprised to find that IPv6 is already integrated in operating systems, network devices, and software. An organization that did their IPv6 planning 5 years ago would have found many products that lacked IPv6 support. An organization that does their IPv6 assessment 5 years from now may not even need to do an assessment.”
This reinforces how having a specific IPv6 vendor policy will be to your advantage because your IPv6 assessment will have a more positive outcome.
Last but not least is any third party provider you may utilize. These would include providers for things like WAN transport, Internet access, Email, DNS, Cloud service providers for IaaS, PaaS and SaaS. This information can be difficult to evaluate as the landscape is changing quickly and your provider might be in the midst of adopting IPv6 themselves. They should be able to provide you with a reasonable roadmap of their planned support and as long as they match your requirements you should be good to go. If they do not match your requirements it is time to look for another provider. Granted, this can be a more difficult than this statement implies. You may have long term contractual arrangements or other roadblocks. Just identifying concerns and what your long term goals are might be all you can do. You likely won’t be able to impact change in your third party provider but if you are one of the lucky few who can, please push for IPv6 support!
The end result of the assessment is a complete inventory of applications, hosts and infrastructure that are impacted by IPv6. You will need to differentiate those items in your inventory that actually need to make a transition to adopt IP6 or not. Not everything has to adopt it and it will make it easier to identify what is in and out of scope for your next phases.
Once you have the assessment completed you are ready to tackle your Proof of Concept and Deployment projects with less fear of failure or potential unknown impacts from adopting IPv6. One of the critical goals of an assessment is to reduce the FUD (i.e., fear, uncertainty, and doubt) around IPv6. After all, it is just a simple networking protocol. Don’t let it scare you to the point you don’t actually deploy it! To also help reduce the FUD, IPv6 training and education becomes an important tool. I will cover that in more detail in my next post.
IPv6 is the future and the future is now!
Happy 2015, now go deploy IPv6…
