Zusammenfassung

  • GLOBALLY DOWN beendet in RFC 9866 die Nutzung der aktuellen DODAG-Version für aufwärts gerichtetes Routing. Der Zustand ist kein forensischer Befund über den physischen Root.
  • RNFD vereinigt Sentinel-Beobachtungen in probabilistischen Conflict-Free Replicated Counters. Der Standardwert 0,51 gilt für eine Schätzung, nicht für eine namentlich prüfbare Abstimmung.
  • Ein Root-Failure-Entscheidungsbeleg sollte Version, Beobachter, Signale, Prüfungen, Zähler, Parameter, Sicherheitsmodus, Maßnahme und Wiederherstellung verbinden und die Ursache getrennt als bestätigt oder unbekannt ausweisen.

Der Border Router sendet noch. Trotzdem fehlen mehreren Nachbarn die Link-Layer-Bestätigungen, und einige führen ihn nicht länger als Elternknoten. Für die Frage, ob Verkehr weiter nach oben geschickt werden darf, reicht diese Lage aus: Die aktuelle Topologie ist nicht mehr verlässlich. Für die Aussage, der Router sei physisch abgestürzt, reicht sie nicht.

RNFD verkürzt genau dieses gefährliche Warten. Root-Nachbarn in der Rolle von Sentinels beobachten ihre Verbindungen. Acceptors nehmen die Informationen auf, führen sie zusammen und verbreiten sie. So kann das Netz schneller als mit den gewöhnlichen RPL-Reaktionen feststellen, dass die aktuelle DODAG-Version nicht weiterverwendet werden soll.

Das Protokoll trifft damit eine Entscheidung unter Unsicherheit. Gute Governance verlangt nicht, diese Unsicherheit vor der Schutzmaßnahme zu beseitigen. Sie verlangt, sie im späteren Bericht nicht zu verstecken.

Der Weg zum Zustand gehört zum Befund

Der Local Observation of Root State kennt UP, SUSPECTED DOWN, LOCALLY DOWN und GLOBALLY DOWN. Verdacht kann durch ausbleibende Bestätigungen, die Entfernung des Root aus der Elternmenge oder indirekt durch weitergegebene Zählerinformation entstehen.

Eine Sentinel kann mit DIS oder ICMPv6 Echo Request prüfen, ob der Root erreichbar ist. Bei bestimmten direkten Beobachtungen darf diese zusätzliche Prüfung entfallen. Ein Dashboard, das nur den Endzustand speichert, vernichtet deshalb relevante Unterschiede: Welches Signal löste den Verdacht aus? Wurde geprüft? Was kam zurück? Warum durfte die Prüfung ausfallen?

Bei GLOBALLY DOWN kündigt ein Knoten unendlichen Rank an, besitzt keinen bevorzugten Elternknoten und routet in dieser Version nicht mehr nach oben. Der Zustand ist innerhalb dieser DODAG-Version endgültig. Die Wiederaufnahme erfolgt über eine neue Version, die der Root initiiert.

Die Versionsgrenze verhindert ein zufälliges Zurückspringen in den alten Graphen. Sie begrenzt zugleich die Aussage. Ein lebender Root kann erkennen, dass seine Version aufgegeben wurde, und eine neue erzeugen. Er darf auch vorzeitig reagieren, wenn seine lokalen Zähler den Schwellenwert annähern. Geschlossen wird eine Routing-Version, nicht die Ursachenakte.

Verteilte Schätzung statt Wahlprotokoll

RNFD führt positive und negative Beobachtungen in zwei Conflict-Free Replicated Counters. Dahinter stehen probabilistische Linear-Counting-Bitfelder. Die Zusammenführung ist idempotent, kommutativ und assoziativ. Wiederholungen und unterschiedliche Reihenfolgen können deshalb zusammenlaufen, ohne jede Kopie als neue Beobachtung zu zählen.

Das Ergebnis schätzt eine Menge. Es bewahrt keine vollständige Liste authentifizierter Stimmen. Der voreingestellte Konsensschwellenwert beträgt 0,51, der Verdachtszuwachs 0,12 und die Sättigungsgrenze 0,63. Ein höherer Schwellenwert kann Fehlalarme verringern, erkauft dies aber mit langsamerer Erkennung.

Die Formulierung „Eine Mehrheit bewies den Root-Absturz“ ist daher zu stark. Zutreffend ist: Unter der damaligen Sentinel-Auswahl und Konfiguration überschritt die replizierte Schätzung die Regel, nach der diese Version global unbrauchbar wurde.

RFC 9866 schließt weder falsch negative noch falsch positive Ergebnisse aus. Instabile Verbindungen können Fehlalarme begünstigen. RNFD lässt sich deaktivieren, ohne RPL abzuschalten. Eine solche Reaktion auf wiederholte Fehlalarme braucht jedoch einen Verantwortlichen, eine Frist, die alte Konfiguration und einen Ersatz für die weggefallene Erkennung.

Sicherheitskontext verändert die Aussagekraft

Manipulierte oder gefälschte RNFD-Optionen können einen Fehlalarm erzwingen, einen echten Fehler verdecken oder den DIO-Verkehr erhöhen. Wenn dieses Risiko zum Bedrohungsmodell gehört, verweist RFC 9866 auf RPL-Sicherheitsmechanismen.

Ein geschützter Wert von 0,51, ein ungeschützter Wert und derselbe Wert während einer Schlüsselstörung sind keine gleichwertigen Belege. Solange nicht alle Nachbarn kompromittiert sind, kann ein aktiver Root eine falsche globale Erklärung möglicherweise anhand seiner lokalen Zähler erkennen. Diese Möglichkeit ist kein universeller Schutz. Die Root-Sicht muss im Datensatz enthalten sein.

Die IANA-Zuweisung 0x0E kennzeichnet die RNFD-Option eindeutig. Sie belegt weder Implementierung noch korrekte Sentinel-Auswahl, Telemetrie, Interoperabilität oder erfolgreiche Erholung.

Acht Felder für den Entscheidungsbeleg

Ein belastbarer Datensatz hält auseinander:

  1. RPL-Instanz, DODAG, Version, lokal bekannte Root-Identität und Zeitfenster;
  2. erwartete und tatsächlich aktive Sentinels, Auswahlregel und bekannte Lücken;
  3. fehlende Bestätigungen, Elternwechsel, indirekte Signale, Prüfungen und ausgelassene Prüfungen;
  4. positive und negative CFRCs, Schätzungen, Größe, Sättigung, Zusammenführungen und Messpunkte;
  5. Konsensschwelle, Verdachtszuwachs, Sättigung, Timer und Konfigurationsrevision;
  6. RPL-Sicherheitsmodus, Schlüssel- oder Nachbaranomalien, Manipulationshinweise und Root-Beobachtung;
  7. Zeitpunkt des globalen Zustands, Routing-Stopp, Ersatzverhalten, neue Version und Rückkehr nutzbaren Verkehrs;
  8. bestätigte Ursache, konkurrierende Hypothesen, zuständige Untersuchung oder ausdrücklich unbekannt.

Dieser Beleg ist ein Betriebsvorschlag, keine zusätzliche Forderung von RFC 9866. Er verzögert die Schutzhandlung nicht. Der alte Graph darf zuerst isoliert werden. Er verhindert nur, dass schnelle Automation später als Beweis einer nicht untersuchten Ursache dient.

Den Erfolg nicht überdehnen

RNFD definiert ein wertvolles gemeinsames Minimum: Beobachtung nahe am Root, robust zusammenführbare Information, eine Schwellenregel, den Abschluss der alten Version und eine saubere Grenze zur neuen. Konfigurationswege bleiben außerhalb des RFC. Ersatzstrom, virtuelle Roots und Kontinuitätsarchitektur bleiben eigene Maßnahmen.

Die Überwachung sollte mindestens RNFD-Aktivität, globalen Down-Zustand, DODAG-Version und Rank zeigen; zusätzlich sind Rolle, genauer LORS, Zähler und Konstanten sinnvoll. Je folgenreicher die Automation, desto weniger genügt eine einzelne rote Lampe.

Zwei Sätze können gleichzeitig wahr sein: RNFD nahm die unsichere Version zu Recht außer Betrieb. Die physische Ursache blieb ungeklärt. Der erste schützt das Routing, der zweite die Wirklichkeit.

Quellen