This case study documents a ~16-day project to maximize the native IPv6 traffic ratio on a sophisticated Small Office/Home Office (SOHO) network. I presented this work at APRICOT 2026 during the APNIC IPv6 Deployment session.
Starting from a healthy but suboptimal baseline of approximately 67% IPv6, a data-driven analysis using NetFlow monitoring was conducted to identify and remediate major sources of residual IPv4 traffic.
The investigation revealed that while general web and streaming traffic were already highly IPv6-dominant (>75%), the BitTorrent application was the primary laggard, operating at only 44% IPv6 due to default fallback behaviours. A single, targeted configuration change — binding the application exclusively to the IPv6 interface — had a profound impact. This action flipped the application’s performance to 92.6% IPv6, lifting the entire network’s stable operational average to 79.2% native IPv6.
The project conclusively demonstrates that a near-native IPv6-first environment is achievable in 2025 without transition technologies, and that the remaining barriers are primarily external, consisting of legacy IoT hardware, IPv4-only web services, and ISP infrastructure.
Introduction: An optimized dual-stack environment
The project began with a well-configured dual-stack network operating over Aussie Broadband, a residential ISP providing native IPv6 connectivity with a /48 prefix delegation. The internal network was already highly optimized, featuring:
- A pure IPv6 DNS infrastructure using Pi-hole with Unbound.
- Router Advertisement (RA) with RDNSS for client auto-configuration (SLAAC), with no IPv4 DNS servers offered to internal clients.
- A MikroTik gateway providing robust routing and NetFlow export capabilities.
- An internal IPv6-first philosophy, with local services such as media servers and the NetFlow analyser itself running on planned, memorable IPv6 addresses (for example, …::cafe, …::beef).
Despite this robust foundation, a historical analysis of all available NetFlow data (16 days) revealed a network-wide IPv6 traffic ratio of 67.7%. While significantly above the global average, this indicated substantial room for improvement. The primary objective was therefore established: To identify and remediate the sources of residual IPv4 traffic and maximize the native IPv6 ratio, with the ultimate goal of building a viable case for an IPv6-only internal network.
Methodology: A data-driven investigation
The primary tool for this analysis was Akvorado, a real-time NetFlow collector and visualizer running on a dedicated local server. The methodology followed a systematic, iterative process:
- Establish a baseline: Analyse historical traffic to understand the initial IPv6/IPv4 split across different applications, identified by destination port.
- Isolate slow movers: Filter traffic to identify the applications or services with the lowest IPv6 ratios and highest IPv4 bandwidth consumption.
- Targeted intervention: Implement specific configuration changes on the identified laggard applications.
- Measure and validate: Collect and analyse data for a defined period to measure the impact of the intervention.
- Define the ‘IPv4 floor’: Isolate and categorize the remaining, irreducible IPv4 traffic to understand the final limitations of a native IPv6-only approach.
The optimization journey: From ‘it works’ to ‘it’s right’
Initial analysis immediately identified BitTorrent as the primary source of IPv4 traffic, acting as a significant drag on the network’s overall average.
The historical baseline for BitTorrent
The 30-day average before the experiment’s conclusion showed a clear problem (Table 1).
| Metric (BitTorrent only) | Before (30-day average) |
| IPv6 ratio | 44.3% |
| Average IPv6 traffic | 0.86Mbps |
| Before (30-day average) | 1.08Mbps |
BitTorrent was a majority-IPv4 application, a surprising fact given the P2P world’s history as an early adopter of IPv6 via technologies like Teredo.
The deceptive nature of ‘working’ dual-stack
A crucial discovery was made — even with IPv6 enabled and an IPv6 port forward in place, the qBittorrent client, bound to “Any” interface by default, was actively using IPv4. It was receiving IPv4 peer addresses from trackers and initiating outbound connections via the gateway’s Network Address Translation (NAT) function.
This created a suboptimal, asymmetric connection state:
- IPv6: Full, bidirectional connectivity.
- IPv4: Outbound-only connectivity. Inbound connections were blocked as there was no IPv4 port forwarding.
The application ‘just worked’, but its performance was fundamentally crippled on the IPv4 side, and its fallback behaviour was polluting the network with inefficient traffic.
The critical intervention: Surgical exclusion
The definitive solution was not to encourage a preference, but to enforce a structural change.
- Action: The qBittorrent client’s ‘Network Interface’ was bound exclusively to the IPv6 interface.
- Effect: This surgically removed the application’s ability to use the IPv4 stack. The suboptimal, outbound-only NAT path was eliminated, forcing all communication onto the superior, fully functional native IPv6 path.
Results: A shift to a premium peer pool
The impact was immediate and profound. The two-day average after this fix represents the new, stable state for BitTorrent.
| Metric (BitTorrent only) | Before (30-day average) | After (two-day average) | Change |
| IPv6 Ratio | 44.3% | 92.6% | +48.3 points |
| Average IPv6 traffic | 0.86Mbps | 4.72Mbps | +448% |
| AverageIPv4 traffic | 1.08Mbps | 0.38Mbps | -65% |
Qualitative analysis revealed another key benefit: The peer pool had shifted from a large quantity of mixed-quality IPv4 peers to a smaller, but higher-quality, set of high-performance IPv6 seedboxes and peers in well-connected data centres.
Why not 100%? I was still seeing IPv4 addresses encoded under::ffff:0:0/96!
Defining the irreducible ‘IPv4 floor’
With BitTorrent optimized, the final step was to analyse the remaining IPv4 traffic. This ‘IPv4 floor’ represents the hard limit of native optimization. The investigation identified three primary categories:
- Legacy Internet of Things (IoT) hardware: Four Ring cameras were confirmed to be IPv4-only, contributing a constant stream of video upload traffic that constitutes a significant portion of the IPv4 baseline. This represents a vendor-imposed limitation.
- Legacy web services: Analysis confirmed that major services still lack complete IPv6 support.
- Amazon.com and CloudFront: The main retail site and many CloudFront distributions used by third parties lack AAAA records.
- GitHub.com: The core website remains primarily IPv4, though asset domains are now served over IPv6.
- ISP infrastructure: A top source of IPv4 was identified as an Aussie Broadband ‘third party’ caching proxy/accelerators (running Apache Traffic Server), which serves popular content from within the ISP’s IPv4 network.
Final results: The new 80% network baseline
By combining the ‘after’ states for both BitTorrent and general traffic, we can establish the new, stable operational baseline for the entire network.
| Metric (overall network) | Before (30-day average) | After (two-day average) |
| Overall IPv6 ratio | 67.7% | 79.2% |
| Total average IPv6 traffic | 4.82Mbps | 7.08Mbps |
| Total average IPv4 traffic | 2.30Mbps | 1.86Mbps |
This represents a sustained 11.5 percentage point increase in the network’s overall native IPv6 performance, pushing the new baseline to nearly 80%, with peaks consistently exceeding 90% during periods of high IPv6-dominant activity.
Conclusion: The case is made, the path is clear
This case study has successfully proven that a home network in late 2025 can and should operate as an overwhelmingly IPv6-native environment. The journey from a 67.7% baseline to a stable 79.2% average demonstrates that the era of IPv4 dominance is over for well-configured networks with access to modern services.
The key takeaways are clear:
- The vast majority of high-bandwidth content (P2P, video streaming) is available and performs excellently over native IPv6.
- Application-level configuration, specifically the choice to surgically exclude legacy protocols rather than merely prefer modern ones, is often the final hurdle.
- The remaining ~20% of IPv4 traffic is a well-defined ‘floor’ of legacy hardware, services, and infrastructure that is external to the user’s control.
The path forward: Addressing the final 20%
The network has reached the practical limit of what is achievable through native IPv6 optimization alone. The final, most elegant solution for the residual ~20% of legacy traffic is a gateway-level Customer-Located Address Translator (CLAT), a core component of the 464XLAT architecture.
Currently, this presents a vendor-imposed limitation, as MikroTik’s otherwise powerful RouterOS does not yet offer a native CLAT implementation. Therefore, the path forward is one of strategic waiting and advocacy. The onus now shifts from user configuration to the vendor ecosystem.
The deployment of CLAT and provider-side PLAT (NAT64) capabilities within mainstream networking platforms like RouterOS represents the final domino to fall. This will enable millions of advanced users — who have already done the work to optimize their networks — to seamlessly transition their internal infrastructure to a pure, simplified, and forward-looking IPv6-only state. Until then, the ~80% native IPv6 network stands as a testament to what is possible, and as a clear signal to vendors of the features that are now critically needed.
Watch Terry’s APRICOT 2026 presentation on this topic in full:
Terry Sweetser is the Founder and Principal Consultant of The Internet Engineering & Infrastructure Strategic Initiative and is building an advisory, consulting and board portfolio across the Asia Pacific region. His work in the community includes Routing Security, IPv6 Adoption, Fellowships, conference programs and training. He holds a BEng and MBA from QUT in Brisbane, where he has also been a business coach and sessional academic.
Adapted from the original post on Terry’s Medium.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.