Last Updated: Dec 28, 2021
Network administrators that have not acknowledged the existence of IPv6 do so at the peril of their employers and customers. This is due to not only technology moving forward according to new standards and best practices, but the fact that the number of IPv4 addresses is nearly exhausted on a global level. Acquiring IPv4 blocks is NOT a guarantee and requires documentation and justification – which means that if you need routable IPv4 space – get in line with everyone else and/or bring your wallet.
There is good news though – IPv6 deployments have continued growing and chances are you are already using IPv6 – but haven’t realized it yet. As a network administrator, your consumer technology may actually be ahead of some of your business technology in this regard. Comcast, Verizon, and T-Mobile are just a few service providers that have deployed IPv6 extensively both internally and externally for their users. As more users work from their homes, many of them are already on hybrid or IPv6 networks provided by their internet service providers. Though managing a more remote fleet of devices has its own challenges, IPv6 compatibility is likely not one of them.
Alongside these efforts, there has been significant progress to bring IPv6 services live as well. So if you are just getting ready to check out IPv6 – you are in luck, there are plenty of real-world experiences and resources to help out.
While the deployment and migration to IPv6 is not common, let’s dig into how we can help the Network Operations team with this “IPv6 Migration Top 5”.
Concern 1 – Selling the Migration Internally to CIO/CFO
The first concern is convincing management within your organization to proceed with the migration to IPv6. Since IPv6 is most likely “not replacing” your IPv4 network, you will be running them concurrently – which impacts things financially since there are direct operational costs. You got it – dual-stack = two networks, so you are going to need to present this effectively so it doesn’t come across as “double the workload”. In this Concern, we mention the CIO or CFO, but this could just as easily be any other decision maker or stakeholder in the project’s approval process. This concern normally arises in other projects as well for similar reasons. Not everyone is an expert on technical matters, nor should they be expected to be. As IT professionals however, it does become our responsibility to communicate our expertise effectively so those that do make decisions can make them while informed, and not based out of fear, confusion, or past experiences that were not well planned or thought out. Since IPv6 can be a “disruptive” upgrade (especially if done incorrectly), and changes the networking game in a few ways, expect resistance by decision makers.
The solution to this concern is communication. Decision makers must know exactly what is at stake in the migration and what it means for the organization. This means studying the migration from multiple perspectives that your decision maker will likely want to know about, and doing your homework twice so you are prepared for questions and other unexpected situations. It should also be noted that while the communication should not attempt to scare the decision maker into a choice, results and consequences are a part of this migration and must be communicated. Techniques for communication should also be utilized such as targeting the audience with a style that makes them comfortable (dress, bound presentation, etc), and one that eliminates confusion while still being effective (not using too much jargon, relating back to other principles besides IT). Communicate effectively, and this concern should be easier to deal with. One example from the field: One of our customers was preparing for IPv6 and worked in data regarding the costs of maintaining and acquiring IPv4 space. These numbers (based on actual data) were great at getting attention of the executive team, but also showing that large blocks of IPv4 are an asset with intrinsic value and cleaning up their network could free up IPv4 space to be divested and leased. This could help defray the costs of IPv6 training and implementation while also providing that path to a post-IPv4 world.
Pro-Tip for 2020: How to present on IPv6 without alienating your non-technical audience. 1) Ths shift with IPv6 is cultural as well as technical. That means that throwing acronyms on slides will only ensure that your message gets ignored. Bring in your audience by speaking directly to them and presenting actual solutions. For example: An introduction slide might just mention some bullet points on the global shift that is behind IPv6 adoption and why. Then follow up with the opportunities that IPv6 brings to the table in terms of scalability. Close it out with some examples of solutions powered by IPv6 tied to real business concerns/opportunities and tie them to your organization. Finally – the Call To Action – is this informational? Do you want to get budget/resources to research IPv6?
A key angle is not only showcasing the short-term impact (potentially getting new hardware, training, etc) but also getting a feel for the long term. If done correctly, deploying IPv6 sets you up for a not too distant world where IPv4 is deployed less and less and your network “reach” is growing more and more. The result is that you can frame the longer-term discussions regarding “What do we need IPv4-only networks for?” These are the long term planning perspectives that executives like (and need) to understand – that costs don’t just increase forever, but this protocol shift will possibly have a short term increase as the technology is absorbed, and then falls below legacy costs, while providing higher levels of scalability, redundancy and performance for both the internal network and external links.
Concern 2 – The Cost
Cost can include monetary assets, but also personnel and time. The migration to IPv6 will take all 3, but more so of personnel and time. A large amount of planning will be needed to get through the project as quickly as possible, and have everything working at the end. With planning come the people to perform that function. Any monetary cost may include new equipment (routers, switches) or servers, and should be considered. However, we will focus on the other 2 costs as they will likely be significantly larger.
Having the correct personnel on the project can help reduce cost. These personnel will need to be efficient at their tasks, communicate well, and have a variety of experience and points of view (not so much into other departments besides IT yet, but good to identify these stakeholders as early as possible). The faster an initial plan can be written and proposed, the fewer hours and people it takes, reducing cost. WIth the initial plan, it is important to balance thoroughness with “topic fatigue” – if stakeholders are brought in too early, there can be lots of push back before the project even gets off the ground and delays will mount. Suddenly no one wants to work on a project that has turned into a slog. Within this plan, have an ear out for other projects that would be candidates to go alongside with. Once the migration over to IPv6 begins, it can be combined with other projects such as PC replacement, application upgrade deployment or datacenter updates. This will perform two tasks at once, removing the need to revisit a project already completed, saving cost. Many of these ideas are already in use in many businesses to save cost through the same or similar means. You can also consult project managers or other organization resources for more ideas.
From the monetary cost standpoint, most of it will be either new equipment to perform specific IPv6 functions, or for new equipment not IPv6 compatible. However, one specific cost to consider is an IPAM solution, which is a software suite that can index, search, and analyze an existing network IP address scheme. It is specifically mentioned here for its functionality, and should likely be mentioned as a topic of discussion in any team meeting or presentation. As you begin to scope out the IPv6 and IPv4 data that you have today and will need in the future, you may discover that the use of IP address metadata has changed since the systems/spreadsheets were put in place. It is worth revisiting this early on so that you don’t end up with an “I guess we need another tool to fill the gaps that we didn’t plan for” scenario.
When dealing with the concern of cost, remember it includes more than money. It is any resource that will be used by the organization. Time and personnel are costs that should always be seriously considered and factored in. Consulting other business leaders on conserving cost is a good step, along with having good team members working on the project, and soliciting ideas can help. At the very least, always try to never come in over cost and be realistic in how funds will be allocated for a given timeframe.
Depending on the structure of your organization, having an IPv6 Committee or Task Force is a great way to increase the visibility of IPv6, and also coordinate these shared efforts in a direct way. One of the big drivers of project cost within the organization can be mitigated by efficient communication. Silos can make communication more inefficient, so this strategy is a simple way to bring together the cultural and technical resources to make your IPv6 migration successful.
One aspect of IPv6 deployment that cost may not overtly address is going to be on the software side for applications that you either build/manage internally or buy commercially. It could be little things like:
- The perpetual license for the software you bought 5 years ago and let maintenance expire – will it support IPv6 even if you update it? Or do you need to keep an IPv4 only network island for legacy applications like this?
- Monitoring is typically “per endpoint or application” – but some monitoring systems may see the addition of IPv6 as “another endpoint” and not an extension of a current object. So depending on your monitoring platform – deploying IPv6 could mean getting bumped up into a higher pricing tier.
You get the idea though – IPv6 will require some vendor conversations beyond “do you check the box” as it could uncover some surprises that you were not expecting that will directly impact your operating budget.
Concern 3 – Complexity
Migrating to IPv6 will be complex. It will involve all departments of the organization, or at least all of them that use computers, and every piece of equipment connected to the network at any time. While IT has traditionally been the focus, it is important to remember that IoT has expanded the role of the network and devices across the organization. Some of those elements that you may not have considered in your plan might have changed. For example, ten years ago Building Management Systems (BMS) with robust APIs were few and far between, but today, BMS vendors provide all sorts of integration and networking options. This needs to be reflected in your migration strategy especially since it will need to be done in phases over time. Keeping everyone on the same page working together for the best outcome and smoothest transition. Now the complexity can be seen a little better. There are other factors such as compatibility with IPv6 and clearing out IPv4, but those are discussed later.
For right now, let’s deal with just the complexity issue rather than technical details. There are several different ways to work through a complex issue, and it always involves planning. In order to ensure nothing is missed, a plan must be created that will detail information such as timelines, groups of devices to be migrated, priorities, etc. In doing so, you can break the complex situation into more manageable pieces that are easier to work on and communicate to the rest of the organization. Again, IPAM can assist with this task by creating reports that can be interpreted and used in the planning process. A flexible IPAM tool/module will also have metadata features to help you track/capture this information.
This is only a brief look at the potential complexity. It can be taken even further by different makes and models of equipment that coexist on the network. But to deal with the concern, the best bet is to reduce the complexity. You can do this by planning out your migration by groups, devices, time, or whatever works best for you. The important part is that everyone agrees on it, and it is something the organization can live with in terms of effectiveness for the business process. It should also be sure to have every single component on the network, and be followed, checked, and updated as needed throughout the deployment.
One of the primary ways to start with plan creation is just doing an audit of your environment. This may require inventory lists, network scanning tools or possibly just concatenating all the distributed spreadsheets and systems with the information you need. Once you have a basic overview – then you can drill down into one environment for a more detailed inspection. When deploying IPv6, doing everything at once isn’t very likely – you will probably want to pick a few pilot projects first that will allow you to test out your IPv6 limits in a non-threatening environment (say a staging environment of an enterprise application). This way you can refine your processes as you go based on the realities of your environment. As mentioned previously – your IPv6 Committee or Task Force will make this stage SO MUCH EASIER than going it alone.
Concern 4 – Dealing with Legacy System Issues
Legacy systems can be defined basically as older systems. They likely are missing some common functionality from current technology, but still exist because they perform a key or important function for the organization just fine, thus there is no reason to replace it. With IPv6 deployments, it’s worth revisiting as the networks around legacy applications are changing (who hasn’t had a firewall or load balancer ruin their day at some point?)
When an organization deploys IPv6, the devices on the network need to support IPv6 addresses per interface, along with their existing IPv4 address(es) (a technique known as dual-stacking). If the device cannot utilize an IPv6 address, it will eventually cause conflicts and problems in not being able to be found or communicate properly (this is where tunnels come in and they have their own management overhead). It is possible to force it to use IPv4 only, but as more IPv6 capable systems come online in your network, the legacy environments will become more of a liability and require more creative workarounds.
The best way to deal with legacy systems is analyzing them for compatibility. Knowing that this can take up significant resources given the volume of equipment, IPAM can help, but it can’t do everything. You will need to get on the server(s) and perform a capability audit. By scanning and detailing the network, it can help determine compatibility for devices connected to the network, and provide a report. This is highly recommended not only for this function, but to assist in keeping addresses correct during deployment. More importantly, it will help you get an idea of compatibility on the hardware level as well as the application level. With some basic scanning and OS level auditing, you should have a decent start to ensure that IPv6 won’t bring any infrastructure challenges that you haven’t already anticipated. Applications can be another story though, so don’t get too excited.
Network audits may sound like a simple solution, but that only works to a point. It is likely that in your research, an important piece of equipment will be found to be incompatible with IPv6. At that time, the deployment plan for IPv6 expanded to include all of these devices, which must be planned for migration themselves and implemented on a parallel schedule to the entire migration. The sooner the compatibility of all devices can be determined the better, as it will allow for a timeline to be determined, and a better view of the scope for the entire IPv6 deployment.
Concern 5 – Cleaning Current IPv4 Inventory
The final concern is getting a handle on your existing IPv4 inventory. For many network administrators, this will involve getting new equipment to address any IPv6 compatibility issues, deploying it, then hanging onto the old equipment “just in casies”. But it is more than just equipment. Inventory in this case should also include services such as DNS and DHCP, both of which are impacted by IPv6. This is also the final step of IPv6 migration where IPv4 is removed from the network, so while it should still be a concern, there is a decent amount of time before this happens. The key part is still going to be the addition of IPv6 functionality (IPv6 reverse zones, AAAA records, DHCPv6, etc.).
To counter this concern, planning is still the key. However, at this point, it is less about the plan itself, and more about executing it. By this stage, dual-stacking should be fully implemented and all non-compatible devices either replaced or their purpose moved to a compatible device. Once this is stable, discussions for decommissioning IPv4 services can commence, but will require significant testing as the challenges will most likely not be in the network layer, but in the application layer.
Aside from proper planning and execution, there are other ways to plan for IPv4 service reclamation. To start, if your objective is turning off IPv4, this is accomplished at a technical level through network management tools like Group Policy or configuration distribution programs. IPAM can also be of service here by showing any devices not compatible with IPv6 versus which devices are compatible but not yet utilizing IPv6. Either way – turning off IPv4 is a big deal and should be tested extensively as there are more dependencies than you may think.
If your objective is dual-stack, there is an even greater value to your plan since you will be essentially running two networks simultaneously. Testing/Lab environments for these objectives is a must, and always check with manufacturers to ensure that reboots or other strange actions will not result from suddenly removing that communication method from items like servers and firewalls. Naturally, scheduled downtime is an absolute must, no way this should ever be done under any circumstance during business hours.
However, at a certain point, you need to make some deployment decisions based on your plans. If you are going to run both IPv4 and IPv6, you will probably have an easier time to ensure that the network works as intended since most systems are intelligent enough to use whatever stack is available. The challenge can be when you turn off IPv4 – the “incompatible” network elements will be obvious (for better or worse). As part of any deployment plan, testing is going to be key and will go a long way to ensuring that your dual stack deployment will go smoothly now, and in the future. Alas, sometimes now is all you have – so understanding how IPv4 is deployed and the impact of removing/disabling the protocol is key. As you can guess – part of your game plan at this stage should also include robust configuration management automation. This approach will help ensure that any interesting scenarios (production is now unreachable!) can be forecasted and (worst case) rolled back seamlessly.
Reflection
These are only what are considered to be the top 5 concerns with IPv6 migration, specific only to network administrators. There are many other challenges and concerns within this project as well. But with each of those, and the 5 seen here, there are some basic strategies that can minimize the impact of them.
Communication is always important, especially within the organization. This migration is everyone’s concern, so why not involve them. Of course, not everyone will be involved at every stage, but it helps to build a team environment. With that communication comes planning and understanding so everyone will be together on the project. Use the resources available within the organization as well as the ones outside such as the IPAM.
Regardless of the approach, the entire migration will take time, resources, and planning. There will be meeting after meeting, and a huge amount of information gathered and utilized. By working together in your organization, you can make these top 5 concerns, and all the others not mentioned here, have less impact on the project, and have a higher chance of a successful deployment.