Summary

  • La revisión 10 del borrador v6ops propone que el prefijo NAT64 conocido represente direcciones IPv4 privadas y compartidas; sigue en Last Call del IESG hasta el 23 de noviembre de 2026.
  • El texto propone traducción predeterminada en los CLAT no administrados y una opción para desactivarla en los traductores administrados; aconseja conservar el rechazo anterior durante las actualizaciones.
  • Una dirección privada solo cobra sentido dentro de su dominio de enrutamiento. El operador tendrá que decidir qué cliente puede alcanzar qué servicio, en lugar de delegar esa decisión al rechazo de RFC 6052.

Hay una regla de acceso escondida en un documento de direccionamiento. RFC 6052 prohíbe combinar el prefijo 64:ff9b::/96 con direcciones IPv4 no globales y obliga al traductor a tirar esos paquetes. La prohibición evita ambigüedades: 10.0.0.1 puede designar servidores distintos en dos redes privadas. También impide que un dispositivo exclusivamente IPv6 llegue a un servidor interno IPv4 por la misma ruta NAT64 que utiliza para destinos públicos.

El IETF estudia invertir esa relación. Su borrador permitiría representar con el prefijo conocido direcciones privadas de RFC 1918 y direcciones compartidas de RFC 6598. Una empresa podría conectar clientes IPv6 a aplicaciones internas heredadas sin mantener dos sistemas de prefijos. La simplificación tiene una condición: la traducción deja de actuar como guardia gratuito. Alguien tiene que decidir si el camino debe existir y quién puede recorrerlo.

La solución de dos prefijos se rompe en el cliente

La arquitectura que parece prudente sobre una pizarra separa prefijos: uno conocido para Internet, otro específico para direcciones internas. DNS64 puede elegir una respuesta sintetizada cuando controla la consulta. Un CLAT recibe a veces una dirección IPv4 literal de una aplicación y construye él mismo el destino IPv6. Entonces necesita una regla que relacione rangos IPv4 con prefijos de traducción.

El borrador señala que los métodos extendidos de descubrimiento, incluidos RFC 7050 y los anuncios de RFC 8781, no entregan ese mapa. Si el dispositivo aprende ambos prefijos, puede producir dos destinos IPv6 para la misma dirección pública. Dos rutas posibles significan dos superficies de filtrado y dos historias en el registro de incidentes. El prefijo de uso local de RFC 8215 tampoco aporta la tabla de selección cuando convive con el prefijo conocido.

Por eso la revisión 10 cambia las palabras normativas de RFC 6052. El «no debe usarse» pasa a «puede usarse». Un CLAT no administrado debería traducir esos paquetes de forma predeterminada. Un traductor del proveedor, PLAT, debería hacerlo salvo que se configure lo contrario y debe ofrecer el control para impedirlo. El borrador recoge además una realidad incómoda: algunas implementaciones CLAT ya traducen esos destinos mientras otras cumplen el rechazo antiguo. No ofrece un censo de ninguna de las dos.

El dueño de la ruta hereda la decisión

El apartado de seguridad del borrador observa que ciertos administradores dependen del rechazo obligatorio como protección implícita de la infraestructura privada. Recomienda que un PLAT ya conforme conserve ese comportamiento durante una actualización. Cambiar de versión no debería abrir por sorpresa el acceso a un sistema interno. Una apertura deliberada necesita rutas hacia el dominio correcto y reglas ACL, de cortafuegos o de filtrado NAT que definan origen, destino y servicio.

El detalle del dominio importa más que el prefijo. Dos sucursales pueden tener la misma 10.0.0.1, una para nóminas y otra para un equipo industrial. El traductor no conoce la propiedad de ese número. Si el operador instala una ruta equivocada, la conversión puede funcionar impecablemente y entregar el paquete a la máquina equivocada. Una salida técnica válida no equivale a una autorización válida.

Una prueba seria empieza antes del cambio: inventario de direcciones privadas usadas por aplicaciones, comportamiento real de CLAT y PLAT, registros de descartes, reglas actuales y rutas de retorno. Debe incluir un flujo permitido y otro prohibido desde cada clase de cliente. El hecho concreto que falta en cualquier red es su propia tabla de correspondencia entre número privado, servicio y dominio. El borrador no puede escribirla desde una reunión del IETF.

La revisión permanece en Last Call hasta el 23 de noviembre; RFC 6052 sigue siendo la norma publicada. La disputa útil que abre el borrador ya es clara. Una prohibición universal hizo más fácil operar sin discutir permisos. Retirarla puede hacer más útil IPv6, pero también obligará a la organización a firmar cada permiso que antes daba por supuesto.

Borrador IETF · RFC 6052 · RFC 1918 · RFC 6598