]> Aalyria Technologies

rtaylor@aalyria.com

Spatiam Corporation

a.montilla@spatiam.com

INT Delay/Disruption Tolerant Networking DTN BPv7 Bundle Protocol Encapsulation 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Bundle Protocol version 7 (BPv7) defines a layered architecture in which a Bundle Protocol Agent (BPA) relies on convergence-layer adapters (CLAs) to transfer bundles between nodes. This document defines Bundle-in-Bundle Encapsulation (BIBE), in which the transfer between two nodes is performed by a BP network itself: an outbound bundle (the "encapsulated bundle") is carried as the payload of one or more bundles (the "encapsulating bundles") which traverse the BP network between the encapsulating node and the decapsulating node in the normal manner. This document is an editorial consolidation of prior work: the architecture and concepts originate in draft-ietf-dtn-bibect and the CCSDS Bundle-in-Bundle Encapsulation effort, and the design contributions of others are recorded in the Contributors and Acknowledgments sections. The editors claim no design novelty; the contribution of this document is to restate that body of work as a single self-contained specification. BIBE thus occupies the architectural position of a convergence layer — the "link layer" beneath it is itself a BP network — but this document deliberately does not require that it be implemented as a convergence-layer adapter; it specifies observable behavior only, in terms of the encapsulation function and decapsulation element defined in . 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.

Use Cases BIBE has broad utility; motivating use cases include:

• Security encapsulation. BPSec 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 bundle can be encapsulated for carriage across a BPv7 network, or vice versa.
• Segmentation. BPv7 bundle fragmentation () is incompatible with some BPSec deployments and is prohibited for bundles bearing certain security blocks. The segmentation mechanism defined in this document () 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 (), 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 ().

As in , the encapsulated bundle is treated throughout as an opaque sequence of octets: no field of this protocol identifies its format, and nothing in the procedures of this document depends upon it. Bundles of different Bundle Protocol versions can therefore be carried, and multiplexed to the same decapsulation endpoint, without an explicit discriminator: a receiver can distinguish the formats by simple examination of the initial octets of the decapsulated data (a BPv6 bundle begins with the octet 0x06, the BPv6 version number, whereas a BPv7 bundle begins with the initial octet of a CBOR array). Indeed, any binary data can be carried; the disposition of decapsulated data that is not a bundle is beyond the scope of this document and is a matter for the receiving implementation. Encapsulating bundles are themselves bundles and may in turn be encapsulated, enabling nested encapsulation to arbitrary depth as required by policy.

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 and IP-in-IP , 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 ().
• 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 is the analog of "outer fragmentation" in IP tunnels (): 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 ) and the security concerns cataloged in (see ).

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 when, and only when, they appear in all capitals, as shown here.

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

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 .

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.

Functional Model BIBE is specified as observable behavior, not as a component architecture, in terms of two entities:

• An "encapsulation function", invoked by the BPA of the encapsulating node in the course of forwarding a bundle: it generates one or more payloads, each encapsulating all or part of the bundle being forwarded, and, acting in the capacity of a bundle source, sources the encapsulating bundles that carry them (). Each encapsulating bundle is a new bundle, originated at the encapsulating node; see .
• A "decapsulation element", registered in one or more endpoints of the decapsulating node: it takes delivery of the payloads of encapsulating bundles, performs reassembly when required, and, acting in the capacity of a convergence-layer adapter, presents encapsulated bundles to the BPA for forwarding and/or delivery in the standard manner ().

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.

Functional model: encapsulation of bundle B in bundle E node --CLA--> ... --CLA--> BPA ----------+ ordinary BPv7 forwarding of bundle E ]]>

How a BPA selects the encapsulation function is an implementation matter: it might be realized as a convergence-layer adapter selected by a forwarding table entry, applied as a filter or transform on the egress forwarding path, or integrated in some other way. Nothing in this document depends on the choice. The decapsulation element, by contrast, cannot be realized solely as a convergence-layer adapter: it takes delivery of the payloads of bundles addressed to it, and it therefore MUST be registered in one or more endpoints — in the terms of , it acts in the capacity of an element of the node's application agent. When it presents an encapsulated bundle to the BPA, however, it presents a received bundle for the reception processing of (), and in doing so acts in the capacity of a convergence-layer adapter. Nothing in this document prevents a single component from acting in both capacities — indeed, taking delivery of encapsulation payloads in the capacity of an application-agent element and presenting encapsulated bundles in the capacity of a convergence-layer adapter is the natural realization. The choice of endpoints in which a decapsulation element is registered is a matter of administrative policy at the decapsulating node. A BIBE tunnel is a deliberate, bilaterally configured arrangement — an encapsulating node must in any case hold per-peer configuration (), 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 (). A decapsulation endpoint SHOULD be an endpoint formed in a URI scheme whose procedures define which member or members of the endpoint take delivery of a bundle destined for it. A singleton endpoint satisfies this trivially; so would an endpoint in a scheme with defined multicast delivery semantics — delivery to every member — which would realize multicast BIBE: encapsulated forwarding to every member of the decapsulation endpoint at once. What is to be avoided is an endpoint with more than one member for which the choice of delivering member is left unspecified, as the Bundle Protocol leaves it for multi-member endpoints in the dtn scheme; the consequences of that indeterminacy for BIBE — unpredictable duplication of whole-bundle payloads, and segmented transfers that can never be reassembled — are set out in . 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.

Procedures

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 , 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 (), 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 . The encapsulation function then generates the payload or payloads:

• If the length of the bundle does not exceed the segmentation threshold for that endpoint (), 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 . If the bundle cannot be segmented — the encapsulation function does not support segmentation, or the decapsulation element is not known to support reassembly () — then forwarding by encapsulation has failed, and the forwarding contraindication procedures of 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 . 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 ().

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 (). 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 , 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 .
• 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 (). An abandoned transfer occupies reassembly state at the decapsulation element until the transfer's expiry (), and its Transfer ID remains unavailable for reuse until that same time (). 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 (), and an element holding only some of a transfer's segments can never complete it. A singleton endpoint satisfies this requirement trivially. An endpoint in a scheme whose delivery procedures deliver every bundle to every member () also satisfies it: each member takes delivery of the complete set of segments and reassembles independently. What cannot satisfy it is a multi-member endpoint for which the choice of delivering member is unspecified: distinct encapsulating bundles of one transfer may then be delivered to different members, each member accumulates a disjoint, incomplete set of segments, and the transfer fails silently at its expiry. Accordingly, an encapsulating node MUST NOT segment a bundle toward a decapsulation endpoint unless it is known — by the rules of the EID's scheme (every 'ipn' scheme EID identifies a singleton endpoint, ) or by configuration — that every bundle destined for that endpoint is delivered either to a single member or to every member. Whole-bundle payloads are not subject to this constraint: any member taking delivery holds the entire encapsulated bundle, although delivery to more than one member duplicates the encapsulated bundle at each.

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 (). Both elements of the scope are explicit in every encapsulating bundle and are compared literally, as EIDs, at the decapsulating node (), 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 () 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 : 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 (), a Transfer ID becomes safely reusable at exactly the transfer's expiry time. Subject to this rule, the assignment strategy is an implementation matter, and uniqueness in any wider scope implies uniqueness in this one: a sequential counter per (source node ID, destination EID) pair, a counter per destination EID, and a single counter for the whole node are all valid disciplines, as is random assignment. To satisfy the rule across restarts of the encapsulating node, an implementation SHOULD either persist sufficient assignment state or select Transfer IDs after restart in a manner unlikely to collide with transfers still in flight (e.g. derived from a timestamp). CBOR uints are variable-length with no fixed wrap point, and the encoding stays small (1–5 octets) for realistic values, so there is no pressure to keep the identifier space compact.

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 () — whereupon reception proceeds as defined in : the encapsulated bundle may be forwarded, delivered, etc. Where the decapsulated data is not a BPv7 bundle (see ), 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 .

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 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 (), whereupon reception proceeds as defined in , and the reassembly structure SHALL be discarded.

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 () — both because no further segment can arrive after that time, and because the Transfer ID may thereafter be reused for a new transfer (): 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 is one such policy, and is specifically recommended in .

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 (, ) SHALL be exactly the octets captured by the encapsulation function (); neither the encapsulation function nor the decapsulation element modifies them in any way, and any divergence is corruption () or an attack (), 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.

Primary Block The fields of the encapsulating bundle's primary block () 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 ().

Source node ID:

SHOULD be a node ID of the encapsulating node — the EID of any singleton endpoint in which that node is registered (): anonymous (dtn:none) sourcing defeats the peer authentication measures described in . 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 (), 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 (); 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 and . 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, ), 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 (), 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 (). The alternative — assigning all encapsulating bundles of a transfer an identical creation timestamp — is not viable in general: the sequence number component of the creation timestamp is generated by the source node's BPA as a property of the timestamp mechanism (), 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.

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 (), 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 .
• A Bundle Age block (), if present, reflects the age of the encapsulating bundle only.
• A Previous Node block () 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 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 , 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 (). A Previous Node block in a decapsulated bundle consequently identifies the encapsulating node: the single hop that the tunnel presents, consistent with . 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.

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

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 .

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., ), 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 (), a transfer that expires or is discarded incomplete (), and a payload discarded for a reserved array size () 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 , and verifying that a tunnel is correctly configured is an operational matter for its administrators. A post-delivery disposition signal would make every decapsulation element a bundle source, require an enumeration of failure reasons, and amount to the acknowledgement layer this protocol does not have; and the conditions it could report are configuration errors of a bilaterally configured tunnel, properly detected by its operators rather than corrected by the protocol.
3. Encapsulating and decapsulating nodes require compatible configuration (the decapsulation endpoint, the segmentation threshold, and whether reassembly is supported), established in advance.
4. An encapsulating bundle whose destination endpoint has no registered decapsulation element at the destination node will be delivered to whatever application is registered there, or abandoned; nothing distinguishes an encapsulating bundle from any other bundle in transit.
5. As with IP tunnels, recursive encapsulation loops are possible: if the route toward a decapsulation endpoint itself resolves to BIBE encapsulation (at this node or a mutually recursive one), each encapsulation produces a new bundle that is encapsulated 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 ), or by configuration validation ensuring the route to a decapsulation endpoint does not traverse the tunnel it serves.

Diagnostics BIBE requires no diagnostic machinery of its own: because encapsulating bundles are ordinary bundles and decapsulation ends in ordinary reception (), the bundle status report mechanism of 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 (). When enabled for diagnosis, the observation points are:

• Tunnel ingress: encapsulation is a forwarding operation (), 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 (). Reception and forwarding reports trace the tunnel path; a deletion report identifies where and why an encapsulating bundle was lost, using the existing reason codes (e.g. "Lifetime expired", "Depleted storage", "No known route to destination from here", "No timely contact with next node on route", "Block unintelligible", "Hop limit exceeded" — the latter being the signature of the encapsulation loops cautioned against in ).
• 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 () 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 , 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 () rather than transit loss — which is precisely the distinction an administrator needs when a tunnel fails silently. The dispositions internal to the decapsulation element (, , ) 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.

Security Considerations Security considerations largely follow those of BPv7 and BPSec . In addition, because BIBE is a tunneling protocol, the security concerns cataloged for IP tunneling in apply, translated to the BP layer, and are addressed in the following subsections.

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.

Circumvention of Policy Enforcement As 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.

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.

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 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 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 (): 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 (), detects any corrupt reassembly after decapsulation.

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 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 permits, any transfer exceeding it: the sender-claimed expiry then bounds well-behaved transfers, while the configured bound caps the exposure to hostile or broken ones. Because decapsulation endpoints are established by administrative policy rather than at a well-known service identifier (), 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 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 for the required loop protections.

IANA Considerations This document has no IANA actions: decapsulation endpoints are established by administrative policy (), 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.

References Normative References This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Aalyria Technologies This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK] This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK] This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK] Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. This memo provides information for the Internet community. This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK] A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK] This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community. This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116. It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

CDDL Expression For informational purposes, restates the structure defined in in CDDL , extending the $payload-block-data socket defined in Appendix B of : 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 disagree, the text governs.

CDDL definition of the encapsulating bundle payload

Note that encoding constraints (definite-length encoding) are matters for the text definitions of ; 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.

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 . Brian Sipos contributed the CDDL formulation in , the discipline of keeping normative text definitions strictly separate from CDDL, and the review that led to the PDU-derived Transfer ID scope of . 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 IPNGROUP

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

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. University of Bologna

carlo.caini@unibo.it

Co-author of draft-ietf-dtn-bibect.