要約

  • 10月28日付のROLL草案は、Response Spreadingに0x0B、DIO Option Requestに0x0Cを要求する。しかしIANAの現行台帳では同じRPL制御メッセージ用オプション番号が、RFC 9854のRREQとRREPに割り当て済みだ。前版も同じ番号を求めており、今回初めて生じた食い違いではない。
  • NフラグはマルチキャストDISのたびに近隣ルーターのTrickleタイマーをリセットする代わりに、明示的なDIOを一回返させる。草案自身が、DISの連発や旧実装との混在では電池、電波、処理能力がなお消費されると認める。

台帳の同じ升に二人を座らせる

RPLのオプション番号は飾りではない。受信側が後続のバイトをどう読むかを決める札だ。RFC 9854はRREQを0x0B、RREPを0x0Cと記し、IANAのRPL Control Message Options表にも同じ割り当てが載る。一方、草案の第7.2節はその二つを別用途に要求する。草案にはIANA確認待ちと書かれている。だから番号は確定していない。それでも、同一の名前空間に二つの意味を置いたまま実装できるわけではない。

ここで観測されているのは文書と登録簿の衝突であって、稼働中のネットワークでパケットが誤読された事実ではない。次の版には、空いた番号への変更か、別の符号化の明示的な決定が必要だ。前版02も同じ値を掲げていた。03版が新たに壊したのではなく、修正しないまま持ち越したのである。

番号を正す価値は、草案が解こうとする問題にある。RFC 6550の下で端末がDODAG Information Solicitation、つまりDISをマルチキャストすると、該当する近隣ルーターはそれを不整合として扱い、Trickleタイマーをリセットする。DIOという経路情報の発信頻度がしばらく増える。質問者には有益だが、質問していない側が何度も送信し、周囲の端末もその電波を聞く。小さな電池の網では、親切な返答にも値札が付く。

草案のN、No Inconsistencyフラグは、この連鎖を切る。Nを立てたマルチキャストDISを受けたルーターは、該当するTrickleタイマーを動かさず、明示的なDIOを返す。一度の返事と、一定期間の発信増を区別する設計だ。Tフラグならユニキャスト応答を指定でき、Response Spreadingなら複数の返事を時間的に散らせる。RフラグとDIO Option Requestは、どのDIOオプションを求めるか絞る。要求を細かくするほど、近隣全員に払わせる無駄は減る。

一回の返事を千回頼む人

しかし「一回」は相手が一回だけ尋ねる場合の単位だ。草案の安全性の節は、繰り返すDISが電力、電波、処理を食うこと、悪意のある制約が有用な応答を抑えること、古いルーターが従来どおりTrickleをリセットし得ることを列挙する。新たな認証や完全性保護は追加されない。既存のRPL保護、オプション検査、資源の上限、送信頻度の制御が実務上の防波堤になる。

質問を発する端末と請求書を受け取る端末が違う。ここがこの話の統治上の芯だ。IETFのDatatrackerでは03版は作業部会のInternet-Draftで、RFCではない。空いた番号への修正と、新旧混在の網でDISを反復したときの送受信・電力測定が、実際の節約幅を決める。

出典