IPv6 para ISPs en Latinoamérica: por qué ya no hay excusa para esperar
El agotamiento del espacio IPv4 no es una predicción: es un hecho consumado. IANA asignó su último bloque de /8 en 2011. LACNIC —el registro de direcciones de internet para Latinoamérica— agotó sus reservas para nuevas asignaciones directas hace años. Hoy, un ISP que necesita espacio IPv4 adicional tiene que comprarlo en el mercado secundario a costos que crecen cada año.
Mientras tanto, IPv6 lleva más de una década lista para producción. La mayoría de los sistemas operativos modernos la soportan por defecto. Los grandes CDN, nubes públicas y plataformas de contenido tienen IPv6 nativo hace tiempo. Y aún así, muchos ISPs en Latinoamérica siguen operando exclusivamente sobre IPv4 con CGNAT como solución de corto plazo que se extendió indefinidamente.
Este artículo no es un evangelio tecnológico. Es un análisis práctico de por qué el momento de implementar IPv6 ya pasó, y cómo hacerlo sin romper el servicio a tus clientes actuales.
El problema real con CGNAT
CGNAT (Carrier-Grade NAT) fue diseñado como solución transitoria para estirar el espacio IPv4 mientras se completaba la migración a IPv6. En la práctica, se convirtió en una solución permanente en muchas redes, con costos que se suelen subestimar:
Costo operativo: Un equipo CGNAT de capacidad adecuada para un ISP mediano (50.000–200.000 suscriptores) tiene un costo significativo en hardware y licencias. Ese costo escala con el crecimiento de la base de clientes.
Problemas de aplicaciones: CGNAT rompe aplicaciones que asumen una IP pública única por sesión. VPNs IPsec, algunos juegos online, aplicaciones de videoconferencia, y servicios P2P tienen problemas frecuentes en entornos CGNAT. Estos problemas generan tickets de soporte difíciles de diagnosticar y resolver.
Trazabilidad y cumplimiento legal: En varios países de Latinoamérica, las regulaciones exigen que los ISPs puedan identificar al suscriptor asociado a una IP en un momento dado. Con CGNAT, esa trazabilidad requiere guardar logs de traducción (source IP + port + timestamp) a volúmenes que pueden superar los 100GB diarios para ISPs grandes. El costo de storage y la complejidad del sistema de logs es un overhead permanente.
Latencia agregada: Cada paquete pasa por una capa adicional de traducción. En la práctica el impacto es bajo en latencia promedio, pero en conexiones sensibles (gaming, VoIP, trading) puede ser medible.
CGNAT no es el problema en sí: es un síntoma de no haber invertido en IPv6 a tiempo. Cada año que pasa, el costo de eliminar CGNAT crece porque la infraestructura construida alrededor de él se hace más compleja.
Por qué IPv6 es mejor para tu red (no solo para tus clientes)
La narrativa habitual de IPv6 se centra en “más direcciones”. Pero para un operador de red, los beneficios más relevantes son otros:
Fin del NAT en la red de clientes: Cada suscriptor recibe un prefijo IPv6 propio (típicamente un /56 o /48). Las aplicaciones funcionan de punto a punto sin traducción, lo que elimina toda una clase de problemas de conectividad.
Enrutamiento más limpio: IPv6 fue diseñado con enrutamiento jerárquico eficiente desde el principio. La ausencia de NAT y las direcciones más estructuradas simplifican las tablas de ruteo y el debugging de tráfico.
Mejor soporte de multicast: IPv6 usa multicast extensivamente (reemplaza broadcast de ARP con Neighbor Discovery). Para ISPs con servicios IPTV o multicast, esto es relevante.
Preparación para IoT y 5G: Los dispositivos IoT —medidores inteligentes, cámaras, sensores— se despliegan en cantidades que hacen CGNAT insostenible. El modelo correcto para IoT a escala es IPv6 con prefijo propio por dispositivo o por hogar.
Eliminación del mercado secundario de IPv4: Una vez que la mayoría del tráfico de tus clientes corre sobre IPv6, la dependencia de IPv4 cae dramáticamente. El espacio IPv4 que ya tenés alcanza para el tráfico residual por mucho tiempo.
Modelos de transición: cuál aplica a tu red
No existe una única forma de desplegar IPv6. Los tres modelos más usados en ISPs son:
Dual Stack
El modelo más simple conceptualmente: cada dispositivo tiene tanto dirección IPv4 como IPv6. El tráfico fluye por IPv6 cuando el destino tiene IPv6, y por IPv4 cuando no.
Ventajas: Compatible con toda la infraestructura existente, sin necesidad de tunelización. Desventaja: Requiere IPv4 simultáneamente, por lo que no elimina CGNAT inmediatamente.
Recomendado para: Inicio de despliegue, redes que no pueden hacer cambios bruscos.
464XLAT (CLAT + PLAT)
El modelo recomendado por operadores móviles y cada vez más por ISPs de banda ancha fija. La red del operador es IPv6-only. Los clientes corren un traductor local (CLAT) que convierte el tráfico IPv4 de las aplicaciones a IPv6, y en el borde de la red un PLAT (generalmente PNAT64) lo convierte de vuelta a IPv4 para llegar a destinos IPv4-only.
Ventajas: Elimina CGNAT centralizado, reduce el parque de equipos en el core, IPv6-only en la red de distribución. Desventaja: Requiere CPEs compatibles con CLAT (todos los Android modernos y iOS 12+ lo soportan nativamente; CPEs domésticos requieren firmware actualizado).
Recomendado para: ISPs con base de clientes modernos (smartphones, routers actualizados) y disposición a hacer un cambio de arquitectura más profundo.
IPv6-mostly (RFC 8925)
IPv6-mostly es uno de los modelos de transición más prácticos para ISPs que tienen una base mixta de dispositivos modernos y legados, y representa el camino más directo hacia eliminar CGNAT sin forzar cambios disruptivos.
El problema que resuelve: En Dual Stack, el ISP asigna una dirección IPv4 a todos los clientes aunque la mayoría de su tráfico ya vaya por IPv6. Eso significa que el CGNAT sigue siendo necesario para todos. IPv6-mostly resuelve esto al separar a los clientes según su capacidad real: los dispositivos modernos que pueden operar sin IPv4 no la solicitan, y el pool de IPv4 se reserva para los que genuinamente la necesitan.
Cómo funciona — DHCP Option 108 (RFC 8925):
La clave es el DHCP Option 108, también llamado “IPv6-Only Preferred”. Cuando un cliente envía un DHCPREQUEST con esta opción, le está diciendo al servidor: “Prefiero operar sin IPv4 — no me asignes una dirección IPv4 si no es necesario”.
El servidor DHCP puede responder de dos formas:
- Si soporta Option 108: responde con un tiempo de espera (en segundos) que le indica al cliente cuánto tiempo puede operar sin IPv4. El cliente acepta y opera solo en IPv6 por ese período.
- Si no soporta Option 108: ignora la opción y asigna IPv4 normalmente. El dispositivo moderno recibe IPv4 como fallback y opera en Dual Stack.
Esto hace que IPv6-mostly sea completamente compatible hacia atrás: los dispositivos que no entienden Option 108 (equipos viejos, Windows 7, IoT legado) simplemente reciben IPv4 como siempre.
Conectividad IPv4 para dispositivos IPv6-only:
Los clientes que operan sin dirección IPv4 asignada necesitan un mecanismo para llegar a destinos IPv4-only en internet. Esto se resuelve con el par NAT64 + DNS64:
- DNS64: El resolver del ISP sintetiza registros AAAA (IPv6) para dominios que solo tienen registros A (IPv4). Convierte la dirección IPv4 destino en una IPv6 con un prefijo reservado (tipicamente
64:ff9b::/96). - NAT64: Un gateway en el borde de la red traduce el tráfico IPv6 con ese prefijo hacia el destino IPv4 real.
El resultado: el dispositivo IPv6-only puede alcanzar cualquier destino en internet sin tener una dirección IPv4 pública ni pasar por CGNAT.
Dispositivo (IPv6-only)
│
├── Destino IPv6 nativo: tráfico directo IPv6 ──────────────────► internet IPv6
│
└── Destino IPv4-only:
DNS64 genera AAAA sintética
Paquete sale por 64:ff9b::/96
NAT64 traduce → ──────────────────────────────────────────► internet IPv4
Beneficios operativos para el ISP:
- Reducción inmediata de carga CGNAT: En redes con alta penetración de smartphones (Android/iOS) y routers modernos, el 60–80% de los dispositivos pueden calificar para operar IPv6-only. Eso reduce en forma proporcional la cantidad de conexiones IPv4 que el CGNAT debe manejar.
- Transición gradual sin riesgo: El ISP habilita IPv6-mostly progresivamente. Los dispositivos que no califican siguen en Dual Stack. No hay una fecha de corte forzada.
- Sin cambios en CPEs del cliente: Option 108 es una opción DHCP estándar. Los sistemas operativos modernos (Android 10+, iOS 14+, Windows 11, macOS Monterey+) ya la soportan de fábrica. No requiere actualización de firmware del CPE del cliente.
- Mide la madurez de la red: El ratio de dispositivos que “eligen” IPv6-only es un indicador directo de qué tan lista está la base instalada del ISP para una eventual migración completa.
Lo que los ISPs deben preparar:
- Soporte de Option 108 en el servidor DHCP: Los principales DHCP servers (ISC DHCP 4.4.3+, Kea 2.0+, y la mayoría de BRAS/BNG modernos) ya lo soportan.
- Infraestructura NAT64 + DNS64: Puede implementarse con soluciones open source (TAYGA para NAT64, BIND 9.8+ o Unbound para DNS64) o en equipos de red existentes que soporten la función.
- Prefijo NAT64 anunciado por RA: El router de acceso debe anunciar el prefijo NAT64 vía Router Advertisement para que los clientes IPv6-only sepan cómo llegar a destinos IPv4.
- Excepción para aplicaciones que no usan DNS: Algunas aplicaciones (pocos casos hoy) usan IPs hardcodeadas IPv4. Para estos casos, el prefijo NAT64 no ayuda y el dispositivo necesitaría IPv4. Son casos excepcionales pero deben mapearse antes del despliegue.
IPv6-mostly en la hoja de ruta:
IPv6-mostly no es excluyente con los otros modelos — de hecho, es complementario. Un ISP puede:
- Arrancar con Dual Stack (Fase 3 de la hoja de ruta anterior).
- Habilitar Option 108 y NAT64/DNS64 en paralelo.
- Monitorear el porcentaje de clientes que eligen IPv6-only (empieza bajo, crece con cada CPE que se actualiza).
- Eventualmente migrar a IPv6-mostly como modo por defecto, con IPv4 solo para los que lo soliciten explícitamente.
Este camino permite al ISP reducir su exposición a CGNAT de forma continua y medible, sin una migración big-bang que pueda afectar a clientes.
Recomendado para: ISPs con alta penetración de smartphones y routers modernos, y que quieren reducir CGNAT sin migración disruptiva. Es el modelo de transición con mejor relación riesgo/resultado a mediano plazo.
MAP-E / MAP-T
Permite encapsular tráfico IPv4 de clientes dentro de IPv6 usando reglas determinísticas (sin estado en el operador). Es técnicamente elegante y escala bien, pero la configuración de CPEs es más compleja.
Recomendado para: Operadores con ingeniería avanzada y control total sobre los CPEs del cliente.
Hoja de ruta práctica para ISPs
Un despliegue de IPv6 que no interrumpa el servicio existente típicamente sigue estas fases:
Fase 1 — Auditoría y asignación (1-2 meses)
- Verificar qué equipos del core y distribución soportan IPv6 en la versión de firmware actual.
- Solicitar a LACNIC un bloque IPv6 propio si no se tiene uno. El proceso es sencillo y el espacio es gratuito (sin costo por tamaño del bloque).
- Definir el plan de numeración: prefijos para infraestructura de red, prefijos para clientes (política de asignación de /56 o /48 por suscriptor).
Fase 2 — Core y upstream (2-3 meses)
- Habilitar IPv6 en los equipos de core y en las sesiones BGP con upstreams/tránsito.
- Configurar anuncios BGP IPv6 con los peers de peering (IX points locales como NAP.BR, CABASE, LACIX, etc.).
- Validar que el tráfico IPv6 fluye correctamente entre el core y el uplink.
Fase 3 — Distribución y BRAS/BNG (2-4 meses)
- Habilitar DHCPv6-PD (Prefix Delegation) en el BRAS/BNG para asignar prefijos a clientes.
- Configurar RA (Router Advertisement) o SLAAC según el modelo de CPE.
- Piloto en un segmento de clientes voluntarios: validar aplicaciones, latencia, trazabilidad.
Fase 4 — Despliegue masivo y reducción de CGNAT (6-12 meses)
- Rollout de Dual Stack o 464XLAT a la base de clientes progresivamente.
- Monitorear el ratio IPv6/IPv4 de tráfico de salida para confirmar la adopción.
- A medida que el tráfico IPv4 cae, evaluar la reducción de la capacidad CGNAT instalada.
Errores comunes que frenan el despliegue
Bloquear ICMPv6: El protocolo Neighbor Discovery de IPv6 depende de ICMPv6. Filtrarlo con las mismas reglas de firewall que se usan para ICMP en IPv4 rompe la conectividad IPv6 de formas difíciles de diagnosticar. ICMPv6 types 133–137 (ND) deben siempre estar permitidos.
No asignar prefijos suficientemente grandes: Asignar un /64 a cada cliente en lugar de un /56 o /48 limita la capacidad de tener múltiples subredes en el hogar (algo cada vez más común con IoT y segmentación de redes domésticas). La práctica recomendada actual es /56 por sitio residencial y /48 por sitio empresarial.
Olvidar el DNS: Muchos despliegues configuran conectividad IPv6 pero olvidan que los resolvers DNS deben ser accesibles por IPv6. Si el resolver de tu red solo responde en IPv4, los clientes en redes IPv6-only no pueden resolver nombres.
No actualizar el sistema de trazabilidad: Con IPv6, la dirección de cliente puede ser el prefijo asignado más la dirección generada por SLAAC (privacidad de extensiones). Los sistemas de logs de autenticación y RADIUS deben registrar el prefijo asignado para mantener la trazabilidad.
El momento es ahora
“Ya lo haremos cuando sea urgente” es la lógica que llevó a la situación actual: redes que dependen de CGNAT para funcionar, deuda técnica que crece, y costo de migración que aumenta cada año.
En Ayuda.LA acompañamos a ISPs en el diseño e implementación de migraciones IPv6, desde la auditoría inicial hasta el despliegue en producción. El proceso es gradual y no requiere interrumpir el servicio existente.
Conocé más sobre nuestros servicios de networking y consultoría para ISPs.
¿Querés evaluar el estado IPv6 de tu red?
Podemos hacer un diagnóstico rápido de tu arquitectura actual e identificar la ruta más directa para implementar IPv6 sin riesgo operativo.
¿Tenés dudas sobre IPv6 para tu red? Escribinos a [email protected] — respondemos todos los mensajes.