IPv6 adoption is slowing because IPv4 still masks the cost

At a glance

What this is: This is an analysis of why IPv6 adoption is still uneven in 2025, despite IPv4 exhaustion and the protocol’s larger address space.

Why it matters: It matters to identity and security teams because IP-layer transition work changes how access is routed, monitored, and governed across services, devices, and network boundaries.

By the numbers:

• 2025, f early 2025, global IPv6 adoption stands at slightly over 43%, based on IPv6 traffic to Google.
• The United States is only slightly above 50% IPv6 adoption, while France, Germany, and India have much higher adoption rates at 80%, 75% and 74% respectively.
• There are roughly 1.2 billion websites with 194 million actively maintained.

👉 Read DigiCert's analysis of IPv6 adoption in 2025

Context

IPv6 adoption is the slow transition from a 32-bit address model to a 128-bit one that can scale beyond the exhaustion of IPv4. The article’s core point is that the migration is technically necessary, but operationally delayed by the fact that IPv4 still works well enough through NAT, CIDR, and address recycling to reduce urgency.

For identity and access teams, that delay matters because network protocol choices still shape reachability, logging, policy enforcement, and segmentation. In mixed environments, dual-stack operation creates extra administrative load, especially where DNS, routing, and monitoring must support both protocols without weakening control.

The article also shows that transition speed varies sharply by market, which is typical for infrastructure change driven by ISP support, hardware refresh cycles, and operational budgets. That makes IPv6 adoption less a pure standards problem and more a governance and lifecycle problem.

Key questions

Q: How should organisations plan an IPv6 migration without disrupting existing services?

A: Start with a dependency inventory of DNS, routing, firewalls, monitoring, and externally facing services. Then roll out dual-stack in controlled phases, using network refresh cycles and provider readiness as constraints. The goal is not to switch everything at once, but to make sure visibility and policy enforcement remain equivalent in both protocol families.

Q: Why do IPv4 workarounds slow down IPv6 adoption?

A: Because NAT, private ranges, and address recycling make IPv4 appear operationally adequate even after its exhaustion. Those mechanisms reduce urgency, but they also preserve complexity and hide the cost of staying on an ageing protocol. The longer they remain in place, the harder it becomes to justify the transition on business grounds.

Q: What breaks when IPv6 is added without DNS and monitoring updates?

A: Teams lose consistent visibility. IPv6 uses different addressing conventions, and if DNS, logging, or troubleshooting tools are not aligned, operators can see a working network but still miss resolution errors, policy mismatches, or fragmented telemetry. Migration then fails as an operations problem, not a connectivity problem.

Q: Which frameworks help teams govern IPv6 transition work?

A: The most relevant lenses are NIST Cybersecurity Framework 2.0 for governance and control alignment, and Zero Trust Architecture for consistent policy across mixed network paths. Treat IPv6 adoption as part of broader infrastructure governance so that routing, access, and observability stay controlled during the transition.

Technical breakdown

Why IPv4 exhaustion still does not force migration

IPv4 exhaustion should have ended the transition debate, but it did not because several life-extending mechanisms delayed the crisis. NAT allows many internal devices to share one public address, while CIDR and VLSM make addressing more efficient. Private ranges also keep internal traffic off the public internet. These controls reduce immediate pressure, but they also preserve technical debt by making IPv4 feel serviceable long after its design limits were reached.

Practical implication: treat IPv4 extensions as temporary debt and inventory where they still mask migration risk.

Dual-stack networking and DNS complexity

Dual-stack means an environment runs IPv4 and IPv6 at the same time. That sounds simple, but it doubles the places where routing, resolution, and policy can fail. IPv6 uses longer hexadecimal addresses and different conventions, which increases manual configuration error, and DNS stacks often still favour IPv4 by default. The result is not just compatibility work, but a governance challenge because visibility, troubleshooting, and access policy must stay consistent across both paths.

Practical implication: test DNS, routing, and logging parity before expanding IPv6 exposure.

ISP support and hardware refresh cycles shape adoption

IPv6 adoption is constrained less by the protocol than by the economics of deployment. ISPs control much of the network path, so hesitant or partial support slows customer uptake. At the enterprise edge, routers and switches usually last longer than endpoints, so IPv6 becomes a capital planning issue rather than a simple configuration change. Where provider support is uneven, organisations inherit fragmented connectivity and inconsistent operational data.

Practical implication: align network refresh plans and ISP requirements with the IPv6 rollout window.

NHI Mgmt Group analysis

IPv6 migration is an identity-adjacent governance problem, not just a network upgrade. Once addressing, routing, and DNS operate in dual-stack mode, security teams inherit two parallel control planes that must be monitored, logged, and governed consistently. That creates policy drift risk across access paths, asset inventories, and troubleshooting workflows. Practitioners should treat protocol transition as part of access governance, not a separate network project.

Dual-stack environments create control ambiguity that looks like resilience but behaves like fragmentation. IPv4 workarounds such as NAT reduce immediate pressure, yet they also obscure the real state of connectivity and make policy enforcement harder to reason about. That matters for IAM and security teams because visibility gaps in network pathing can become visibility gaps in authentication, segmentation, and incident response. The practical conclusion is that partial migration must be governed as a bounded exception, not a steady state.

IPv6 adoption follows infrastructure lifecycle, not standards enthusiasm. ISPs, routers, and DNS platforms all move on different replacement cycles, so adoption is constrained by refresh timing more than protocol maturity. This is why the article’s 43% global adoption figure is more revealing than the technical benefits list: the limiting factor is operational readiness. Teams should map IPv6 rollout to asset life, supplier support, and monitoring coverage, not to policy intent alone.

DNS becomes a hidden control point during protocol transition. The article’s discussion of longer address notation and compatibility issues shows that name resolution is where many IPv6 failures will surface first. If DNS tooling, operator training, and resolution policy are not updated together, organisations will see configuration error rather than clean protocol migration. Practitioners should treat DNS readiness as the migration gate, because that is where dual-stack complexity becomes operationally visible.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That combination of confidence, delay, and weak practice is why the NHI Lifecycle Management Guide matters when transition work turns into lifecycle control.

What this signals

IPv6 adoption should be managed as a transition programme with observability debt, not as a one-time enablement task. The moment dual-stack becomes permanent by default, organisations lose the clean boundary between temporary compatibility and actual architecture. Security and platform teams should define retirement criteria for IPv4 dependencies now, then anchor them to refresh cycles, ISP readiness, and DNS validation.

Addressing change becomes a governance issue when it changes how identities, services, and policy are reached. IPv6 is not an IAM control by itself, but it affects the reliability of the control plane that IAM depends on. That is why teams should pair network transition planning with access path monitoring and control verification, especially where service exposure depends on name resolution and segmentation.

The practical lesson is that infrastructure transitions fail when they outlive their exception status. As long as NAT and dual-stack are treated as permanent shortcuts, the organisation accumulates hidden complexity. Map the migration to lifecycle management discipline by using the NHI Lifecycle Management Guide to think in terms of inventory, ownership, and retirement rather than ad hoc enablement.

For practitioners

• Inventory dual-stack dependencies across critical services Map every application, DNS zone, load balancer, firewall policy, and monitoring path that must behave correctly in both IPv4 and IPv6. Prioritise systems where NAT currently hides complexity, because those are the places where migration risk is most likely to stay invisible until cutover.
• Tie IPv6 rollout to network refresh cycles Build the migration plan around router, switch, and ISP support windows rather than setting a protocol-only deadline. That lets you use existing hardware lifecycles to reduce spend while still avoiding indefinite dual-stack sprawl.
• Validate DNS and logging parity before expansion Test address resolution, access logs, alerting, and incident triage in both protocol families before broadening IPv6 exposure. If one stack has weaker observability, your control coverage is incomplete even if connectivity works.
• Define where NAT is acceptable and where it is technical debt Document which environments may continue using IPv4 translation and which services must move to native IPv6. This prevents temporary workaround patterns from becoming permanent architecture by default.

Key takeaways

• IPv6 adoption remains constrained less by protocol design than by the operational comfort of IPv4 workarounds and delayed infrastructure refresh cycles.
• Dual-stack environments increase governance complexity because DNS, routing, visibility, and troubleshooting all have to work cleanly across two protocol families.
• The practical path forward is to treat IPv6 migration as a managed lifecycle programme with defined retirement points for IPv4 dependencies.

Key terms

• IPv6: IPv6 is the current internet protocol designed to replace IPv4 by providing a much larger address space. It uses 128-bit addresses, which makes large-scale growth possible without the address exhaustion constraints that now affect legacy IPv4 networks.
• Dual-stack: Dual-stack is a deployment model where devices and services support both IPv4 and IPv6 at the same time. It is often used during migration, but it also increases operational complexity because policy, monitoring, DNS, and routing must remain consistent across both protocol families.
• Network Address Translation: Network Address Translation is a method that lets many internal devices share one public IPv4 address. It extends the life of IPv4, but it can also hide underlying addressing pressure and make migration to native IPv6 easier to delay than to complete.
• DNS resolution: DNS resolution is the process of translating human-readable domain names into IP addresses that networks can route to. During IPv6 migration, DNS becomes a critical control point because address formatting, lookup behavior, and observability all have to remain reliable across both protocol versions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: The State of IPv6 Adoption in 2025: Progress, Pitfalls, and Pathways Forward. Read the original.