LACNIC Blog > IPv6 > IPv6 desde la operación: aprendizajes, errores comunes y próximos pasos para la región
IPv6 desde la operación: aprendizajes, errores comunes y próximos pasos para la región
26/06/2026
La pregunta de Alejandro Acosta, de LACNIC, abrió el panel sobre IPv6 en LACNIC 45 con un punto de partida directo ¿por qué en 2026 seguimos necesitando impulsar IPv6?
La respuesta que surgió de la conversación fue clara porque el desafío ya no es sólo habilitar el protocolo sino incorporarlo de manera consistente. Todavía hay servicios sin registros AAAA, despliegues parciales, configuraciones incompletas y proyectos que no contemplan IPv6 desde el inicio. El panel reunió a referentes con distintas experiencias en IPv6 -desde redes académicas, datacenters hasta despliegues en proveedores de servicios- para analizar qué está frenando la adopción, aprendizajes y qué pasos concretos pueden acelerar una implementación más madura.
Los protagonistas
El debate, moderado por Acosta, contó con cuatro expertos: Lee Howard, especialista en IPv6 con más de 35 años de experiencia en redes, Tomás Lynch, arquitecto de redes senior en Vultr, Henry Alves de Godoy administrador de redes de Unicamp y Orlando Flores Ávila, experto en IPv6.
¿Qué sigue frenando el despliegue?
Lee Howard identificó tres barreras para avanzar con IPv6. La primera está en los equipos del cliente: muchos CPE declaran soporte para IPv6 pero llegan con la función desactivada por defecto, o sin mecanismos de transición funcionales. El segundo aparece en los sistemas internos de gestión operacional, muchas veces desarrollados a medida y difíciles de modificar, que terminan convirtiéndose en cuellos de botella para el despliegue.
(Acceso libre, no requiere suscripción)
Pero el tercer obstáculo es menos técnico y más operacional: la percepción de complejidad. Según Howard, muchas organizaciones tienen las condiciones para avanzar técnicamente pero postergan la decisión por miedo a que IPv6 implique más riesgos o dificultades de las que realmente presenta. Tomás Lynch agregó un matiz importante: el problema no es solo no tener IPv6, sino también tenerlo desplegado de forma incorrecta o incompleta. Un ejemplo concreto son las políticas de ruteo: hay redes que aplican comunidades BGP, local-preference y criterios cuidadosos para IPv4, pero no replican esas mismas reglas al recibir prefijos IPv6
El argumento económico
Orlando Flores Ávila señaló que, en muchos casos, el punto de inflexión llega cuando mantener CGNAT se vuelve más costoso que avanzar con IPv6. Ese costo no se limita a la inversión en hardware: también incluye recursos de cómputo, operación, soporte y la complejidad adicional que introduce en la red. En ese momento, la decisión deja de ser exclusivamente técnica y pasa a tener también un componente financiero.
Según explicó, muchas organizaciones comenzaron con esquemas de dual stack. Una vez consolidada esa etapa, los beneficios económicos y operativos de IPv6 se vuelven más visibles. El paso siguiente es avanzar hacia redes con IPv6 nativo y mantener mecanismos de traducción únicamente para alcanzar la porción de Internet que todavía opera sobre IPv4.
Pero el tercer obstáculo es menos técnico y más operacional: la percepción de complejidad. Según Howard, muchas organizaciones tienen las condiciones para avanzar técnicamente pero postergan la decisión por miedo a que IPv6 implique más riesgos o dificultades de las que realmente presenta. Tomás Lynch agregó un matiz importante: el problema no es solo no tener IPv6, sino también tenerlo desplegado de forma incorrecta o incompleta. Un ejemplo concreto son las políticas de ruteo: hay redes que aplican comunidades BGP, local-preference y criterios cuidadosos para IPv4, pero no replican esas mismas reglas al recibir prefijos IPv6
El argumento económico
Orlando Flores Ávila señaló que, en muchos casos, el punto de inflexión llega cuando mantener CGNAT se vuelve más costoso que avanzar con IPv6. Ese costo no se limita a la inversión en hardware: también incluye recursos de cómputo, operación, soporte y la complejidad adicional que introduce en la red. En ese momento, la decisión deja de ser exclusivamente técnica y pasa a tener también un componente financiero.
Según explicó, muchas organizaciones comenzaron con esquemas de dual stack. Una vez consolidada esa etapa, los beneficios económicos y operativos de IPv6 se vuelven más visibles. El paso siguiente es avanzar hacia redes con IPv6 nativo y mantener mecanismos de traducción únicamente para alcanzar la porción de Internet que todavía opera sobre IPv4.
El hito del 50%
El panel también abordó un dato reciente: por primera vez, más del 50 % de los accesos a servicios de Google se realizaron sobre IPv6. Los panelistas discutieron qué significa ese hito y cómo puede interpretarse desde la región.
Howard matizó el alcance del dato ya que mide accesos a servicios de Google, no el volumen agregado del Internet global. Además, señaló que los IXPs de la región no necesariamente reflejan este crecimiento, porque gran parte del tráfico IPv6 viaja por interconexiones privadas entre ISPs y plataformas de contenido, sin pasar por puntos de intercambio. Lo que sí importa, según Howard, son los reportes internos de data centers e ISPs.
Henri Alves de Godoy puso el dato en clave regional: América Latina y el Caribe ya no es solamente una región que sigue tendencias en IPv6. También genera conocimiento y experiencia que puede ser útil para otras regiones. En Unicamp, el 75% del tráfico ya circula sobre IPv6, y la universidad funciona como multiplicador hacia estudiantes que luego llevan esas prácticas a sus organizaciones.
Lynch propuso una lectura pragmática del hito : el 50% puede ser un argumento de gestión interna. Para organizaciones donde el despliegue sigue trabado por falta de presupuesto o de apoyo ejecutivo, ese número puede ayudar a mostrar que IPv6 ya no es una tecnología del futuro, sino una realidad operativa.
IPv6 Mostly: una evolución posible
Durante el panel, Alves de Godoy compartió el proyecto piloto de Unicamp con IPv6 Mostly, un modelo en el que la red opera principalmente sobre IPv6, con IPv4 disponible de forma transparente cuando el destino lo requiere.
El mecanismo clave es CLAT, un traductor del lado del cliente que ya está integrado de forma nativa en sistemas como Android, iOS y macOS. Para que funcione, la red debe señalizar correctamente que permiten que el sistema operativo se active de forma automática. La ventaja frente a otros enfoques es que no exige llevar toda la complejidad hasta el CPE. El sistema operativo ya cuenta con la capacidad necesaria, el desafío para la organización es habilitar el entorno de red.
Las ventajas técnicas
Lynch también planteó que el argumento del agotamiento de IPv4, aunque sigue siendo válido, perdió parte de su fuerza como motor de decisión. Después de décadas de advertencias, muchas organizaciones aprendieron a convivir con NAT, CGNAT y transferencias de bloques IPv4.
Por eso, propuso destacar las capacidades que IPv6 habilita de forma nativa. Entre ellas mencionó BGP unnumbered que permite establecer sesiones eBGP sin asignar direcciones a los enlaces; el uso de IPv6 como next hop en MP-BGP que simplifica la operación al transportar rutas IPv4 e IPv6 en una sola sesión ; y SRv6 que permite incorporar instrucciones de encaminamiento usando direcciones IPv6 con ventajas para automatización y arquitectura de la red. El punto central es que IPv6 no debe presentarse únicamente como una respuesta al agotamiento de direcciones, sino como una plataforma para simplificar, escalar y modernizar la operación de las redes.
Recomendaciones concretas
El cierre estuvo orientado a la acción. Estas fueron algunas de las recomendaciones compartidas :
No tratar IPv6 como un proyecto paralelo. Si un proyecto nuevo comienza con la idea de “agregar IPv6 más adelante”, probablemente ese momento no llegue. IPv6 debe estar presente desde el diseño inicial, especialmente en el plan de direccionamiento.
Empezar por un servicio de baja criticidad. Habilitar IPv6 en un servidor web secundario, por ejemplo, obliga a configurar conectividad, seguridad y monitoreo para ambos protocolos. También permite detectar fallas de forma separada, si no se monitorea IPv4 e IPv6 por separado, no se sabrá cuál de los dos está fallando.
Usar nuevas herramientas para acelerar la curva de aprendizaje. Las herramientas de IA pueden ayudar a obtener un punto de partida para configuraciones o diagnósticos, siempre que sus respuestas sean verificadas por personal técnico.
Aprender de errores ya documentados. La región cuenta con experiencias reales, buenas prácticas y casos de despliegue que pueden evitar repetir problemas conocidos.
Apoyarse en la comunidad técnica. Quienes ya desplegaron IPv6 suelen estar dispuestos a compartir aprendizajes. Buscar pares en la región, incluso en organizaciones competidoras, puede ayudar a reducir incertidumbre y acelerar decisiones.
LACNIC cuenta con materiales y cursos de capacitación en su Campus, y la comunidad de operadores de la región tiene experiencia acumulada para acompañar nuevos procesos de despliegue. El protocolo está maduro, los casos de uso están documentados y el soporte existe. Lo que queda es la decisión de empezar -o de terminar- correctamente lo que ya se comenzó
