Why IPv6 Matters for ISPs (and How to Start)

IPv6 has a reputation as a “we'll get to it eventually” project — something modern and worthy that can safely wait behind more urgent work. For a growing ISP, that framing is backwards. IPv6 is one of the most practical levers available for reducing cost, complexity and support load, and the longer it is deferred, the more painful and expensive the eventual migration becomes. It is not a research exercise; it is operational hygiene with a direct line to your margins.

The driver is simple arithmetic. The pool of fresh public IPv4 addresses ran dry years ago, so every new customer you connect on IPv4 has to be served from address space that is scarce, increasingly expensive to acquire, and operationally awkward to stretch. The standard way to stretch it — Carrier-Grade NAT — works, but it is a tax: a tax in hardware, in logging, in broken applications, and in support tickets. IPv6 is the way out of paying that tax forever.

The core reason: addresses

IPv4 offers a few billion addresses, which sounded limitless in the 1980s and is laughably small for a planet of connected devices. To keep growing on IPv4 you have two options, and both cost. You can buy address space on a transfer market where prices have climbed for years, or you can share a small pool of public addresses across many customers using CGNAT. IPv6's address space, by contrast, is so large that scarcity simply is not a design concern — every customer, and indeed every device, can hold a real, globally routable address again. That removes an entire category of scaling pain rather than just postponing it.

What it actually buys you

• Less CGNAT, less cost: any traffic that can run over IPv6 bypasses your NAT entirely. That eases port-allocation pressure on the CGNAT platform, shrinks the logging burden, and reduces how much expensive shared-IPv4 capacity you must buy as you grow.
• Clean, hierarchical addressing: instead of carving scarce IPv4 into ever-smaller slivers and tracking the fragments, you can design a logical address plan with consistent prefix sizes and room to spare — once, properly.
• Fewer broken-app tickets: end-to-end addressing avoids many of the quirks CGNAT introduces, where shared public IPs trip rate limits, break inbound connections, get a customer blocklisted for a neighbour's behaviour, or confuse geolocation. Those are real, recurring support costs.
• Future-readiness: a large and growing share of the internet's biggest destinations are IPv6-capable, so a meaningful fraction of your traffic can move to IPv6 the moment you enable it. Being ready is increasingly table stakes, not a differentiator.

IPv4-plus-CGNAT versus IPv6

Dual-stack: the practical, low-risk path

You do not flip a switch from IPv4 to IPv6 overnight, and you should not try. The standard, low-risk approach is dual-stack: run both protocols simultaneously on the same network. Customers automatically use IPv6 wherever the far end supports it, and fall back to IPv4 — often CGNAT'd — where it does not. Nobody has to choose; the devices and operating systems already prefer IPv6 when it is available. Over time, as more of the internet becomes reachable over IPv6, a growing share of your traffic naturally shifts off the CGNAT platform and your IPv4 pressure eases on its own, without forcing anything or risking a hard cutover.

The honest trade-off of dual-stack is that you are running two address families at once, which is more to monitor, troubleshoot and secure than a single stack would be. That is a real but modest cost, and it is the price of a safe transition. The alternative — an abrupt migration — carries far more risk, and the do-nothing option simply lets the IPv4 and CGNAT tax compound. Dual-stack is the sensible middle, which is exactly why it became the default industry approach.

One operational detail catches teams off guard: the customer's experience under dual-stack depends on something called happy-eyeballs behaviour, where the device races an IPv6 and an IPv4 connection and uses whichever answers first. That is forgiving — a broken IPv6 path quietly falls back to IPv4 instead of failing outright — but it also means a half-broken IPv6 deployment can hide. Customers stay happy on IPv4 fallback while your shiny new IPv6 path silently does nothing, delivering none of the CGNAT relief you deployed it for. The lesson is that you cannot trust “no complaints” as proof IPv6 works; you have to measure adoption directly, which is why that step is non-negotiable rather than a nice-to-have.

Security and monitoring must cover both families

A point that is easy to overlook in the rush to turn IPv6 up: every firewall rule, access-control policy, logging path and monitoring check you built for IPv4 now needs an IPv6 equivalent. A device reachable over IPv6 but only firewalled on IPv4 is exposed, full stop. Treat the second address family as a first-class citizen in your security posture from day one rather than bolting it on later, because an unwatched, unfiltered IPv6 path is worse than no IPv6 at all — it is an open door you forgot you installed.

How to start

• Get your allocation. Request IPv6 space from your Regional Internet Registry. Unlike IPv4, it is plentiful and inexpensive, and you will receive a block large enough to plan generously.
• Plan the addressing once, cleanly. Decide a consistent prefix size to delegate to each subscriber and a hierarchy that mirrors your network's structure — region, POP, access node. Because address space is abundant, design for clarity and aggregation rather than conservation. This is the step most worth doing carefully, because re-numbering later is painful.
• Enable it from the core outward. Turn IPv6 up in the core first, then the edge, then the access layer, and finally hand IPv6 to customers through your provisioning. Working inward-out keeps each stage testable.
• Provision it through your existing systems. Delegating prefixes to subscribers should flow through the same provisioning path that already manages their service, so IPv6 is just another attribute of the customer rather than a parallel manual process. ISP Digital's provisioning and billing ties subscriber records to what the network hands them, so adding IPv6 fits the existing customer lifecycle.
• Measure adoption. Track the share of traffic riding IPv6 as your key success signal. Watching that fraction climb is direct, satisfying proof that the deployment is working and that CGNAT load is genuinely shrinking.

Common mistakes

A few errors recur. Treating IPv6 as indefinitely deferrable until address costs and CGNAT pain force a rushed, expensive scramble. Designing the address plan carelessly — inconsistent prefix sizes, no hierarchy — and then needing to renumber, which is the one genuinely hard thing to undo. Enabling IPv6 in the core but never actually delegating it to customers, so all the work delivers none of the CGNAT relief. Forgetting that security policy and monitoring must cover both families, leaving an IPv6 path that is live but unwatched. And declaring victory at turn-up without measuring adoption, so nobody notices that customers are not actually getting working IPv6.

The takeaway

IPv6 is not about being modern for its own sake — it is a concrete, financial answer to IPv4 scarcity and the downsides of CGNAT. Deploy it dual-stack so the transition is gradual and low-risk, plan the addressing properly the first time so you never have to renumber, enable it from the core outward, and provision and measure it through the systems you already run. Do that and you convert a looming, expensive problem into a quiet, finished piece of infrastructure — one that keeps paying back every time a customer connects without touching your CGNAT platform.