Resumen

  • RFC 9872 recomienda obtener el prefijo de síntesis NAT64 desde la opción PREF64 de los anuncios de router definida en RFC 8781.
  • La señal no solo entrega una cadena de bits: conserva la relación entre prefijo, vigencia, red de acceso y ruta hacia el traductor.

La decisión crítica ocurre antes del primer paquete traducido. El equipo ya está en una red solo IPv6 y conoce el destino IPv4, pero para sintetizar una dirección IPv6 necesita un prefijo que el traductor NAT64 de esa red reconozca. Un prefijo válido aprendido en el contexto equivocado produce una dirección bien formada que puede resultar inalcanzable.

RFC 9872 sitúa esa configuración junto al proceso de conexión. El equipo debería buscar primero PREF64 en los anuncios de router según RFC 8781, y el operador que despliega NAT64 debería incluirlo allí. El mecanismo DNS de RFC 7050 sigue disponible cuando el anuncio no contiene la opción o el equipo no puede procesarla, pero pasa a ser una alternativa consciente.

El anuncio transporta ámbito y tiempo

RFC 8781 reserva el tipo 38 de Neighbor Discovery para PREF64. La opción contiene el prefijo, un código de longitud y una vigencia en unidades de ocho segundos. Una vigencia cero retira el prefijo. La recomendación evita que su vigencia sea menor que la del router predeterminado, porque el prefijo podría caducar mientras el camino que lo anunció aún parece activo.

El equipo debe tratar PREF64 como información propia de la red donde lo recibió. Si implementa Provisioning Domains, debe vincularlo al PvD correspondiente. Puede usar cualquiera de varios prefijos anunciados con vigencia no nula, pero RFC 8781 recomienda elegir una sola fuente cuando coexisten distintos métodos de descubrimiento.

En una red multihomed, esta asociación evita separar el dato de su camino. El tráfico sintetizado con el prefijo de un proveedor tiene que salir por un enlace que alcance el traductor de ese proveedor. Guardar solo el valor y olvidar la interfaz destruye la evidencia necesaria para elegir correctamente.

DNS puede observar otra red

RFC 7050 obtiene PREF64 consultando a un resolvedor DNS64 por un nombre IPv4 especial y analizando las respuestas AAAA sintetizadas. Sin embargo, DNS cifrado, una VPN o una configuración manual pueden desplazar el resolvedor fuera de la red de acceso. Ese resolvedor puede no conocer el prefijo del traductor local.

La caché introduce otro desfase. La información descubierta por DNS permanece según su TTL, mientras que un anuncio de router puede comunicar un cambio o una retirada con vigencia cero directamente en el enlace. La autoridad que configura el camino puede así modificar también el dato que permite usarlo.

La recomendación está en RFC 9872, el formato en RFC 8781 y la alternativa DNS en RFC 7050. RFC 6052 define los formatos de direcciones IPv4 embebidas y RFC 7915 la traducción sin estado. Su publicación no demuestra adopción, disponibilidad ni rendimiento actuales.

Descubrir PREF64 tampoco autentica el anuncio, prueba que el traductor sea alcanzable, demuestra despliegue o rendimiento, ni convierte el Well-Known Prefix de RFC 6052 en una opción válida para toda red NAT64. Cada una de esas cinco afirmaciones requiere evidencia independiente.