摘要

  • 2026 年 9 月 7 日发布的 draft-ietf-dtn-bibe-00，是 DTN 工作组新一版 Bundle-in-Bundle Encapsulation 草案；它把复活后的工作收窄到封装与分段，不沿用旧稿中的 custody transfer 机制。
  • 每个外层 bundle 都是独立新建的 BPv7 对象。外层交付只能证明载荷到了解封装 endpoint，不能证明所有分段进入同一个解封装单元、完成重组并作为内层 bundle 交给 BPA。
  • 现有状态报告能够观察解封装之前和之后，却不能表达解封装单元内部的拒绝、逐出与过期；这段证据必须由节点本地日志、计数器和配置记录补齐。

最容易误判的场景有四盏绿灯。一个大 bundle 被切成四段，分别装进四个新生成的外层 bundle。四个外层对象全都按计划抵达，交付报告也一个不少。只是 endpoint 背后有两个成员：前两段交给了 A，后两段交给了 B。两个解封装单元各自拥有真实而不完整的状态，谁也拼不出内层对象。到期后，两个状态都被删除。

这时，“四个外层载荷已经交付”完全属实；“内层 bundle 已被接收”却从未发生。两句话并不矛盾，因为它们属于不同对象、不同处理阶段，也由不同证据支持。

draft-ietf-dtn-bibe-00 的价值正在这里。它在 9 月 7 日成为 DTN 工作组文档的第 00 版，目前仍是可修改、可替换、也可能过期的 Internet-Draft。工作组身份说明该机制已进入共同工作序列，不代表 RFC 批准、最终共识、部署事实或互操作结论。

BIBE 把待转发 bundle 捕获为一串不透明字节，可以完整放进一个外层载荷，也可以拆进多个载荷。封装节点不是“修改后继续转发”原对象，而是以新来源的身份创建新的 BPv7 bundle。外层目的地是解封装 endpoint，不是内层目的地；它有自己的来源、创建时间、寿命、报告地址、控制标志、扩展块和安全策略。

独立外层有实际用途。若在外层载荷上施加机密性保护，隧道路径上的节点连内层来源与目的地都看不到。中间域可以按自己的路由、队列、服务质量和安全规则处理外层，而不改动内层字节。不同版本的 Bundle Protocol 也可借此跨越另一版本的网络。

代价是形成两本账。外层“交付”止于载荷到达已注册的解封装单元。内层“接收”只在完整载荷被接受，或所有分段完成重组并交给 BPA 后出现。两者之间不是无状态的管道，而是带可选能力、有限存储和本地政策的执行面。

分段阈值由双方事先按 endpoint 配置。它只限制每个外层载荷中的内层字节；外层主块、扩展块、CBOR 包装和 BPSec 开销仍要另算。封装端为一次传送分配 Transfer ID，并用 total length 与 offset 描述各段。这个 ID 要和外层 source node ID、destination EID 一起解释，本身不表示顺序、新旧或丢失。

第一段一旦请求发送，BIBE 没有 abort 或 cancellation 信号。如果发送端半途停止，接收端看到的现象与途中丢段相同。不完整状态会保留到共同到期时间，或者因本地资源政策更早被清除。在旧传送仍可能到达的窗口内复用同一 ID，甚至会把不同代际的分段引向同一个键。

重组规则明确区分可接受与不可接受。offset 加长度超过 total length 的分段格式错误；同一传送出现不同总长度，或相同区间出现不同字节，都会使状态被判为损坏并删除；内容完全相同的重复段则可以忽略。更基础的一层是，分段生成与重组都是可选能力。不支持重组的解封装单元必须丢弃分段载荷。

即使实现支持重组，本地存储也不是无限承诺。节点可以在共同到期时间之前依据资源政策逐出不完整状态；被逐出的传送就此失败，内层 bundle 不会进入 BPA。于是，外层报告系统看到的“交付完成”与解封装单元真实执行的“状态已清除”可以同时存在。

endpoint 名称也不能替代成员亲和性。ipn 的 singleton endpoint 天然符合“所有分段进同一单元”的要求；向每个成员广播完整集合的 endpoint 也可行。无法保证成员选择的一组 endpoint 则不行。名称解析成功、外层路由正确，并不自动建立跨多个外层对象的共同重组上下文。

新草案有意不提供 BIBE 自身的确认与重传。封装端把外层 bundle 成功交给下层网络后，就完成了自己意义上的 forwarding。若业务需要可靠性，只能由下层 convergence layer、重复发送、位于其他层次的 custody/acknowledgement，或端到端应用提供。IETF 126 的 DTN 会议记录尤其重要：复活 BIBE 的决定明确排除了 custody transfer，只保留封装与分段。

RFC 9171 的状态报告仍然有用，但不能跨对象偷换含义。外层报告可以追踪隧道入口、途中转发、删除和交付；内层报告只有在解封装结果被交给 BPA 后才重新出现。如果所有外层交付报告都已收到，却没有预期的内层接收报告，运维人员就能把故障范围收窄到解封装，而不是笼统归咎于传输路径。

但范围收窄不等于原因已经查明。不支持重组、保留数组尺寸、总长度冲突、区间冲突、内存逐出和到期，都发生在外层交付之后、内层 bundle 形成之前。草案明确说，这些处置无法作为任一 bundle 的状态报告表达，应通过解封装节点的本地日志和计数器暴露。只采集中心化 BP 报告的系统，可以数据一致却事实不全。

寿命规则提供边界，却不能代替接收端治理。同一传送的所有外层 bundle 使用同一个到期时间，而且不得晚于内层 bundle。这样既避免隧道延长已经失效的传送机会，也为清理状态和安全复用 Transfer ID 提供时点。可这个时点由发送端声明。恶意或失控的 peer 可以给出很远的日期，再故意缺一段；接收端仍需自行设定最大保留期和存储额度。

安全权威也不能从外层继承到内层。外层 BIB 可以认证隧道 peer，并在进入重组前阻止伪造载荷，却不能认证内层主块声称的来源。外层加密同时会让中间节点看不到本来可能拒绝的内容，因此解封装节点必须重新执行普通入站准入；需要端到端来源保证时，内层自身还要有独立保护。

Heng Lu 的现实分层方法要求每个结论停在自己的证据边界。工作组标签是协调状态，外层交付报告是传输观察，重组是本地处理结果，BPA 接收是新的协议事实，应用处理与外部结果还在后面。收集成本较低的一层，不能替较难观测的一层作证。

因此，可靠的运维记录应当把这些证据关联起来，而不是压成一个状态：外层来源与 endpoint、Transfer ID、共同到期时间、分段区间、实际接收单元、拒绝或逐出原因、重组完成哈希、内层身份和 BPA 接收事件。四盏绿灯可以证明隧道边缘收到了四份载荷。只有完整链条，才能证明里面的 bundle 真正被接收。

来源

  1. IETF Datatracker — Bundle-in-Bundle Encapsulation
  2. DTN 工作组第 00 版草案
  3. IETF 126 DTN 工作组会议记录
  4. 此前的个人草案
  5. 已过期的 BIBE-CT 工作组草案
  6. RFC 9171 — Bundle Protocol Version 7
  7. RFC 9172 — Bundle Protocol Security
  8. RFC 9758 — ipn URI Scheme 更新
  9. RFC 6169 — IP 隧道安全问题
  10. RFC 4459 — 隧道中的 MTU 与分片
  11. RFC 2473 — IPv6 通用包隧道
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality Layers