Bundle-in-Bundle Encapsulation

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 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.¶

• 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).¶

The encapsulated bundle is a BPv7 bundle. As in [BTPU], however, it is treated throughout the tunnel as an opaque sequence of octets: no field of this protocol describes its content, and neither the encapsulation function nor the decapsulation element parses it. Its validity as a bundle is assessed only once it has been presented to the BPA of the decapsulating node (Section 4.4).¶

Encapsulating bundles are themselves bundles and may in turn be encapsulated, enabling nested encapsulation to arbitrary depth as required by policy. One application is the recursive layering of DTN networks, each layer free to use its own routing approach ([RECURSIVE-DTN]).¶

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).¶

2.1. Terminology

Encapsulated bundle:

A BPv7 bundle 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.¶

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. 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.¶

• 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.¶

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).¶

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. The requirement extends only to the transfer's expiry (Section 5.1), after which no encapsulating bundle of the transfer can be delivered. A singleton endpoint satisfies it 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. An endpoint whose members may take delivery of distinct bundles — one with anycast semantics, or a multi-member endpoint for which the choice of delivering member is unspecified — does not satisfy it in general: distinct encapsulating bundles of one transfer may be delivered to different members, each member accumulates a disjoint, incomplete set of segments, and the transfer fails silently at its expiry, having occupied reassembly state at each of those members until then.¶

Accordingly, an encapsulating node MUST NOT segment a bundle toward a decapsulation endpoint unless it is known that, until the transfer's expiry, every encapsulating bundle of the transfer that is delivered will be delivered to the same member, or to every member. This 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. It is also known where the encapsulating node sets the transfer's expiry, as Section 5.1 permits, no later than the end of an interval during which only one member can take delivery: for example, a single contact during which that member, as the encapsulating node's next hop, is the only member that can take delivery. Such an interval ends no later than the earliest time at which any other member could take delivery of an encapsulating bundle of the transfer; where the coverage of several members overlaps, that may be well before the end of the contact. 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.¶

A transfer bounded in this way fails if the interval closes before all of its encapsulating bundles have been transmitted: those not yet transmitted expire at the encapsulating node. An encapsulating node that retains the encapsulated bundle until every encapsulating bundle of the transfer has been transmitted (Section 4.1 permits, but does not require, this) can detect that failure locally, and can encapsulate the bundle afresh, as a new transfer, in a later interval, subject as always to the encapsulated bundle's remaining lifetime (Section 5.1).¶

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 (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).¶

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. Decapsulated octets that do not constitute a well-formed BPv7 bundle (Section 4 of [RFC9171]) are disposed of by that processing in the same way as a malformed bundle received via any convergence layer.¶

• 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 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.¶

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, and a configured upper bound on the total-length of a transfer for which any reassembly state will be committed, are two such policies, and both are specifically recommended in Section 7.5.¶

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. 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 a bundle 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.¶

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]).¶

Assigning every encapsulating bundle of a transfer an identical creation timestamp, and hence an identical lifetime, is not an alternative. The creation timestamp is a property of the BPA's timestamp mechanism (Section 4.2.7 of [RFC9171]), not a per-transfer parameter, and together with the source node ID it identifies a bundle: bundle status reports identify their subject bundle by exactly that pair (Section 6.1.1 of [RFC9171]), so encapsulating bundles sharing a creation timestamp would render the per-segment delivery reports of Section 6.1 indistinguishable.¶

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 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, 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 (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.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"). On the tunnel path, "Hop limit exceeded" signals a routing loop among the nodes forwarding the encapsulating bundle, and is available only if the encapsulating node included a Hop Count block. It is not a signature of the recursive encapsulation loops cautioned against in Section 6: each encapsulation sources a new bundle whose hop count starts at zero (Section 5.2), so no hop limit is ever reached, and such loops are detectable only by the local protections required there.¶

• 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.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.¶

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.¶

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.¶

Total-length is likewise claimed by the sender: a single segment payload claiming a very large total-length can induce a decapsulation element that commits storage for the whole transfer upon receipt of its first segment to commit far more storage than the adversary has sent. A decapsulating node SHOULD therefore also be configurable with a maximum acceptable total-length, and SHOULD discard any segment payload whose total-length exceeds it before committing any reassembly state. A natural choice is the largest bundle the node would accept via any convergence layer: the reassembled bundle is in any case subject to the node's normal inbound admission policy, and nothing is gained by reassembling a bundle that will then be refused. Independently of any such bound, an implementation SHOULD NOT commit storage in proportion to a claimed total-length in advance of receiving the corresponding octets.¶

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.¶

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>.

[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-05, 15 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-btpu-05>.

[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>.

[RECURSIVE-DTN]

Feldmann, M., Nöthlich, T., Walter, F., Nitsch, M., Fraire, J. A., Murzik, G. A., and F. Fuchs, "Recursive Delay-Tolerant Networking using Bundle-in-Bundle Encapsulation", DOI 10.48550/arXiv.2510.27325, arXiv 2510.27325, October 2025, <https://arxiv.org/abs/2510.27325>.

[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>.

[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>.