摘要

  • RFC 9866 的 GLOBALLY DOWN 针对的是当前 DODAG 版本能否继续承担上行路由，而不是“边界路由器已经物理崩溃”的法证结论。
  • RNFD 通过概率型无冲突复制计数器合并 Sentinel 的观测；默认 0.51 阈值作用于估算结果，并非可逐一核验身份的多数表决。
  • 运营方应保存一份根节点失效决策凭证，把版本、观测者、证据来源、探测、计数器、阈值、安全模式、处置和恢复连起来，并把最终原因另列为“已证实”或“未知”。

最容易误判的场景，并不是一座彻底熄灭的根节点，而是一座还亮着的根节点。

它可能仍有电，进程也可能偶尔回应；但周围数个邻居的无线链路正在抖动，链路层确认接连缺失，根节点被移出父节点集合。对依赖这张图的设备来说，继续把流量向上送已经不再可靠。此时，网络有充分理由停止使用旧图，却没有充分理由宣称硬件已经崩溃。

RFC 9866 所定义的 Root Node Failure Detector（RNFD），正是为了缩短这种危险等待。它让根节点邻居中的 Sentinel 负责观察，让 Acceptor 接收、合并并传播观测，最终可使网络对当前 DODAG 版本得出 GLOBALLY DOWN。这个状态的价值在于能指导动作；它的边界在于没有回答物理世界里究竟发生了什么。

四个状态不是四级物理诊断

RNFD 的 Local Observation of Root State（LORS）包括 UP、SUSPECTED DOWN、LOCALLY DOWN 和 GLOBALLY DOWN。这些词看上去像对同一故障事实不断增强的确信，其实更准确的读法是：它们分别对应不同强度的路由处置依据。

Sentinel 可以因为收不到链路层确认，或者因为根节点不再能作为父节点而进入怀疑状态。它可以用 DIS 或 ICMPv6 Echo Request 再探测一次。对于某些直接观测，规范也允许跳过这一步。因此，同样的 SUSPECTED DOWN 可能来自不同证据路径；若系统只保留最后一盏红灯，调查者就无法知道当时观察到了什么、验证了什么，又为何没有验证。

进入 GLOBALLY DOWN 后，节点在当前版本中通告无限 Rank，不再拥有首选父节点，也停止向上路由。该状态对这一版本是终局性的。恢复不是把旧状态改回绿色，而是由根节点发起新的 DODAG 版本。

“版本”是理解边界的钥匙。RNFD 判定的是旧版本不应再被信任。一台仍然存活的根节点完全可能发现大家已经放弃旧版本，随后创建新版本；根节点也可以在本地计数接近阈值时提前行动。这不是协议自相矛盾，而是安全决策与因果诊断原本就属于两条记录。

0.51 不是逐名点票

RNFD 用正、负两个 Conflict-Free Replicated Counter 表示观测。它们基于概率型线性计数位数组，合并运算具备幂等、交换和结合性质。消息重复到达、先后顺序不同，仍可安全汇合；只要连通条件允许，分布式状态能够趋于一致。

代价是计数结果属于估算。它不保存一份“谁投了哪一票”的实名名单。默认共识阈值是 0.51，默认怀疑增长值是 0.12，默认饱和阈值是 0.63。提高共识阈值通常会降低误报风险，却也延长检测时间。

所以，准确的事故语言应当是：“在当时的 Sentinel 集合和生效参数下，复制观测的估算值越过了本版本的全局失效阈值。”把它改写为“多数已认证邻居证明根节点崩溃”，就把概率型运营规则夸大成了身份精确的因果证明。

RFC 9866 对此很坦白。概率方法无法覆盖所有极端情况，可能出现漏报，也可能出现误报，链路不稳定尤其可能推动误报。RNFD 可以单独停用而不必关闭 RPL。频繁误报或许构成停用理由，但停用同样需要保留责任人、配置版本、替代检测方式和复核期限；否则，临时降噪会悄悄变成永久失明。

安全模式决定信号能被信到什么程度

被篡改或伪造的 RNFD 选项可以制造误报、掩盖真实故障，或者放大 DIO 流量。风险模型包含这些威胁时，规范建议使用 RPL 安全机制。因此，计数器快照若不携带安全模式，就缺少解释它所必需的上下文。

同样越过 0.51，在已认证环境、未保护环境和密钥异常期间具有不同的证据强度。如果并非所有根邻居都已被攻陷，仍存活的根节点可能从本地计数中识别出误报；“可能识别”不能被写成“必然阻止”。根侧看到了什么，应当和网络侧共识一并保存。

IANA 将 RPL 控制消息选项类型 0x0E 分配给 RNFD，只证明公共码点已登记。它不证明某台设备实现了功能、Sentinel 选择合理、遥测完整，或者新版本能够成功恢复。

一份决策凭证要保留八件事

不必把事故管理塞进协议字段。更实际的办法，是在协议状态旁保存一份结构化凭证：

  1. 图的身份：RPL 实例、DODAG 标识与版本、当时所认定的根节点及生效时间窗；
  2. 观测者集合：预期与实际 Sentinel、选择规则、缺席者及临时加入者；
  3. 证据路径：确认缺失、父节点变化、间接计数增长、DIS/ICMPv6 探测结果，以及跳过探测的原因；
  4. 计数器记录：正负 CFRC 的状态、估算值、数组大小、饱和程度、合并过程和采样节点；
  5. 决策参数：共识阈值、怀疑增长值、饱和阈值、定时器和配置修订号；
  6. 信任环境：RPL 安全模式、密钥或邻居异常、伪造迹象以及根节点的本地观测；
  7. 处置与恢复：何时达到全局失效、何时停止上行、采用什么后备行为、谁或什么触发新版本、何时恢复有效转发；
  8. 原因结论：已确认原因、竞争性解释、证据负责人；尚未证明时明确写“未知”。

这份凭证是运营建议，不是 RFC 9866 的新增要求，也不是 IETF 合规证书。它不阻止网络先隔离旧图。它只阻止事后报告借用自动决策的速度，虚构一份并不存在的确定性。

把规范的成功保持在正确范围内

RNFD 解决的是一个有限却重要的问题：低功耗网络不应在根节点不可用时无限等待。Sentinel 观察，Acceptor 合并，概率阈值关闭旧版本，新版本提供恢复边界。这些都是真实的协调成果。

但配置手段不在 RFC 范围内，备用电源、虚拟根和整体连续性也不是 RNFD 的替代品。监控至少应暴露 RNFD 是否启用、是否全局失效、DODAG 版本与 Rank；更完整的实现还应暴露角色、精确 LORS、计数器和常量。最终结果仍由运行中的代码、实际配置和本地证据决定。

因此，一份诚实的复盘可以同时写下两句话：“RNFD 正确地让当前 DODAG 版本退出服务。”“根节点看似失效的物理原因仍然未知。”第一句保护网络，第二句保护事实。

来源