LACNIC Blog > IPv6 > IPv6 from an Operational Perspective: Lessons Learned, Common Mistakes, and Next Steps for the Region
IPv6 from an Operational Perspective: Lessons Learned, Common Mistakes, and Next Steps for the Region
June 26, 2026
Alejandro Acosta of LACNIC opened the IPv6 panel discussion at LACNIC 45 with a direct question: Why do we still need to promote IPv6 in 2026?
The consensus that emerged from the discussion was clear: the challenge is no longer simply enabling the protocol but integrating it consistently. There are still services with no AAAA records, as well as partial deployments, incomplete configurations, and new projects that do not consider IPv6 from the outset. The panel brought together experts with diverse IPv6 expertise—from academic networks and data centers to service provider deployments—to analyze what is holding back adoption, lessons learned, and what concrete steps can accelerate a more mature implementation.
The Panelists
The debate was moderated by Alejandro Acosta and featured four experts: Lee Howard, an IPv6 specialist with over 35 years of networking experience; Tomás Lynch, Senior Network Architect at Vultr; Henry Alves de Godoy, Network Administrator at Unicamp; and Orlando Flores Ávila, an IPv6 expert.
What Continues to Hinder Deployment?
Lee Howard identified three barriers to advancing IPv6 adoption. The first lies was customer-premises equipment (CPE). Many devices claim to support IPv6, but the feature is often disabled by default or lacks functional transition mechanisms. The second barrier relates to internal operational support systems, which tend to be custom-developed and difficult to modify, making them bottlenecks for deployment.
(Free access, no subscription required)
The third obstacle, however, is less technical and more operational: perceived complexity. According to Lee Howard, many organizations have the technical capacity to move forward but continue to postpone the decision because they fear that IPv6 will involve greater risks and implementation difficulties than it actually does. Tomás Lynch added an important nuance: the challenge is not merely the lack of IPv6, but also incorrect or incomplete deployments. A concrete example is routing policy: some networks apply BGP communities, local preference, and carefully defined criteria for IPv4, but fail to replicate those same policies when receiving IPv6 prefixes.
The Financial Argument
Orlando Flores Ávila pointed out that, in many cases, the tipping point comes when maintaining CGNAT becomes more expensive than advancing with IPv6. This cost is not limited to hardware investment, but also includes computing resources, operation, support, and the additional complexity CGNAT introduces to the network. At that point, the decision is no longer purely technical—it now includes a financial dimension.
As Flores Ávila explained, many organizations start with dual-stack deployments. Once this stage is consolidated, the economic and operational benefits of IPv6 become more evident. The next step is to move toward native IPv6 networks, maintaining translation mechanisms only for reaching the portion of the Internet that still operates on IPv4.
The third obstacle, however, is less technical and more operational: perceived complexity. According to Lee Howard, many organizations have the technical capacity to move forward but continue to postpone the decision because they fear that IPv6 will involve greater risks and implementation difficulties than it actually does. Tomás Lynch added an important nuance: the challenge is not merely the lack of IPv6, but also incorrect or incomplete deployments. A concrete example is routing policy: some networks apply BGP communities, local preference, and carefully defined criteria for IPv4, but fail to replicate those same policies when receiving IPv6 prefixes.
The Financial Argument
Orlando Flores Ávila pointed out that, in many cases, the tipping point comes when maintaining CGNAT becomes more expensive than advancing with IPv6. This cost is not limited to hardware investment, but also includes computing resources, operation, support, and the additional complexity CGNAT introduces to the network. At that point, the decision is no longer purely technical—it now includes a financial dimension.
As Flores Ávila explained, many organizations start with dual-stack deployments. Once this stage is consolidated, the economic and operational benefits of IPv6 become more evident. The next step is to move toward native IPv6 networks, maintaining translation mechanisms only for reaching the portion of the Internet that still operates on IPv4.
The 50% Milestone
The panel also addressed recent data showing that, for the first time, more than 50% of connections to Google services were made over IPv6. The panelists discussed what this milestone means and how it can be interpreted from a regional perspective.
Howard clarified the scope of the data, noting that it reflects access to Google services rather than the aggregate volume of global Internet traffic. He also noted that the region’s IXPs do not necessarily mirror this growth, as a large portion of IPv6 traffic moves over private interconnections between ISPs and content platforms, bypassing Internet exchange points. According to Howard, what matters are the internal reports of data centers and ISPs.
Henri Alves de Godoy put the data into a regional perspective: Latin America and the Caribbean are no longer merely following IPv6 trends. Our region is also generating knowledge and experience that can be useful for others. At Unicamp, 75% of traffic already flows over IPv6, and the university acts as a multiplier, as students then bring those practices to their organizations.
Lynch proposed a pragmatic interpretation of the milestone: the 50% figure can be used as an argument for internal management. For organizations where deployment remains stalled because of budget constraints or a lack of executive support, this number can help show that IPv6 is no longer a technology of the future, but an operational reality.
IPv6 Mostly: A Possible Evolution
During the panel, Alves de Godoy shared Unicamp’s IPv6 Mostly pilot project. In this model, the network operates primarily over IPv6, while IPv4 remains transparently available when the destination requires it.
The key mechanism is CLAT, a client-side translation technology that is already natively integrated into operating systems such as Android, iOS, and macOS. For this to work, the network must properly signal to the operating system that it can activate CLAT automatically. The advantage over other approaches is that it avoids moving all the complexity to the CPE. The operating system already has the necessary capabilities; the organization’s challenge is enabling the network environment.
Technical Advantages
Lynch also suggested that while the IPv4 exhaustion argument remains valid, it has lost some of its impact as a primary decision driver. After decades of warnings, many organizations have learned to coexist with NAT, CGNAT, and IPv4 block transfers.
Because of this, he proposed highlighting the capabilities that native IPv6 enables. Among these, he mentioned BGP unnumbered, which allows establishing eBGP sessions without assigning addresses to links; the use of IPv6 next hops in MP-BGP, which simplifies operations by carrying IPv4 and IPv6 routes in a single session; and SRv6, which allows routing instructions to be embedded in IPv6 addresses, offering advantages for network automation and architecture. The core message is that IPv6 should not be presented solely as a response to address exhaustion, but as a platform for simplifying, scaling, and modernizing network operations.
Practical Recommendations
The session closed with a series of action-oriented recommendations:
Do not treat IPv6 as a side project. If a new project begins with the idea of “adding IPv6 later,” that moment will likely never come. IPv6 should be present from the initial design stage, especially in the addressing plan.
Start with a low-criticality service. For example, enabling IPv6 on a secondary web server requires configuring connectivity, security, and monitoring for both protocols. It also allows for separate fault detection; if IPv4 and IPv6 are not monitored independently, it will be impossible to know which one is failing.
Use new tools to accelerate the learning curve. AI tools can help establish a starting point for configurations or diagnostics, provided their outputs are validated by technical personnel.
Learn from documented errors. The region has real-world experience, best practices, and deployment case studies that can help avoid repeating known issues.
Leverage the technical community. People who have already deployed IPv6 are often willing to share their knowledge. Seeking peers within the region, even among competing organizations, can help reduce uncertainty and accelerate decision-making.
LACNIC offers training materials and courses through its Campus, and the region’s operator community has accumulated experience to support new deployment processes. The protocol is mature, use cases are documented, and support exists. What remains is the decision to begin—or complete—what has already been started.
