要約

  • RFC 9866のGLOBALLY DOWNが確定させるのは、現行DODAG版を上向きルーティングに使わないという判断であり、Root機器が物理的に壊れたという原因ではない。
  • RNFDはSentinelの観測を確率的なConflict-Free Replicated Counterで統合する。既定値0.51は推定値に対する閾値で、署名付きの名簿を数える投票ではない。
  • DODAG版、観測者、検証、カウンター、閾値、セキュリティ、隔離、復旧を結ぶ判断記録を残し、原因は立証できるまで「不明」と分離すべきである。

中央のRootがまだ電波を出しているのに、周囲からは到達できない。こうした場面は機器の生死を二択で表示する監視画面には収まりにくい。リンク層の確認が返らず、Rootが親候補から外れ、複数の近隣ノードが疑いを共有し始める。上向き経路としては危険だが、電源断なのか、無線の非対称性なのか、分断なのかはまだ分からない。

RNFDが必要とされたのは、この不確実性が解消するまで待つこと自体が危険だからだ。低電力・損失性ネットワークでは、使えないRootへの依存を早く断つ価値が大きい。RFC 9866は、Rootの近隣であるSentinelが観測し、Acceptorがその情報を統合・伝搬し、現行グラフを閉じる手順を定める。

重要なのは、速い判断と広い断定を混同しないことだ。プロトコルは「この版を使い続けてよいか」に答える。事故調査は「何がRootを使えなくしたか」に答える。前者の成功は、後者の証拠を自動的には生まない。

LORSが示すのは行動の根拠

Local Observation of Root Stateには、UP、SUSPECTED DOWN、LOCALLY DOWN、GLOBALLY DOWNがある。Sentinelは、リンク層ACKの欠落や親集合からのRoot除外を直接観測して疑いを持つことがある。制御面から受け取ったカウンターの増加が疑いを強める場合もある。

SUSPECTED DOWNではDISやICMPv6 Echo Requestによる確認が可能だ。一方、直接観測を根拠に確認を省略できる経路も仕様に含まれる。従って、最終状態だけを保存しても診断には足りない。何を観測し、どの確認を行い、なぜ省略したかを残さなければ、同じ赤表示の背後にある証拠差が消えてしまう。

GLOBALLY DOWNに達したノードは、現行版で無限Rankを広告し、優先親を持たず、上向き転送を止める。この状態はそのDODAG版では終端である。復旧にはRootが新しい版を開始する必要がある。

この版境界は、古いグラフが一つの遅延パケットで不用意に復活するのを防ぐ。同時に、宣言の射程も明確にする。生きているRootが全体停止を知って新しい版を始めることは可能であり、閾値に近づいた段階で先回りすることもできる。RNFDが閉じたのは旧版であって、原因調査そのものではない。

合意値は推定であり点呼ではない

正と負の観測は二つのConflict-Free Replicated Counterに格納される。実体は確率的な線形計数ビット配列で、統合は冪等・可換・結合的である。重複や到着順の違いに耐え、接続が保たれれば分散状態は収束できる。

しかし、そこには「どの認証済みSentinelが賛成したか」という完全な名簿はない。個体数は推定される。既定の合意閾値は0.51、疑いの増加値は0.12、飽和閾値は0.63である。閾値を高くすれば誤検知を減らせる可能性がある一方、検出は遅くなる。

事故記録で「過半数がRoot故障を証明した」と書けば、この仕組みを過大評価する。より正確なのは、「当時のSentinel構成と設定値の下で、複製された観測推定が現行版を停止する基準を越えた」である。

RFC 9866は確率方式に万能保証がないことも明記する。偽陰性も偽陽性もあり得る。とくに不安定なリンクは偽陽性を生み得る。RNFDだけを無効にしてRPLを継続することもできるが、無効化の権限、理由、期限、代替検知を記録しなければ、短期の雑音対策が恒久的な盲点になる。

セキュリティ状態を外しては解釈できない

RNFDオプションの改変や偽装は、偽陽性を作り、実際の故障を隠し、DIOトラフィックを増やし得る。脅威モデルに含まれるならRPLのセキュリティを用いるべきだとRFCは示す。

同じ0.51でも、保護された観測、未保護の観測、鍵異常中の観測は同じ証拠ではない。全近隣が侵害されていなければ、動作中のRootが自分のカウンターから偽陽性を見抜ける場合がある。これは可能な検出経路であって、常時成立する保証ではない。Root側の記録も判断票に含める必要がある。

IANAが割り当てたRPL Control Message Option 0x0Eは共通の識別子を与えるだけだ。特定製品の実装、Sentinel配置、監視機能、相互運用や復旧結果を証明しない。

Root停止判断のレシート

運用記録には、少なくとも次の八点が要る。

  1. RPLインスタンス、DODAG ID、版、Root識別と対象時間帯。
  2. 期待されたSentinel群、実際の参加群、選定規則と欠落ノード。
  3. ACK欠落、親集合変更、間接観測、DIS/ICMPv6結果、省略した検証。
  4. 正負CFRC、推定数、配列サイズ、飽和状態、統合履歴と採取地点。
  5. 合意閾値、疑い増加値、飽和閾値、タイマー、設定版。
  6. RPLセキュリティ、鍵・近隣異常、偽装兆候、Root自身の観測。
  7. 全体停止時刻、上向き転送停止、代替動作、新版開始、実用通信の復帰。
  8. 確定原因、競合仮説、調査責任者。証明できなければ明示的な「不明」。

これはRFCの追加要件ではなく、運用上の提案である。安全動作を原因調査まで遅らせるものでもない。先に旧版を隔離し、後から原因を詰めればよい。ただし、速く動けたことを、原因まで分かった証拠として使ってはならない。

小さな成功を大きな神話にしない

RFC 9866が共有する最小仕様は有用だ。近隣観測、重複に強い統合、共通の停止基準、版を切り替える復旧境界がある。設定方法は範囲外であり、予備電源や仮想Rootの代わりでもない。

監視ではRNFDの有効状態、全体停止、DODAG版、Rankを少なくとも見せるべきで、役割、詳細LORS、カウンター、定数も公開できる。実際の結果を決めるのは、動いているコード、現場の設定、現在の観測である。

「RNFDは旧版を正しく止めた」と「物理的な原因は未確定」は両立する。前者が経路を守り、後者が記録の正確さを守る。

出典