要約

  • RFC 9914の正のPDR-ACKは、Rootが要求されたTrackを構築し、合意した期間の維持を約束したことを示す。パケットがそのTrackを使ったことは示さない。
  • 運用上の立証には、要求とシーケンス、動作モード別の導入状態、Trackと各セグメントの寿命、パケット上のTrack識別、経路観測、受信アプリの結果を別々に結び付ける必要がある。

「成功」という一語が、異なる時点を隠していた。制御ログには要求と正の応答があり、RootはTrackを構築したと答えている。しかし、そのTrackIDを持つパケットはまだ観測されておらず、出口で受信された記録もない。ACKは誤っていない。誤りは、ACKの射程を運用成果まで広げた説明にあった。

2026年4月公開の RFC 9914 はProposed Standardであり、RPLにおけるRoot-Initiated Routing Stateを規定する。RFC Editorの記録は、RFC 6550、RFC 6553、RFC 8138を更新することも示す。対象は低電力・損失性ネットワークへTrackを投射する仕組みであり、特定製品の実装や実ネットワークの成績を報告する文書ではない。

入口はP-DAO-REQでRootにTrackを要求できる。要求にはTrackID、入口と出口、希望寿命、PDRSequenceが含まれ、Rootは同じシーケンスでPDR-ACKを対応付ける。正の応答は、Trackを構築し合意期間中に維持するというRootの約束である。負の応答は拒否を示す。ここには通過パケットの測定値は含まれない。

構築の実体はモードで変わる。Non-Storing Modeでは、入口、Root、ソースルートやトンネル側に必要な状態が置かれる。Storing Modeでは、Rootが出口へProjected DAO（P-DAO）を送り、情報は入口方向へ逆に伝わり、参加ルーターが各区間を保存する。最後に入口から正のP-DAO-ACKが戻る。ACKが戻らなければ、Rootは同じTrackIDで再試行するか、Trackを解体できる。同じ「installed」という表示でも、どこに何が保存されたかは同じではない。

拒否理由も一枚岩ではない。Vector Information Optionはエラーを返すことができ、Out of Resources、Predecessor Unreachable、Unreachable Targetなどの状態が区別される。これは、あるノードが区間を受け入れられなかった理由を狭く示す。無線断の物理原因やアプリケーション停止まで証明するものではない。

時間管理には二重以上の粒度がある。各ベクトルにはSegment SequenceとSegment Lifetimeがある。古いシーケンスは無視され、同じ組の再送は状態を変えてはならず、寿命ゼロは区間を削除する。セグメントの更新と失効は非同期であり、要求者に約束したTrack全体の寿命とは独立して動く。Trackの残り時間だけを見ても、内部区間が同じ姿を保っているとは言えない。

さらに、Trackの奥で起きた変更は入口へ通知されない場合がある。Rootがサービスを保てる限り、詳細な付け替えは透明である。維持不能になれば全Trackを解体し、寿命ゼロの負のPDR-ACKを非同期で送ることができる。失敗通知がないことは、途中の状態が不変だった証拠ではない。

転送規則は、この境界を実際の損失へつなぐ。Track経路は主DODAG経路より優先され、いったんTrackに入ったパケットは通常のDODAGへ戻ってはならない。次のTrack隣接が到達不能ならパケットは破棄される。これは意図しない迂回でTrackの特性を壊さないための規律だが、通常RPLの到達性をTrack配送の代替証拠にできないことも意味する。

データ面ではTrackIDとDODAGIDを観測できる。RPL Packet Information、ソースルーティング、カプセル化の扱いは RFC 9008 とRFC 6553の規則を継承する。ある観測点で特定パケットがTrackに属したことは示せるが、観測していないホップや受信アプリケーションの処理結果までは分からない。

経路の再投射は順序にも影響する。変更前から飛行中のパケットと、変更後に入ったパケットが異なる経路を通れば、遅延差によってジッターや順序逆転が生じる。Deterministic Networkingの RFC 8655 は境界付きサービスの背景を与え、RFC 9912 はRAWの保護経路、複製・除去、高速適応を説明する。どちらも、個別TrackのACKを測定済みSLAへ変換する文書ではない。

攻撃面にも制御状態固有の弱点がある。不正ノードがP-DAOを作れれば、状態更新を繰り返してルーターの記憶領域を枯渇させ得る。RFC 9914はリンク層セキュリティを必要とし、RFC 7416のRPL脅威分析を参照する。IANA RPLレジストリにコードポイントが登録されていても、それは特定ネットワークの防御設定や攻撃耐性を認証しない。

監査可能な記録は、P-DAO-REQとPDRSequence、Rootの判断とTrack寿命、Storing/Non-Storingの別、必要なP-DAO/P-DAO-ACK、ノード別の拒否状態、Segment Sequenceと寿命、パケットで見たTrackID/DODAGID、入口・出口・各ホップの測定、再投射中の損失や順序、アプリケーション結果を結ぶべきだ。これは仕様の観測境界から導いた編集上の証拠設計であり、RFCが定める保存スキーマではない。

Lu Hengの Minimum Initial Specification は共有仕様を最小限にし、後の判断を現場の責任に残す。Running-Code Primacy は宣言より実装状態と観測結果を重く扱う。Reality Layers は要求、ACK、経路状態、パケット、サービスを一つに混ぜない。いずれも明示した編集原則で、IETF要件の追加ではない。

RFC 9914を正しく評価する鍵は、ACKを弱く見ることではない。ACKが証明する内容を正確に扱うことだ。Trackを要求し、状態を導入し、パケットで利用を確かめ、受信側で成果を測る。その順序を保存して初めて、自動化の緑色が現実に接続される。

Sources