Summary

  • RFC 9866 coordinates a routing-safety conclusion about the current RPL DODAG version. Its terminal GLOBALLY DOWN state is not a forensic determination that the border router physically crashed.
  • RNFD merges Sentinel observations through probabilistic Conflict-Free Replicated Counters. A default 0.51 consensus threshold is an operating rule over estimated observations, not an identity-exact vote or a guarantee against false positives and false negatives.
  • A defensible root-failure decision receipt should preserve the version, observer cohort, evidence path, counter state, thresholds, security mode, action and recovery—then keep the eventual cause in a separate field.

Imagine the border router is still powered. Its process has not died, its radio can still emit, and no one has established a hardware fault. Several of its neighbouring nodes, however, are traversing unstable links. Link-layer acknowledgments disappear. A few nodes stop accepting the root as a parent. Their observations spread. The current routing graph becomes unsafe to rely on.

RFC 9866 permits that network to converge on GLOBALLY DOWN. Nodes then advertise infinite Rank, abandon a preferred parent and stop routing upward in the affected DODAG version. That is not a contradiction. The protocol answers an operational question: may this version of the graph still be used? It does not answer the incident investigator's question: what physically happened to the root?

The distinction matters because fast safety decisions are designed to act before every cause is known. If the final state is later written as “the border router crashed,” a precise distributed decision has been turned into an unsupported causal story.

Four states, four scopes of knowledge

RNFD adds a Local Observation of Root State, or LORS. UP is the ordinary condition. SUSPECTED DOWN means evidence has created doubt. LOCALLY DOWN records the observing node's conclusion. GLOBALLY DOWN means the protocol's consensus condition has been reached for the current DODAG version.

Those labels can sound like progressively stronger descriptions of one physical fact. They are better read as progressively stronger bases for routing action. A Sentinel—the RFC's term for a root neighbour that monitors its link—may become suspicious after missing link-layer acknowledgments or after removing the root from its parent set. It may probe with a DIS or an ICMPv6 Echo Request. Direct observations can also permit the verification step to be skipped. The path into suspicion therefore matters: the same displayed state can rest on different evidence.

Other nodes act as Acceptors. They receive, merge and propagate the network's positive and negative observations. The resulting state is distributed knowledge about reachability and confidence, not a remote hardware diagnostic. It can support a sound rule that traffic must no longer climb this graph while leaving power, software, radio interference, congestion, partition, compromise and configuration as unresolved causes.

This is the first governance boundary. A protocol state should be allowed to mean exactly what the protocol needs it to mean. Making it carry a larger causal claim does not create evidence; it only hides what remains unknown.

Consensus is estimated, not counted by name

RNFD represents positive and negative observations with Conflict-Free Replicated Counters. They are probabilistic linear-counting bit arrays. Their merge operation is idempotent, commutative and associative, properties that let copies combine safely in a distributed network. While connectivity remains sufficient, the state can converge even when messages arrive more than once or in different orders.

The counter does not preserve an exact roster of identified voters. It estimates the population represented in the bit array. The default consensus threshold is 0.51. The default suspicion-growth value is 0.12, and the default saturation threshold is 0.63. These constants give implementations shared behavior. They do not turn the estimate into a roll call.

That difference affects audit language. “A majority of authenticated root neighbours proved a crash” says more than the mechanism establishes. A more accurate statement is that, under the configured Sentinel population and RNFD parameters, the replicated observations crossed the rule for declaring the current version globally unusable.

The RFC itself is candid about the boundary. Its probabilistic design cannot guarantee every corner case. False negatives and false positives are possible. Unstable links can help produce a false positive, and a compromised participant can try to inject or suppress RNFD information. A higher consensus threshold can reduce false-positive risk at the price of slower detection. These are not defects that invalidate RNFD. They are the cost and purpose of a fast distributed safety detector operating with limited resources.

The terminal state belongs to a version

GLOBALLY DOWN is terminal within the current DODAG version. Once a node reaches it, ordinary upward routing does not resume merely because a later packet suggests the root may be alive. The recovery boundary is explicit: the root creates a new DODAG version.

This version rule prevents an old graph from oscillating casually back into service. It also shows why causal wording must remain narrow. A root can learn that other nodes declared its version globally down and start a new version. It can even act pre-emptively when its local view approaches the threshold. A live root participating in recovery is entirely compatible with the protocol having made a serious, disruptive safety decision.

The operational record therefore needs two clocks. One clock follows the decision: first suspicion, local conclusion, propagation, threshold crossing and last use of the old version. The other follows recovery: root-side observation, new-version creation, new parent formation and restored forwarding. Neither clock, by itself, establishes why the original links failed.

The same separation helps when RNFD is disabled. The RFC allows an implementation to turn RNFD off without disabling RPL. Frequent false positives might justify that choice. But “disabled” should record who made the change, for which version or configuration, under what evidence and with what substitute detection. Otherwise a response to noisy links can silently become a permanent reduction in failure visibility.

Security changes the trust placed in the signal

RNFD information can be attacked. A modified or spoofed option can push a network toward a false positive, conceal a real failure or increase DIO traffic. RFC 9866 therefore points to RPL security when modification or spoofing is within the threat model.

Security mode is not a decorative compliance field. It changes what can be inferred from the same counter state. An unauthenticated observation crossing 0.51, an authenticated observation crossing 0.51 and a threshold crossed during a known key or neighbour anomaly are not equivalent incident records. The root's own local counters may expose a false positive if at least one honest neighbour remains, but that too is evidence to retain rather than a guarantee to assume.

IANA's allocation of RPL Control Message Option type 0x0E gives RNFD a shared protocol identifier. It proves that the option has a registered codepoint. It says nothing about whether a particular device supports RNFD, selects Sentinels correctly, uses RPL security, exposes monitoring data or handles a recovery safely.

A root-failure decision receipt

The remedy is not to ask RNFD to become an incident-management system. It is to keep a compact record beside the protocol state. A useful root-failure decision receipt contains:

  1. Graph identity: RPL instance, DODAG identity and version, root identity as known locally, and the time window in which the conclusion applied.
  2. Observer cohort: which nodes were Sentinels, how they were selected, the expected population and any unavailable or newly added observers.
  3. Evidence path: missing acknowledgments, parent-set change, received counter growth, DIS or ICMPv6 probe results, skipped verification and the reason for skipping it.
  4. Counter record: positive and negative CFRC state, estimated counts, array size, saturation, merge observations and the node from which each snapshot was taken.
  5. Decision parameters: consensus threshold, suspicion-growth value, saturation threshold, timers and the effective configuration revision.
  6. Trust context: RPL security mode, key or neighbour anomalies, suspected spoofing or modification, and what the root itself observed.
  7. Action and recovery: when GLOBALLY DOWN was reached, when upward forwarding stopped, fallback behavior, who or what initiated a new version, and when useful routing returned.
  8. Causal disposition: confirmed cause, competing explanations, evidence owner and an explicit unknown when no cause has been proved.

This receipt is an editorial operating proposal, not an RFC 9866 requirement or an IETF certificate. It does not delay the safety action. The network may isolate the old graph first and complete causal investigation later. The receipt simply prevents the final incident narrative from borrowing certainty from the speed of the routing decision.

Preserve the narrow success

RFC 9866 supplies a bounded common mechanism for a difficult problem: a low-power network should not wait indefinitely for its root when upward routing has become unusable. Sentinels observe. Acceptors merge. A probabilistic threshold can close the old version. A new version can reopen a working graph. That is real, valuable coordination.

The protocol also leaves real work to the operator. Configuration means are outside its scope. Backup power and virtual roots remain separate resilience choices. Monitoring needs to expose at least RNFD activity, globally-down state, DODAG version and Rank; richer implementations can expose roles, exact LORS, counters and constants. Running code and local evidence determine what actually happened.

The honest post-incident sentence may therefore contain two conclusions: “RNFD correctly removed the current DODAG version from service” and “the physical cause of the root's apparent failure remains unknown.” Those statements reinforce rather than weaken each other. The first protects the network. The second protects the record.

Sources