NAT64 con IPv4 es la t\u00e9cnica que permite a redes IPv6-only llegar a recursos IPv4 mediante traducci\u00f3n de protocolo, y para muchos operadores con reservas de direcciones p\u00fablicas justas se ha vuelto imprescindible. Los pools de los RIR hace tiempo que se agotaron, y en el mercado secundario una direcci\u00f3n cuesta entre 30 y 50 USD. \u00bfMantener un parque IPv4 completo para clientes que mayoritariamente navegan en IPv6? Ya no cuadra. En esta gu\u00eda pr\u00e1ctica veremos cu\u00e1ndo tiene sentido desplegar NAT64, c\u00f3mo dise\u00f1ar la arquitectura y, sobre todo, c\u00f3mo dimensionar el pool de IPv4 para que el ahorro sea real sin degradar la experiencia del usuario.<\/p>\n
El escenario t\u00edpico: 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\u00fablica a cada abonado mediante DHCP, ese \/24 se agota en 256 clientes. Y el crecimiento te obliga a comprar o alquilar m\u00e1s espacio. Con NAT64 la cosa cambia: los clientes trabajan en IPv6 puro y solo el tr\u00e1fico hacia destinos IPv4 atraviesa el traductor, compartiendo el pool.<\/p>\n
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 \u2014Google, Meta, Netflix y Cloudflare son plenamente accesibles por IPv6 desde hace a\u00f1os\u2014. El coste de oportunidad tambi\u00e9n 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.<\/p>\n
Pero ojo con el matiz: NAT64 no sustituye a un AS con tr\u00e1nsito IPv4 propio. Si tus clientes son mayoritariamente gamers, usuarios de VPN o acceden a servicios sin IPv6, el ratio de traducci\u00f3n ser\u00e1 alto y necesitar\u00e1s m\u00e1s direcciones de las que parece a primera vista. Analiza tus flujos antes de decidir. Siempre.<\/p>\n
El despliegue est\u00e1ndar combina tres piezas, definidas en los RFC 6146, 6147 y 6052:<\/p>\n
Un detalle cr\u00edtico que muchos descubren tarde: si usas el prefijo 64:ff9b::\/96<\/em>, solo funcionar\u00e1 el tr\u00e1fico hacia IPv4 literales y dominios con A puro; los hairpinning<\/em> hacia tus propios servicios IPv4 requieren prefijos espec\u00edficos o doble traducci\u00f3n. Si despliegas 464XLAT (imprescindible para Android y para aplicaciones con IPv4 literales incrustadas), a\u00f1ades un clat en el CPE que encapsula IPv4 en IPv6 antes del NAT64. Considera tambi\u00e9n 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.<\/p>\n La pregunta del mill\u00f3n. La m\u00e9trica de referencia es el ratio de sesiones por IP<\/strong>, no usuarios por IP. Cada direcci\u00f3n 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\u00e1fico IPv6 domina.<\/p>\n Y una last thing que casi nadie hace desde el primer d\u00eda: monitoriza el consumo de puertos y los descartes por agotamiento. Si ves saturaci\u00f3n, ampl\u00eda el pool con otro \/24. Comprarlo a precio de mercado puede ser caro, pero alquilar espacio a trav\u00e9s de una plataforma con vendedores verificados como IP4 Market te da flexibilidad para ajustar capacidad sin inmovilizar capital, con la opci\u00f3n de compra m\u00e1s adelante si el crecimiento lo justifica.<\/p>\n Validado el NAT64 en laboratorio, llega la parte que de verdad aprieta: producci\u00f3n. Ah\u00ed 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\u00f3n Stateless IP\/ICMP) te deja balancear tr\u00e1fico entre varios nodos con ECMP sin pelear con la sincronizaci\u00f3n de tablas NAT. \u00bfQue 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.<\/p>\n Luego est\u00e1 el logging. Cr\u00edtico, sobre todo si operas como ISP o hosting y te pueden llegar requerimientos legales o denuncias por abuso. Registra cada asignaci\u00f3n de IPv6 a IPv4 con marca temporal y exporta los logs a un colector central v\u00eda syslog o IPFIX. En NAT64 con estado, ajusta la retenci\u00f3n de los flows a tu normativa local (en Espa\u00f1a, la Ley de Conservaci\u00f3n de Datos para operadores electr\u00f3nicos marca los requisitos); con clientes empresariales, normalmente bastan 30-90 d\u00edas. Y correlaciona esos logs con tu SIEM: as\u00ed detectas patrones de escaneo o abusos que salen desde el pool compartido.<\/p>\n En el plano del enrutamiento, publica la ruta hacia tu prefijo IPv6 NAT64 y valida con RPKI que todo lo que anuncias \u2014el \/96 o \/64 de traducci\u00f3n y los \/24 IPv4 del pool\u2014 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\u00f3lo origina \/48 m\u00e1s espec\u00edficas, crea el ROA con el maxLength adecuado o el BGP de tus pares rechazar\u00e1 las rutas. Sin drama, sin aviso. Simplemente dejas de estar alcanzable para parte de Internet.<\/p>\n 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\u00e1s pasar\u00e1 por DNS64\/NAT64. Para esos casos la \u00fanica salida es NAT64 con prefijo configurado y descubrimiento mediante RFC 7050, o soporte en la propia aplicaci\u00f3n para resolver v\u00eda prefijo. Antes de migrar, audita tu c\u00f3digo y tu configuraci\u00f3n buscando cadenas IP. Todas.<\/p>\n El segundo bloque t\u00edpico son las aplicaciones que ignoran el registro AAAO… perd\u00f3n, AAAA, o que fallan por un Happy Eyeballs (RFC 8305) mal implementado. Los servicios heredados que s\u00f3lo hacen consultas A y conf\u00edan en la direcci\u00f3n devuelta para conexiones directas fallar\u00e1n en silencio, que es lo peor: ni error claro ni stack trace. Prueba siempre con las aplicaciones cr\u00edticas de tu stack. Bases de datos, agentes de monitorizaci\u00f3n, 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 \u2014SIP, FTP activo, H.323\u2014 no funcionan a trav\u00e9s de NAT64 sin un ALG espec\u00edfico.<\/p>\n 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\u00e1 a una IP que sirve a much\u00edsima gente a la vez. Documenta bien tu capacidad de correlaci\u00f3n, porque el d\u00eda que te reporten un abuso desde tu rango vas a necesitar responder con datos, no con buenas intenciones.<\/p>\n Consejo pr\u00e1ctico:<\/strong> mant\u00e9n una lista de aplicaciones incompatibles documentada y una v\u00eda de escape para esos flujos (por ejemplo, un APN o VLAN con IPv4 nativo temporal). Y no des de baja el \u00faltimo \/24 IPv4 de tu red hasta validar que todos los flujos cr\u00edticos operan correctamente v\u00eda NAT64 durante al menos un mes completo de ciclo de negocio. Un mes entero, no una semana buena.<\/p>\n<\/div>\n 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\u00f3n de 1:100 o superiores en perfiles de navegaci\u00f3n t\u00edpica. Para un ISP u operador de hosting que ya agot\u00f3 sus reservas propias, significa seguir creciendo sin comprar IPv4 a precios de mercado elevados desde el primer d\u00eda. Eso s\u00ed, no me gusta venderlo como soluci\u00f3n definitiva, porque no lo es: los ALGs que no existen, las aplicaciones con IPv4 literal y la trazabilidad de un pool compartido imponen l\u00edmites que conviene tener identificados antes de migrar tr\u00e1fico real.<\/p>\n Mi recomendaci\u00f3n pr\u00e1ctica: 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\u00f3n de tu espacio propio. Para esa ampliaci\u00f3n, 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 \u2014NAT64 para eficiencia inmediata y una estrategia de adquisici\u00f3n de IPv4 para el medio plazo\u2014 tu red queda preparada para el agotamiento definitivo del espacio IPv4 sin sacrificar servicio ni margen.<\/p>\nDimensionamiento del pool: cu\u00e1ntas IPv4 necesitas realmente<\/h2>\n
\n
Configuraci\u00f3n en producci\u00f3n: alta disponibilidad, logging y RPKI<\/h2>\n
Checklist antes de cortar tr\u00e1fico real<\/h3>\n
\n
Errores comunes y problemas de compatibilidad con aplicaciones<\/h2>\n
Conclusi\u00f3n: NAT64 como puente mientras ampl\u00edas tus reservas<\/h2>\n