Resumen

  • RFC 9805 ordena que los nuevos protocolos normalizados en el futuro no usen la opción IPv6 Router Alert; los usos históricos de su lista exhaustiva pueden continuar, incluso en versiones posteriores.
  • IANA ha cerrado el registro de valores, pero esa decisión administrativa no filtra un solo paquete. La política del equipo, la telemetría y una migración ejecutada son las pruebas que faltan.

En 1999, Router Alert parecía una nota adhesiva eficiente pegada a ciertos datagramas: «este paquete, aunque no vaya dirigido a ti, merece una mirada más atenta». En 2025, el IETF decidió que ningún protocolo nuevo debía volver a pegar esa nota.

La RFC 9805 convierte ese cambio de criterio en una obligación normativa. Los protocolos que ya emplean la opción pueden seguir haciéndolo. Los futuros protocolos que aspiren a estandarización no deben incorporarla. La lista de excepciones no queda abierta a interpretación: es la enumeración exhaustiva del apéndice A.

IANA cerró además la vía de expansión. En sus parámetros IPv6, el tipo 0x05 aparece como Router Alert, desaconsejado para protocolos nuevos. El registro de valores de Router Alert consta como cerrado, y el rango antes reservado para experimentación ya no puede utilizarse con ese fin.

Hay que resistir la tentación de convertir una ventanilla cerrada en una red saneada. Los valores existentes siguen registrados. Los protocolos heredados siguen autorizados. Los equipos siguen recibiendo tráfico y conservan su configuración. El acto de IANA impide nuevas asignaciones; no modifica la ruta de ejecución de un dispositivo.

El origen ayuda a entender la deuda. La RFC 2711 definió Router Alert dentro de las opciones Hop-by-Hop de IPv6. Algunos mensajes de control, como RSVP, iban destinados a un extremo pero requerían que los routers del trayecto examinaran o procesaran información. Analizar en profundidad todos los datagramas era demasiado costoso. La marca permitía mantener rápido el tráfico normal y separar los casos excepcionales.

Pero la marca sólo expresa interés; no autentica el interés ni paga el trabajo que solicita. La propia RFC 2711 advertía que el uso gratuito podía degradar el rendimiento y que una inundación de datagramas falsos podía ser más grave. Un router de tránsito podía limitar la tasa u otras características.

La RFC 6398 describió después el problema de autorización. No existe un mecanismo universal y cómodo para clasificar de antemano los Router Alert deseados y los indeseados. A diferencia de una sesión de control con pares identificados, un paquete marcado puede presentar cualquier origen y destino. La solicitud puede alcanzar routers del núcleo, no sólo una frontera administrativamente preparada.

El coste cae sobre una arquitectura desigual. Según la RFC 6192, el plano de reenvío suele manejar grandes tasas con hardware especializado, mientras el plano de control ejecuta funciones variadas en procesadores de propósito general. Saturar este último amenaza también la estabilidad del reenvío que programa.

Una defensa razonable intenta clasificar y limitar antes de elevar tráfico al plano de control. Sin embargo, RFC 9805 señala que las listas de control son más eficientes cuando comparan campos en posiciones fijas. Localizar Router Alert dentro de un encabezado Hop-by-Hop exige más trabajo. El operador puede asumirlo, ignorar la opción, o descartar o limitar con dureza los paquetes Hop-by-Hop en el borde. Una política demasiado abierta expone capacidad; una demasiado ciega puede romper un protocolo legítimo.

RFC 9805 no resuelve esa tensión con un algoritmo nuevo. Impide que el conjunto de razones legítimas siga creciendo. Es una decisión sobre incentivos: un diseñador futuro ya no podrá obtener una comodidad local trasladando a todos los routers del trayecto una nueva obligación de inspección.

La excepción histórica sigue siendo concreta. El documento sólo califica MLDv2 y MRD como usos ampliamente desplegados. El resto de la tabla corresponde a tecnologías con despliegue limitado, carácter experimental, ausencia conocida de implementación IPv6 o, en el caso de MPLS Ping, un uso de Router Alert ya desaconsejado.

Crear versiones de MLDv2 y MRD sin esa dependencia queda fuera del alcance de RFC 9805. Por tanto, «no habrá nuevos usos» no equivale a «los viejos usos han terminado». Entre ambas frases hay diseño de protocolo, código, compras, ventanas de cambio, coexistencia y evidencia de que la función multicast sigue operativa.

La RFC 9673 había cambiado el marco general de las opciones Hop-by-Hop: por defecto, su procesamiento no debería mandar paquetes al plano de control. Router Alert conserva una excepción porque su función es precisamente pedir más examen. RFC 9805 limita esa excepción por nacimiento, no por borrado: sólo pueden permanecer los linajes ya enumerados.

Una auditoría seria debe pedir recibos distintos.

  1. El texto de RFC 9805 demuestra la prohibición para futuros estándares.
  2. IANA demuestra el cierre de asignaciones.
  3. La especificación del protocolo demuestra que un flujo pertenece a la excepción.
  4. La configuración y la versión de software demuestran la intención local.
  5. Capturas, contadores, colas y métricas de CPU demuestran el comportamiento real.
  6. Pruebas de servicio demuestran que la protección no ha eliminado la función válida.
  7. La desaparición medida del flujo, tras una sustitución, demuestra la retirada de una dependencia.

Saltar del segundo punto al séptimo es fabricar una conclusión. Quedarse en el quinto sin probar el servicio también lo es.

La idea de especificación inicial mínima, decisión futura localizada y adopción voluntaria encaja con este cierre. El IETF fija un límite pequeño y común. Cada red decide cómo tratar lo que aún necesita, y cada comunidad de protocolo deberá diseñar una salida que pueda adoptarse sin una autoridad central operando todos los routers.

La primacía del código en funcionamiento marca el criterio de éxito: menos dependencia observada, políticas más estrechas, equipos estables bajo carga y continuidad del servicio. Ninguna etiqueta de registro puede sustituir esos hechos.

Las capas de realidad evitan la exageración final. El cierre de IANA es real. La prohibición normativa también. El tráfico heredado pertenece a otra capa, igual que la seguridad de un equipo concreto. RFC 9805 no fracasa por no gobernarlas todas; gana credibilidad al no fingir que lo hace.

Fuentes