Summary

  • El IESG abrió el 2 de noviembre la última consulta de draft-ietf-v6ops-nat64-wkp-1918-10; los comentarios vencen el 23 de noviembre.
  • El borrador propone traducir direcciones IPv4 privadas y compartidas bajo 64:ff9b::/96. La versión 10 añade una recomendación para exponer la conducta predeterminada de cada traductor gestionado.

Una prohibición fácil de escribir

La RFC 6052 impone una instrucción tajante: el prefijo conocido de NAT64 no debe representar direcciones IPv4 sin alcance global y el traductor debe descartar esos paquetes. Para un cliente solo IPv6 que necesita llegar a un servidor IPv4 interno, esa frase define dónde termina una ruta posible.

El aviso del 2 de noviembre somete a examen otra regla. La versión 10 permitiría representar direcciones privadas de RFC 1918 y direcciones compartidas de RFC 6598 con 64:ff9b::/96. Los CLAT no gestionados tendrían que traducirlas por defecto. Los PLAT gestionados tendrían que hacerlo salvo que su configuración disponga otra cosa, y ofrecer una opción para desactivar la traducción. La prohibición universal deja espacio a una política de red elegida por su operador.

La justificación técnica también tiene un límite concreto. Según el borrador, los mecanismos de descubrimiento de prefijos NAT64 más extendidos no indican al cliente qué segmento IPv4 corresponde a cada prefijo. Si aprende dos, puede sintetizar direcciones con ambos incluso para un destino público. Los autores describen CLAT actuales que descartan y otros que ya traducen; no presentan una cifra de dispositivos afectados.

La novedad es preguntar qué hará la caja

La autorización y el interruptor para el PLAT ya estaban en la versión 09. La versión 10 incorpora el apartado 4.3: recomienda que los traductores gestionados hagan visible su valor predeterminado para destinos no globales. El operador debería comprobar con configuración explícita o supervisión que el comportamiento real coincide con la política buscada. También necesita reglas de encaminamiento adecuadas para que los paquetes lleguen a algún sitio.

El apartado de seguridad frena los cambios silenciosos en equipos ya instalados. Un PLAT que cumple la RFC 6052 y descarta por defecto debería conservar ese valor al actualizarse. Por eso la misma etiqueta técnica puede cubrir dos generaciones de equipos con decisiones iniciales distintas. El documento propone reconocer esa diferencia, no esconderla detrás de una casilla de conformidad.

Antes de cambiar una red hay que tener versión, valor de fábrica, ajuste explícito, ruta, filtro y una prueba de paquete hacia el destino privado. No se ha publicado esa combinación para una red específica; esos datos determinarían su exposición real.

Fuentes