Resumen

  • GLOBALLY DOWN en RFC 9866 ordena dejar de usar la versión actual del DODAG; no es una prueba pericial de que la raíz haya perdido alimentación, se haya detenido o esté destruida.
  • Los contadores positivos y negativos de RNFD son estructuras probabilísticas que se fusionan de forma segura. El umbral predeterminado de 0,51 no equivale a una votación nominal exacta.
  • Un recibo de decisión debe guardar observadores, pruebas, contadores, parámetros, seguridad, tiempos y recuperación, y reservar un campo distinto para la causa confirmada o aún desconocida.

Supongamos que la torre central sigue encendida. El proceso responde de vez en cuando y no hay evidencia de un daño de hardware. Desde varios vecinos, sin embargo, los enlaces se han vuelto intermitentes. Faltan confirmaciones de capa de enlace; la raíz desaparece del conjunto de padres; la información de sospecha se propaga. Para los nodos que dependen de ese grafo, la diferencia entre «apagada» y «prácticamente inalcanzable» ya no resuelve la decisión inmediata: no deben seguir enviando tráfico hacia arriba por una ruta insegura.

Ese es el terreno de RNFD, el Root Node Failure Detector de RFC 9866. El protocolo acelera una conclusión operativa sobre la raíz de RPL. No instala un sensor forense dentro del router. La red puede disponer de pruebas suficientes para abandonar su grafo actual y carecer de pruebas suficientes para explicar la causa.

De la observación local a una regla global

Los vecinos designados como Sentinels vigilan sus enlaces con la raíz. Su Local Observation of Root State puede ser UP, SUSPECTED DOWN, LOCALLY DOWN o GLOBALLY DOWN. La sospecha puede nacer de confirmaciones de enlace ausentes, de que la raíz ya no sea un padre aceptable o del crecimiento de información recibida por el plano de control.

Antes de concluir localmente, una Sentinel puede enviar DIS o ICMPv6 Echo Request. El RFC permite omitir esa comprobación cuando la observación directa ya satisface la condición prevista. Por eso un panel que solo conserve el estado final pierde una parte decisiva del expediente: qué señal abrió la sospecha y qué verificación se hizo, falló o fue omitida.

Los Acceptors fusionan y retransmiten las observaciones. RNFD usa dos Conflict-Free Replicated Counters, uno positivo y otro negativo. Son matrices de bits basadas en conteo lineal probabilístico. La fusión es idempotente, conmutativa y asociativa, de modo que copias repetidas y órdenes distintos no destruyen la coherencia distribuida.

La contrapartida es que el número representa una estimación, no una lista de identidades que pueda auditarse como un acta de votación. El umbral de consenso predeterminado es 0,51; el crecimiento de sospecha, 0,12; y el umbral de saturación, 0,63. Cambiar esos valores altera la relación entre rapidez y falsos positivos. El medio de configuración queda fuera del alcance del RFC, de modo que el operador debe conservar quién cambió cada valor y cuándo.

GLOBALLY DOWN cierra una versión, no un caso

Al alcanzar GLOBALLY DOWN, un nodo anuncia Rank infinito, deja de tener padre preferido y no enruta hacia arriba dentro de esa versión del DODAG. Es un estado terminal para esa versión. La recuperación exige que la raíz inicie una nueva.

La regla parece severa porque debe serlo. Una versión declarada insegura no vuelve a la normalidad por una señal tardía y aislada. Pero la severidad de la acción no aumenta el alcance de la prueba. Una raíz aún viva puede observar que la red abandonó su versión y generar la siguiente. Incluso puede anticiparse cuando sus contadores locales se acercan al umbral.

Así, el informe correcto puede decir: «la versión 37 dejó de ser utilizable y RNFD la cerró» sin añadir «el equipo sufrió un crash». La segunda frase requiere registros de alimentación, proceso, radio, seguridad y otros sistemas que RNFD no pretende sustituir.

El RFC reconoce además que el método probabilístico no garantiza todos los casos límite. Puede haber falsos negativos y falsos positivos, en especial con enlaces inestables. RNFD puede desactivarse sin desactivar RPL. Una serie de falsos positivos puede justificarlo, pero la desactivación debe tratarse como una decisión reversible y documentada, no como la desaparición del riesgo.

La seguridad forma parte de la interpretación

Una opción RNFD modificada o suplantada puede empujar un falso positivo, ocultar un fallo real o aumentar el tráfico DIO. Cuando esa amenaza es plausible, RFC 9866 recomienda la seguridad de RPL. El mismo valor de contador tiene distinto peso si fue recibido con protección, sin ella o durante una anomalía de claves.

Si no todos los vecinos están comprometidos, la raíz puede detectar una falsa declaración mediante sus contadores locales. Esa posibilidad es una defensa, no una garantía universal. El recibo debe guardar qué observó la propia raíz y si había vecinos honestos conocidos.

El código 0x0E asignado por IANA identifica la opción RNFD. No demuestra que un producto la implemente, que sus Sentinels estén bien elegidas, que exporte telemetría o que la recuperación funcione.

Ocho piezas de un recibo defendible

Un registro operativo útil separa las siguientes piezas:

  1. Identidad del grafo: instancia RPL, DODAG, versión, identidad local de la raíz y ventana temporal.
  2. Cohorte observadora: Sentinels esperadas y presentes, criterio de selección y ausencias conocidas.
  3. Ruta de evidencia: confirmaciones perdidas, cambio de padre, información indirecta, sondas y verificaciones omitidas.
  4. Estado de los contadores: matrices positiva y negativa, estimaciones, tamaño, saturación, fusiones y punto de captura.
  5. Parámetros efectivos: umbral, crecimiento de sospecha, saturación, temporizadores y revisión de configuración.
  6. Contexto de confianza: modo de seguridad RPL, anomalías de claves o vecinos y observación local de la raíz.
  7. Acción y recuperación: cruce del umbral, abandono del tráfico ascendente, comportamiento alternativo, creación de nueva versión y retorno del servicio útil.
  8. Conclusión causal: causa confirmada, hipótesis aún abiertas, responsable de la investigación o desconocida.

Este recibo no forma parte de RFC 9866. Es una disciplina de operación. Permite que el mecanismo automático actúe antes de conocer la causa sin que el relato posterior utilice esa velocidad como sustituto de una prueba.

No pedir al estándar más de lo que comparte

El valor del RFC está en su mínimo interoperable: roles comunes, estados definidos, contadores fusionables, una regla de consenso y una salida limpia mediante otra versión. No reemplaza alimentación de respaldo, raíces virtuales ni diseño de continuidad. Tampoco define toda la configuración local.

La monitorización debería mostrar si RNFD está activo, si el nodo está globalmente caído, la versión del DODAG y el Rank. También puede exponer el rol, el LORS exacto, los contadores y las constantes. Cuanto más grave sea la automatización, menos aceptable resulta un producto que solo muestre una luz roja.

Conservar el límite no debilita la respuesta. La red puede tomar una decisión tajante sobre el tráfico y mantener una conclusión prudente sobre el mundo físico. Lo primero evita seguir una ruta rota. Lo segundo evita fabricar una causa.

Fuentes