A data-driven overview of the rapidly accelerating transition to IPv6
Rather quietly, and with little fanfare, IPv6 hit a major milestone last year. In early 2025, more than half of all internet traffic in the US was running in the IPv6 space, according to data published by Google. The number now sits at 56.77% and continues to climb. Other data sources put the share of IPv6 traffic in the USA slightly higher: 60.73% according to Facebook and 67.86% according to Cisco.
Whatever the exact figure may be, the overarching trend is clear: IPv6 adoption is taking off rapidly, both in the United States and around the world. In January 2020, the share of internet traffic on IPv6 was about 30%. Today, just six years later, it’s right around the 50% mark, which is an increase of 60% from the January 2020 benchmark.
To help security teams get ready for the transition to IPv6, we’re publishing a three-part series on The Switch To Six. If you missed it, you can find Part I here. In this post, Part II, we will discuss how widespread IPv6 adoption is now due to the proliferation of devices that default to it, and examine how that defaulting can also lead to the challenge of shadow IPv6.
The Forces Driving IPv6 Adoption
On average, 48.8% of all internet traffic globally runs on IPv6, with just over 51% still on IPv4. This is set to change in early 2026, likely in March or April, as IPv6 finally overtakes IPv4 as the majority shareholder of global internet traffic.
While IPv6 adoption started slow—the share of internet traffic on IPv6 didn’t hit 1% until 2013—the transition has started gaining steam in recent years. There are several major factors driving the adoption of IPv6, covered in more detail below.
Mass Adoption Through Telcos
Many of the world’s largest telecommunications providers are moving rapidly towards full adoption of IPv6. For instance, data from Akamai shows that 88.4% of T-Mobile’s network is on IPv6, while the figure is 74% for AT&T and 74.8% for Verizon.
With massive enterprises like these implementing IPv6 at scale, the share of internet traffic on IPv6 is given a huge push. End users who connect to these networks (including mobile networks) are running on IPv6 and don’t even know it.
IoT and Scaling
Many devices across the internet now default to IPv6, for reasons ranging from simple capacity constraints on IPv4 for things like IoT devices to simplified infrastructural management for cloud platforms and services.
The explosive proliferation of IoT devices—going from 15.41 billion in 2015 to 75.44 billion in 2025—has encouraged IoT devices to default to IPv6, as it simplifies setup and complexity for end users, rather than having to manage NAT rules or port forwarding. All the devices just have their own IPv6 address. Given that the entire IPv4 space only has around 4.3 billion unique addresses, IoT devices alone would take up more than 17x the entire available space if they all operated on a solely IPv4 addressing model. Instead, most IoT devices rely on NAT workarounds. While the majority of these devices claim to support IPv6 and can handle IPv6 traffic, only 8.6% of tested IoT devices continued to function in an IPv6-only network.
There is a clear disconnect here, where most IoT devices clearly do still depend upon IPv4 for some function but primarily operate in IPv6. This disconnect is particularly interesting given that IPv6 incorporates stateless address autoconfiguration (SLAAC), which allows devices to configure their own addresses without manual work or a centralized DHCP server, making deployment at scale easier. Yet, despite this technical advantage designed specifically for the kind of plug-and-play simplicity IoT devices require, the reality is that most devices still maintain some dependency on IPv4 infrastructure, even while actively using IPv6.
This shouldn’t be read as a failure of IPv6, but rather as an indication of where we are in the adoption curve. The direction of travel is clear: new IoT devices are being designed with IPv6 as the primary addressing scheme, with the expectation that networks will support it. The IoT sector’s partial IPv6 implementation mirrors the broader pattern we see across the internet: organizations and manufacturers are moving toward IPv6, but they’re doing so incrementally, maintaining IPv4 compatibility as a safety net during the transition period.
Cloud Architecture
This pattern extends beyond IoT devices to more structural systems as well. Major service providers are actively rolling out IPv6 support across their platforms.
In November 2025, Okta began enabling IPv6 support on their Content Delivery Network (CDN) for Commercial and FedRAMP Moderate customers—a rollout they explicitly framed as preparation “for the growing number of devices and networks that rely on IPv6.” AWS had a wave of IPv6 expansion in September 2025, extending support across EC2—a move they explicitly positioned as addressing IPv4 limitations and preparing for growing traffic demands. And Microsoft Azure announced general availability for inbound IPv6 support for Azure App Service across all public Azure regions.
Technologies like Happy Eyeballs mean that most modern applications and network stacks can now prefer IPv6 by default when both protocols are available, while seamlessly falling back to IPv4 when not.
IPv4 Scarcity & The IPv6 Tipping Point
The exhaustion of IPv4 addresses has created a scarcity crisis that’s fundamentally reshaping internet infrastructure. As IPv4 addresses become increasingly expensive and difficult to obtain, organizations face a stark choice: continue relying on workarounds like NAT, or transition to IPv6’s virtually unlimited address space.
We believe we are fast approaching the tipping point where IPv6 will reach critical mass and it won’t make sense to deploy on IPv4 anymore. This creates a network effect: as more organizations move to IPv6, it will force those who are slower to switch to follow suit in order to maintain interconnectivity and interoperability with the wider tech ecosystem. Organizations that delay risk integration challenges with cloud computing platforms, SaaS applications, and other modern infrastructure that increasingly assumes IPv6 support.
As these technologies mature and catch up, the transition will only become easier, cheaper, and less risky for enterprises. At some point in the not-so-distant future, deploying on IPv4 will feel like buying a DVD player rather than using a streaming service to watch movies—sure, you can still do it and it will still work, but you wouldn’t do it without a compelling reason.
Getting Prepared For IPv6 Adoption
While the benefits of the IPv6 transition across devices and services are substantial, security teams still need to be able to monitor IPv6 traffic and protect devices running on IPv6. When vendors upgrade their systems, or when doing your own migration, it is vital to keep track of what is turned on and where, because the scale of IPv6 is also its biggest challenge for security teams. Many traditional security tools cannot effectively function in IPv6 the way they can in IPv4. While IPv4 can be brute-force scanned to find unnoticed assets and protect them, doing so in IPv6 is computationally infeasible due to how much larger the space is, even though most of it is empty.
Not only that, but IPv6 can also represent a more active risk, including ways to circumvent controls imposed on an otherwise protected network through IPv6, sometimes bypassing NAT rules entirely. This can happen with Teredo tunneling, allowing devices that would otherwise be blocked from forming outbound connections on non-standard ports to tunnel unauthorized IPv6 traffic through port 3544, or with device vulnerabilities specific to IPv6, such as CVE-2025-26686, allowing RCE on default Windows configurations.
These aren’t theoretical risks, either. Researchers at Carnegie Mellon demonstrated in 2009 how iptables rules successfully blocked Google over IPv4 but were completely bypassed when Teredo automatically encapsulated IPv6 traffic through the firewall via UDP. Teredo is a Microsoft product designed to provide full IPv6 connectivity to IPv6-capable hosts on the IPv4 internet that lack native IPv6 network connections. More recently, due to a lack of mirroring between iptables and ip6tables, TrustWave was able to circumvent a firewall to access a Redis database during a pentest.
None of this is meant to imply that adopting IPv6 creates unnecessary risk. Rather, the point is to the transition must be properly managed from a security standpoint– and, currently, most tools do not provide adequate coverage for IPv6 networks.
This is one of the key ways in which SixMap differentiates itself in a crowded market. All of SixMap’s capabilities are compatible with both IPv4 and IPv6 networks and hosts. By automatically discovering and mapping all in-use IPv6 by your organization, with no noticeable impact to system operations or heavy network usage, SixMap helps security teams give IPv6 the same level of protection as IPv4. Get in touch with the SixMap team to learn more.
