IPv6 · sequencing brief

Deployment Brief · IPv6 Transition

Turning on IPv6 is easy. Turning off IPv4 is the project.

Most operators have already enabled IPv6 somewhere, announced a prefix, and put a tick in a compliance box. The bill did not move. It did not move because dual-stack hands every subscriber an IPv6 prefix and a public IPv4 address, so you are still buying one address per customer — you are just also carrying v6. This brief is about the order of operations that actually shrinks the pool.

$20–45

per IPv4 address, 2026

what growth costs you

40–60

subscribers per address

once translation is on

engines, one config key

CGNAT · MAP-T · MAP-E · NAT64

data plane

translation beside BNG and QoS

IPv6 is not the deliverable. A smaller IPv4 pool is the deliverable. IPv6 is how you get one.

1 · The bill you are actually paying

Every new subscriber on a one-address-per-customer design needs a public IPv4 address, and those are bought on a transfer market rather than allocated. At current market rates, growth has a per-head price attached before you have installed a single metre of fibre.

Adding 10,000 subscribers	Public IPv4 needed	Address cost at $20–45
One public address per subscriber	10,000	$200,000 – $450,000
Shared behind translation (40–60 subs per address)	~167 – 250	$3,300 – $11,300
Difference	~40–60× fewer	~97% less

Shape, not forecast. Sharing ratio depends on your subscriber behaviour and port-block sizing; the IPv6-only line depends on how much of your traffic still has an IPv4-only destination, which falls every year. Both curves bend the same way for every operator — only the gradient is yours.

2 · Why “we enabled IPv6” did not help

Dual-stack was designed as a transition mechanism, and it is a good one — but it is a transition toward something, not the destination. While a subscriber holds both a v6 prefix and a public v4 address, you are paying for the v4 address. Enabling IPv6 on top of that adds capability and adds cost; it removes nothing.

The uncomfortable version. If you enabled IPv6 three years ago and your public IPv4 pool has not shrunk since, the project has not started yet. That is not a criticism of the work done — the addressing, the DNS, the CPE testing all had to happen. It is a statement about which step comes next.

3 · Four destinations, and the one your CPE can reach

There are four ways to stop giving every subscriber their own public address. They differ mainly in where the required component lives — and the ones that require something inside the subscriber's home are the ones you do not control.

Engine	What it needs	Suits you when
CGNAT stateful, shared v4	Nothing in the home. State at the border.	Mixed or unknown CPE fleet. The pragmatic default.
MAP-T / MAP-E stateless	CPE that implements MAP. Mapping is computed, not stored — no session table to exhaust.	You control the CPE fleet and want no per-flow state at the border.
NAT64 + DNS64 v6-only access	Single-stack v6 access. A small shared v4 pool at the border.	You are ready to run the access network v6-only. The furthest destination.
464XLAT for comparison	A CLAT inside every subscriber's home — the half of the network you do not own.	Rarely, for a fixed network. Common on mobile, where the handset is the CLAT.

All four run as one XDP data plane on the same box as the BNG, QoS and security, selected by a single config key. The mechanism of each is covered in its own brief: CGNAT, MAP-E / MAP-T, NAT64, and the choice between them.

4 · The sequence

This is the part that is usually missing. Each step is independently useful, independently reversible, and shrinks the pool a little further. Nobody should attempt the last one first.

Steps 1–3 buy you nothing financially, and skipping them is how rollouts fail. They are the work that makes the translation step reversible instead of a flag day.

STEP 1

Measure what you already have

Before changing anything, establish the baseline: what share of your traffic is already IPv6, how many public addresses you hold, how many are actually in use, and what your real subscriber-to-address ratio is today. Most operators discover they hold more than they thought and use fewer than they assumed.

Pool: unchangedRisk: none — read only

STEP 2

Enable dual-stack and leave it alone for a while

Turn on IPv6 alongside the existing v4 service and let it run. This is the step most operators have already done. The point of dwelling here is to find the breakage while every subscriber still has a working v4 path to fall back on — because they do, that breakage is invisible to them and cheap to you.

Pool: unchangedWatch: v6 path MTU, firewall rules written v4-only

STEP 3

Delegate a real prefix to every subscriber

A single v6 address per CPE is not enough for the home behind it. Prefix delegation is what makes the subscriber's own network v6-capable, and it is the precondition for ever removing their v4 address. Do this before you need it.

Pool: unchangedWatch: CPE that accepts a prefix but does not hand it on

STEP 4

Put new subscribers behind translation first

This is where the bill starts moving, and the safe way in is growth rather than migration. New connections go behind the translation engine your CPE fleet supports; existing subscribers keep what they have. You stop buying addresses for growth before you attempt to reclaim any.

Pool: stops growingWatch: inbound-reachability complaints, port-forward users

STEP 5

Migrate cohorts and reclaim

Move existing subscribers in cohorts, smallest and least noisy first, and reclaim their addresses as you go. Reclaimed space is either headroom for growth or an asset with a market price attached — and at this point the project has a positive return rather than a cost.

Pool: shrinkingWatch: static-IP business customers — exclude them deliberately

STEP 6

IPv6-only access, translation only at the border

The access network carries v6 alone; the shared v4 pool exists only for traffic whose destination is still v4-only, and that share falls every year without you doing anything. This is the destination, and almost nobody should attempt it before steps 1 to 5 are boring.

Pool: minimalWatch: v6-literal-hostile applications, legacy VPN

5 · What actually breaks, honestly

Subscribers who accept inbound connections

Anyone running a game server, a camera or a port-forward loses a capability they had. This is the complaint that generates calls. Decide the policy before the migration, not during it — a static-v4 tier is a legitimate answer.

CPE that claims support and does not have it

The gap between a datasheet saying IPv6 and a box delegating a prefix correctly is wide. Test the fleet you actually have, by model and firmware, not the fleet the spreadsheet says you have.

Logging and lawful intercept

Sharing an address across subscribers means an address alone no longer identifies a customer. You need port-block records and a reverse lookup that answers with a name rather than a guess, before the first regulatory request arrives.

Your own tooling

Provisioning, monitoring, abuse handling and billing systems that store an IPv4 address as the customer key will need work. This is usually the longest pole and it is entirely internal — start it early because it blocks nothing else.

6 · How you will know it is working

The metric is not “IPv6 enabled”, which is a boolean that tells you nothing after the first day. Watch three numbers instead, and watch them as a trend:

Public addresses in use, not held

The number that has to fall. Holding is capacity; using is cost. If usage is not falling after step 4, the translation is not carrying the subscribers you think it is.

Subscribers per public address

Your real sharing ratio, measured rather than configured. If it is far below the pool sizing you planned, you have port-block sizing to tune before you buy anything.

IPv6 share of actual traffic

Not of subscribers provisioned — of bytes moved. The gap between those two numbers is where dual-stack is quietly preferring v4.

Pool health, per address

Which public IPs are hot, which are near exhaustion, and whether one abusive subscriber is consuming a block. Exhaustion arrives per-address long before it arrives fleet-wide.

A caution about the third number. Provisioning a subscriber for IPv6 and that subscriber moving IPv6 bytes are different facts, and dashboards routinely report the first while implying the second. If your v6 share looks stuck, check whether you are measuring capability or traffic before concluding the rollout has stalled.

Want the arithmetic for your network?

Send us your subscriber count, how many public IPv4 addresses you hold and how many you are using, and what CPE models are in the field. We will tell you which translation engine your fleet can actually run, what the pool could shrink to, and what the hardware needs to be.

Licence is quoted per deployment. Hardware is commodity x86, bought from whoever you normally buy from.

Email sales@bngsoft.com

Sources and assumptions. IPv4 transfer-market pricing of ~US$20–45 per address (2026) per published IPv4 market pricing reports; prices vary by block size, region and registry. Sharing ratios of 40–60 subscribers per public address are typical for residential CGNAT and depend on port-block sizing and subscriber behaviour — measure yours rather than adopting ours. The 10,000-subscriber table is arithmetic on those two ranges, not a quotation. The IPv6-only curve depends on the share of traffic still destined to IPv4-only endpoints, which differs by market and falls over time. Engine mechanisms, RFC references and validation status are covered in the CGNAT, MAP-E/MAP-T, NAT64 and IPv4-continuity briefs.