Resumen

  • IPv4 como servicio no elimina la dependencia de IPv4: la traslada a DNS64, el descubrimiento de prefijo, el CLAT, el estado del PLAT y los puertos compartidos.
  • IPv6 nativo puede seguir funcionando mientras fallan sólo los nombres IPv4, las direcciones literales o las sesiones traducidas que ya estaban abiertas.
  • La prueba operativa debe relacionar resolver, Pref64, CLAT, estado y conmutación del PLAT, atribución temporal y límites de entrada.

Un usuario cambia el servidor DNS del router doméstico. Los servicios con IPv6 nativo siguen respondiendo. Un destino que sólo publica un registro A deja de recibir una dirección AAAA sintetizada y desaparece. En otro hogar el mismo destino continúa disponible porque el CLAT acepta el paquete IPv4 y conoce por otro mecanismo el prefijo de traducción. Las dos conexiones de banda ancha parecen “activas”.

Ese fallo selectivo resume IPv4-as-a-Service. El operador puede retirar IPv4 de gran parte del acceso o del núcleo y conservar acceso a servidores IPv4 mediante traducción. La compatibilidad deja de ser una dirección entregada de extremo a extremo y pasa a ser una cadena cuyos controles pertenecen al resolver, al equipo del usuario, al enrutamiento y al traductor del proveedor.

Sintetizar AAAA no garantiza el camino

RFC 6147 define DNS64. Si una consulta AAAA encuentra sólo un registro A, DNS64 puede incrustar la dirección IPv4 en un prefijo IPv6, Pref64::/n. El cliente envía tráfico IPv6 hacia esa representación.

Para que funcione, el prefijo de la respuesta debe corresponder al traductor que recibirá el paquete. Resolver y NAT64 no negocian esa relación en cada consulta. Una respuesta sintética demuestra que se construyó una dirección; no demuestra que el PLAT tenga capacidad, comparta el mismo prefijo ni conserve el estado de la sesión.

DNSSEC obliga a declarar dónde se valida y dónde se sintetiza, porque DNS64 altera una respuesta. Un recibo serio registra el resolver, los conjuntos A y AAAA, el resultado DNSSEC y el Pref64 observado. Un simple “DNS responde” no basta.

El CLAT cubre literales, no recrea todo IPv4

RFC 6877 describe 464XLAT. El CLAT, sin estado y situado en el terminal o en el equipo de cliente, transforma IPv4 en IPv6. El PLAT del operador mantiene estado y convierte el tráfico de nuevo a IPv4. Una aplicación que usa nombres puede beneficiarse de DNS64 y una sola traducción con estado; una que usa un literal IPv4 o una API antigua necesita el paso del CLAT.

Por eso el cambio de resolver no tiene un efecto único. RFC 8683 explica que NAT64 sin CLAT puede perder destinos IPv4 si el usuario elige un DNS externo que no sintetiza. Con 464XLAT, el flujo puede sobrevivir sin DNS64 si el CLAT descubre el Pref64 correcto. Si el resolver sintetiza otro prefijo, la dirección puede apuntar fuera del PLAT previsto.

La arquitectura tampoco promete IPv4 completo. RFC 6877 la limita al modelo cliente-servidor hacia servidores IPv4 con dirección global. No ofrece por sí sola entrada IPv4 general ni cualquier modalidad entre pares. Esas exclusiones deben figurar en la oferta y en las pruebas de soporte.

Pref64 se descubre, se acota y caduca

RFC 8781 define una opción PREF64 en los anuncios de router IPv6. Incluye longitud de prefijo y tiempo de vida; cero significa que el host debe dejar de usarlo. El valor se trata como propio de la interfaz y, cuando existe ese modelo, del dominio de aprovisionamiento. Los routers deberían registrar anuncios incompatibles en el mismo enlace.

El control operativo debe guardar cómo se aprendió el prefijo, su valor y vida restante, la interfaz o PvD y la coherencia de los anuncios. Un prefijo antiguo puede sobrevivir al traductor; uno demasiado corto puede caducar antes de la siguiente información útil.

Alta disponibilidad no equivale a continuidad de estado

RFC 6146 define NAT64 con estado. El PLAT conserva enlaces y sesiones para que el retorno encuentre al cliente IPv6. También debe limitar recursos dedicados a fragmentos para evitar agotamiento. La norma no convierte automáticamente dos equipos en una sola tabla de sesiones.

Tras una conmutación, las conexiones nuevas pueden funcionar y las existentes caer. Una sonda que abre TCP después del cambio verá éxito aunque se hayan perdido pagos, descargas o túneles. La prueba necesaria mantiene una sesión antes y después, identifica el PLAT activo, mide margen de estado y vincula el resultado al evento de conmutación.

RFC 9099 añade que NAT64 puede sufrir presión sobre el estado, que DNS64 interactúa con DNSSEC y que la mayoría de usos de IPsec necesitan encapsulación UDP para atravesar esta frontera. Usar 464XLAT sin DNS64 evita la síntesis, no los demás riesgos.

Ahorrar direcciones crea una obligación de atribución

RFC 9313 compara cinco tecnologías IPv4aaS. En 464XLAT, el NAT64 del operador conserva estado por flujo y asigna puertos públicos de forma dinámica. Ese diseño puede compartir IPv4 con eficiencia, pero concentra capacidad y registros.

Si varios clientes usan la misma dirección pública, atribuir una dirección y un puerto exige un mapa ligado a un instante. Registrar cada sesión cuesta almacenamiento y proceso. Asignar bloques de puertos durante más tiempo reduce registros y sacrifica eficiencia. La decisión también depende de la ley; la RFC no fija una conservación universal.

El estado del operador tampoco concede automáticamente un puerto público entrante. Puede hacer falta PCP o una correspondencia explícita. Presentar ese límite como un defecto accidental impide gestionar las expectativas.

Las RFC no aportan un censo mundial de 2026, ni un ahorro o rendimiento universal, ni una tasa típica de fallo. Sí permiten describir y comprobar la cadena de control.

Fuentes

  1. RFC 6146 — NAT64 con estado
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — despliegue de NAT64/464XLAT
  5. RFC 8781 — descubrimiento de PREF64
  6. RFC 9099 — seguridad operativa en IPv6
  7. RFC 9313 — tecnologías IPv4aaS