NAT64 con reservas limitadas de IPv4: guía práctica

NAT64 con IPv4 es la técnica que permite a redes IPv6-only llegar a recursos IPv4 mediante traducción de protocolo, y para muchos operadores con reservas de direcciones públicas justas se ha vuelto imprescindible. Los pools de los RIR hace tiempo que se agotaron, y en el mercado secundario una dirección cuesta entre 30 y 50 USD. ¿Mantener un parque IPv4 completo para clientes que mayoritariamente navegan en IPv6? Ya no cuadra. En esta guía práctica veremos cuándo tiene sentido desplegar NAT64, cómo diseñar la arquitectura y, sobre todo, cómo dimensionar el pool de IPv4 para que el ahorro sea real sin degradar la experiencia del usuario.

¿Por qué NAT64 cuando tus reservas de IPv4 son limitadas?

El escenario típico: un ISP o un operador de hosting que ha migrado su red de acceso a IPv6-only (con dual-stack solo donde es imprescindible) y conserva, pongamos, un /24 o un /23 de IPv4. Si asignas IPv4 pública a cada abonado mediante DHCP, ese /24 se agota en 256 clientes. Y el crecimiento te obliga a comprar o alquilar más espacio. Con NAT64 la cosa cambia: los clientes trabajan en IPv6 puro y solo el tráfico hacia destinos IPv4 atraviesa el traductor, compartiendo el pool.

Las ventajas son claras. Reduces la dependencia de CGNAT tradicional, que igualmente comprime muchos clientes por IP pero te obliga a sostener doble infraestructura. Simplificas la red de acceso. Y alineas tu estrategia con la tendencia de los grandes contenidos —Google, Meta, Netflix y Cloudflare son plenamente accesibles por IPv6 desde hace años—. El coste de oportunidad también pesa: cada IPv4 que liberas puede venderse o alquilarse. En un mercado donde un /24 bien administrado se alquila por unos 150-250 USD al mes, una red con 5 000 abonados puede liberar uno o dos bloques completos y convertirlos en ingresos recurrentes o en reserva para ventas futuras. Plataformas como IP4 Market, con vendedores verificados y precios competitivos, sirven tanto para adquirir el bloque inicial del pool como para monetizar el espacio liberado.

Pero ojo con el matiz: NAT64 no sustituye a un AS con tránsito IPv4 propio. Si tus clientes son mayoritariamente gamers, usuarios de VPN o acceden a servicios sin IPv6, el ratio de traducción será alto y necesitarás más direcciones de las que parece a primera vista. Analiza tus flujos antes de decidir. Siempre.

Arquitectura de referencia: DNS64, stateful NAT64 y pool IPv4

El despliegue estándar combina tres piezas, definidas en los RFC 6146, 6147 y 6052:

1. Servidor DNS64: intercepta las consultas AAAA sin respuesta y sintetiza un registro AAAA a partir del A, encapsulando la IPv4 destino en el prefijo bien conocido 64:ff9b::/96 o en un prefijo propio de tu AS.
2. Stateful NAT64: el gateway que traduce paquetes IPv6 a IPv4, mantiene tabla de sesiones y reescribe cabeceras. Jool es la implementación de referencia en Linux; también lo soportan routers de Nokia, Cisco y Juniper.
3. Pool IPv4: el bloque público que el NAT64 usa para las direcciones de salida, normalmente con PAT (NAPT) para multiplicar sesiones por dirección.

Un detalle crítico que muchos descubren tarde: si usas el prefijo 64:ff9b::/96, solo funcionará el tráfico hacia IPv4 literales y dominios con A puro; los hairpinning hacia tus propios servicios IPv4 requieren prefijos específicos o doble traducción. Si despliegas 464XLAT (imprescindible para Android y para aplicaciones con IPv4 literales incrustadas), añades un clat en el CPE que encapsula IPv4 en IPv6 antes del NAT64. Considera también firmar tus rutas con RPKI/ROA y publicar el pool desde tu propio AS: una IP compartida por cientos de clientes con mala higiene puede arrastrar a todos a listas de bloqueo, y salir de ellas es un proceso lento y desagradable.

Dimensionamiento del pool: cuántas IPv4 necesitas realmente

La pregunta del millón. La métrica de referencia es el ratio de sesiones por IP, no usuarios por IP. Cada dirección IPv4 en un stateful NAT64 soporta ~64 000 puertos con NAPT, y la industria trabaja habitualmente con ratios de 500:1 a 1 000:1 usuarios por IP cuando el tráfico IPv6 domina.

• Mide antes de desplegar: en un dual-stack previo, analiza qué porcentaje del tráfico de tus usuarios es realmente IPv4. En redes residenciales europeas suele situarse entre el 5 % y el 15 % de los flujos.
• Aplica el ratio conservador: para 5 000 abonados con 15 % de tráfico IPv4, un /24 con ratio 500:1 da margen amplio; muchos operadores arrancan con un /24 por cada 3 000-5 000 abonados.
• Vigila los límites por cliente: implementa un límite de puertos por usuario (por ejemplo 1 024-4 096) para evitar que un solo abonado con torrents agote el pool entero.
• Deja colchón para logging: si debes cumplir retención de logs (normativa europea), calcula si tu plataforma soporta port-based logging o si necesitas deterministic NAT, que reduce el ratio efectivo.

Y una last thing que casi nadie hace desde el primer día: monitoriza el consumo de puertos y los descartes por agotamiento. Si ves saturación, amplía el pool con otro /24. Comprarlo a precio de mercado puede ser caro, pero alquilar espacio a través de una plataforma con vendedores verificados como IP4 Market te da flexibilidad para ajustar capacidad sin inmovilizar capital, con la opción de compra más adelante si el crecimiento lo justifica.

Configuración en producción: alta disponibilidad, logging y RPKI

Validado el NAT64 en laboratorio, llega la parte que de verdad aprieta: producción. Ahí hay tres frentes que no conviene descuidar. El primero, la alta disponibilidad. Mi consejo: evita el estado en el gateway siempre que puedas. Un NAT64 sin estado (con el prefijo 64:ff9b::/96 y el algoritmo de Traducción Stateless IP/ICMP) te deja balancear tráfico entre varios nodos con ECMP sin pelear con la sincronización de tablas NAT. ¿Que necesitas estado por usar pools IPv4 compartidos? Entonces despliega pares activo/pasado con VRRP y sesiona ese estado, o al menos dos gateways con afinidad de flujo por hash.

Luego está el logging. Crítico, sobre todo si operas como ISP o hosting y te pueden llegar requerimientos legales o denuncias por abuso. Registra cada asignación de IPv6 a IPv4 con marca temporal y exporta los logs a un colector central vía syslog o IPFIX. En NAT64 con estado, ajusta la retención de los flows a tu normativa local (en España, la Ley de Conservación de Datos para operadores electrónicos marca los requisitos); con clientes empresariales, normalmente bastan 30-90 días. Y correlaciona esos logs con tu SIEM: así detectas patrones de escaneo o abusos que salen desde el pool compartido.

En el plano del enrutamiento, publica la ruta hacia tu prefijo IPv6 NAT64 y valida con RPKI que todo lo que anuncias —el /96 o /64 de traducción y los /24 IPv4 del pool— tenga su ROA bien creado en el RIR correspondiente. Ojo con este detalle, porque es un error que veo una y otra vez: el ROA con maxLength mal configurado en el prefijo NAT64. Si anuncias 2a00:xxxx::/32 pero el gateway sólo origina /48 más específicas, crea el ROA con el maxLength adecuado o el BGP de tus pares rechazará las rutas. Sin drama, sin aviso. Simplemente dejas de estar alcanzable para parte de Internet.

Checklist antes de cortar tráfico real

1. Verifica que los DNS64 sólo se anuncian a clientes compatibles y que los registros AAAA falsos tienen TTL bajo (60-300 segundos) para poder retirarlos rápido.
2. Prueba MTU con paquetes de 1500 bytes y comprueba que el PMTUD funciona: dropa de forma explícita con ICMP Packet Too Big, nunca en silencio.
3. Monitoriza la ocupación del pool IPv4 con alertas al 70% y 85%.
4. Mide latencia NAT64 frente a acceso IPv4 nativo para detectar degradación.

Errores comunes y problemas de compatibilidad con aplicaciones

El primero de la lista es viejo conocido: direcciones IPv4 literales hardcodeadas en aplicaciones o scripts. Un cliente que conecta a 203.0.113.50 directamente jamás pasará por DNS64/NAT64. Para esos casos la única salida es NAT64 con prefijo configurado y descubrimiento mediante RFC 7050, o soporte en la propia aplicación para resolver vía prefijo. Antes de migrar, audita tu código y tu configuración buscando cadenas IP. Todas.

El segundo bloque típico son las aplicaciones que ignoran el registro AAAO… perdón, AAAA, o que fallan por un Happy Eyeballs (RFC 8305) mal implementado. Los servicios heredados que sólo hacen consultas A y confían en la dirección devuelta para conexiones directas fallarán en silencio, que es lo peor: ni error claro ni stack trace. Prueba siempre con las aplicaciones críticas de tu stack. Bases de datos, agentes de monitorización, VPNs IPSec y algunos clientes SIP son los sospechosos habituales (y rara vez fallan solos). IPSec y los protocolos que incrustan direcciones IP en el payload —SIP, FTP activo, H.323— no funcionan a través de NAT64 sin un ALG específico.

Hay un tercero que se olvida mucho: el logging del lado IPv4. Si tu pool lo comparten miles de clientes IPv6, cualquier abuso saliente se atribuirá a una IP que sirve a muchísima gente a la vez. Documenta bien tu capacidad de correlación, porque el día que te reporten un abuso desde tu rango vas a necesitar responder con datos, no con buenas intenciones.

Conclusión: NAT64 como puente mientras amplías tus reservas

NAT64 con IPv4 es una estrategia madura y estandarizada. Permite operar servicios y clientes IPv6-only con un pool IPv4 muy reducido, con ratios de compartición de 1:100 o superiores en perfiles de navegación típica. Para un ISP u operador de hosting que ya agotó sus reservas propias, significa seguir creciendo sin comprar IPv4 a precios de mercado elevados desde el primer día. Eso sí, no me gusta venderlo como solución definitiva, porque no lo es: los ALGs que no existen, las aplicaciones con IPv4 literal y la trazabilidad de un pool compartido imponen límites que conviene tener identificados antes de migrar tráfico real.

Mi recomendación práctica: trata el NAT64 como puente temporal. Despliega la infraestructura, valida la compatibilidad de aplicaciones, deja el logging y el RPKI bien atados, y en paralelo planifica la ampliación de tu espacio propio. Para esa ampliación, IP4 Market te permite comprar o alquilar bloques con vendedores verificados y precios competitivos, de forma que puedas pasar del pool compartido a IPv4 dedicado cuando el volumen de negocio lo justifique. Combinando ambas herramientas —NAT64 para eficiencia inmediata y una estrategia de adquisición de IPv4 para el medio plazo— tu red queda preparada para el agotamiento definitivo del espacio IPv4 sin sacrificar servicio ni margen.