IPv4 exhaustion is not a future problem for Asia-Pacific — it has been operational reality since 2011. The path forward is IPv6 deployed correctly: not dual-stack as a stopgap, but 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. IPv6 is not a protocol upgrade to plan for. It is the exit ramp from an architecture that is already failing.
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, IEISIDouble-NAT breaks application assumptions about direct addressing. Port allocation tables, logging obligations for lawful interception, and stateful session tracking create infrastructure overhead that grows with every subscriber. IPv6 eliminates the need for the state machine entirely.
Applications that rely on inbound connection establishment — gaming consoles, SIP trunks, home automation, remote access — hit persistent friction under CGNAT. IPv6 restores genuine end-to-end reachability without port forwarding workarounds or UPnP dependency.
Stateless address autoconfiguration (SLAAC), mandatory neighbour discovery, built-in flow labelling, and a simplified header structure were designed for a world of ubiquitous addressing — not grafted on as afterthoughts. Routing table aggregation at scale is cleaner. IPsec is native.
Google, Meta, Netflix, Cloudflare, and Akamai all serve significant traffic over IPv6. ISPs with deployed IPv6 see measurable peering and transit cost reduction as high-bandwidth flows shift off the IPv4 path. The content side of the transition is largely done — the access network is the bottleneck.
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.
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 does not 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.
Through APNIC training programmes, I have trained over 2,000 network engineers across 56 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 programmes 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.
It has been production-ready for over a decade. Google has served traffic over IPv6 since 2012. Cloudflare, Akamai, Netflix, and Meta are all predominantly IPv6 for traffic where the client supports it. The remaining friction is on the access network side — ISP deployment and CPE provisioning — not the protocol or the content ecosystem.
Project IPv6-First achieved a stable 79.2% native IPv6 ratio on a fully configured residential network, with peaks exceeding 90%. The remaining ~20% was not due to protocol limitations but to specific external barriers: legacy IoT hardware without IPv6 support (four Ring cameras), incomplete AAAA records on Amazon and CloudFront infrastructure, and Aussie Broadband's own caching layer operating primarily on IPv4. On a network without those specific constraints, higher ratios are achievable.
Dual-stack requires maintaining IPv4 infrastructure throughout the access network. 464XLAT allows an ISP to run an IPv6-only access network while still supporting IPv4-only applications on customer devices. The CLAT (Customer-side Translator) on the CPE converts IPv4 application traffic to IPv6 for the network, and the PLAT (Provider-side Translator) converts it back to IPv4 where needed for legacy destinations. It is the architecture that enables genuine IPv6-first deployment at scale.
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 device estate, 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 significant experience operating across Asia-Pacific through APNIC programmes. Training engagements have covered 56 economies. 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.