Moving 60% of traffic to IPv6 does not automatically remove 60% of CGNAT cost. It removes translation work for those packets. Whether that becomes a smaller address pool, fewer appliances or a lower invoice depends on the constraint that was driving the next purchase.
The investment question is therefore specific: after IPv6 deployment, what IPv4 workload remains at the busy hour, and which committed costs can change? An IPv6 traffic percentage is a useful adoption measure. It is insufficient as a capital plan.
Separate bytes, packets, mappings and addresses
A long video stream can carry many bytes over a small number of flows. Moving it to IPv6 may reduce CGN throughput substantially while removing little mapping state. A household can still create many short IPv4 connections for applications, devices and background services.
Packet rate matters independently of bandwidth. So do new mappings per second, concurrent mappings, mapping lifetimes and the distribution of port use between households. Averages hide the customers who need additional headroom during busy periods.
Public address requirements also depend on allocation policy. If each active subscriber retains a reserved port block, fewer packets do not automatically release that reservation. To reduce address demand, the measured workload must support a different block policy or fewer IPv4 allocations, with acceptable exhaustion risk.
| Cost driver | What IPv6 can reduce | What must be measured |
|---|---|---|
| Translation throughput | IPv4 packets and bytes processed | Busy-hour packet rate and packet sizes |
| Mapping resources | State used by migrated flows | Peak concurrent mappings and creation rate |
| Public IPv4 capacity | Required ports or IPv4-only allocations | Per-subscriber demand and reserved blocks |
| Redundancy | Capacity needed after a failure | Residual load on surviving equipment |
| Support | Some shared-address and translation incidents | Ticket causes and handling time |
| Operations | Potential future IPv4 expansion | Dual-stack running and training costs |
Build a residual IPv4 baseline
Measure representative weekdays, weekends and known demand peaks before changing the network. Record active subscribers, IPv4 throughput, packet rate, concurrent mappings and high-percentile per-subscriber port demand. Include the busiest service areas rather than relying on a network-wide mean.
Repeat those measurements for an IPv6-enabled cohort. Compare similar customers over comparable periods. A cohort with new CPE and different usage can look better for reasons unrelated to address family. Confirm that IPv6 is actually working through the subscriber LAN and applications, not just assigned at the BNG.
Separate normal operation from degraded operation. Your capacity purchase must cover the chosen failure scenario, planned maintenance and growth. A reduction in normal load may create useful resilience headroom before it permits removal of any equipment.
Define the fallback scenario too. If an IPv6 routing or service fault causes applications to use IPv4, the CGN may see a different peak. Decide how much fallback capacity the service objective requires, then test that assumption. Do not quietly count the same spare capacity as both growth reserve and failure reserve.
Work through an address example
Consider an illustrative network with 20,000 active CGN subscribers. Assume 64,000 usable ports per address per protocol for planning, with block accounting validated against the actual allocator. These are sizing assumptions, not a Netavo capacity claim.
Initial reserved block: 2,048 ports per subscriber
Whole blocks per address: floor(64,000 / 2,048) = 31
Minimum addresses before reserve: ceil(20,000 / 31) = 646
Suppose IPv6 now carries 60% of bytes, but the operator retains the same block size because residual IPv4 peaks still require it. The address floor remains 646. The deployment has reduced translation traffic and increased headroom, but it has not yet released public addresses.
If measurements later justify a 1,024-port reservation, the arithmetic becomes 62 whole blocks per address and a floor of 323 addresses. That potential reduction follows the port-demand evidence and allocation change. It does not follow directly from the IPv6 byte percentage.
Both figures exclude operational reserve, additional blocks for heavy users, pool fragmentation and failure capacity. If smaller initial blocks frequently need expansion, the realised saving will be smaller. Validate TCP and UDP demand under the allocator's actual rules rather than adding their nominal port spaces together as interchangeable capacity.
Convert capacity into cash carefully
For leased IPv4, count the addresses that can actually be returned and the date the contract permits it. Lower utilisation creates no immediate saving on a fixed commitment. Partial returns may also be constrained by prefix size or routing arrangements.
For owned IPv4, distinguish avoided purchases, opportunity value and cash released through a sale. These are different entries in an investment case. Use current quotations and your organisation's accounting treatment rather than a generic price per address. Include transaction and operational costs if disposal is part of the plan.
Hardware savings are similarly stepped. If the remaining workload still needs the same number of boxes for redundancy, the current fleet cost may stay unchanged. Deferring the next expansion can nevertheless be valuable, especially where rack space, power or available ports constrain growth.
Use a transparent model:
Annual benefit = address commitments avoided
+ annualised expansion cost avoided
+ support effort saved
- incremental IPv6 operating cost
Initial investment = rollout engineering + CPE remediation + training
Keep avoided expenditure separate from already sunk costs. Test the model with conservative, expected and high-adoption scenarios, and give each scenario an explicit date.
Include the cost of operating both protocols
IPv6 requires usable provisioning, routing, monitoring and support procedures. Staff need to distinguish an IPv4 application failure from an IPv6 reachability problem. CPE remediation and customer communication belong in the rollout budget.
The benefit side should include measured reductions in CGN-related tickets, especially shared-address complaints and port exhaustion. Avoid assuming that every broadband support call disappears when IPv6 is enabled. Wireless coverage, DNS and application account problems remain separate work.
High IPv6 adoption can coexist with an expensive residual IPv4 service, particularly when a small set of applications determines peak state and support requirements.
Set investment gates around decisions you can make: return a leased prefix, defer another appliance, reduce a reservation safely, or avoid a forecast address purchase. Review the evidence at each gate. This gives finance and operations the same definition of a realised saving.
Invest in IPv6 and size the CGN that remains
Netavo provides integrated CGN with deterministic subscriber port blocks and IP groups. Those controls let the operator set an explicit address-sharing policy for the remaining IPv4 workload. Stickiness helps keep egress assignments stable while the network adopts IPv6.
The pragmatic position is IPv6 plus a well-sized CGN. Deploy IPv6 to move capable traffic onto native connectivity, then resize IPv4 resources when observed demand and contractual commitments allow it. That approach captures savings without making residual IPv4 performance depend on an optimistic adoption percentage.
Use a Netavo evaluation to test your workload, consult the documentation for CGN configuration, and review the performance material alongside your own capacity measurements.