Bundle-in-Bundle Encapsulation
draft-ietf-dtn-bibe-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Rick Taylor , Alberto Montilla | ||
| Last updated | 2026-09-07 | ||
| Replaces | draft-taylor-dtn-bibe, draft-ietf-dtn-bibect | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| On agenda | dtn at IETF-127 | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dtn-bibe-00
Delay/Disruption Tolerant Networking R. Taylor, Ed.
Internet-Draft Aalyria Technologies
Intended status: Standards Track A. Montilla, Ed.
Expires: 11 March 2027 Spatiam Corporation
7 September 2026
Bundle-in-Bundle Encapsulation
draft-ietf-dtn-bibe-00
Abstract
This document describes Bundle-in-Bundle Encapsulation (BIBE), a
Delay-Tolerant Networking (DTN) Bundle Protocol (BP) tunneling
mechanism by which a bundle is carried as the payload of one or more
encapsulating bundles, allowing security measures, routing policy,
and protocol version translation to be applied to the encapsulating
bundle without modification of the encapsulated bundle. The protocol
includes an optional segmentation mechanism, allowing a large
encapsulated bundle to be carried in multiple encapsulating bundles.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ricktaylor.github.io/bibe/draft-ietf-dtn-bibe.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-dtn-bibe/.
Discussion of this document takes place on the Delay/Disruption
Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/dtn/.
Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.
Source for this draft and an issue tracker can be found at
https://github.com/ricktaylor/bibe.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Taylor & Montilla Expires 11 March 2027 [Page 1]
Internet-Draft BIBE September 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Similarity to IP Tunneling . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Functional Model . . . . . . . . . . . . . . . . . . . . . . 6
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Transmission . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Segmentation . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Transfer IDs . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Reception . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Reassembly . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. Reassembly State . . . . . . . . . . . . . . . . . . . . 13
5. The Encapsulating Bundle . . . . . . . . . . . . . . . . . . 14
5.1. Primary Block . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Extension Blocks . . . . . . . . . . . . . . . . . . . . 16
5.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
6.1. Diagnostics . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Composition with BPSec . . . . . . . . . . . . . . . . . 21
7.2. Circumvention of Policy Enforcement . . . . . . . . . . . 21
7.3. Spoofing of the Encapsulated Bundle . . . . . . . . . . . 22
7.4. Injection Against Transfers . . . . . . . . . . . . . . . 22
7.5. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 23
Taylor & Montilla Expires 11 March 2027 [Page 2]
Internet-Draft BIBE September 2026
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. CDDL Expression . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
Bundle Protocol version 7 (BPv7) [RFC9171] defines a layered
architecture in which a Bundle Protocol Agent (BPA) relies on
convergence-layer adapters (CLAs) to transfer bundles between nodes.
This document defines Bundle-in-Bundle Encapsulation (BIBE), in which
the transfer between two nodes is performed by a BP network itself:
an outbound bundle (the "encapsulated bundle") is carried as the
payload of one or more bundles (the "encapsulating bundles") which
traverse the BP network between the encapsulating node and the
decapsulating node in the normal manner.
// This document is an editorial consolidation of prior work: the
// architecture and concepts originate in draft-ietf-dtn-bibect and
// the CCSDS Bundle-in-Bundle Encapsulation effort, and the design
// contributions of others are recorded in the Contributors and
// Acknowledgments sections. The editors claim no design novelty;
// the contribution of this document is to restate that body of work
// as a single self-contained specification.
BIBE thus occupies the architectural position of a convergence layer
— the "link layer" beneath it is itself a BP network — but this
document deliberately does not require that it be implemented as a
convergence-layer adapter; it specifies observable behavior only, in
terms of the encapsulation function and decapsulation element defined
in Section 3.
Conformance to this specification is OPTIONAL for BP nodes. A
conforming node may implement the encapsulation function, the
decapsulation element, or both; a unidirectional tunnel requires only
one at each end.
1.1. Use Cases
BIBE has broad utility; motivating use cases include:
* Security encapsulation. BPSec [RFC9172] requires that the primary
block of a bundle remain in plaintext so that it can be routed.
Encapsulating a bundle allows a Bundle Confidentiality Block on
the encapsulating bundle's payload to encrypt the entire
Taylor & Montilla Expires 11 March 2027 [Page 3]
Internet-Draft BIBE September 2026
encapsulated bundle, including its source and destination,
providing a defense against traffic analysis that BPSec alone
cannot offer.
* Cross-domain and service-provider encapsulation. A bundle
arriving at the edge of a network domain can be encapsulated so
that domain-specific policies (forwarding, quality of service,
security) are applied to the encapsulating bundle, leaving the
encapsulated bundle unmodified. The encapsulating bundle egresses
the domain at a designated decapsulating node.
* Version encapsulation. A Bundle Protocol version 6 [RFC5050]
bundle can be encapsulated for carriage across a BPv7 network, or
vice versa.
* Segmentation. BPv7 bundle fragmentation (Section 5.8 of
[RFC9171]) is incompatible with some BPSec deployments and is
prohibited for bundles bearing certain security blocks. The
segmentation mechanism defined in this document (Section 4.2)
provides an alternative: a large bundle is carried opaquely as
chunks in multiple smaller encapsulating bundles, which is of
particular utility when a downstream convergence-layer adapter
cannot carry large bundles.
* Traffic differentiation. Decapsulation endpoints are ordinary
endpoints established by policy (Section 3), so a decapsulating
node may establish several — per tunnel, per peer, or per traffic
class — at no protocol cost. The destination EID of each
encapsulating bundle then acts as a flow identifier visible along
the encapsulating path: nodes on the tunnel path can apply
forwarding, queueing, and quality-of-service policy to tunnel
traffic by destination EID alone, without inspecting the payload —
including when the payload is encrypted. The same visibility
necessarily reveals that class structure to on-path observers
(Section 7).
As in [BTPU], the encapsulated bundle is treated throughout as an
opaque sequence of octets: no field of this protocol identifies its
format, and nothing in the procedures of this document depends upon
it. Bundles of different Bundle Protocol versions can therefore be
carried, and multiplexed to the same decapsulation endpoint, without
an explicit discriminator: a receiver can distinguish the formats by
simple examination of the initial octets of the decapsulated data (a
BPv6 bundle begins with the octet 0x06, the BPv6 version number,
whereas a BPv7 bundle begins with the initial octet of a CBOR array).
Indeed, any binary data can be carried; the disposition of
decapsulated data that is not a bundle is beyond the scope of this
document and is a matter for the receiving implementation.
Taylor & Montilla Expires 11 March 2027 [Page 4]
Internet-Draft BIBE September 2026
Encapsulating bundles are themselves bundles and may in turn be
encapsulated, enabling nested encapsulation to arbitrary depth as
required by policy.
1.2. Similarity to IP Tunneling
BIBE shares a pattern with generic IP tunneling, and this document
deliberately follows the same architectural conventions where the
analogy holds:
* Like GRE [GRE] and IP-in-IP [IPIP], BIBE is a stateless
encapsulation: there is no tunnel session, no negotiation, and no
convergence-layer acknowledgement. The tunnel is defined entirely
by configuration at its two endpoints.
* Encapsulation is a tunnel ingress operation: routing or forwarding
policy directs an encapsulated bundle "into" the tunnel exactly as
an IP route directs a packet to a tunnel interface. An
implementation that realizes the encapsulation function as a
virtual interface (a convergence-layer adapter) selected by a
forwarding table entry mirrors a multipoint GRE interface; an
implementation that applies it as egress policy mirrors policy-
based tunnel selection. Either way, a single encapsulation
function may serve multiple decapsulation endpoints — and,
conversely, several decapsulation endpoints at one node give the
encapsulating node a per-class tunnel selector, in the manner of
the GRE Key field [GREKEY] (Section 1.1).
* Applying a Bundle Confidentiality Block to the encapsulating
bundle's payload is the analog of IPsec tunnel mode: the entire
inner datagram, including its addressing, is protected, whereas
BPSec applied directly to a bundle (like transport mode) must
leave the primary block in plaintext for routing.
* The segmentation mechanism of Section 4.2 is the analog of "outer
fragmentation" in IP tunnels ([TUNMTU]): the tunneled payload is
divided by and reassembled at the tunnel endpoints, transparently
to the encapsulated bundle, rather than fragmenting the
encapsulated bundle itself ("inner fragmentation", i.e. BPv7
bundle fragmentation) which alters the tunneled data unit and
interacts poorly with BPSec.
IP tunneling experience also carries over its known hazards:
recursive encapsulation loops (see Section 6) and the security
concerns cataloged in [TUNSEC] (see Section 7).
Taylor & Montilla Expires 11 March 2027 [Page 5]
Internet-Draft BIBE September 2026
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Terminology
Encapsulated bundle: A bundle, of any Bundle Protocol version,
forwarded by encapsulation and carried opaquely as (part of) the
payload of one or more encapsulating bundles.
Encapsulating bundle: A BPv7 bundle whose payload encapsulates all
or part of another bundle, formatted as described in Section 5.3.
The payload takes one of two forms: a "whole-bundle payload"
carrying an entire encapsulated bundle, or a "segment payload"
carrying part of one.
Encapsulation function: The function of an encapsulating node that
generates encapsulation payloads from a bundle being forwarded and
sources the encapsulating bundles that carry them. See Section 3.
Decapsulation element: The element of the application agent of a
decapsulating node that takes delivery of encapsulation payloads,
performs reassembly when required, and presents encapsulated
bundles to the BPA. See Section 3.
Decapsulation endpoint: An endpoint in which a decapsulation element
is registered; the destination endpoint of encapsulating bundles.
Transfer: The context in which the segments of a single encapsulated
bundle are transmitted, identified by a Transfer ID.
3. Functional Model
BIBE is specified as observable behavior, not as a component
architecture, in terms of two entities:
* An "encapsulation function", invoked by the BPA of the
encapsulating node in the course of forwarding a bundle: it
generates one or more payloads, each encapsulating all or part of
the bundle being forwarded, and, acting in the capacity of a
bundle source, sources the encapsulating bundles that carry them
(Section 4.1). Each encapsulating bundle is a new bundle,
originated at the encapsulating node; see Section 5.
Taylor & Montilla Expires 11 March 2027 [Page 6]
Internet-Draft BIBE September 2026
* A "decapsulation element", registered in one or more endpoints of
the decapsulating node: it takes delivery of the payloads of
encapsulating bundles, performs reassembly when required, and,
acting in the capacity of a convergence-layer adapter, presents
encapsulated bundles to the BPA for forwarding and/or delivery in
the standard manner (Section 4.4).
Figure 1 illustrates the asymmetry of the model: the encapsulation
function operates on the forwarding path of the encapsulating node,
while the decapsulation element is an element of the application
agent of the decapsulating node; the encapsulated bundle experiences
the entire tunnel as a single hop.
Encapsulating Node Decapsulating Node
bundle B ...(to bundle B, the tunnel is one hop)... bundle B
| ^
| |
(forwarding path) (application agent)
v |
+--------------+ +--------------+
| encapsulation| | decapsulation|
| function | | element |
+--------------+ +--------------+
| ^
| sources bundle E payload of E |
| (payload carries B, delivered to |
| destined for the the decap |
| decap endpoint) endpoint |
v |
BPA --CLA--> node --CLA--> ... --CLA--> BPA ----------+
ordinary BPv7 forwarding of bundle E
Figure 1: Functional model: encapsulation of bundle B in bundle E
How a BPA selects the encapsulation function is an implementation
matter: it might be realized as a convergence-layer adapter selected
by a forwarding table entry, applied as a filter or transform on the
egress forwarding path, or integrated in some other way. Nothing in
this document depends on the choice.
The decapsulation element, by contrast, cannot be realized solely as
a convergence-layer adapter: it takes delivery of the payloads of
bundles addressed to it, and it therefore MUST be registered in one
or more endpoints — in the terms of Section 3.2 of [RFC9171], it acts
in the capacity of an element of the node's application agent. When
it presents an encapsulated bundle to the BPA, however, it presents a
received bundle for the reception processing of Section 5.6 of
Taylor & Montilla Expires 11 March 2027 [Page 7]
Internet-Draft BIBE September 2026
[RFC9171] (Section 4.4), and in doing so acts in the capacity of a
convergence-layer adapter. Nothing in this document prevents a
single component from acting in both capacities — indeed, taking
delivery of encapsulation payloads in the capacity of an application-
agent element and presenting encapsulated bundles in the capacity of
a convergence-layer adapter is the natural realization.
The choice of endpoints in which a decapsulation element is
registered is a matter of administrative policy at the decapsulating
node. A BIBE tunnel is a deliberate, bilaterally configured
arrangement — an encapsulating node must in any case hold per-peer
configuration (Section 6), of which the decapsulation endpoint ID is
simply one element — so there is no unsolicited-contact scenario for
which a "well-known service" convention would be required, and the
absence of one denies adversaries a predictable target for
unsolicited traffic (Section 7). A decapsulation endpoint SHOULD be
an endpoint formed in a URI scheme whose procedures define which
member or members of the endpoint take delivery of a bundle destined
for it. A singleton endpoint satisfies this trivially; so would an
endpoint in a scheme with defined multicast delivery semantics —
delivery to every member — which would realize multicast BIBE:
encapsulated forwarding to every member of the decapsulation endpoint
at once. What is to be avoided is an endpoint with more than one
member for which the choice of delivering member is left unspecified,
as the Bundle Protocol leaves it for multi-member endpoints in the
dtn scheme; the consequences of that indeterminacy for BIBE —
unpredictable duplication of whole-bundle payloads, and segmented
transfers that can never be reassembled — are set out in Section 4.2.
Note that BIBE encapsulation is a forwarding operation, not a
delivery operation: policy (including BPSec) applicable to the
forwarding path of the encapsulating bundle applies to it in the
normal way. The payloads generated by the encapsulation function are
plaintext; any confidentiality protection is applied by the BPA in
the course of transmitting the encapsulating bundle, exactly as for
any other bundle payload.
4. Procedures
4.1. Transmission
When the BPA of the encapsulating node determines — by forwarding
table entry, forwarding policy, or other configuration — that a
bundle is to be forwarded by encapsulation toward a specified
decapsulation endpoint, the bundle is presented to the encapsulation
function.
Taylor & Montilla Expires 11 March 2027 [Page 8]
Internet-Draft BIBE September 2026
The bundle so presented is the bundle as the encapsulating node
forwards it. The forwarding-time processing that precedes
transmission over any convergence-layer adapter — in particular the
Previous Node block replacement of Section 4.4.1 of [RFC9171],
subject to the encapsulating node's policy — is performed by the BPA
in the normal manner, exactly as when forwarding via any other
convergence-layer protocol; it is not a function of the encapsulation
function. Because this document does not require that the
encapsulation function be realized as a convergence-layer adapter
(Section 3), however, the capture point must be pinned explicitly:
the octets captured for encapsulation SHOULD be those of the bundle
after that forwarding-time processing, so that, for example, a
Previous Node block frozen into the encapsulated bundle identifies
the encapsulating node. The consequences for the blocks of the
encapsulated bundle are set out in Section 5.
The encapsulation function then generates the payload or payloads:
* If the length of the bundle does not exceed the segmentation
threshold for that endpoint (Section 4.2), the encapsulation
function SHALL generate a single whole-bundle payload
encapsulating the entire bundle, and SHALL request transmission of
an encapsulating bundle, destined for that endpoint, carrying that
payload. A bundle that can be carried whole SHOULD NOT be
segmented.
* Otherwise the bundle SHALL be segmented as described in
Section 4.2. If the bundle cannot be segmented — the
encapsulation function does not support segmentation, or the
decapsulation element is not known to support reassembly
(Section 4.4) — then forwarding by encapsulation has failed, and
the forwarding contraindication procedures of Section 5.4 of
[RFC9171] apply at the encapsulating node as for a failure of any
convergence layer.
The fields and blocks of each encapsulating bundle are populated as
described in Section 5.
Upon requesting transmission of the encapsulating bundle(s),
forwarding of the encapsulated bundle at the encapsulating node is
complete; no further state regarding it need be retained. BIBE
provides no acknowledgement of its own, so "complete" means
successful hand-off to the underlying network, as with any unreliable
convergence layer (Section 6).
Taylor & Montilla Expires 11 March 2027 [Page 9]
Internet-Draft BIBE September 2026
4.2. Segmentation
For each decapsulation endpoint to which encapsulating bundles will
be sent, a maximum segment size — the endpoint's "segmentation
threshold" — SHALL be established by a-priori configuration
(Section 6). The segmentation threshold accommodates, for example,
size limits of convergence-layer adapters on the path of the
encapsulating bundles. Note that the threshold bounds encapsulated-
bundle octets per encapsulating bundle: an implementation sizing
encapsulating bundles for a downstream limit must also account for
the encapsulating bundle's own overhead (primary block, extension
blocks, payload CBOR framing, and any BPSec blocks).
The segmentation mechanism is aligned with the transfer/segment model
of [BTPU], but requires none of BTPU's padding, message framing, or
transfer-window machinery: BPv7 itself provides the "framing layer",
guaranteeing that the payload of each encapsulating bundle is
delivered whole or not at all, so only segment identification and
reassembly rules are needed.
When a bundle is to be segmented:
* The encapsulation function SHALL assign the transfer a Transfer ID
as described in Section 4.3.
* The encapsulation function SHALL partition the octets of the
bundle into two or more segments, each no larger than the
segmentation threshold, covering every octet of the bundle exactly
once, in order, without alteration.
* For each segment the encapsulation function SHALL generate a
segment payload with the common transfer-id, the total length of
the bundle, the segment's offset, and the segment's octets, and
SHALL request transmission of an encapsulating bundle, destined
for the indicated endpoint, carrying that payload.
Requesting transmission of the first encapsulating bundle of a
transfer commits the encapsulation function to the remainder: this
protocol provides no abort or cancellation signal, so a transfer
abandoned partway is indistinguishable, at the decapsulating node,
from loss of the remaining encapsulating bundles in transit
(Section 6). An abandoned transfer occupies reassembly state at the
decapsulation element until the transfer's expiry (Section 4.6), and
its Transfer ID remains unavailable for reuse until that same time
(Section 4.3).
Taylor & Montilla Expires 11 March 2027 [Page 10]
Internet-Draft BIBE September 2026
Segmentation requires that any decapsulation element taking delivery
of a segment of a transfer take delivery of every segment of that
transfer: reassembly state is held by the element that takes delivery
(Section 4.5), and an element holding only some of a transfer's
segments can never complete it. A singleton endpoint satisfies this
requirement trivially. An endpoint in a scheme whose delivery
procedures deliver every bundle to every member (Section 3) also
satisfies it: each member takes delivery of the complete set of
segments and reassembles independently. What cannot satisfy it is a
multi-member endpoint for which the choice of delivering member is
unspecified: distinct encapsulating bundles of one transfer may then
be delivered to different members, each member accumulates a
disjoint, incomplete set of segments, and the transfer fails silently
at its expiry. Accordingly, an encapsulating node MUST NOT segment a
bundle toward a decapsulation endpoint unless it is known — by the
rules of the EID's scheme (every 'ipn' scheme EID identifies a
singleton endpoint, Section 5.1 of [RFC9758]) or by configuration —
that every bundle destined for that endpoint is delivered either to a
single member or to every member. Whole-bundle payloads are not
subject to this constraint: any member taking delivery holds the
entire encapsulated bundle, although delivery to more than one member
duplicates the encapsulated bundle at each.
4.3. Transfer IDs
Transfer IDs are unsigned integers that identify a transfer uniquely
within the scope of the pair (source node ID, destination EID) borne
by the primary blocks of the transfer's encapsulating bundles
(Section 5.1). Both elements of the scope are explicit in every
encapsulating bundle and are compared literally, as EIDs, at the
decapsulating node (Section 4.5), so neither peer requires any
context beyond the bundle itself — in particular, no knowledge of
which node IDs name the same node, of how many encapsulation
functions operate at a node, or of how many endpoints a decapsulation
element is registered in. A node holding several node IDs
(Section 4.2.5.2 of [RFC9171]) consequently has an independent
Transfer ID space for each (source node ID, destination EID) pair it
uses. A Transfer ID carries no ordering semantics: a decapsulation
element MUST NOT infer transmission order, recency, or loss from the
numeric values of Transfer IDs. There is no analog of the transfer
window of [BTPU]: the temporal bound on a transfer is provided by
bundle expiry, since the Bundle Protocol guarantees that no bundle is
delivered after the end of its lifetime.
An encapsulating node MUST NOT assign a Transfer ID that identifies
another transfer with the same (source node ID, destination EID), any
of whose encapsulating bundles have yet to expire. Because every
encapsulating bundle of a transfer shares a single expiry time
Taylor & Montilla Expires 11 March 2027 [Page 11]
Internet-Draft BIBE September 2026
(Section 5.1), a Transfer ID becomes safely reusable at exactly the
transfer's expiry time. Subject to this rule, the assignment
strategy is an implementation matter, and uniqueness in any wider
scope implies uniqueness in this one: a sequential counter per
(source node ID, destination EID) pair, a counter per destination
EID, and a single counter for the whole node are all valid
disciplines, as is random assignment. To satisfy the rule across
restarts of the encapsulating node, an implementation SHOULD either
persist sufficient assignment state or select Transfer IDs after
restart in a manner unlikely to collide with transfers still in
flight (e.g. derived from a timestamp).
// CBOR uints are variable-length with no fixed wrap point, and the
// encoding stays small (1–5 octets) for realistic values, so there
// is no pressure to keep the identifier space compact.
4.4. Reception
Upon delivery of the payload of an encapsulating bundle to a
decapsulation element:
* If the payload is a whole-bundle payload, the encapsulated bundle
SHALL be presented to the BPA as a received bundle — the
decapsulation element here acting in the capacity of a
convergence-layer adapter (Section 3) — whereupon reception
proceeds as defined in Section 5.6 of [RFC9171]: the encapsulated
bundle may be forwarded, delivered, etc. Where the decapsulated
data is not a BPv7 bundle (see Section 1.1), its disposition is
determined by examination of its initial octets and is an
implementation matter — e.g. presentation of a BPv6 bundle to a
BPv6 agent.
* If the payload is a segment payload and the decapsulation element
does not support reassembly, the element SHALL discard the
payload. Support for reassembly is OPTIONAL; support for
generating segments is likewise OPTIONAL.
* If the payload is a segment payload and the decapsulation element
supports reassembly, the payload SHALL be processed as described
in Section 4.5.
4.5. Reassembly
A decapsulation element maintains a reassembly structure per active
transfer, keyed by the triple (source node ID, destination EID,
transfer-id) of the encapsulating bundle. Every component of the key
is taken from the encapsulating bundle itself, so the key is
unambiguous even when one decapsulation element is registered in
several endpoints. Source node IDs and destination EIDs are compared
Taylor & Montilla Expires 11 March 2027 [Page 12]
Internet-Draft BIBE September 2026
literally, as EIDs: a decapsulation element is not required to
determine whether two distinct EIDs name the same node or endpoint,
and the consistency rules of Section 5.1 ensure that literal
comparison suffices. The nature of the reassembly structure is an
implementation matter.
Upon processing a segment payload:
* If segment-offset plus the length of encapsulated-data exceeds
total-length, the payload is malformed: the decapsulation element
SHALL discard it and SHOULD discard the reassembly structure for
the transfer, if any.
* If a reassembly structure for the transfer exists and the
payload's total-length differs from the transfer's previously
recorded total-length, the transfer is corrupt: the decapsulation
element SHALL discard the payload and the reassembly structure.
* The BP network may duplicate encapsulating bundles (multi-path
forwarding, repetition at lower layers), so identical duplicates
are normal and benign: if the octets of the segment duplicate
octet ranges already received with identical content, the
duplicate octets MAY be ignored. If they overlap previously
received ranges with differing content, the transfer is corrupt:
the decapsulation element SHALL discard the payload and the
reassembly structure.
* Otherwise the decapsulation element SHALL insert the segment into
the reassembly structure.
* If, after insertion, every octet in the range zero to total-length
has been received, reassembly is complete: the reassembled
encapsulated bundle SHALL be presented to the BPA as a received
bundle (Section 3), whereupon reception proceeds as defined in
Section 5.6 of [RFC9171], and the reassembly structure SHALL be
discarded.
4.6. Reassembly State
A decapsulation element retains reassembly state for a transfer only
while the transfer can still complete. An incomplete transfer MUST
be discarded no later than the transfer's expiry — the single expiry
time shared by all encapsulating bundles of the transfer
(Section 5.1) — both because no further segment can arrive after that
time, and because the Transfer ID may thereafter be reused for a new
transfer (Section 4.3): reassembly state retained beyond expiry could
wrongly absorb segments of the new transfer.
Taylor & Montilla Expires 11 March 2027 [Page 13]
Internet-Draft BIBE September 2026
Before that deadline, retention of reassembly state is a matter for
the same local resource management policies that govern any other
storage the node commits. A transfer whose state is discarded under
such policy has simply failed: the encapsulated bundle is never
presented to the BPA. A configured upper bound on the interval for
which an incomplete transfer is retained is one such policy, and is
specifically recommended in Section 7.5.
5. The Encapsulating Bundle
An encapsulating bundle is a new bundle, originated by the
encapsulating node acting in the capacity of a bundle source; it is
not a modified copy of the encapsulated bundle, nor a forwarding of
it. No field of the encapsulated bundle's primary block, and no
extension block of the encapsulated bundle, is copied to the
encapsulating bundle by any rule of this document: the encapsulated
bundle contributes octets to the payload, and nothing else.
The converse also holds: the tunnel contributes nothing to the
encapsulated bundle. The encapsulated bundle is immutable while
encapsulated — the octets presented to the BPA of the decapsulating
node (Section 4.4, Section 4.5) SHALL be exactly the octets captured
by the encapsulation function (Section 4.1); neither the
encapsulation function nor the decapsulation element modifies them in
any way, and any divergence is corruption (Section 4.5) or an attack
(Section 7), not processing. This invariance is what allows
integrity protection applied to the encapsulated bundle itself to
survive the tunnel intact.
An encapsulating bundle is an ordinary bundle, and its payload is not
an administrative record; a decapsulation endpoint MUST NOT be the
administrative endpoint of the node. The destination endpoint of an
encapsulating bundle is a decapsulation endpoint, which is distinct
from the destination of the encapsulated bundle.
// Carrying the payload as ordinary application data at a dedicated
// endpoint, rather than as an administrative record, avoids any
// administrative record type allocation, permits multiple
// decapsulation endpoints per node (e.g. per-tunnel), and keeps the
// administrative endpoint free of high-volume traffic.
5.1. Primary Block
The fields of the encapsulating bundle's primary block (Section 4.3.1
of [RFC9171]) are populated as for any newly created bundle, subject
to the following:
Destination EID: SHALL be the decapsulation endpoint ID toward which
Taylor & Montilla Expires 11 March 2027 [Page 14]
Internet-Draft BIBE September 2026
the encapsulated bundle is being forwarded. When the payload is a
segment payload, every encapsulating bundle of the transfer SHALL
bear the same destination EID: the destination is one element of
the scope that identifies the transfer (Section 4.3).
Source node ID: SHOULD be a node ID of the encapsulating node — the
EID of any singleton endpoint in which that node is registered
(Section 4.2.5.2 of [RFC9171]): anonymous (dtn:none) sourcing
defeats the peer authentication measures described in Section 7.
Note that a node may legitimately hold many node IDs; which of
them is used is a matter of policy. When the payload is a segment
payload, however, the source node ID MUST NOT be dtn:none, and
every encapsulating bundle of the transfer SHALL bear the same
source node ID: a decapsulation element identifies a transfer by
literal comparison of source node IDs (Section 4.5), without
resolving which node an EID names, so a node holding several node
IDs must use one of them consistently throughout a transfer.
Report-to EID: Set according to the policy of the encapsulating
node.
Bundle processing control flags: Set according to the policy of the
encapsulating node; the flags of the encapsulated bundle have no
bearing on them. The "bundle's payload is an administrative
record" flag MUST NOT be set.
Creation timestamp: Set as for any newly created bundle
(Section 4.2.7 of [RFC9171]); it is unrelated to the creation
timestamp of the encapsulated bundle.
Lifetime: SHALL be set such that the expiry time of the
encapsulating bundle (creation time plus lifetime) is no later
than the expiry time of the encapsulated bundle: the tunnel can
never extend the transmission opportunity of the encapsulated
bundle — an encapsulating bundle that outlived it would waste
network resources carrying data already expired at decapsulation —
and this bound underpins the transfer machinery of Section 4.3 and
Section 4.6. The expiry time MAY be earlier than that of the
encapsulated bundle, deliberately curtailing the tunnel transit:
for example, where it is known that a bundle failing to complete
the tunnel sub-path within a certain duration cannot achieve
onward delivery within its own lifetime. Where the encapsulated
data has no expiry known to the encapsulating node (e.g. arbitrary
binary data, Section 1.1), an expiry bound SHALL be established by
a-priori configuration and applied in the same way.
Taylor & Montilla Expires 11 March 2027 [Page 15]
Internet-Draft BIBE September 2026
For a segmented transfer, every encapsulating bundle of the transfer
SHALL share a single expiry time — the transfer's expiry — regardless
of when each is created, so that the expiry of a transfer is well
defined at both the encapsulating and decapsulating nodes. Since a
bundle's expiry is a quantity derived from its creation time and
lifetime (Section 5.5 of [RFC9171]), this is achieved by a rolling
calculation: each encapsulating bundle is created with its natural
creation timestamp, and its lifetime is set to the interval remaining
between its creation and the transfer's expiry. A node without an
accurate clock performs the same calculation against locally elapsed
time, setting each encapsulating bundle's lifetime to the transfer
duration remaining at that bundle's creation and carrying a Bundle
Age block as usual (Section 4.4.2 of [RFC9171]).
// The alternative — assigning all encapsulating bundles of a
// transfer an identical creation timestamp — is not viable in
// general: the sequence number component of the creation timestamp
// is generated by the source node's BPA as a property of the
// timestamp mechanism (Section 4.2.7 of [RFC9171]), not assignable
// per transfer, and duplicate (source node ID, creation timestamp)
// pairs risk the "unexpected network behavior" cautioned against
// there. The rolling calculation composes with any timestamp
// generator, and has the useful side effect that later-created
// encapsulating bundles carry shorter lifetimes, so the network
// never retains one longer than the transfer it serves.
Selection of all other parameters governing the forwarding of
encapsulating bundles (priority, security policy, etc.) is likewise a
matter for the encapsulating node; the corresponding parameters of
the encapsulated bundle MAY be consulted where they are known.
5.2. Extension Blocks
The encapsulating bundle carries only extension blocks pertaining to
its own conveyance, inserted according to the policy of the
encapsulating node and processed on the encapsulating path exactly as
for any other bundle. In particular:
* A Hop Count block (Section 4.4.3 of [RFC9171]), if present, is
new: its count starts at zero at the encapsulating node. The hop
count of the encapsulated bundle, if any, does not advance while
the bundle is encapsulated — the entire tunnel transit appears to
the encapsulated bundle as a single hop. This is both a feature
(tunnel transparency) and a hazard; see the loop considerations in
Section 6.
* A Bundle Age block (Section 4.4.2 of [RFC9171]), if present,
reflects the age of the encapsulating bundle only.
Taylor & Montilla Expires 11 March 2027 [Page 16]
Internet-Draft BIBE September 2026
* A Previous Node block (Section 4.4.1 of [RFC9171]) is inserted and
replaced hop by hop on the encapsulating path in the normal
manner, identifying nodes of the tunnel path, not of the
encapsulated bundle's path.
Note that, symmetrically, the extension blocks of the encapsulated
bundle are not processed while it is encapsulated. In particular,
the Bundle Age block of an encapsulated bundle is not updated during
tunnel transit, so the age of an encapsulated bundle originated by a
node without an accurate clock is under-counted by the tunnel transit
time. This is an unavoidable consequence of carrying the
encapsulated bundle opaquely; the lifetime rule of Section 5.1 bounds
the error to at most the remaining lifetime of the encapsulated
bundle at encapsulation. The decapsulation element cannot correct
the encapsulated bundle's Bundle Age block: doing so would modify the
encapsulated bundle, violating the opacity of the tunnel and
invalidating any integrity protection covering it. Once the
encapsulated bundle has been presented to the BPA of the
decapsulating node, however, tunnel opacity is no longer at stake:
the bundle is processed as any received bundle, and the BPA MAY
account for the tunnel transit time in the Bundle Age block in the
manner of Section 4.4.2 of [RFC9171], exactly as a receiving node may
account for known transmission time over any other convergence layer.
The tunnel transit time may be known a priori (e.g. from a contact
plan) or measured from the encapsulating bundles themselves: for a
whole-bundle payload, the age of the encapsulating bundle at delivery
— computed from its creation timestamp, or carried in its own Bundle
Age block — is precisely the tunnel transit time, and for a segmented
transfer the interval from the earliest creation timestamp among the
transfer's encapsulating bundles to the completion of reassembly
serves the same purpose.
The state in which the encapsulated bundle's blocks are frozen is the
state in which the encapsulating node forwards it (Section 4.1). A
Previous Node block in a decapsulated bundle consequently identifies
the encapsulating node: the single hop that the tunnel presents,
consistent with Section 6.1. The decapsulating node takes this block
as it finds it — it cannot verify it in general (the encapsulating
node may hold several node IDs, the encapsulated data may not be a
BPv7 bundle, and the block is optional) and correcting it would
modify the encapsulated bundle — but a stale or absent Previous Node
block is consulted only during local processing at the decapsulating
node and is replaced in the normal manner upon onward forwarding.
Taylor & Montilla Expires 11 March 2027 [Page 17]
Internet-Draft BIBE September 2026
5.3. Payload
The payload of an encapsulating bundle SHALL be represented as a CBOR
array, encoded with definite length. The array size discriminates
the payload form:
* An array of size 1 is a whole-bundle payload. Its sole element is
the encapsulated-data field.
* An array of size 4 is a segment payload: the three segmentation
fields, in the order defined below, followed by the encapsulated-
data field.
* All other array sizes are reserved for future use; a payload with
a reserved array size MUST be discarded by a receiving
decapsulation element.
The fields are defined as follows:
transfer-id: An unsigned integer identifying the transfer to which
this segment belongs (Section 4.3).
total-length: An unsigned integer giving the total length in octets
of the encapsulated bundle.
segment-offset: An unsigned integer giving the offset in octets,
from zero, of the first octet of encapsulated-data within the
encapsulated bundle.
encapsulated-data: A byte string, encoded with definite length. In
a whole-bundle payload, its content is the entire encapsulated
bundle; in a segment payload, its content is a contiguous sequence
of octets of the encapsulated bundle.
An informative CDDL expression of this structure is provided in
Appendix A.
6. Deployment Considerations
The following characteristics of BIBE are to be considered before
deployment:
Taylor & Montilla Expires 11 March 2027 [Page 18]
Internet-Draft BIBE September 2026
1. It is unreliable: there is no BIBE-layer acknowledgement or
retransmission. Where reliability is required it is expected to
be provided by the convergence layers carrying the encapsulating
bundles, by replication/repetition strategies at lower layers
(see, e.g., [BTPU]), by custody or other acknowledgement
signalling operating at a higher layer over the encapsulated
bundles, or end to end by the communicating applications.
2. It fails silently: no condition at or beyond the decapsulation
endpoint is signalled to the encapsulating node. A segment
payload discarded because the decapsulation element does not
support reassembly (Section 4.4), a transfer that expires or is
discarded incomplete (Section 4.6), and a payload discarded for a
reserved array size (Section 5.3) are, to the encapsulating node,
indistinguishable from loss of the encapsulating bundles in
transit — so a misconfigured tunnel, such as a segmentation
threshold set toward a peer that does not support reassembly,
presents as persistent silent loss. This document deliberately
defines no signal reporting the disposition of a payload after
delivery; the visibility available from existing status report
machinery is set out in Section 6.1, and verifying that a tunnel
is correctly configured is an operational matter for its
administrators.
// A post-delivery disposition signal would make every
decapsulation
// element a bundle source, require an enumeration of failure
// reasons, and amount to the acknowledgement layer this protocol
// does not have; and the conditions it could report are
// configuration errors of a bilaterally configured tunnel,
properly
// detected by its operators rather than corrected by the
protocol.
3. Encapsulating and decapsulating nodes require compatible
configuration (the decapsulation endpoint, the segmentation
threshold, and whether reassembly is supported), established in
advance.
4. An encapsulating bundle whose destination endpoint has no
registered decapsulation element at the destination node will be
delivered to whatever application is registered there, or
abandoned; nothing distinguishes an encapsulating bundle from any
other bundle in transit.
5. As with IP tunnels, recursive encapsulation loops are possible:
if the route toward a decapsulation endpoint itself resolves to
BIBE encapsulation (at this node or a mutually recursive one),
each encapsulation produces a new bundle that is encapsulated
Taylor & Montilla Expires 11 March 2027 [Page 19]
Internet-Draft BIBE September 2026
again, without limit. Unlike IP, a bundle has no hop-limit field
that survives encapsulation, so the loop is not self-terminating
within bundle lifetime. An implementation MUST protect against
this, for example by refusing to encapsulate a bundle it
recognizes as one of its own encapsulating bundles, by bounding
nesting depth (compare the tunnel encapsulation limit of
[TUNLIMIT]), or by configuration validation ensuring the route to
a decapsulation endpoint does not traverse the tunnel it serves.
6.1. Diagnostics
BIBE requires no diagnostic machinery of its own: because
encapsulating bundles are ordinary bundles and decapsulation ends in
ordinary reception (Section 5.6 of [RFC9171]), the bundle status
report mechanism of Section 6.1 of [RFC9171] already observes every
stage of the encapsulation chain. Status reports are requested per
bundle and honoured subject to node policy; they are a diagnostic
instrument, and the report flags of encapsulating bundles SHOULD NOT
be set in normal operation — a stream of status reports directed at
the encapsulating node both amplifies traffic and identifies tunnel
traffic to on-path observers (Section 7).
When enabled for diagnosis, the observation points are:
* Tunnel ingress: encapsulation is a forwarding operation
(Section 3), so an encapsulated bundle that requests forwarding
reports causes a "bundle forwarded" status report from the
encapsulating node in the normal way.
* Tunnel transit: the encapsulating node sets the report flags and
report-to EID of the encapsulating bundles it sources
(Section 5.1). Reception and forwarding reports trace the tunnel
path; a deletion report identifies where and why an encapsulating
bundle was lost, using the existing reason codes (e.g. "Lifetime
expired", "Depleted storage", "No known route to destination from
here", "No timely contact with next node on route", "Block
unintelligible", "Hop limit exceeded" — the latter being the
signature of the encapsulation loops cautioned against in
Section 6).
* Transfer completion: delivery reports requested on the
encapsulating bundles of a transfer confirm, chunk by chunk, that
its payloads reached the decapsulation element; a delivery report
still absent at the transfer's expiry (Section 5.1) identifies the
lost segment(s) to the encapsulating node without any signal from
the decapsulating peer.
Taylor & Montilla Expires 11 March 2027 [Page 20]
Internet-Draft BIBE September 2026
* Tunnel egress: the reassembled or whole encapsulated bundle is
presented to the BPA per Section 5.6 of [RFC9171], so its own
reception, deletion, and onward forwarding reports resume in the
normal way; to the encapsulated bundle's reporting, the entire
tunnel transit appears as a single hop.
These observation points compose: delivery reports confirming that
every encapsulating bundle of a transfer reached the decapsulation
endpoint, while the encapsulated bundle's own reception report from
the decapsulating node never arrives, localize the failure to the
decapsulation element itself — a configuration mismatch (Section 6)
rather than transit loss — which is precisely the distinction an
administrator needs when a tunnel fails silently.
The dispositions internal to the decapsulation element (Section 4.4,
Section 4.5, Section 4.6) occur after delivery of the encapsulating
bundle and concern data that is not (or not yet) a bundle; they are
not expressible as status reports about either bundle, and SHOULD
instead be surfaced by local means (logs, counters) at the
decapsulating node.
7. Security Considerations
Security considerations largely follow those of BPv7 [RFC9171] and
BPSec [RFC9172]. In addition, because BIBE is a tunneling protocol,
the security concerns cataloged for IP tunneling in [TUNSEC] apply,
translated to the BP layer, and are addressed in the following
subsections.
7.1. Composition with BPSec
BIBE composes constructively with BPSec: a BCB on the payload of the
encapsulating bundle encrypts the entire encapsulated bundle,
including its primary block, concealing the encapsulated source and
destination from observers on the encapsulating path.
7.2. Circumvention of Policy Enforcement
As [TUNSEC] observes for IP, tunneled traffic is opaque to inspection
and filtering points along the tunnel path: a node on the
encapsulating path that would, by policy, have refused to forward or
store the encapsulated bundle (by destination, source, block content,
size, or any other criterion) cannot apply that policy, particularly
when the encapsulating payload is encrypted. BIBE therefore permits
bundles to cross policy boundaries that they could not cross natively
— which is precisely its cross-domain use case when authorized, and a
policy-evasion channel when not.
Taylor & Montilla Expires 11 March 2027 [Page 21]
Internet-Draft BIBE September 2026
Consequently the decapsulating node is a policy enforcement point: a
decapsulated bundle MUST be subjected to the node's normal inbound
bundle admission policy, exactly as if it had arrived via any
convergence layer, before it is forwarded or delivered. A node
SHOULD NOT afford decapsulated bundles any trust derived from the
encapsulating bundle's security verification unless policy explicitly
says so. Network operators SHOULD restrict, by policy, where
decapsulation elements may be registered and from which peers each
will accept encapsulating bundles, just as prudent IP networks
control where tunnels may terminate.
7.3. Spoofing of the Encapsulated Bundle
Nothing in this protocol authenticates the contents of an
encapsulated bundle: the source of the encapsulated bundle is
whatever its primary block claims, and an authorized (or compromised)
encapsulating peer can inject bundles claiming any source.
Authentication of the encapsulating bundle (e.g. a Block Integrity
Block (BIB) covering the payload) authenticates only the tunnel peer,
not the encapsulated bundle's provenance; end-to-end assurance of the
encapsulated bundle requires BPSec applied to the encapsulated bundle
itself.
7.4. Injection Against Transfers
An adversary able to cause a fabricated bundle to be delivered at a
decapsulation endpoint, bearing the (source node ID, destination EID)
pair and Transfer ID of a transfer in progress, can attack that
transfer. An inconsistent forged segment — one with a mismatched
total-length, or content overlapping previously received ranges —
causes the reassembly rules of Section 4.5 to discard the transfer;
this is a targeted denial of service against a single transfer.
Note, however, that the discard rules are not the vulnerability: the
same adversary can instead inject a consistent forged segment —
matching total-length, at an offset not yet received — and thereby
corrupt the reassembled bundle silently, which no reassembly rule can
detect. Injection of forged segments is fatal to a transfer whatever
the discard rules do; the rules of Section 4.5 merely convert the
detectable subset of such corruptions into prompt failure, releasing
reassembly state rather than expending further resources on a
transfer that can no longer complete correctly.
The mitigation is the same as for resource exhaustion (Section 7.5):
authenticate encapsulating bundles (e.g. with a BIB covering the
payload) so that forged payloads are discarded before they reach the
reassembly procedures, and note that integrity protection applied to
the encapsulated bundle itself, surviving the tunnel intact
(Section 5), detects any corrupt reassembly after decapsulation.
Taylor & Montilla Expires 11 March 2027 [Page 22]
Internet-Draft BIBE September 2026
7.5. Resource Exhaustion
A decapsulating node is exposed to resource-exhaustion attack by an
adversary transmitting incomplete transfers, or segment payloads with
large total-length values. Although Section 4.6 bounds the retention
of reassembly state by the expiry of the encapsulating bundles, that
expiry is claimed by the sender: an adversary can assign its
encapsulating bundles distant expiry times and simply decline to send
one or more segments. A decapsulating node SHOULD therefore be
configurable with an upper bound of its own on the retention of
reassembly state — a maximum interval for which an incomplete
transfer may be held, or equivalently a maximum acceptable remaining
lifetime for encapsulating bundles carrying segment payloads — and
discard, as Section 4.6 permits, any transfer exceeding it: the
sender-claimed expiry then bounds well-behaved transfers, while the
configured bound caps the exposure to hostile or broken ones.
Because decapsulation endpoints are established by administrative
policy rather than at a well-known service identifier (Section 3), an
adversary has no predictable target for such traffic; operators
SHOULD treat decapsulation endpoint IDs as configuration shared only
with authorized tunnel peers. The expiry deadline and local resource
management policies of Section 4.6 mitigate this; deployments SHOULD
additionally authenticate encapsulating bundles (e.g. with a BIB
covering the payload) so that payloads from unauthorized sources can
be discarded before reassembly state is committed. Authentication
narrows the exposure to authorized peers but does not eliminate it: a
compromised or misbehaving authorized peer can still commit
reassembly storage up to whatever bound local policy enforces, and
that policy is therefore the mitigation of last resort.
Recursive encapsulation is a related amplification hazard; see
Section 6 for the required loop protections.
8. IANA Considerations
This document has no IANA actions: decapsulation endpoints are
established by administrative policy (Section 3), so no well-known
service identifier is defined, and the payload of an encapsulating
bundle is not an administrative record, so no administrative record
type is allocated.
9. References
9.1. Normative References
Taylor & Montilla Expires 11 March 2027 [Page 23]
Internet-Draft BIBE September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
9.2. Informative References
[BTPU] Taylor, R., "Bundle Transfer Protocol - Unidirectional",
Work in Progress, Internet-Draft, draft-ietf-dtn-btpu-04,
7 September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dtn-btpu-04>.
[GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/rfc/rfc2784>.
[GREKEY] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/rfc/rfc2890>.
[IPIP] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/rfc/rfc2003>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/rfc/rfc5050>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
Taylor & Montilla Expires 11 March 2027 [Page 24]
Internet-Draft BIBE September 2026
[RFC9758] Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI
Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025,
<https://www.rfc-editor.org/rfc/rfc9758>.
[TUNLIMIT] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/rfc/rfc2473>.
[TUNMTU] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <https://www.rfc-editor.org/rfc/rfc4459>.
[TUNSEC] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/rfc/rfc6169>.
Appendix A. CDDL Expression
For informational purposes, Figure 2 restates the structure defined
in Section 5.3 in CDDL [RFC8610], extending the $payload-block-data
socket defined in Appendix B of [RFC9171]: the payload block content
is an encoded CBOR array in which the three segmentation fields are
optional as a group — either all present (a segment payload) or all
absent (a whole-bundle payload) — and the final field is always a
byte string. If this CDDL and the text definitions of Section 5.3
disagree, the text governs.
$payload-block-data /= bstr .cbor encapsulation-payload
encapsulation-payload = [
? (
transfer-id: uint,
total-length: uint,
segment-offset: uint
),
encapsulated-data: bstr
]
Figure 2: CDDL definition of the encapsulating bundle payload
Note that encoding constraints (definite-length encoding) are matters
for the text definitions of Section 5.3; CDDL does not express
encoding options. Note also that encapsulated-data is deliberately a
plain bstr rather than bstr .cbor bundle: its content may be a BPv6
bundle (which is not CBOR) in the version-encapsulation use case, and
in a segment payload it is an arbitrary slice of octets that need not
be well-formed CBOR at all.
Taylor & Montilla Expires 11 March 2027 [Page 25]
Internet-Draft BIBE September 2026
Acknowledgments
This document is directly derived from draft-ietf-dtn-bibect,
authored by Scott Burleigh, Alberto Montilla, Joshua Deaton, and
Carlo Caini; its architecture and concepts originate with them. The
central insight — that a BP network can itself serve as the "link
layer" beneath a further layer of bundle protocol — is Scott
Burleigh's, and the encapsulation-only scope of this document is a
return to that of his original 2013 formulation, draft-irtf-burleigh-
bibe.
The segmentation mechanism was designed within the CCSDS Bundle-in-
Bundle Encapsulation effort of the Space Internetworking Services
(SIS-DTN) working group, which identified bundle segmentation, rather
than BPv7 fragmentation, as the appropriate tool for carrying large
bundles over size-limited paths, and defined the representation this
document adopts. Joshua Deaton contributed to both the IETF and
CCSDS strands of that work, which was demonstrated in a prototype
implementation within DTNME at NASA. The segmentation model is
aligned with the transfer/segment design of [BTPU].
Brian Sipos contributed the CDDL formulation in Appendix A, the
discipline of keeping normative text definitions strictly separate
from CDDL, and the review that led to the PDU-derived Transfer ID
scope of Section 4.3.
The original bundle-in-bundle encapsulation concept derives from
draft-irtf-dtnrg-bundle-encapsulation (2009) by Susan Symington, Bob
Durst, and Keith Scott of The MITRE Corporation, whose influence is
gratefully acknowledged.
Contributors
Scott Burleigh
IPNGROUP
Email: sburleig.sb@gmail.com
Author of the successive BIBE Internet-Drafts, from draft-irtf-
burleigh-bibe (2013) through draft-ietf-dtn-bibect, from which this
document is directly derived; the BIBE architecture is his.
Joshua Deaton
SAIC
Email: joshua.e.deaton@nasa.gov
Taylor & Montilla Expires 11 March 2027 [Page 26]
Internet-Draft BIBE September 2026
Co-author of draft-ietf-dtn-bibect, and contributor to the CCSDS
Orange Book segmentation work on which the segmentation mechanism of
this document builds.
Carlo Caini
University of Bologna
Email: carlo.caini@unibo.it
Co-author of draft-ietf-dtn-bibect.
Authors' Addresses
Rick Taylor (editor)
Aalyria Technologies
Email: rtaylor@aalyria.com
Alberto Montilla (editor)
Spatiam Corporation
Email: a.montilla@spatiam.com
Taylor & Montilla Expires 11 March 2027 [Page 27]