Summary

  • Posted on 7 September 2026, draft-ietf-dtn-bibe-00 is a new DTN working-group Internet-Draft. It revives BIBE around encapsulation and segmentation, without the custody-transfer machinery associated with earlier work.
  • BIBE makes each encapsulating bundle a new, independent BPv7 object. Delivery of those outer payloads does not prove that one decapsulation element accepted every segment, retained the state, reconstructed the inner bytes and presented a bundle to the BPA.
  • The draft deliberately provides no BIBE acknowledgement. Its ordinary status reports can surround the decapsulation interval, but failures inside that interval require local logs, counters and configuration evidence.

The cleanest failure starts with four green lights. A large bundle is divided into four opaque byte ranges. Each range is carried inside a newly originated BPv7 bundle. The four outer bundles traverse the tunnel and each generates a delivery report at the destination endpoint. Nothing appears lost in transit.

Yet the inner bundle may still be absent. If the endpoint has several members and delivery selection is unspecified, two outer bundles can reach one decapsulation element and two another. Each element holds a valid but incomplete set. Neither can present the reconstructed bundle to its BPA. At expiry, both erase their state. Every outer delivery statement was true; the inferred inner receipt was false.

That is the narrow operational importance of draft-ietf-dtn-bibe-00. Posted on 7 September, it is revision 00 of a DTN working-group document and remains an Internet-Draft. It consolidates earlier BIBE work into an observable tunnelling mechanism: an outbound bundle is captured as opaque octets, carried whole or in segments inside ordinary BPv7 bundles, and recovered at a configured decapsulation endpoint. Working-group status makes it a common work item. It does not make the text an RFC or establish deployment, conformance or interoperability.

The outer and inner objects are deliberately independent. An encapsulating bundle is originated by the tunnel ingress as a new bundle, not forwarded as a modified copy of the bundle inside it. Its destination is the decapsulation endpoint, not the inner destination. Its source, creation time, lifetime, report-to address, flags, extension blocks and security treatment belong to the tunnel journey. No inner primary-block field or extension block is copied outward by the protocol.

That separation is useful. A confidentiality block on the outer payload can conceal the complete inner bundle, including its source and destination, from nodes along the tunnel. A domain can apply its own routing, queueing or security policy to the outer object without changing the inner bytes. BPv6 and BPv7 bundles can cross another-version network, and the inner integrity protection can survive because the bytes remain invariant.

It also creates two ledgers. “Outer bundle delivered” means its payload reached a decapsulation element registered for the endpoint. “Inner bundle received” exists only after a whole payload is accepted or every byte of a segmented transfer is reassembled and the result is presented to the BPA under RFC 9171. Between those records lies a function with optional capabilities, finite storage and local policy.

Segmentation makes the interval consequential. An operator configures a maximum inner-byte threshold for each endpoint, while separately accounting for the outer bundle, CBOR and security overhead. The encapsulator assigns a Transfer ID and partitions the inner octets into ordered ranges that cover the object exactly once. The ID is scoped by the literal outer source node ID and destination EID. It carries no ordering, freshness or loss semantics.

Once the first segment is sent, there is no BIBE abort message. If generation stops halfway, the receiver cannot distinguish that choice from segments lost in transit. Partial state remains until the shared transfer expiry or until local resource policy removes it. The ID cannot safely be reused for the same source and destination while an earlier transfer may still be alive.

Reassembly has hard rejection rules. A segment extending beyond the declared total is malformed. A changed total length or conflicting overlap corrupts the transfer and causes state to be discarded; identical duplicate bytes are benign. A receiver that does not support optional reassembly must discard segment payloads. Even otherwise valid state may be evicted early to protect storage. In each case, the inner bundle never reaches the BPA.

The all-segments requirement is stricter than an endpoint label suggests. Segments must all reach one decapsulation element, unless the endpoint's delivery semantics make every member receive the complete set. A singleton ipn endpoint satisfies the condition. An endpoint that distributes bundles among members without a stable rule does not. The name can resolve, the outer bundles can arrive and the transfer can still fail because the configured relationship did not preserve affinity.

BIBE adds no acknowledgement or retransmission layer to repair this. At ingress, forwarding is complete after the encapsulator successfully hands the new outer bundles to the underlying network. Reliability, if required, must come from a lower convergence layer, repetition, a separate custody or acknowledgement mechanism above the inner bundles, or the communicating applications. The 2026 rescope is especially important here: IETF 126 records that the revived work excludes custody transfer and concentrates on encapsulation and segmentation.

The existing status-report machinery remains useful if its propositions are kept separate. Reports on the outer bundles can trace tunnel reception, forwarding, deletion and final delivery. Reports on the recovered inner bundle resume only after it has been presented to the BPA. If every outer delivery report arrives but an expected inner reception report does not, an administrator can localize the problem to decapsulation rather than the tunnel path.

The draft also names the blind spot. Unsupported reassembly, malformed payload rejection, conflicting segments, incomplete-state eviction and expiry happen after outer delivery but before the bytes become an inner bundle. They cannot be expressed as status reports about either object. They should appear in local logs and counters at the decapsulating node. A centralized dashboard that collects only Bundle Protocol reports can therefore be internally consistent and operationally incomplete.

Lifetime policy reinforces the distinction. Every outer bundle in one transfer shares an expiry no later than the inner bundle's expiry. That prevents the tunnel from extending an already expired inner opportunity and tells the receiver when no late segment can complete the state. But the sender declares that expiry. A hostile or broken peer can claim a distant time and withhold one segment, so the decapsulator needs its own maximum retention interval and storage budget.

Security cannot be inherited across the boundary either. Authentication on the outer payload can establish the tunnel peer and protect segments before reassembly. It does not authenticate the source claimed in the inner primary block. The outer tunnel's opacity can also defeat inspection rules on intermediate nodes, making the decapsulation node an essential admission-control point. Operators must apply ordinary inbound policy to the recovered inner object and use end-to-end inner protection where provenance matters.

The Heng Lu discipline is to refuse the authority shortcut. A working-group label is coordination state. An outer delivery report is a transport observation. Reassembly is a local technical result. BPA reception is a new protocol fact. Application processing and an external outcome sit later still. None obtains the authority of the next merely by being easier to collect.

The operational standard should therefore be a joined receipt, not a greener status. For every transfer, retain the outer source and endpoint, Transfer ID, shared expiry, segment ranges, actual receiving element, rejection or eviction reason, reassembly completion, resulting inner bundle identity and BPA reception. Only that chain supports the sentence “the inner bundle was received.” Four outer delivery reports support a useful but narrower sentence: “the tunnel delivered four payloads to its configured edge.”

Sources

  1. IETF Datatracker — Bundle-in-Bundle Encapsulation
  2. Current working-group draft 00
  3. IETF 126 DTN working-group minutes
  4. Individual predecessor draft
  5. Expired BIBE-CT working-group draft
  6. RFC 9171 — Bundle Protocol Version 7
  7. RFC 9172 — Bundle Protocol Security
  8. RFC 9758 — Updates to the ipn URI Scheme
  9. RFC 6169 — Security Concerns with IP Tunneling
  10. RFC 4459 — MTU and Fragmentation Issues with Tunneling
  11. RFC 2473 — Generic Packet Tunneling in IPv6
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality Layers