The business case for making the transition from IPv4 to IPv6
While the transition to IPv6 will be a long process, those paying close attention to the space may have noticed an accelerating pace of adoption in 2026, with some major players posting new updates. For instance, AWS IAM Identity Center now supports IPv6 after previously building support for AWS Lambda and Amazon ECS. Cisco recently published a proof of concept for how government agencies could maintain connectivity to the IPv4 world while operating on an IPv6-only basis. These kinds of changes, while incremental, are aimed at planning beyond the current dual-stack world, and moving fully to IPv6.
To help security teams think about the case for investing in the transition to IPv6, we’re publishing a three-part series on The Switch To Six. If you missed the previous two installments, we’ve linked to Part I and to Part II for easy access.
In this post, Part III, we will discuss the direct business case for making the switch to IPv6 sooner rather than later, the technical and security benefits that decision can have in the short and long term, and address some of the most common objections to the question “why now?”
The IPv4 Scarcity Tax
One of the strongest and easiest arguments to make regarding the switch to IPv6 is about address space. IPv6’s original purpose was to resolve the address exhaustion problem with IPv4.
While IPv4 prices decreased in 2025, Hilco Global noted that price declines were not tied to decreased demand, but rather an increase in available supply from sellers. Hilco Global (operating as IPv4.Global) is a subsidiary of ORIX Corporation and the world’s largest IPv4 address marketplace, having facilitated close to $1 billion in transactions. This market change cannot last forever, as the IPv4 space has been fully allocated and blocks are just being subdivided further and further. By contrast, IPv6 is so abundant and inexpensive that provisioning a /48 block is outright free with some vendors.
The average cost per IPv4 address was $26.81 in the period from January 1, 2025 to February 13, 2026, according to data from Hilco Global. Per-address pricing for IPv6 is nearly impossible to find—the abundant supply makes a secondary resale market unnecessary, and that near-nonexistence alone is a powerful illustration of the economic gulf between the two protocols.
To put the scale difference in tangible terms: a free /48 IPv6 netblock contains roughly 1.2 septillion addresses. The closest comparable IPv4 transaction in the Hilco Global data was a /23 purchased on October 7, 2025, at $26.75 per address—but that block contained just 512 addresses. Imagine buying a single parking space versus being handed a lot the size of a continent, for free. That’s the ratio we’re talking about.
You may say to yourself: “So what? I can afford that price for IPv4, and there’s no guarantee that prices will go up again.” That’s true. However, that outright cost ignores the root of the eventual end case where the infrastructure of IPv4 is treated like 4G cellular infrastructure, or even how we have outright decommissioned 3G. Dual-stack has served as a way to extend the transition time and reduced both costs and pain in the short term, but the hidden costs of continuing to maintain IPv4 as more of the world moves to IPv6 add up in ways that don’t appear on an address-price chart—in NAT complexity, in operational overhead, and in the growing brittleness of workarounds stacked atop workarounds.
As Cisco stated in its 2025 blog series on IPv6, we ran out of new public IPv4 addresses in the mid-2010s, and we are still feeling the consequences: prices have skyrocketed on secondary markets, ISPs have had to increasingly deploy Carrier Grade NAT, and enterprises have had to constantly re-address their networks to squeeze every last bit out of each subnet.
On the regulatory front, Memorandum M-21-07 called for at least 80 percent of IP-enabled assets on federal networks to operate in IPv6-only environments by September 30, 2025. Federal agencies have made substantial progress toward that goal, and the strategies and architectures they’ve developed offer useful lessons for private enterprises. As ARIN noted in its analysis of the business case for IPv6-only, these federal efforts demonstrate that IPv6-only operation is not theoretical—it’s being operationalized today. Both the ambition of the mandate and the continued momentum behind it reinforce that the direction of travel is clear, even if the timeline is longer than originally hoped.
The Security Case: Why Your Security Team Should Care Most
Because this series is aimed at security teams, the security case for IPv6 transition deserves direct and prominent attention—not as a footnote to operational benefits, but as a standalone benefit.
The core security problem with the current dual-stack status quo is that attacks thought solved on IPv4 can be dangerously missed on IPv6. Modern devices are configured to prefer IPv6 by default, which means that in a dual-stack environment, devices may silently operate over IPv6 even when administrators believe the network is IPv4-only. This can enable man-in-the-middle attacks via rogue Router Advertisements, neighbor discovery protocol (NDP) spoofing, and generic shadow IT problems where devices expose themselves on a protocol stack that isn’t being monitored. Cisco has stressed this point explicitly, noting that security teams should be involved from the start of any IPv6 transition, precisely because dual-stack environments create gaps that attackers can exploit.
These aren’t theoretical risks. As we have discussed in a previous blog, an Advanced Persistent Threat (APT) group recently leveraged IPv6’s Stateless Address Autoconfiguration (SLAAC) to covertly infiltrate a targeted network, spoofing IPv6 addresses to redirect legitimate software downloads toward malware distribution. The attack succeeded precisely because the targeted organization’s monitoring tools did not adequately cover IPv6 traffic—a blind spot that exists in the majority of enterprises today.
Academic research confirms the breadth of the problem: a 2023 analysis published in the MDPI journal Computers found that NDP attacks on public IPv6 networks can enable address spoofing, denial-of-service, and man-in-the-middle attacks, and that the theoretical countermeasure—the Secure Neighbor Discovery (SEND) protocol—has not been widely deployed due to its complexity and cost.
The Teredo vulnerability we discussed in Part II is another example. In a dual-stack environment, Teredo tunneling can create IPv6 connectivity through IPv4 NAT devices without the administrator’s knowledge, effectively punching holes in the firewall. Moving primarily to IPv6 eliminates these hybrid-state vulnerabilities and gives security teams a single, coherent protocol to monitor, harden, and defend. The choice isn’t between IPv4’s familiarity and IPv6’s uncertainty—it’s between a shrinking protocol with growing blind spots and a modern protocol that your infrastructure is already silently running.
Building the Business Case: Short-Term and Long-Term Benefits
Besides the outright cost advantage of IPv6 in the long term and the security imperative outlined above, the case for switching now includes reducing the challenges of managing a dual-stack infrastructure and alleviating decades of built-up technical debt due to NAT workarounds. Both of these benefits don’t just help the security team—they reduce costs and complexity for the broader organization.
Ending the Dual-Stack Tax
The most direct operational benefit from moving primarily to IPv6 is reducing the need to manage a dual-stack network environment. Every dual-stack network is, in effect, two networks: two sets of firewall rules to maintain, two address schemes to plan around, two sets of routing policies to troubleshoot. When something breaks in the interaction between the two, the debugging complexity doesn’t just double—it compounds, because the failure modes of the interaction between IPv4 and IPv6 are their own category of problem. Cisco’s own enterprise network team experienced this firsthand when they converted Building 23 in San Jose to IPv6-only, serving over 500 employees. The project explicitly cited avoiding the maintenance of two protocol stacks and reduced OPEX as primary advantages of the transition.
Consider what dual-stack complexity looks like in practice. In containerized environments like Kubernetes, dual-stack configuration requires careful coordination across the CNI plugin, kube-proxy, and service definitions; a misconfiguration in any one layer can cause intermittent connectivity failures that are notoriously difficult to diagnose. In VPN environments, administrators routinely struggle with IPv6 traffic failing even when IPv4 works perfectly, because firewall rules, address delegation, and routing tables must be independently configured for both protocol families. These aren’t edge cases—they are the daily reality of running two parallel network stacks.
Relieving the NAT Debt
Alleviating the technical debt buildup in supporting dual-stack IPv4 and IPv6 is another major argument for prioritizing the shift. The hidden costs of NAT are well-documented by the networking community. ARIN’s analysis of the business case for IPv6-only enterprise described NAT used to handle overlapping private IPv4 prefixes as creating “architectural brittleness”—a bargain where getting the network running today comes at a future cost of network design flexibility. Their analysis further noted that the prospect of enterprise-wide renumbering is so daunting that some network engineers have been known to change jobs rather than face it.
Cisco has echoed this in its own transition guidance, noting that using NAT obfuscates IP addresses within the enterprise network, making Access Control List management far more complex and inhibiting security because hundreds of devices sharing the same IPv4 address makes it difficult to apply security policies accurately or quarantine rogue devices without affecting all the other devices identified with that same IP address.
A peer-reviewed paper published in Scientific Research Publishing (SCIRP) on IPv6 transitions found that IPv6 deployment enables 15–30% faster page loads and 40% more efficient video streaming, while also reducing security vulnerabilities by 40–62% through mandatory IPsec implementation. These are measurable gains that translate directly into operational savings.
Moving IPv6-first also means less dependency on workarounds for services that are IPv6-only, and it stops the debt from growing further. The old saying about planting a tree applies well here: the best time was 20 years ago, but the second best time is now. The amount of engineering time spent maintaining dual-stack compatibility—time that could be spent on more productive work—only increases the longer the transition is delayed.
First-Mover Advantage
Keeping pace with others, or even being a first mover, is also a compelling reason to act now. The federal government’s push has ripple effects downstream to federal contractors. According to Google’s IPv6 statistics, global IPv6 availability reached approximately 45–49% of Google’s user base as of late 2025. According to Cisco’s 2025 analysis, the United States was at 53%, while France, Germany, and India were at 78%, 76%, and 72%, respectively. As more markets operate primarily on IPv6, adopting it preemptively positions proactive companies to reach those markets without friction.
Why the Common Objections Don’t Hold Up
“Our Current Setup Works Fine”
This is true in the same way that COBOL still runs core banking systems at major financial institutions—and the parallel is more instructive than it first appears. COBOL doesn’t just cost more to maintain; it poses existential risk when key personnel leave. According to BizTech Magazine, 71% of IT leaders say their mainframe teams are understaffed, and 54% say they are underfunded—even though COBOL supports more than 80% of in-person credit card sales and 95% of ATM transactions. Pragmatic Coders reports that 60% of organizations using COBOL say that finding skilled developers is their biggest challenge, with the average COBOL programmer now 55 years old and 10% of the workforce retiring annually. When the Netherlands’ Social Insurance Bank faced severe issues with its outdated COBOL systems, it had to bring back retired experts because the critical knowledge to maintain and improve the systems had largely retired with them.
IPv4 is walking the same path. The pool of engineers who deeply understand complex NAT configurations, carrier-grade NAT edge cases, and the interaction between legacy IPv4 workarounds is not growing. Every year spent on IPv4 adds to a growing layer of technical debt: more complex NAT configurations, more workarounds, more brittle systems that fewer people fully understand. The cost of maintaining this infrastructure doesn’t stay flat—it accelerates as dual-stack environments grow more tangled and as the pool of engineers comfortable troubleshooting legacy configurations shrinks. There is a growing risk of crucial institutional knowledge walking out the door when your most experienced network engineer retires.
“It’s Too Expensive and Complex”
The complexity of an IPv6 transition is a one-time learning curve. The complexity of indefinitely extending IPv4’s lifespan through workarounds is permanent and compounding. Comcast, one of the largest telecoms, reported that the anticipated difficulty of their IPv6 deployment was worse than the reality. Today, less than 5% of cable modems across their network rely on IPv4, over 70% of broadband customers are actively provisioned with IPv6, and all of Comcast’s products and services have either completed or begun IPv6 preparations. Cisco completed its own transition of Building 23 to IPv6-only in just three months—a building serving over 500 employees with at least two devices per person and 120+ access points.
“Our Customers Don’t Need It”
This argument treats IPv6 adoption as something you can opt into on your own timeline, and the history of technology transitions shows that assumption is almost always wrong. When standards shift, the window between “optional” and “urgent” closes faster than anyone expects. Organizations that wait for the forcing function end up paying premiums to rush the transition and suffer the competitive disadvantage of being the last vendor or provider to support what the rest of the market already does. According to Wikipedia’s compilation of IPv6 deployment data, Tunisia went from 0% to 20% IPv6 adoption within a single year of its official launch, driven by the recognition that IPv6 is a prerequisite for 5G deployment. Markets can move faster than your migration plan.
“We’ll Wait”
Waiting is itself a decision—one with compounding costs. Every year of delay adds another layer of NAT complexity, another year of dual-stack maintenance overhead, another cohort of experienced engineers who retire without transferring their knowledge of your specific legacy configurations.
The question isn’t whether you’ll eventually need IPv6. It’s whether you’ll adopt it on your terms or someone else’s.
