El paquete llevaba el valor correcto. Nunca llegó a convertirse en estado de control.

Resumen

• RFC 5350 dio a IPv4 un registro de valores Router Alert y corrigió el mapa IPv6. Una asignación evita que dos usos estables reclamen el mismo número; no demuestra que un dispositivo analice la opción ni que permita al paquete alcanzar el plano de control.
• RFC 6398 documenta caminos operativos distintos: procesamiento en hardware, desvío a una ruta lenta, filtrado, limitación, túnel o configuración para ignorar la opción. El valor identifica la función solicitada; la política del operador decide si la solicitud consume recursos.
• RFC 9805 cerró el registro IPv6 para nuevas asignaciones y prohibió que nuevos protocolos normalizados adopten la opción, pero mantuvo los usos heredados enumerados. Cierre, desaparición del tráfico y resultado del servicio no son sinónimos.

El problema de 2008 era una colisión de significado

RFC 5350 no apareció para medir redes. Apareció para ordenar un campo. IPv6 ya tenía un registro administrado por IANA; IPv4 tenía la semántica básica de RFC 2113 para el valor cero y usos posteriores, pero carecía de un mecanismo general de asignación. RFC 3175 había introducido niveles de agregación y los dos espacios ya no coincidían sin ambigüedad.

El documento creó el registro IPv4, fijó las asignaciones iniciales, reservó un intervalo experimental y sometió los nuevos valores a IETF Review. En IPv6 corrigió una entrada duplicada y ordenó el espacio disponible. Ese resultado es valioso: un implementador puede saber qué documento define un número y un revisor puede impedir una colisión futura.

Pero el registro termina exactamente donde empieza la máquina. No instala una rutina en una tarjeta, no activa un protocolo, no abre una cola hacia la CPU y no crea estado. La asignación expresa quién puede usar un símbolo dentro de la coordinación común. La ejecución depende de actores que poseen el router, soportan el coste y responden por el fallo.

Por eso un inventario debe separar «valor asignado» de «valor soportado». El primer dato viene de IANA. El segundo requiere evidencia del equipo, la versión de software, la interfaz y la configuración. Un sistema que copie la tabla pública y la presente como matriz de capacidad ha convertido documentación en telemetría sin observar nada.

Un paquete conforme podía ser irrelevante para ese nodo

Router Alert nació para que un router detectara tráfico de interés sin inspeccionar en profundidad cada datagrama. La frase tradicional decía que los routers debían examinar el paquete más de cerca. RFC 7126 añade la condición operativa: si participan en la función indicada por el Value.

Esa condición impide una lectura imperial del encabezado. El emisor puede pedir atención; no puede nombrar unilateralmente a todos los routers del camino como participantes. Un nodo puede no ejecutar RSVP, no admitir ese uso desde el exterior o restringirlo a una red controlada. También puede conocer la opción y decidir que su presencia no justifica un desvío costoso.

Un valor correcto es entonces evidencia de intención codificada. No prueba identidad del emisor, relación de confianza, capacidad disponible ni aceptación del mensaje superior. El filtro que detuvo el paquete del ejemplo no contradijo el registro. Aplicó una autoridad diferente: la del operador sobre su frontera de control.

Esta distinción es importante para los sistemas automáticos de seguridad. Una consulta a IANA puede explicar qué pretende el código. No debe elevarse a veredicto de legitimidad. El veredicto necesita origen, interfaz, tasa, zona de confianza, protocolo habilitado y política vigente.

El salto al plano de control era un evento de riesgo

RFC 6398 describe implementaciones que tratan Router Alert de maneras muy diferentes. Algunas pueden procesar la opción en el camino rápido. Muchas envían la mayoría de los paquetes marcados al camino lento, salvo que estén configuradas para ignorarlos o descartarlos. Se informó incluso de equipos IPv4 que no clasificaban por Value y procesaban cualquier Router Alert.

La diferencia entre transferencia y control no es estética. El plano de reenvío suele usar componentes diseñados para grandes tasas. El plano de control usa recursos generales más escasos. Si una marca remota abre esa segunda ruta sin protección, el coste por paquete cambia y aparece una superficie de denegación de servicio.

RFC 6398 pide protección activa y fuerte. Propone filtros, límites, aislamiento, túneles y configuraciones que permitan ignorar la opción. Esas medidas no niegan que el valor esté asignado. Niegan que la asignación baste para reclamar capacidad interna.

El recibo decisivo es la disposición local: ignorado y reenviado; descartado; limitado; reconocido pero deshabilitado; enviado a una cola protegida; o aceptado por un manejador concreto. Si el registro operativo guarda solo «Router Alert presente», pierde el momento en que la política convirtió —o se negó a convertir— la señal en trabajo.

Del número al servicio había nueve puertas

Una investigación rigurosa puede ordenar la cadena así:

1. la autoridad de coordinación había asignado o reservado el valor;
2. el paquete observado llevaba el formato y el número correctos;
3. el nodo relevante recibió realmente el paquete;
4. el analizador leyó la opción;
5. el nodo reconoció la función y participaba en ella;
6. la política local autorizó el tratamiento o el desvío;
7. el protocolo superior validó el mensaje y al emisor;
8. se creó o modificó el estado pretendido;
9. el reenvío o servicio visible reflejó ese estado.

Cada puerta puede cerrarse sin alterar las anteriores. Una captura confirma el punto dos, no el seis. Un contador de CPU confirma trabajo, no aceptación del protocolo. Una tabla de estado confirma una decisión interna, no la experiencia final.

Esta secuencia también distribuye correctamente la responsabilidad. IANA responde por la claridad de la asignación. El proveedor de plataforma responde por la implementación. El operador responde por la política. El protocolo responde por su validación. El servicio responde por el resultado. Ningún actor debería recibir crédito o culpa por toda la cadena a partir de un único dato.

Cuando la reserva no aparece, la pregunta útil no es «¿estaba registrado el valor?». Es «¿cuál fue la primera puerta sin recibo?». Esa pregunta reduce el espacio de error y evita reescribir una falla local como problema abstracto de normalización.

La experimentación no viajaba con un pasaporte universal

RFC 5350 reservó un intervalo para usos experimentales, y a la vez advirtió que las redes de producción podían no soportarlo. También reconoció el riesgo de que dominios diferentes usaran el mismo valor experimental con significados distintos.

Dentro de un dominio, el administrador puede coordinar dispositivos, límites y duración. Fuera de él, el número no lleva consigo el acuerdo. Un paquete puede salir de un laboratorio donde el código era inequívoco y entrar en una red donde es desconocido, coincide con otra prueba o activa una protección genérica.

La documentación del experimento debe incluir alcance, participantes, interfaces, valor, significado, límites, prevención de fuga y fecha de expiración. De otro modo, el símbolo sobrevive más que el consentimiento que le daba sentido.

La ruta de respaldo también debe ser explícita. Si la opción se ignora, ¿el paquete sigue siendo útil? Si se filtra, ¿existe señalización alternativa? Si el experimento depende de que dominios no coordinados consuman recursos, el diseño ya ha confundido espacio numérico con autorización externa.

En 2025 el futuro de IPv6 cambió, no su pasado

El estado actual de los registros muestra una bifurcación. IPv4 conserva IETF Review. IPv6 aparece cerrado tras RFC 9805. Los nuevos protocolos normalizados no deben usar la opción IPv6 Router Alert; los protocolos heredados incluidos en la lista pueden continuar.

RFC 9805 identifica problemas acumulados: tráfico no deseado que puede alcanzar el plano de control, análisis costoso de Hop-by-Hop, descarte frecuente de estas cabeceras y uso limitado más allá de redes locales. Describe MLDv2 y MRD como ampliamente desplegados entre los casos listados; los demás son limitados, experimentales o carecen de implementación conocida.

No se debe convertir esa descripción en un censo mundial. Tampoco se debe decir que el cierre elimina los paquetes existentes. Una regla sobre nuevos diseños no reconfigura el parque instalado. Un operador puede seguir soportando un uso local; otro puede bloquearlo desde hace años.

El cambio sí altera las decisiones futuras. Un arquitecto ya no puede asumir que obtendrá un nuevo valor IPv6 para una función inédita. Debe elegir un mecanismo que no dependa de esa opción o justificar un uso heredado existente. Esa restricción es normativa; la verificación de cada trayectoria sigue siendo empírica.

El registro era evidencia, no resultado

La nota de Lu Heng sobre especificación mínima ofrece una lente posterior: la coordinación común puede limitarse al objeto necesario y dejar las decisiones futuras a quienes ejecutan el sistema. No demuestra nada sobre la intención de RFC 5350 y no debe mezclarse con la historia del estándar.

La aplicación correcta es limitada. IANA mantiene valores y referencias. Los operadores deciden soporte, confianza, límites y retirada. Esa separación no debilita el estándar; evita exigir al registro una capacidad de mando que nunca tuvo.

La nota sobre capas de realidad ayuda a conservar los recibos. El registro es una realidad documental; la opción en el paquete, una realidad observada; la acción del router, una realidad operacional; el servicio, otro resultado. Presentarlas como una sola verdad hace elegante el panel y pobre la investigación.

Para una organización, la pregunta práctica es qué dependencias heredadas siguen vivas. Hay que mapear valores a plataformas, interfaces, colas, procesos y servicios. Si una renovación de hardware cambia la disposición predeterminada, el registro permanecerá igual. Solo un inventario operativo mostrará el cambio.