Resumen

  • RFC 9872 aconseja obtener PREF64 mediante la opción de Router Advertisement de RFC 8781 cuando esté disponible, y reservar RFC 7050 para ausencia de la señal o compatibilidad heredada.
  • En un equipo multihomed, la evidencia útil no es el prefijo aislado, sino su asociación temporal con router, origen IPv6, siguiente salto y resultado del traductor.

El error no exige que nadie anuncie datos inválidos. Basta con que un equipo reciba un PREF64 válido del proveedor A, sintetice una dirección y seleccione la fuente y el router del proveedor B. La cadena contiene piezas correctas, pero el traductor de A no está en el camino de B.

Ese es el problema operativo que ordena RFC 9872. El documento de consenso IETF, publicado en septiembre de 2025, recomienda que los hosts busquen primero la opción PREF64 definida por RFC 8781 y que los operadores NAT64 la incluyan en sus anuncios de router. La heurística DNS de RFC 7050 sigue disponible cuando no hay opción o el sistema es antiguo.

PREF64 es el prefijo IPv6 con el que se componen destinos traducibles hacia IPv4. RFC 6052 delimita sus formatos. Conocerlo habilita DNS64 local según RFC 6147, CLAT dentro de 464XLAT y la conversión de literales IPv4 contemplada por RFC 8305. Ninguna de esas facultades garantiza un egreso.

RFC 7050 observa respuestas AAAA sintetizadas para ipv4only.arpa.. RFC 8880 convierte ese nombre en un caso especial. El método necesita el DNS64 de la red o lógica específica en aplicaciones y resolutores locales. Un resolutor alternativo o un VPN con túnel dividido puede sustituir el DNS sin llevarse todo el tráfico, dejando al host sin el PREF64 local o sin forma de asociarlo al enlace correcto.

El multihoming vuelve visible la pérdida. Dos DNS64 pueden devolver dos prefijos. La respuesta no dice de manera fiable qué ISP, prefijo fuente o gateway corresponde a cada uno. Por tanto, “PREF64 descubierto” no es una condición operativa completa. Hace falta registrar la procedencia que permita seleccionar el camino compatible.

Una Router Advertisement conserva esa vecindad. RFC 4861 ya transporta presencia de routers y parámetros IPv6. RFC 8781 incorpora el prefijo y su tiempo de vida. El host puede mantener la pareja router–PREF64 y retirar el uso cuando recibe vida cero. Es una relación local verificable, no una garantía universal: el anuncio todavía puede ser hostil o estar equivocado y el traductor puede no responder.

También cambia quién controla la caducidad. La consulta DNS ocurre después de configurar la pila y queda condicionada por un TTL que tal vez pertenezca a un servicio externo. El operador no siempre puede revocar de inmediato un prefijo aprendido. Un anuncio nuevo puede actualizarlo o retirarlo sin desconectar al equipo. Lo importante es reducir el intervalo de estado incorrecto.

La seguridad no desaparece; cambia de superficie. Al no derivar PREF64 de una respuesta DNS se evita esa vía de falsificación, pero la protección del primer salto gana peso. RFC 6105 define RA-Guard y RFC 8781 mantiene sus cautelas. RFC 9463 permite anunciar resolutores designados y cifrados; la confidencialidad del DNS no crea por sí sola el vínculo con el egreso.

La migración necesita inventario, no fe. Los hosts conformes que entienden RFC 8781 deben preferirla, mientras los antiguos pueden necesitar RFC 7050. RFC 9872 además reconoce que algunos equipos de redes móviles aún no pueden insertar la opción aunque los sistemas operativos móviles la soporten. El registro oficial demuestra la publicación, no el despliegue de una red concreta.

La primacía del código operativo de Heng Lu exige comprobar la ruta, no venerar el anuncio. Su idea de especificación inicial mínima favorece un dato común estrecho con decisiones locales. Su análisis del impuesto dual-stack permanente obliga a contabilizar el coste de mantener heurística, RA, seguridad y traducción a la vez.

RFC 9872 no convierte un prefijo en autoridad. Restituye el contexto suficiente para que un terminal tome una decisión mejor y para que un operador pueda reconstruirla después.

Fuentes