要約

  • TREB改訂01は、参加するBPv7ノードが選択した次ホップ、ローカル時刻、リンク特性を記録し、Bundle Status Reportで送信元へ返す仕組みを提案する。
  • 記録されるのは送信キューに入れた時点であり、実際の送信や受信ではない。ノードは参加拒否、項目の非開示、以前の記録の置換、報告の不生成を選べる。
  • 変更され続ける往路・復路のTREBはホップ単位でしか保護できない。このため草案は、hop-recordを診断専用とし、経路制御やアクセス制御への利用を明示的に禁じる。

経路ではなく、経路についての記録

IPのtracerouteは、異なるHop Limitでパケットを失効させ、その応答を送信側から観測する。TREBは別の構造を取る。DTNでは、Bundleが次の無線、光、地上、衛星間リンクを待ち、長い中断の後に転送されるからだ。

出発ノードはtraceroute-idを作り、最初のhop-recordを付ける。参加ノードは、自分のNode ID、選んだ次ノード、キュー投入時刻、予定する送信開始時刻、リンク種別、名目速度、推定距離、収束層、次の通信機会に対するキュー量を記す。配送または削除の記録が折り返し点になり、その後ろには報告Bundle自身の復路記録が続き得る。

これは運用上の空白を埋める。通常の状態報告だけで経路を再構成するには各中継ノードの報告が必要で、リンクの詳細も乏しい。TREBなら、一つの配送報告で蓄積した往路と報告の復路を持ち帰れる可能性がある。

ただし、改訂01は2026年9月28日付の個人Internet-Draftで、期限は2027年4月1日、想定ステータスはExperimentalである。IANAのブロック種別を要求している段階で、割り当て済みではない。実装状況には実装が一件もなく、測定結果も将来版に委ねられている。

キュー投入は送信完了ではない

転送hop-recordは、ノードが次ホップを選び、Bundleを送信キューへ置いた時に作られる。無線が送信した、通信窓が開いた、隣接ノードが受信した、宛先アプリケーションが処理したという受領証ではない。

送信失敗や次ホップ変更で再度キューに入れると、前の記録は新しい記録に置き換わる。最終的に送られるコピーに残るのは最新の局所判断であり、失敗を含む全試行の不変ログではない。

event-timeはローカルのキュー投入時刻で、radiate-timeは予定開始時刻にすぎず、実際の送信時刻で更新されない。BPv7はノード間の時計同期を要求しない。異なるノードの値を引き算しても、そのまま遅延測定にはならない。伝送遅延と伝搬遅延の分離も仕様範囲外だ。

ゼロも実測ゼロとは限らない。時刻、速度、距離、収束層、混雑で、未知、非該当、非開示を表す。構造化された数値列の中に、各運用者の開示方針が埋め込まれている。

沈黙には複数の理由がある

参加は任意である。送信元への信頼、トポロジー保護、資源制約、ローカル方針を理由に、ノードはTREBを処理せずそのまま転送できる。ある記録のnext-node-idと次のself-node-idがつながらなければ、間に少なくとも一つ透明ノードがある。しかしTREBだけでは数も全識別子も分からない。

全ノードが正しく更新するなら、Hop Count Blockとの差から透明ホップ数を推定できる。一方、record-limitは記録の増大を抑える上限であり、ループ防止ではない。上限後もBundleは転送され、後続ノードの記録はオーバーフローとして報告から回収される場合がある。

報告要求も命令ではない。BPv7では、フラグが立っていてもBPAが報告を生成するかは裁量に残る。欠けた転送報告は、未生成、方針による省略、復路での損失のいずれでもあり得る。出発側の完了タイムアウト後は、まだネットワークを移動中でも遅着報告を無視する。

したがって言えるのは、ローカル期限までに追加証拠が届かなかったということだけだ。最後に見えたノードでBundleが失われたとは言えない。

復路は別の観測である

配送・削除報告では、折り返し記録の前が追跡対象Bundleの往路、後が報告Bundleの復路を示す。両方向が同じ経路を通る保証はない。透明ノードや上限到達によって復路も部分的になり得る。

転送報告は異なる。報告元自身の一件と位置だけを持ち、復路では変更されない。送信元はtraceroute-id、対象Bundle、位置、Node IDの連鎖から再構成する。Bundleが複製されれば、同じ位置に複数の記録が現れ、一本の線ではなく木になる。

整列された表は客観性を感じさせる。しかし各行の著者は、その行で描かれるノードである。開示範囲も各ノードが決め、最終の並べ方は出発側が決める。整合した物語と中立な証人は同じではない。

書き換わるブロックに端末間保証は置けない

TREBはノードの識別、トポロジー、時刻、リンク能力、混雑を明らかにする。その一方、往路のブロックと配送・削除報告の復路コピーは各参加ノードで変更される。その可変部分を端末間で完全性保護または暗号化することはできず、BIBやBCBは現在の転送ノードから次ノードまでのホップ単位になる。

作成後に変わらない転送報告は、報告ノードから保護できる。それでも保証されるのは一件の申告元であり、経路全体の独立証明ではない。草案はhop-recordを端末間認証されていない診断データと位置付け、ルーティングやアクセス制御への入力を禁止する。

報告先も攻撃面になる。BPv7のreport-to EIDは、ここで十分な送信元認証にならない。偽造された診断Bundleが、より大きい報告を第三者へ向けさせる可能性がある。サイズ上限、レート制限、送信元認可、不一致時の省略はリスクを抑えるが、宛先欄を身元証明には変えない。