Bundle-in-Bundle Encapsulation
draft-taylor-dtn-bibe-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rick Taylor | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-taylor-dtn-bibe-00
Network Working Group R. Taylor, Ed.
Internet-Draft Aalyria Technologies
Intended status: Standards Track 6 July 2026
Expires: 7 January 2027
Bundle-in-Bundle Encapsulation
draft-taylor-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-taylor-dtn-bibe.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-taylor-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 Expires 7 January 2027 [Page 1]
Internet-Draft BIBE July 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 7 January 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 . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Transfer IDs . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Reception . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Reassembly . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Reassembly State . . . . . . . . . . . . . . . . . . . . 12
5. The Encapsulating Bundle . . . . . . . . . . . . . . . . . . 13
5.1. Primary Block . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Extension Blocks . . . . . . . . . . . . . . . . . . . . 15
5.3. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 17
6.1. Diagnostics . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Composition with BPSec . . . . . . . . . . . . . . . . . 20
7.2. Circumvention of Policy Enforcement . . . . . . . . . . . 20
7.3. Spoofing of the Encapsulated Bundle . . . . . . . . . . . 20
7.4. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Taylor Expires 7 January 2027 [Page 2]
Internet-Draft BIBE July 2026
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. CDDL Expression . . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
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 editor claims 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:
Taylor Expires 7 January 2027 [Page 3]
Internet-Draft BIBE July 2026
* 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
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,
Taylor Expires 7 January 2027 [Page 4]
Internet-Draft BIBE July 2026
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.
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.
Taylor Expires 7 January 2027 [Page 5]
Internet-Draft BIBE July 2026
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).
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
Taylor Expires 7 January 2027 [Page 6]
Internet-Draft BIBE July 2026
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.
* 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
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.
Taylor Expires 7 January 2027 [Page 7]
Internet-Draft BIBE July 2026
The decapsulation element, by contrast, cannot be a convergence-layer
adapter: it must take 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 is an element of the
node's application agent.
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
a singleton endpoint. The Bundle Protocol does not specify which
member or members of an endpoint with more than one member take
delivery of any particular bundle; the consequences of this for BIBE
— 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.
The bundle so presented is the bundle as the encapsulating node
forwards it: encapsulation is a forwarding operation (Section 3), and
the forwarding-time processing that would precede 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 — SHOULD be applied to the bundle before
its octets are captured for encapsulation. The consequences for the
blocks of the encapsulated bundle are set out in Section 5.
Taylor Expires 7 January 2027 [Page 8]
Internet-Draft BIBE July 2026
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).
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.
Taylor Expires 7 January 2027 [Page 9]
Internet-Draft BIBE July 2026
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.
Segmentation requires that every segment of a transfer be delivered
to the same decapsulation element: reassembly state is held by the
element that takes delivery (Section 4.5), and a transfer whose
segments are divided among different elements can never complete.
When a decapsulation endpoint has more than one member node, the
Bundle Protocol does not specify which member takes delivery of any
particular bundle, so distinct encapsulating bundles of one transfer
may be delivered to different members; each member then 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 that endpoint is known
to be a singleton endpoint — by the rules of the EID's scheme (every
'ipn' scheme EID identifies a singleton endpoint, Section 5.1 of
[RFC9758]) or by configuration. 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 (encapsulating node, decapsulation
endpoint). The scope is the encapsulating node itself, not any
particular node ID it uses: however many node IDs a node holds
(Section 4.2.5.2 of [RFC9171]), it draws from a single Transfer ID
space per decapsulation endpoint. 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.
Taylor Expires 7 January 2027 [Page 10]
Internet-Draft BIBE July 2026
An encapsulating node MUST NOT assign a Transfer ID that identifies
another transfer, to the same decapsulation endpoint, any of whose
encapsulating bundles have yet to expire. Because every
encapsulating bundle of a transfer shares a single expiry time
(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: sequential assignment is one
convenient choice, but random assignment is equally valid. 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, 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 pair (source node ID of the encapsulating
bundle, transfer-id). Source node IDs are compared literally, as
EIDs: a decapsulation element is not required to determine whether
two distinct EIDs name the same node, and the source consistency rule
of Section 5.1 ensures that literal comparison suffices. The nature
of the reassembly structure is an implementation matter.
Taylor Expires 7 January 2027 [Page 11]
Internet-Draft BIBE July 2026
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, 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.
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.
Taylor Expires 7 January 2027 [Page 12]
Internet-Draft BIBE July 2026
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
the encapsulated bundle is being forwarded.
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
Taylor Expires 7 January 2027 [Page 13]
Internet-Draft BIBE July 2026
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.
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
Taylor Expires 7 January 2027 [Page 14]
Internet-Draft BIBE July 2026
// 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.
* 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 decapsulating node cannot correct the
Taylor Expires 7 January 2027 [Page 15]
Internet-Draft BIBE July 2026
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.
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.
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, scoped to the pair (encapsulating node,
decapsulation endpoint). See 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
Taylor Expires 7 January 2027 [Page 16]
Internet-Draft BIBE July 2026
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:
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.
Taylor Expires 7 January 2027 [Page 17]
Internet-Draft BIBE July 2026
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
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
Taylor Expires 7 January 2027 [Page 18]
Internet-Draft BIBE July 2026
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.
* 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.
Taylor Expires 7 January 2027 [Page 19]
Internet-Draft BIBE July 2026
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.
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.
Taylor Expires 7 January 2027 [Page 20]
Internet-Draft BIBE July 2026
7.4. 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. 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
[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>.
Taylor Expires 7 January 2027 [Page 21]
Internet-Draft BIBE July 2026
[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-02,
17 February 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dtn-btpu-02>.
[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>.
[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>.
Taylor Expires 7 January 2027 [Page 22]
Internet-Draft BIBE July 2026
[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 Expires 7 January 2027 [Page 23]
Internet-Draft BIBE July 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, and the
discipline of keeping normative text definitions strictly separate
from CDDL.
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.
Alberto Montilla
Spatiam Corporation
Email: a.montilla@spatiam.com
Co-author of draft-ietf-dtn-bibect.
Taylor Expires 7 January 2027 [Page 24]
Internet-Draft BIBE July 2026
Joshua Deaton
SAIC
Email: joshua.e.deaton@nasa.gov
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.
Author's Address
Rick Taylor (editor)
Aalyria Technologies
Email: rtaylor@aalyria.com
Taylor Expires 7 January 2027 [Page 25]