Summary
draft-acee-lsr-ospfv3-deprecate-ah-00propone que las nuevas implementaciones OSPFv3 no incorporen IPsec AH y que los operadores migren a ESP con cifrado nulo o al Authentication Trailer. La revisión 00 es un Internet-Draft individual, no un estándar aprobado.- La etiqueta deprecada no reconfigura el enlace. Primero todos los routers deben aceptar el reemplazo; después puede cambiar la transmisión, y el camino antiguo solo se retira tras demostrar autenticación, adyacencia, convergencia y reenvío.
A las dos de la mañana, un router comienza a enviar Hellos con el mecanismo nuevo. El vecino tiene la clave, pero no la asociación de entrada correcta. Un tercero dispone de una imagen compatible, aunque la función sigue desactivada en esa interfaz. El cuarto espera AH. Los cuatro inventarios pueden aparecer en verde; el primer paquete revela que todavía no pertenecen al mismo conjunto compatible.
Ese es el valor operativo de Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication, revisión 00, fechada el 30 de septiembre de 2026. El borrador individual aspira a Standards Track y actualizaría RFC 4552 si fuera aprobado. No es un RFC ni demuestra adopción por un grupo de trabajo, fabricante u operador.
RFC 4552 exige soporte de ESP y permite AH. El nuevo texto desaconseja AH para implementaciones OSPFv3 nuevas, deja que las existentes lo mantengan por compatibilidad con una advertencia y dirige la migración hacia ESP-NULL o el Authentication Trailer de RFC 7166.
ESP con cifrado nulo aporta integridad y autenticación, no confidencialidad. El Trailer tiene su propia construcción y cubre la dirección IPv6 de origen. Ninguna opción detiene a un router comprometido que ya posee una clave compartida válida.
El documento no cambia el estado del enlace
El borrador cita la adopción limitada de AH, su carácter opcional en RFC 8221 y la complejidad de mantener dos caminos de código, configuración y operación. También observa que el tráfico OSPFv3 normal usa direcciones de enlace local y Hop Limit 1, por lo que la cobertura adicional de campos IPv6 inmutables ofrece poco valor en este caso.
Son argumentos de diseño, no un censo independiente. Y ninguno negocia una transición. Publicar el borrador no instala una clave, no crea una SA entrante y no elige el instante en que cada vecino empezará a enviar de otra forma.
La revisión 00 fija la restricción: una interfaz o enlace virtual OSPFv3 utiliza un mecanismo de autenticación y todos los routers del enlace deben coincidir. La unidad segura de cambio es, por tanto, el enlace entero.
Preparar la recepción antes de cambiar el envío
RFC 4552 ya ofrece una disciplina de tres pasos para renovar claves. Primero se crea la SA entrante nueva en todos los routers. Solo cuando todos pueden recibirla se reemplaza la SA de salida. La SA entrante antigua se elimina después de que todos transmitan con la nueva.
Migrar de AH a ESP no es la misma operación que cambiar una clave, pero conserva la lógica: recibir lo nuevo, enviar lo nuevo, retirar lo viejo. Cada frontera necesita evidencia de todos los participantes.
El borrador permite un cambio coordinado en ventana de mantenimiento o un despliegue gradual únicamente en implementaciones capaces de aceptar más de un mecanismo durante la transición. Esa capacidad debe verificarse en el software activo y en la interfaz concreta.
El solapamiento compra continuidad a costa de ampliar temporalmente la aceptación. Si dura poco, rompe adyacencias; si dura demasiado, mantiene abierto el camino anterior. Debe tener responsable, inventario de miembros, comienzo, vencimiento y una regla que detenga el corte ante cualquier recibo ausente.
Mantener Full no dice por qué se aceptó el paquete
ESP-NULL sigue siendo IPsec y utiliza el perfil de SA y claves manuales de RFC 4552. Authentication Trailer viaja con OSPFv3, incluye un identificador de SA y un número criptográfico creciente de 64 bits.
RFC 7166 define además un modo transitorio opcional que envía Trailer pero todavía acepta paquetes sin él. Puede mantener conectados a vecinos antiguos, aunque el propio RFC advierte de exposición a datos no autenticados durante ese periodo.
Por eso el estado Full no basta. La observación debe atribuir cada paquete al camino nuevo, al antiguo o al modo permisivo. Una autenticación válida prueba acceso a la clave; no identifica a una persona, no garantiza que el router esté sano ni autoriza automáticamente cada LSA.
El retiro final pertenece al cambio
La cadena conserva por separado: revisión exacta; soporte real de cada imagen; estado de recepción, algoritmo y época de clave; selección de salida; Hellos y Database Description autenticados; vecinos estables en Full; LSDB convergente; FIB y tráfico; y, al final, retiro de AH o de la aceptación permisiva con repetición de las pruebas.
Ningún escalón demuestra el siguiente. Una adyacencia puede seguir viva por el camino viejo. Una LSDB igual no prueba la FIB. Tráfico exitoso durante el solapamiento no identifica qué mecanismo lo sostuvo.
La doctrina de Heng Lu separa especificación común mínima, decisión futura local y adopción voluntaria. El estándar define lo necesario para interoperar; el operador elige mecanismo y ventana. La adopción solo queda probada por código activo, paquetes aceptados, vecinos estables y reenvío observado.
La pregunta directiva no es si AH ya lleva la etiqueta deprecada. Es si todos los routers del enlace aceptan la misma prueba nueva en la misma época de clave y si el camino anterior ha quedado realmente cerrado.
Sources
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

