Bundle Protocol Version 7
updated by
Extracted elements (31)
BP is designed as a store-carry-forward overlay network sitting at the application layer of constituent networks, rather than as a conventional internet protocol. This enables operation under intermittent connectivity, large variable delays, and high bit error rates by allowing physical motility to carry data and decoupling sender/receiver concurrent presence.
CBOR encoding was chosen for bundle representation because it enables compact, self-describing binary structure. The ipn URI scheme further supports compact representation by encoding endpoints as pairs of unsigned integers rather than text strings, optimizing for resource-constrained DTN environments.
The protocol is designed for extensibility: additional blocks, administrative records, control flags, and status report types may be defined in supplementary specifications. Unrecognized bundle and block processing control flags MUST be ignored to permit incremental deployment across nodes that may not implement the same extension set simultaneously.
Implementations of BPv7 (this document) will not be interoperable with implementations of RFC 5050 (BPv6). Additionally, the dtn-scheme syntactic rules imposed by BPv7 are more restrictive than those in RFC 5050, potentially affecting applications conforming to the earlier specification.
All implementations MUST include procedures for recognizing, parsing, and acting on (but not necessarily producing) the three defined extension block types: Previous Node Block (type 6), Bundle Age Block (type 7), and Hop Count Block (type 10).
Bundle age MAY be determined by subtracting the creation timestamp from current time only if the timestamp is non-zero and the local clock is known accurate; otherwise bundle age MUST be obtained from the Bundle Age extension block. When a bundle expires, the BPA MUST delete it citing 'Lifetime expired' or 'Traffic pared'.
During bundle reception (Section 5.6), CRCs SHOULD be computed for every block with an attached CRC. If any block is malformed (including syntactically invalid CBOR) or any CRC fails verification, the BPA MUST delete the bundle for reason 'Block unintelligible'.
Generation of status reports MUST be disabled by default and enabled only when the risk of excessive network traffic is deemed acceptable. Requesting status reports for a single bundle can generate up to 1 + 2*(N-1) status report bundles where N is the path length.
If the bundle's source node ID is the null endpoint ID (anonymous bundle), the 'Bundle must not be fragmented' flag MUST be 1 and all status report request flag values MUST be zero, because the bundle is not uniquely identifiable.
The CRC type code for the primary block MUST be non-zero unless the bundle contains a BPSec Block Integrity Block whose target is the primary block. The CRC SHALL be computed over the concatenation of all bytes of the primary block with the CRC field temporarily zeroed.
The format of bundles SHALL conform to CBOR (RFC 8949). The CBOR encodings of all fields in all blocks MUST conform to the core deterministic encoding requirements, except that indefinite-length items are not prohibited.
The primary block of each bundle SHALL be immutable: the CBOR-encoded values of all fields MUST remain unchanged from the time the block is created to the time it is delivered.
Examination of dtn-scheme or ipn-scheme endpoint IDs in transit can support traffic analysis. Where traffic analysis is a plausible threat, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.
A Bundle Status Report is a CBOR array of 4 elements (non-fragment subject bundle) or 6 elements (fragment subject bundle). The first element is a CBOR array of at least four bundle status items covering: received, forwarded, delivered, and deleted status assertions, each optionally including a DTN timestamp.
Administrative records are standard ADUs exchanged between nodes' administrative elements. Each is a CBOR array of two items: record type code (CBOR unsigned integer) and record content. Only administrative record type 1, 'Bundle status report', is defined for BPv7 in this specification.
Bundle fragmentation replaces a bundle with two fragments sharing the same source node ID and creation timestamp; fragment payloads MUST cover the first N and last (M-N) bytes of the original. The primary block of each fragment MUST set the 'bundle is a fragment' flag and include fragment offset and total ADU length fields.
Bundle Processing Control Flags are conveyed in the primary block as a CBOR unsigned integer bit field. Key bits include: bit 0 (bundle is a fragment), bit 1 (ADU is administrative record), bit 2 (must not be fragmented), bit 5 (acknowledgement requested), bits 14/16/17/18 (request status reports for reception/forwarding/delivery/deletion).
The Bundle Age Block (block type 7) contains the number of milliseconds elapsed since bundle creation, updated at each forwarding hop. If the bundle's creation time is zero, the bundle MUST contain exactly one Bundle Age Block. At forwarding, the bundle age value MUST be increased by the elapsed time since reception or creation.
The Hop Count Block (block type 10) contains two unsigned integers: hop limit (1–255) and hop count (initially zero, incremented by 1 on each hop). When hop count exceeds hop limit, the bundle SHOULD be deleted with reason 'Hop limit exceeded'. This block guards against routing loops and ping-pong forwarding anomalies.
The Previous Node Block (block type 6) identifies the node that most recently forwarded the bundle. If the local node is the source, the bundle MUST NOT contain a Previous Node Block. Otherwise, the bundle SHOULD contain exactly one. During forwarding, an existing Previous Node Block MUST be removed and, if configured, a new one inserted with the forwarding node's ID.
The primary bundle block contains the basic forwarding information and SHALL be represented as a CBOR array of 8, 9, 10, or 11 elements depending on whether a CRC is present and whether the bundle is a fragment. Its fields in order are: Version, Bundle Processing Control Flags, CRC Type, Destination EID, Source Node ID, Report-to EID, Creation Timestamp, Lifetime, and optionally Fragment Offset, Total ADU Length, and CRC.
RFC 9171 defines or updates eight IANA registries: Bundle Block Types (Section 9.1), Primary Bundle Protocol Version (9.2), Bundle Processing Control Flags (9.3), Block Processing Control Flags (9.4), Bundle Status Report Reason Codes (9.5), Bundle Protocol URI Scheme Types (9.6), dtn URI Scheme (9.7), and ipn URI Scheme (9.8).
The Bundle Protocol does not itself guarantee the identity of processing entities at endpoints. Authentication requires verification of the signature provided by a Block Integrity Block (BIB) targeting the primary block, as defined by Bundle Protocol Security (BPSec). Nodes that receive bundles should verify authenticity before acting on them.
A registration (node membership in an endpoint) MUST be in one of two states at any time: Active or Passive. In the Active state, deliverable bundles are delivered automatically per scheduling policy. In the Passive state, the delivery failure action fires: either defer delivery until polled/activated, or abandon delivery of the bundle.
A CRC SHALL be represented as a CBOR byte string of 2 bytes for CRC-16/X-25 (type 1) or 4 bytes for CRC32C/Castagnoli (type 2), each constituting an unsigned integer in network byte order. The CRC field SHALL be omitted if and only if the CRC type code is zero.
DTN Time is an unsigned integer representing milliseconds elapsed since the DTN Epoch (2000-01-01 00:00:00 UTC), not affected by leap seconds. Each DTN time SHALL be represented as a CBOR unsigned integer; the value zero indicates unknown time.
Each bundle SHALL be a concatenated sequence of at least two blocks represented as a CBOR indefinite-length array. The first item MUST be the primary bundle block; the last canonical block MUST be the payload block (block number 1); the array is terminated by a CBOR 'break' stop code.
Each canonical (non-primary) block SHALL be a CBOR array of 5 elements (CRC type zero) or 6 elements (CRC present). Fields in order: block type code (unsigned integer), block number (unsigned integer), block processing control flags, CRC type, block-type-specific data (definite-length CBOR byte string), and optional CRC.
Each Endpoint ID (EID) SHALL be represented as a CBOR array of two items: the first is the URI scheme code number (CBOR unsigned integer) and the second is the CBOR encoding of the scheme-specific part as defined per the scheme's registry entry.
The dtn-scheme EID encodes its SSP as a CBOR text string, except 'dtn:none' (the null endpoint) whose SSP SHALL be encoded as CBOR unsigned integer zero. The null endpoint identifies an endpoint that by definition never has any members.
The ipn-scheme EID encodes its scheme-specific part as a CBOR array of two unsigned integers: the node number and the service number (e.g., ipn:13.42 → [13, 42]). All ipn-scheme endpoints are singleton endpoints.