IPv6-Only Data Centers: A Simpler, More Scalable Network?
24/04/2025
For years, the transition to IPv6 has been viewed as a gradual process, typically using dual-stack approaches. However, in certain environments such as modern data centers, the option of moving directly to an IPv6-only network is gaining traction. Why opt for this approach? What does this decision entail in practice? What technical challenges does it involve?
These were some of the questions discussed during a recent webinar organized by LACNIC and led by Tomás Lynch, a network engineer at Vultr with extensive experience in large-scale deployments.
Why IPv6-Only?
In data centers where the stack and services can be fully controlled, IPv6-only simplifies the network, eliminates reliance on IPv4 addresses, and reduces operational complexity. As Lynch pointed out, maintaining a dual-stack environment requires managing two protocols, duplicating configurations, and dealing with issues such as traffic asymmetry and diagnostic challenges.
Furthermore, today it’s no longer necessary to wait for all traffic to be natively IPv6: tools such as NAT64, DNS64, and 464XLAT allow translating requests in the case of services that don’t yet offer IPv6 connectivity, thus facilitating a functional transition.
Lynch stressed that dual stack is a transition, not a destination. “The ultimate goal should be IPv6-only networks, as this simplifies network design, security, and overall operations,” he added.
(Free access, no subscription required)
Tools, Best Practices, and Lessons Learned
Multiple implementation strategies were discussed during the webinar, focusing on tools and operational considerations:
- Differences between ISP and data center networks
- Leaf-spine architecture
- Routing options and why we shouldn’t be afraid of BGP
- Unnumbered BGP sessions
- Sizing a GPU cluster
- RFC5549 and SIIT-DC, NAT64/DNS64
The impact of using IPv4 addresses on each network element was also examined, considering that the use of IPv6-only can simplify configurations, provisioning, monitoring tools, and observability.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.