Working with enterprises, I am often confronted with the challenge of justifying the benefits of deploying IPv6 to C-levels and corporate IT decision makers. The status quo is a strong force. If everything is seemingly running well in the network, what is the driver to deviate? If it ain’t broke, don’t fix it, right? (Even if the network team sees impending problems by putting off network evolution.)
The reality is that making the business case for deploying IPv6 can be a challenge. There is seldom a “you can save $40M if you do this” moment that can be used to get the attention of leaders that often look at the world through a financial lens rather than a technical one.
Ed Horley makes numerous business and financial arguments in support of IPv6 deployment in his blog The Problem Isn’t the Price of IPv4, and Scott Hogg, Tom Coffeen, and Ed further bolster the business case on their IPv6 Buzz 97 podcast Selling An IPv6 Project To Your Organization. At the same time, I would like to build off this theme, but from the opposite direction. There are the business benefits of deploying IPv6, and there are also significant financial negatives associated with clinging to IPv4. It pains me to focus on IPv4 in an IPv6 Center of Excellence blog, but the goal is to assist you, the Network Architect, in building your case to corporate decision makers, and ultimately further the advancement of IPv6.
So, let’s dive into the true costs of IPv4.
The actual cost of IPv4
The first obvious cost of IPv4… is the actual cost of IPv4. The RIR’s have depleted their free pools, so getting address space from ARIN (or any other RIR) is not an option. For large service providers, the lack of public IPv4 address space makes the business case fairly straightforward. And they have aggressively deployed IPv6 – with some turning to IPv6-only. However, the general impression is that most small enterprises have sufficient public IPv4 addresses, and have not yet felt the squeeze of RFC 1918 limitations. But is that completely true? Times are changing. In planning for the future of address management, make sure to account for modern networking trends. Most enterprises have adopted or are adopting a hybrid cloud strategy. Ensure that the network team is in sync with the cloud team on addressing needs in AWS, Azure, GCP, or your CSP of choice. The address requirements may be significantly greater than originally thought. Also, does your enterprise utilize containers, or plan on large IoT deployments? These can also be large consumers of IP addresses.
The point being, even some smaller enterprises, after looking at the big picture and future network evolution, may be squeezed for IPv4 addresses – both public and private.
If addresses are procured from the gray market, there is a hard cost to acquire and transfer these assets. And that cost is currently above $50 per IP and rising.
Or another way to look at the price of IPv4 addresses – they are a benefit to those enterprises that have a wealth of addresses to spare. These IPv4 assets could be sold on the public transfer market to other organizations that can justify the need. This is an important opportunity to keep in mind in your business case.
The hidden costs of managing NAT
In addition to the actual cost of IPv4, there are significant hidden costs. The most obvious is the cost of Network Address Translation (NAT) and address overlaps. Personally, I’ve spent thousands of hours in my career dealing with NAT-related issues. How much time do you spend on this activity each year? Consider the cost of renumbering after M&A activity while attempting to splice together two networks that both use 10.0.0.0/8. Or the cost of troubleshooting application reachability across the WAN given multiple firewalls implementing NAT. Root cause analysis is complicated by sifting through logs where addresses may or may not be the same addresses you were told were the source and destination IP’s having connectivity problems. All of this consumes valuable engineering resources, time, and corporate productivity for critical business functions. There may be additional hidden costs because we often do not consistently account for the effort a full-time employee is spending working on NAT or renumbering issues. (Instead of, say, spending time working on network automation, or zero trust, or other productive new innovations.)
The added complexity of NAT in security policy also increases the risk of misconfiguration. Security can be jeopardized when multiple network and security engineers work on the same firewall sorting through convoluted layers of policy and translation. Consider the risks of a forensics specialist trying to track down a malware infection incident log for a device using 10.3.6.8, and that address is used in multiple different networks simultaneously. Simplicity can be a virtue, while IPv4/NAT/RFC1918 typically is anything but simple. And today, security mistakes can have large material costs that may threaten the entire business.
It can be difficult to articulate and quantify these soft costs to corporate leaders, but we can attempt to frame the argument in human resources costs. If you spend 200 hours per year troubleshooting, think of all the others engaged in the troubleshooting effort with you – project managers, other network engineers, application developers, firewall administrators, etc. Employee time is often not tracked to this level, but it certainly adds up. Not to mention lost productivity in the broader company for employees waiting for the network to “just work.”
Equipment CAPEX and OPEX
One expense that can be more easily pinned down is the cost of network devices. Network Address Translation takes memory, CPU cycles, and silicon to work. Consider the cost of NAT and/or dual stack on routers, ADCs, firewalls, and all other network devices in your environment. It is well known that TCAM is expensive, and deploying larger and more expensive routers to deal with IPv4 and NAT adds cost – not just up front but over the lifetime of the devices given annual subscriptions and maintenance. Firewalls are also expensive bit-movers (or blockers). When spec’ing out the proper firewall model, there are tiers to consider with respect to NAT table and security policy size. IPv4, and the NAT that commonly accompanies it, can add significant expense to your firewall, as well as other network devices. This added expense can bolster a business case that may get the attention of corporate leaders.
Other Hard-to-Quantify Costs
Then there are more subtle drivers of costs that are difficult to quantify. For example, how can you put a price on IPv4 being slower than IPv6 in many cases. For companies that rely on e-commerce revenue or customer experience in their app, performance may be measurable in dollars. For other organizations, performance differences are at least worth noting when pitching the IPv6 business case to your CIO.
Finally, can a cost be assigned to procrastination? The transition to IPv6 is ultimately unavoidable. Early adopters are reaping the benefit of moving to IPv6. Standing on the sidelines could eventually prove costly. There will ultimately be a driver for your organization’s IPv6 transition, whether that is customer experience/demand, extranets/partners, IPv4 exhaustion, or possibly even a compliance mandate. For many applications, and in many areas of the Internet, IPv6 represents a majority of traffic. Forward thinking and avoiding technology obsolescence, while often difficult to quantify, can have benefits – especially in wide-ranging projects such as IPv6 implementations that can’t realistically be done with a single “all-hands-on-deck” effort. Executing such a project in a constant, planned, and non-disruptive fashion can save hard and soft costs. Upgrade to IPv6 on your timetable, not someone else’s!
Conclusions
For large service providers, the deployment of IPv6 is a no-brainer – and probably happened years ago. For greenfield network deployments the same could be said. (Why would they go out of their way to deploy only IPv4, or even dual stack?) However, many enterprises still lag in IPv6 adoption. The goal of the forward-thinking Network Architect is to formulate a business case and get buy-in from corporate decision makers to advance IPv6. There are two sides of this coin that can be used to articulate this thesis: the benefits of IPv6, and the cost of IPv4. C-level executives may not know the difference between IPv4 and IPv6 (or AppleTalk for that matter!). Nor should they care. But they want the business to run efficiently and smoothly. And you can enlighten them to the tangible benefits of starting the journey through dual-stack toward the ultimate goal of IPv6-only. This effort can reduce risk and save money. And it can, and should, be done in a controlled and planned manner.
