For ISPs and network operators across Asia-Pacific ready to move past CGNAT and deploy IPv6 properly.
Not dual-stack as an indefinite stopgap. Not a deployment that stalls at CPE provisioning. Not a consultant who leaves before your team can operate it independently. IPv4 exhaustion has been operational reality in Asia-Pacific since 2011: the path forward is IPv6-first, with deliberate transition architecture.
APNIC entered its final /8 IPv4 allocation in 2011. Every ISP in the region deploying at scale today is behind CGNAT: double-NAT stacks that break peer-to-peer connectivity, complicate lawful interception, degrade gaming and VoIP, and create operational overhead that compounds with subscriber growth.
The question stopped being "should we deploy IPv6?" about ten years ago. The question is now "why haven't you, and what's it actually costing you to stay on CGNAT?"
Terry Sweetser, IEISIPort allocation tables, logging obligations for lawful interception, and stateful session tracking create infrastructure overhead that grows with every subscriber you add.
Applications that rely on inbound connection establishment, gaming consoles, SIP trunks, home automation, remote access, hit persistent friction under CGNAT, and your support team hears about it.
Dual-stack was meant to be transitional. For many ISPs it has quietly become the permanent architecture, carrying the operational cost of running two address families indefinitely.
Google, Meta, Netflix, Cloudflare, and Akamai all serve significant traffic over IPv6. Every megabit still carried over IPv4 transit is a cost that IPv6-native peers have already stopped paying.
Most operators weighing an IPv6 deployment are comparing it against one of these.
Reasonable if CGNAT genuinely isn't causing operational or support-cost pain yet. Where it already is, the compounding cost referenced above keeps growing while you wait, and the eventual deployment doesn't get easier by delaying it.
The right call if your team already has hands-on IPv6 deployment experience at your scale. Where that experience doesn't exist yet, the CPE long tail and edge cases are exactly where first-time deployments stall, and learning them on your own production network is expensive.
Strong for turnkey delivery backed by heavy resourcing. Typically priced and scoped for enterprise engagements, and knowledge transfer to your own team is rarely the primary deliverable, so you can end up dependent on the vendor for ongoing changes.
Can be a good fit for broad network architecture work. IPv6-specific deployment at ISP scale, especially the CPE and provisioning detail, is a narrow specialisation that general network consulting doesn't always cover in depth.
Real-world IPv6 deployment at an ISP is not a routing change. It is a programme spanning prefix delegation policy, CPE firmware behaviour, DNS resolver configuration, SLAAC and DHCPv6 coexistence, customer support tooling, and network monitoring. I have done this at a national scale, with 50,000+ subscribers, and I know where the surprises are.
Structured audit of your current infrastructure: upstream provider support, CPE firmware compatibility, prefix delegation policy, DNS resolver behaviour, and monitoring capability. Produces a clear gap analysis and prioritised deployment sequence.
Dual-stack or IPv6-first architecture design, DHCPv6-PD prefix delegation sizing and policy, RA/SLAAC configuration, router advertisement daemon design, and transition mechanism selection (464XLAT, NAT64, DS-Lite) for your subscriber base and CPE ecosystem.
IPv6 prefix filtering policy, ROA/RPKI for your IPv6 allocations, BGP community design, peering policy updates, and route reflector configuration for IPv6 address families. Vendor-neutral across Cisco, Juniper, MikroTik, and VyOS/EdgeOS environments. For dedicated routing security advisory, see RPKI & Routing Security →
The hidden complexity of ISP IPv6 deployment: CPE firmware behaviour, DHCPv6 client compliance, delegated prefix handling on consumer routers, and the long tail of customer premise equipment that doesn't behave as the RFC intended. Structured testing methodology to de-risk rollout.
Extending your NOC tooling for IPv6: NetFlow/IPFIX with address family separation, per-prefix traffic analysis, IPv6 adoption ratio tracking by customer segment, and alerting on dual-stack fallback patterns that signal deployment problems.
Practical IPv6 workshops for your NOC, network engineering, and support teams. Not protocol theory: operational competency, troubleshooting tools, address plan reading, neighbour discovery debugging, and handling the customer calls that dual-stack deployments generate. See also Training & Capacity Development →
A structured audit of your current infrastructure: upstream provider support, CPE firmware compatibility, prefix delegation policy, DNS resolver behaviour, and monitoring capability. You come out of it with a clear gap analysis and a prioritised deployment sequence, whether or not you engage further.
Structured audit of your current infrastructure and a prioritised deployment sequence you can act on immediately, in-house or with further support.
What typically follows: deployment architecture and design, routing policy and BGP configuration, CPE provisioning support, monitoring setup, and operator training, scoped once the assessment findings are in hand.
Through APNIC training programs, I have trained over 2,000 network engineers, in person across 23 economies in Asia-Pacific. The focus is always operational: engineers who leave knowing how to configure, troubleshoot, and explain IPv6 to their teams, not engineers who have memorised the header format.
Theory gets you through the exam. Operational knowledge gets you through the 2am outage. The gap between those two is where training either earns its cost or doesn't.
Terry Sweetser, IEISIIPv6 training that sticks is built around working configurations. Participants leave with router configs they wrote themselves, troubleshooting steps they ran, and packet captures they interpreted, not a printout of RFC summaries.
IPv6 training designed for APAC addresses the specific constraints of the region: varied CPE ecosystems, ISPs at different stages of dual-stack deployment, upstream provider diversity, and the particular pressure of operating in markets where IPv4 scarcity is already affecting service quality.
The goal of every training engagement is for your team to own IPv6 operations independently. That means covering the failure modes and edge cases, the situations your team will face in production, not just the happy path that works in a clean lab environment.
Structured workshops for teams of 8-20, embedded advisory during active deployment where training happens alongside real work, or train-the-trainer programs for organisations building internal IPv6 capability across multiple sites or regions.
How far can native IPv6 penetration go on a fully configured home network, and what are the actual barriers? Project IPv6-First instrumented a SOHO network with NetFlow collection and systematic intervention to find out. The results challenge common assumptions about where the IPv4 floor comes from.
Starting from a baseline of 67.7% native IPv6 on Aussie Broadband's native dual-stack service (with /48 prefix delegation), a 16-day instrumented study using Akvorado NetFlow collection identified the specific application-layer sources of IPv4 traffic and systematically eliminated each one. The remaining IPv4 floor was not protocol limitations: it was legacy IoT hardware, incomplete AAAA records on major CDNs, and the ISP's own caching infrastructure.
16 days of historical NetFlow data to establish starting ratios by application, destination, and traffic volume.
Application-level filtering by destination port to isolate the specific services pulling disproportionate IPv4 traffic.
Configuration changes on underperforming services, beginning with qBittorrent, which leapt from 44% to 92.6% IPv6 after interface binding.
Post-intervention data collection and validation to confirm changes held and did not introduce new IPv4 dependencies.
Categorisation of the irreducible IPv4 sources: legacy IoT hardware (Ring cameras), CDN gaps (Amazon, CloudFront), and ISP caching infrastructure.
The research points to 464XLAT (CLAT/PLAT architecture) as the elegant solution for the remaining IPv4 floor. By translating IPv4-only application traffic at the customer edge into IPv6 for the network core, it eliminates the need for dual-stack throughout the access network. The current barrier: MikroTik RouterOS lacks native CLAT support, making it the critical vendor feature request for ISPs running that platform at scale across APAC.
Everything above is for the engineer running the deployment. If you're the CTO, CIO, or VP of Engineering who needs to make the call, or get someone else to, this book makes the financial and governance case in language a board will act on — not protocol theory.
Highly variable and depends more on CPE ecosystem than network infrastructure. Core routing changes for a small-to-medium ISP can be completed in weeks. The long tail is CPE: qualifying firmware across your fleet, handling the edge cases in customer-owned hardware, and updating provisioning and support tooling. A realistic timeline for full subscriber base coverage is 6-18 months depending on ISP scale and CPE diversity.
RPKI (Resource Public Key Infrastructure) is essential for both IPv4 and IPv6 routing security, but ISPs deploying IPv6 for the first time have the opportunity to get their Route Origin Authorisations right from the start, rather than inheriting years of legacy ROA debt. IPv6 deployment is a natural forcing function to review and correct your routing security posture across both address families.
Brisbane, Queensland, with in-person experience deploying and training across 23 economies in Asia-Pacific through APNIC programs. Advisory and deployment work is available remotely across the region, with on-site presence where the scope warrants it.
Whether you are planning an ISP deployment, looking to train your team, or investigating why your IPv6 adoption ratio is stuck, start with a conversation. No sales cycle, no pitch deck.