BIBE：外側の配送は内側の Bundle 受信ではない

要約

2026年9月7日付の draft-ietf-dtn-bibe-00 は、BIBE をカプセル化と分割に絞って再始動した DTN ワーキンググループ文書であり、以前の custody transfer を引き継ぐものではない。
外側の各 bundle は新たに生成された独立オブジェクトである。その配送報告だけでは、全 segment が同じ要素に届き、保持され、再構成され、内側の bundle として BPA に渡ったことまでは証明できない。
BP の status report は decapsulation の前後を観測できるが、内部での拒否、破棄、期限切れは表現できない。原因を残す責任は受信ノードのログと counter にある。

四つの外側 bundle に四つの配送報告がそろっていても、内側の受信はゼロになり得る。endpoint の背後に二つのメンバーがあり、前半の segment は一方、後半は他方へ渡ったとする。どちらの decapsulation element も正しい断片を持つが、完全な集合ではない。期限が来れば両方の状態が消える。

外側について「すべて届いた」は正しい。しかし内側について「受信した」は一度も成立していない。この二つを分けるのが、9月7日に提出された新 draft の最も実務的な意味である。文書は DTN ワーキンググループの改訂 00 だが、まだ Internet-Draft であり、RFC、最終合意、実装適合性、導入実績を示すものではない。

BIBE は転送対象の bundle を不透明な octet 列として取り込み、一つの外側 payload に丸ごと入れるか、複数に分ける。カプセル化ノードは外側の bundle を新しい送信元として生成する。外側の宛先は decapsulation endpoint であり、内側の宛先ではない。送信元、生成時刻、lifetime、report-to、flag、拡張 block、セキュリティ処理も外側固有だ。

この独立性には利点がある。外側 payload を暗号化すれば、トンネル途中のノードから内側の送信元と宛先まで隠せる。中間ドメインは内側の byte を変えずに、外側へ経路、queue、QoS、セキュリティ方針を適用できる。BPv6 と BPv7 の版をまたぐ搬送も可能になる。

同時に、証拠は二つの台帳へ分かれる。外側の delivery は、その payload が endpoint に登録された element へ渡ったところで完了する。内側の reception は、whole-bundle payload が受理されるか、全 byte が再構成され、その結果が RFC 9171 の受信 bundle として BPA に渡された時に初めて発生する。その間には任意実装の機能、有限の memory、ローカル policy がある。

分割の threshold は endpoint ごとに事前設定される。対象は外側一個あたりの内側 byte 数であり、外側の primary block、extension、CBOR framing、BPSec の overhead は別途見込まなければならない。各 transfer には Transfer ID、total length、offset が付く。ID は外側の source node ID と destination EID の組と共に意味を持ち、順序、新旧、欠落を表さない。

最初の segment を送信要求した後、BIBE には abort も cancellation もない。送信側が途中でやめても、受信側には経路上の損失と区別できない。部分状態は共通 expiry まで、または資源 policy が先に消すまで残る。以前の transfer が生きている間に同じ組で ID を再利用すると、世代の異なる segment を誤って吸収する恐れがある。

再構成規則は byte の整合性を検査する。offset と長さが total を超えれば malformed、total length が途中で変われば corrupt、同じ範囲に異なる内容が重なれば transfer 全体を破棄する。同一内容の重複は正常に起こり得る。一方、segment の生成も再構成も optional であり、再構成非対応の element は segment payload を捨てなければならない。

対応していても保持は無制限ではない。ローカルの資源管理は expiry 前に不完全状態を削除できる。その transfer は単純に失敗し、内側の bundle は BPA に現れない。外側の report が正しいまま、内側へ進む材料だけが失われる。

したがって、endpoint の名前だけでは足りない。singleton の ipn endpoint は同一 element への到達を保証できる。全 member に完全な集合を配送する仕組みも成立する。しかし外側 bundle ごとに配送先 member が決まり、その選択が固定されない endpoint では、segment が分散して静かに期限切れする。

新しい BIBE は独自の acknowledgment も retransmission も提供しない。入口では、外側 bundle を下位ネットワークへ正常に引き渡した時点で forwarding が終わる。信頼性が必要なら convergence layer、反復、別レイヤーの custody/acknowledgment、または application が担う。IETF 126 の議事録も、復活時に custody transfer を外し、encapsulation と segmentation に範囲を絞ったことを記録している。

RFC 9171 の status report は、対象を混同しなければ診断に役立つ。外側について reception、forwarding、deletion、delivery を追い、内側については BPA への提示後に再び追える。外側の delivery report がすべてそろい、期待する内側 reception report だけが来なければ、故障箇所を transit ではなく decapsulation へ絞れる。

ただし、そこで status report の視界は切れる。再構成非対応、予約済み array size、total の不一致、重複範囲の衝突、資源不足による eviction、expiry は、外側 delivery 後かつ内側 bundle 成立前に起きる。draft は、どちらの bundle の report にも書けないため、decapsulation node のローカルな log と counter で示すべきだとしている。

共通 expiry も境界条件であって、受信側の防御そのものではない。一 transfer の外側 bundle はすべて同時に期限を迎え、その時刻は内側の expiry より遅くできない。だが値を主張するのは送信側だ。遠い期限を設定して最後の一片を送らない peer に備え、受信側は独自の最大保持時間と memory 上限を持つ必要がある。

信頼も外側から内側へ自動継承されない。外側 payload への BIB は tunnel peer を認証し、偽 segment を再構成前に排除する助けになるが、内側 primary block の送信元を認証するものではない。また暗号化された tunnel は中間ノードの inspection を無効にし得るため、出口では通常の inbound admission を内側へ改めて適用しなければならない。

Heng Lu の方法で言えば、ここには連結すべき複数の現実がある。ワーキンググループ名は調整状態、外側 report は搬送観測、再構成はローカル処理結果、BPA reception は別の protocol fact である。application 処理と現実の成果はさらに先だ。収集しやすい事実に、後続の権限を与えてはならない。

運用記録には外側 source、endpoint、Transfer ID、共通 expiry、segment 範囲、実際の受信 element、拒否・eviction 理由、完成 hash、内側の識別子、BPA reception を一つの相関関係として残すべきだ。四つの delivery report は「四つの payload がトンネル端へ届いた」ことを支える。内側の受信を語るには、その先の記録が要る。

外側の Bundle はすべて配送された。それでも内側の Bundle は未受信だった

なぜ重要か

要約

情報源

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説