After years of limited support, IPv6 has finally been properly implemented in cPanel/WebHost Manager (WHM), enabling true dual-stack hosting without complex workarounds. Technically, IPv6 was implemented in version 40 of cPanel/WHM back in 2013. However, Server Name Indication (SNI) couldn’t be used to leverage a shared IPv6 address, nor could the server’s IPv6 be in the same prefix as the IPv6 range used to issue addresses to websites on the server.
With over one million websites now running on a cPanel/ WHM server, it became critical for the software to be updated for modern IPv6 implementations. This post investigates the new deployment, the issues encountered, and the fixes applied along the way.
Identifying the blockers
The original design of cPanel/WHM’s IPv6 imposed two key limitations: SNI could not be used in the traditional sense, and even if a shared IPv6 address was used, it was necessary to assign two isolated prefixes to each server — one for the machine, and one for shared use.
This prevented operators from deploying a standard dual-stack IPv4/IPv6 setup across their hosting fleets as an additional prefix was required purely for the servers themselves, despite there no longer being any technical necessity for that restriction.
As an APNIC Member, The Network Crew Pty Ltd (TNC) (AS138521) were delegated an IPv6 /32 in 2018 and gradually built out their infrastructure, working through blockers to deploy a successful dual-stack network. After finalizing their redundant network rebuild in 2024, it became clear that some key problems remained in the way of successful IPv6 deployment: First, oddities in RouterOS v7 routing; and secondly, the curious implementation of IPv6 in the cPanel/WHM software.
Through extensive work with APNIC’s Technical Assistance Platform (TAP), TNC carried out a raft of configuration overhauls to bolster their network resilience, redundancy, and overall design before drilling into the IPv6 implementation. Checks were performed, configurations adjusted, tests conducted, and outcomes verified.
In terms of IPv6, TNC first checked with Global Secure Layer to verify that nothing required amendment on their side. The all-clear was given regarding routing, indicating the problem lay within the local network. Following investigation with the APNIC TAP, both core routers in TNC’s Sydney network were adjusted to have blackhole routes configured for their /32 IPv6 prefix, which allowed for outbound routing through GSL and future Internet Exchange Points (IXPs), including IX Australia and Edge IX.
This enabled dual-stack testing in the cPanel/WHM software, which exposed fatal problems when attempting to use the same prefix for both the server’s shared IPv6 and the IPv6 range used for hosted websites. With other issues resolved, it became clear that the final hurdle was to effect changes within the software to enable a straightforward and effective dual-stack implementation, without having to re-engineer the network into an unnecessarily complex configuration.
Escalating the cPanel fix
The Network Crew Pty Ltd has been a cPanel Partner Network Operations Centre (Partner NOC) since 2017, and in that time has forged valuable connections within cPanel (now WebPros). This facilitated direct dialogue with Account Management, Engineering, Software Managers, and Developers/Engineers to implement the necessary changes within the product so that TNC — and users globally — could deploy dual-stack without needing complex addressing schemes to work around outdated restrictions.
Across several months in 2024, our team maintained regular contact, then fortnightly meetings, with the cPanel Development team leaders. Together, we identified, understood, and resolved the blockers in the software. After confirming that the IPv6 implementation had remained untouched for several years, the ideal approach was determined. We would introduce small changes with the greatest impact. In practice, this meant removing the IPv6 overlap restriction and resolving legacy warnings.
These changes were first published in development build v125.9999.100, which resolved case RE-1211 by enabling support for nested prefixes. cPanel provided this build to TNC for internal testing, which confirmed a successful deployment. However, testing uncovered an erroneous warning in the software. That issue was raised as case RE-1358 and subsequently addressed in cPanel v126, alongside the prefix overlap fix. By the time this blog post was published, v126 had already reached the STABLE release tier, making the improvements available globally. It is expected to reach the Long-Term Support (LTS) tier soon, at which point the update will roll out to final production servers as well.
TNC is grateful for the support of WebPros/cPanel staff who made the changes possible, particularly Adam Wien, Todd Rinaldo, and Elena Deryabina, who were instrumental in driving the successful fixes through to publication.
Deploying IPv6, SNI or not
Since the promotion of cPanel/WHM to the STABLE tier, which TNC runs internally, we deployed AAAA records to the corporate websites (TNC and Merlot) as well as to the online self-service platform. We also configured /96 prefixes on all Managed Client Servers, facilitating a smooth, gradual dual-stack deployment for their clients’ end customers.
In terms of prefix breakdown, APNIC allocated 2404:2440::/32 to TNC, which is divided into /64s by segment (corporate, customer, and management), and /96s are delegated to each Virtual Machine (VM) based on location and server. Each VM can then either use SNI at the start of the /96 or issue specific /128 addresses per website. This approach keeps the implementation simple, allows for isolated testing by segment, and adheres to best practice by avoiding non-standard prefix sizes.
Due to IPv6’s vast addressing space, there is a renewed approach to static IP addresses — it is no longer prohibitive to address each website individually. While SNI is now possible (even in cPanel), it is equally viable to assign a /128 to each website and implement Pointer (PTR) records (also known as a Reverse DNS record) aligned for Forwards-confirmed Reverse DNS (FCrDNS), should website owners or hosting providers choose to do so.
Internally resilient by design
Throughout their work with the APNIC TAP, TNC undertook a whole-of-network overhaul. The goal was a network capable of enduring disruptions (such as fibre cuts or maintenance periods) seamlessly, and empowering clients to adopt IPv6 without seeking additional IPv4 addresses.
We achieved this by deploying internal Border Gateway Protocol (BGP) between core routers in NEXTDC S2 — a Tier IV data centre in Sydney, Australia, where the managed infrastructure resides. Virtual Router Redundancy Protocol (VRRP) was introduced in place of OSPF to enable seamless gateway routing if a core router became inaccessible. These changes were implemented for both IPv4 and IPv6, ensuring resilience regardless of protocol.
Rather than applying improvements to RouterOS v6, TNC upgraded to v7 before proceeding, avoiding translation or rework post-upgrade. Physical works included relocating hardware, recabling, and switching from copper-based to fibre-based networking. Initially opting for Dell switches, they later migrated to HPE switches due to limitations in Dell’s Network Operating System (NOS). This transition was supported by FibreStore (FS), which enabled transceiver swaps to accommodate the last-minute platform change.
APNIC TAP: ‘Engineering legends’
TNC remain profoundly grateful for the steadfast support provided by the APNIC TAP. Their methodical approach — setting goals, planning backward, and breaking the journey into manageable tasks — made the transformation possible. TNC’s CTO was frequently on-site at NEXTDC for major works, interspersed with TAP sessions for testing and planning successive phases.
We offer sincere thanks to Terry Sweetser, Dave Phelan, and Zobair Khan of APNIC for their tireless work during the 2024 network overhaul (with finishing touches completed in early 2025). Their open-minded, gatekeeper-free approach to network engineering enabled TNC to ask any question, no matter how basic, and receive practical, candid answers from ‘that’s possible, and here’s how’ to ‘that’s a terrible idea, and here’s why’. This honesty underpinned outstanding results.
It is remarkable what can be achieved when dedicated individuals unite with shared goals. TNC contribute to and advocates for open source software and believes APNIC TAP’s methodology reflects the same ethos: Giving, supporting, and advocating for others. One step at a time, they work towards collective, positive outcomes.
We thank everyone who helped another million-plus service deploy IPv6, especially at a pivotal moment, as the APNIC region crosses the 50% IPv6 adoption milestone.
Onwards and upwards.
Luke is Director and CTO at The Network Crew Pty Ltd (AS138521) and Merlot Digital, based in regional Australia. He’s a Linux Systems Engineer, an advocate for open-source, and aims to be ‘1% better every day’.
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.