RFC 9171
Bundle Protocol Version 7
Bundle Protocol Version 7 🦋
Okay bestie, this is RFC 9171 from the IETF (Internet Engineering Task Force), so it's an official Request for Comments 💅 The Category is Standards Track, the ISSN is 2070-1721, and it came out in January 2022. The authors are S. Burleigh from IPNGROUP, K. Fall from Roland Computing Services, and E. Birrane, III from APL at Johns Hopkins University. The title block doesn't list anything it obsoletes or updates, but the abstract says it's adapted from RFC 5050 🌸
Abstract
This document gives a spec for the Bundle Protocol 🎀 It's adapted from the experimental Bundle Protocol spec that the Delay-Tolerant Networking Research Group of the Internet Research Task Force made, which is written up in RFC 5050.
Status of This Memo
This is an Internet Standards Track document ✨
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to give feedback on it is at https://www.rfc-editor.org/info/rfc9171 🧚
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they are in effect on the date this document was published. Please read these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License ⚖️
Table of Contents
1. Introduction
2. Conventions Used in This Document
3. Service Description
3.1. Definitions
3.2. Discussion of BP Concepts
3.3. Services Offered by Bundle Protocol Agents
4. Bundle Format
4.1. Bundle Structure
4.2. BP Fundamental Data Structures
4.2.1. CRC Type
4.2.2. CRC
4.2.3. Bundle Processing Control Flags
4.2.4. Block Processing Control Flags
4.2.5. Identifiers
4.2.5.1. Endpoint ID
4.2.5.1.1. The dtn URI Scheme
4.2.5.1.2. The ipn URI Scheme
4.2.5.2. Node ID
4.2.6. DTN Time
4.2.7. Creation Timestamp
4.2.8. Block-Type-Specific Data
4.3. Block Structures
4.3.1. Primary Bundle Block
4.3.2. Canonical Bundle Block Format
4.4. Extension Blocks
4.4.1. Previous Node
4.4.2. Bundle Age
4.4.3. Hop Count
5. Bundle Processing
5.1. Generation of Administrative Records
5.2. Bundle Transmission
5.3. Bundle Dispatching
5.4. Bundle Forwarding
5.4.1. Forwarding Contraindicated
5.4.2. Forwarding Failed
5.5. Bundle Expiration
5.6. Bundle Reception
5.7. Local Bundle Delivery
5.8. Bundle Fragmentation
5.9. Application Data Unit Reassembly
5.10. Bundle Deletion
5.11. Discarding a Bundle
5.12. Canceling a Transmission
6. Administrative Record Processing
6.1. Administrative Records
6.1.1. Bundle Status Reports
6.2. Generation of Administrative Records
7. Services Required of the Convergence Layer
7.1. The Convergence Layer
7.2. Summary of Convergence-Layer Services
8. Security Considerations
9. IANA Considerations
9.1. Bundle Block Types
9.2. Primary Bundle Protocol Version
9.3. Bundle Processing Control Flags
9.4. Block Processing Control Flags
9.5. Bundle Status Report Reason Codes
9.6. Bundle Protocol URI Scheme Types
9.7. dtn URI Scheme
9.8. ipn URI Scheme
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Significant Changes from RFC 5050
Appendix B. CDDL Expression
Acknowledgments
Authors' Addresses1. Introduction ✨
Ever since the Bundle Protocol spec (Experimental RFC 5050 [RFC5050]) dropped in 2007, the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) has been implemented in multiple programming languages and deployed on a whole bunch of computing platforms 💖 All that implementation and deployment experience has shown where the protocol could be simpler, more capable, and easier to use. This document standardizes the Bundle Protocol, and it's adapted from RFC 5050 with those lessons learned built in. The significant changes from the RFC 5050 Bundle Protocol spec are listed in Appendix A 📝
This document describes BP version 7 (BPv7) 🌈
Delay-Tolerant Networking is a network architecture for communications in and/or through highly stressed environments 🥺 Stressed networks include ones with intermittent connectivity, large and/or variable delays, and high bit error rates. To do its job, BP can be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network. Key capabilities of BP include:
- Ability to use physical motility for the movement of data 🚶♀️
- Ability to move the responsibility for error control from one node to another 🔁
- Ability to cope with intermittent connectivity, including cases where the sender and receiver are not concurrently present in the network 👻
- Ability to take advantage of scheduled, predicted, and opportunistic connectivity, whether bidirectional or unidirectional, in addition to continuous connectivity 📅
- Late binding of overlay-network endpoint identifiers to underlying constituent network addresses 🎯
For descriptions of these capabilities and the rationale for the DTN architecture, see [ARCH] and [SIGC] 📚
BP's place in the standard protocol stack is shown in Figure 1 🦋 BP uses underlying "integrated" transport and/or network protocols for communications within a given constituent network. The layer where those underlying protocols live is called the "convergence layer", and the interface between the Bundle Protocol and a specific underlying protocol is called a "convergence-layer adapter" 🫶
Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3) 👑
+-----------+ +-----------+
| BP app | | BP app |
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BP v | | ^ BP v | | ^ BP v | | ^ BP |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v + +-^---------v + +-^---------+
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +-------------+ +-------------+ +-----------+
| | | |
|<---- A network ---->| |<---- A network ---->|
| | | |Figure 1: The Bundle Protocol in the Protocol Stack Model
This document describes the format of the protocol data units (PDUs), which are called "bundles", that get passed between entities taking part in BP communications 📦
The entities are called "bundle nodes". This document does not cover:
- Operations in the convergence-layer adapters that bundle nodes use to transport data through specific types of internets. (However, the document does discuss the services that must be provided by each adapter at the convergence layer.) 🙈
- The bundle route computation algorithm 🗺️
- Mechanisms for populating the routing or forwarding information bases of bundle nodes 🧭
- The mechanisms for securing bundles en route 🔒
- The mechanisms for managing bundle nodes 🛠️
Heads up: implementations of the specification in this document will not be interoperable with implementations of RFC 5050 💀
2. Conventions Used in This Document ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜
3. Service Description 🌸
3.1. Definitions 📖💖
okay bestie, this is the glossary section 🎀 so we're gonna go term by term, no skipping!!
- Bundle: A bundle is a PDU of BP 🎁. It's named that because negotiating the parameters of a data exchange may be impractical in a delay-tolerant network, so it's often better practice to "bundle" with a unit of application data all the metadata that might be needed to make the data immediately usable when it's delivered to the application. Each bundle comprises a sequence of two or more "blocks" of protocol data, which serve various purposes. ✨
- Block: A Bundle Protocol block is one of the protocol data structures that together constitute a well-formed bundle. 🧩
- Application Data Unit: An application data unit (ADU) is the unit of data whose conveyance to the bundle's destination is the purpose for sending some bundle that is not a fragment (as defined below). 💅
- Bundle payload: A bundle payload (or simply "payload") is the content of the bundle's payload block. "bundle content", "bundle payload", and "payload" are used interchangeably in this document. For a bundle that is not a fragment (as defined below), the payload is an ADU. 🍓
- Partial payload: A partial payload is a payload that comprises either the first N bytes or the last N bytes of some other payload of length M, such that 0 < N < M. Every partial payload is a payload too, which means it can be further subdivided into partial payloads. 🌈
- Fragment: A fragment, a.k.a. "fragmentary bundle", is a bundle whose payload block contains a partial payload. 🦋
- Bundle node: A bundle node (or, in this document, simply a "node") is any entity that can send and/or receive bundles. Each bundle node has three conceptual components, defined below and shown in Figure 2: a "Bundle Protocol Agent", a set of zero or more "convergence-layer adapters", and an "application agent". ("CL1 PDUs" are the PDUs of the convergence-layer protocol used in network 1.) 🌸
Here's the figure, bestie, it's giving architecture 🏰
+-----------------------------------------------------------+
|Node |
| |
| +-------------------------------------------------------+ |
| |Application Agent | |
| | | |
| | +--------------------------+ +----------------------+ | |
| | |Administrative element | |Application-specific | | |
| | | | |element | | |
| | | | | | | |
| | +--------------------------+ +----------------------+ | |
| | ^ ^ | |
| | Admin|records Application|data | |
| | | | | |
| +----------------v--------------------------v-----------+ |
| ^ |
| | ADUs |
| | |
| +-----------------------------v-------------------------+ |
| |Bundle Protocol Agent | |
| | | |
| | | |
| +-------------------------------------------------------+ |
| ^ ^ ^ |
| | Bundles | Bundles Bundles | |
| | | | |
| +------v-----+ +-----v------+ +-----v-----+ |
| |CLA 1 | |CLA 2 | |CLA n | |
| | | | | . . . | | |
| | | | | | | |
+-+------------+-----+------------+-----------+-----------+-+
^ ^ ^
CL1|PDUs CL2|PDUs CLn|PDUs
| | |
+------v-----+ +-----v------+ +-----v-----+
Network 1 Network 2 Network n
Figure 2: Components of a Bundle NodeOkay so that's the whole node layout 👑
- Bundle Protocol Agent: The Bundle Protocol Agent (BPA) of a node is the node component that offers the BP services and executes the procedures of the Bundle Protocol. It's the main character of the node 🎀
- Convergence-layer adapter: A convergence-layer adapter (CLA) is a node component that sends and receives bundles on behalf of the BPA, using the services of some "integrated" protocol stack that is supported in one of the networks within which the node is functionally located. 🔌
- Application agent: The application agent (AA) of a node is the node component that uses the BP services to achieve communication for some user purpose. The application agent in turn has two elements: an administrative element and an application-specific element. 🧚
- Application-specific element: The application-specific element of an AA is the node component that constructs, requests transmission of, accepts delivery of, and processes units of user application data. 💜
- Administrative element: The administrative element of an AA is the node component that constructs and requests transmission of administrative records (defined below), including status reports, and accepts delivery of and processes any administrative records that the node receives. 🫶
- Administrative record: A BP administrative record is an ADU that is exchanged between the administrative elements of nodes' application agents for some BP administrative purpose. The only administrative record defined in this specification is the status report, discussed later. 📝
- Bundle endpoint: A bundle endpoint (or simply "endpoint") is a set of zero or more bundle nodes that all identify themselves for BP purposes by some common identifier, called a "bundle endpoint ID" (or, in this document, simply "endpoint ID"). Endpoint IDs are described in detail in Section 4.2.5.1. 🦋
- Singleton endpoint: A singleton endpoint is an endpoint that always contains exactly one member. 🌟
- Registration: A registration is the state machine characterizing a given node's membership in a given endpoint. Any single registration has an associated delivery failure action (as defined below), and it must at any time be in one of two states: Active or Passive. Registrations are local. Information about a node's registrations is not expected to be available at other nodes, and the Bundle Protocol does not include a mechanism for distributing information about registrations. 🔐
- Delivery: A bundle is considered to have been delivered at a node subject to a registration as soon as the ADU that is the payload of the bundle, together with any relevant metadata (an implementation matter), has been presented to the node's application agent in a manner consistent with the state of that registration. 🎁
- Deliverability: A bundle is considered "deliverable" subject to a registration if and only if (a) the bundle's destination endpoint is the endpoint with which the registration is associated, (b) the bundle has not yet been delivered subject to this registration, and (c) the bundle has not yet been "abandoned" (as defined below) subject to this registration. It's giving checklist energy ✅
- Abandonment: To abandon a bundle subject to some registration is to assert that the bundle is not deliverable subject to that registration. 🙅♀️
- Delivery failure action: The delivery failure action of a registration is the action that is to be taken when a bundle that is "deliverable" subject to that registration is received at a time when the registration is in the Passive state. 🚨
- Destination: The destination of a bundle is the endpoint comprising the node(s) at which the bundle is to be delivered (as defined above). 📍
- Transmission: A transmission is an attempt by a node's BPA to cause copies of a bundle to be delivered to one or more of the nodes that are members of some endpoint (the bundle's destination), in response to a transmission request issued by the node's application agent. 🚀
- Forwarding: To forward a bundle to a node is to invoke the services of one or more CLAs in a sustained effort to cause a copy of the bundle to be received by that node. 💨
- Discarding: To discard a bundle is to cease all operations on the bundle and functionally erase all references to it. The specific procedures by which this is accomplished are an implementation matter. 🗑️
- Retention constraint: A retention constraint is an element of the state of a bundle that prevents the bundle from being discarded. That is, a bundle cannot be discarded while it has any retention constraints. 🔒
- Deletion: To delete a bundle is to remove unconditionally all of the bundle's retention constraints, enabling the bundle to be discarded. ✂️
That's the whole glossary, bestie, you're literally a definitions queen 👑🌈
3.2. Discussion of BP Concepts 🌸
Okay bestie, let's talk about what a bundle actually is. The same bundle (the same unit of DTN protocol data) can exist at the same time in lots of places across a network, possibly with a few blocks that differ. Copies can sit in memory on one or more bundle nodes, or be in transit between nodes. From the point of view of one bundle node, a bundle is just its own instance (copy) in local memory of some bundle that's floating around the network. 💖
The payload of a bundle that gets forwarded because of a bundle transmission request is the ADU whose location was passed in as a parameter to that request. The payload of a bundle that gets forwarded because a bundle was received is the payload of the received bundle. ✨
A bundle node is usually a single process running on a general-purpose computer, but the definition is way broader than that. It could be a thread, an object in an object-oriented operating system, a special-purpose hardware device, etc. 🧚
How the BPA functions get done is totally an implementation matter 💅. The BPA stuff could be coded into each node individually, or live in a shared library that many bundle nodes on one computer use together. It could be a daemon that any number of bundle nodes on one or more computers call through inter-process or network communication, or it could be built into hardware.
Every CLA has its own thin layer of protocol sitting between BP and the (usually "top") protocol(s) of the underlying integrated protocol stack. This "CL protocol" might only multiplex and demultiplex bundles to and from that underlying integrated protocol, or it might offer extra CL-specific functionality 🦋. How a CLA sends and receives bundles, plus the definitions of CLAs and CL protocols, are beyond the scope of this specification.
Also, the administrative element of a node's application agent can sometimes act as a CLA itself! That means outgoing bundles can get "tunneled" through encapsulating bundles 🍓:
- An outgoing bundle is a byte array. This byte array may, like any other, be presented to the BPA as an ADU that is to be transmitted to some endpoint.
- The original bundle thus forms the payload of an encapsulating bundle that is forwarded using some other convergence-layer protocol(s).
- When the encapsulating bundle is received, its payload is delivered to the peer application agent administrative element, which then instructs the BPA to dispatch that original bundle in the usual way.
What this tunneling is useful for (like cross-domain security) is beyond the scope of this specification 🙈.
The only interface between the BPA and the application-specific element of the AA is the BP service interface. But between the BPA and the administrative element of the AA, there's also a (conceptual) private control interface. This private control interface lets the BPA and the administrative element of the AA direct each other to take action under specific circumstances 👑.
If a node is just a BP "router," the AA might not have any application-specific element at all. Other nodes' AAs can have application-specific elements doing arbitrarily complex application stuff, maybe even offering multiplexed DTN communication services to a bunch of other applications. Just like with the BPA, how the AA does its job is totally an implementation matter 💖.
Singletons are the most familiar kind of endpoint, but the endpoint idea is meant to be broader. For example, the nodes in a sensor network might all be registered in one shared endpoint and all receive any data delivered there 🌈. Note too that any single bundle node can be registered in multiple bundle endpoints and receive all the data delivered at each of them ⭐.
Remember that every node, by definition, includes an application agent, which includes an administrative element, which swaps administrative records with the administrative elements of other nodes 🫶. So every node is permanently, structurally registered in the singleton endpoint where administrative records from other nodes get delivered. You can never assume that registration in any other endpoint is permanent 😭. This endpoint is called the node's "administrative endpoint." It's uniquely and permanently tied to the node, which is why the ID of a node's administrative endpoint can always serve as the "node ID" (see Section 4.2.5.2) of that node 🔥.
Every bundle's destination is an endpoint, which may or may not be a singleton. Every bundle's source is a node, identified by node ID. Heads up though: the source node ID asserted in a bundle might be the null endpoint ID (as described later) instead of the real ID of the source node. Bundles whose asserted source node ID is the null endpoint ID are called "anonymous" bundles 🙈.
The BPA of a node can run any number of transmissions at the same time 💅.
When the BPA of a node decides it has to forward a bundle, either to a node that's a member of the bundle's destination endpoint or to some intermediate forwarding node, it calls on the services of one or more CLAs and keeps at it, in a sustained effort, until a copy of the bundle gets received by that node 🚀.
When a bundle is received, what happens next depends on whether the receiving node is registered in the bundle's destination endpoint. If it is, and the bundle's payload is non-fragmentary (maybe because fragmentary payloads were successfully reassembled, including the original payload of the newly received bundle), then the bundle is normally delivered to the node's application agent, following the registration that makes the node a member of that destination endpoint ✨.
The Bundle Protocol itself does NOT ensure that a bundle reaches its destination. Hmm, correction, bestie: it doesn't ensure delivery at all. Data loss along the path can be minimized by using reliable convergence-layer protocols between neighbors on all segments of the end-to-end path. But for real end-to-end bundle delivery assurance, you'll need to develop extensions to the Bundle Protocol and/or application-layer mechanisms 🥺.
The Bundle Protocol was designed to be extensible 🎀. Bundle Protocol extensions, documented elsewhere, can extend this specification by defining additional:
- blocks
- administrative records
- bundle processing control flags
- block processing control flags
- types of bundle status reports
- bundle status report reason codes
- mandates and constraints on processing that conformant BPAs must perform at specified points in the inbound and outbound bundle processing cycles
3.3. Services Offered by Bundle Protocol Agents ✨
The BPA of each node is expected to provide the following services to the node's application agent 🧚:
- commencing a registration (registering the node in an endpoint).
- terminating a registration.
- switching a registration between Active and Passive states.
- transmitting a bundle to an identified bundle endpoint.
- canceling a transmission.
- polling a registration that is in the Passive state.
- delivering a received bundle.
Note that the details of registration functionality are an implementation matter and are beyond the scope of this specification 💅.
4. Bundle Format 🎀
4.1. Bundle Structure 💜
The format of bundles SHALL conform to the Concise Binary Object Representation (CBOR) [RFC8949].
Cryptographic verification of a block is only possible if the sequence of octets that the verifying node hashes (the canonicalized representation of the block) is identical to the sequence of octets that the hash declared for that block was computed over 🔐. To make sure blocks are always in canonical representation when they get transmitted and received, the CBOR encodings of the values of all fields in all blocks MUST conform to the core deterministic encoding requirements specified in [RFC8949], except that indefinite-length items are not prohibited 🌸.
Each bundle SHALL be a concatenated sequence of at least two blocks, represented as a CBOR indefinite-length array 🦋. The first block in the sequence (the first item of the array) MUST be a primary bundle block in CBOR encoding as described below, and the bundle MUST have exactly one primary bundle block. The primary block MUST be followed by one or more canonical bundle blocks (additional array items) in CBOR encoding as described in Section 4.3.2. Every block following the primary block SHALL be the CBOR encoding of a canonical block. The last such block MUST be a payload block, and the bundle MUST have exactly one payload block. The payload block SHALL be followed by a CBOR "break" stop code, which terminates the array 🍓.
(Note that, while CBOR permits considerable flexibility in the encoding of bundles, this flexibility must not be interpreted as inviting increased complexity in PDU structure.)
Each block of a bundle has a block number associated with it. The block number uniquely identifies the block within the bundle, so blocks (notably Bundle Protocol Security blocks) can reference other blocks in the same bundle without any ambiguity 🔥. The block number of the primary block is implicitly zero. The block numbers of all other blocks are explicitly stated in block headers, as noted below. Block numbering has nothing to do with the order the blocks are sequenced in the bundle. The block number of the payload block is always 1 💖.
An implementation of the Bundle Protocol MAY discard any sequence of bytes that does not conform to the Bundle Protocol specification 🗑️.
An implementation of the Bundle Protocol MAY accept a sequence of bytes that does not conform to the Bundle Protocol specification (e.g., one that represents data elements in fixed-length arrays rather than indefinite-length arrays) and transform it into conformant BP structure before processing it. Procedures for accomplishing such a transformation are beyond the scope of this specification 🪄.
4.2. BP Fundamental Data Structures 🌈
4.2.1. CRC Type ⭐
The CRC type is an unsigned integer type code, and the following values (and no others) are valid 🔢:
0indicates "no Cyclic Redundancy Check (CRC) is present."1indicates "a standard X-25 CRC-16 is present." [CRC16]2indicates "a standard CRC32C (Castagnoli) CRC-32 is present." [RFC4960]
CRC type SHALL be represented as a CBOR unsigned integer 💜.
For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143] 🫶.
Note that more robust protection of BP data integrity, if you need it, can be provided by Block Integrity Blocks (BIBs) as defined in the Bundle Protocol Security specification [BPSEC] 🛡️✨.
4.2.2. CRC 🎀
Okay bestie, the CRC SHALL be omitted from a block if and only if the block's CRC type code is zero. So zero means no CRC, no drama 💅
When it's not omitted, the CRC SHALL be represented as a CBOR byte string that's two bytes long (aka CBOR additional information 2, if CRC type is 1) or four bytes long (aka CBOR additional information 4, if CRC type is 2). Either way, the bytes SHALL make up an unsigned integer (16 or 32 bits, respectively) in network byte order 🔥
4.2.3. Bundle Processing Control Flags ✨
Bundle processing control flags are all about the bundle as a whole, not any one particular block inside it 🌈 They get sent along in the primary block of the bundle, so that's where you'll find them 🧚
These flags assert the following properties:
- 🍓 The bundle is a fragment. (Boolean)
- 🍓 The bundle's payload is an administrative record. (Boolean)
- 🍓 The bundle must not be fragmented. (Boolean)
- 🍓 Acknowledgment by the user application is requested. (Boolean)
- 🍓 Status time is requested in all status reports. (Boolean)
- 🍓 Flags requesting types of status reports (all Boolean):
- Request reporting of bundle reception.
- Request reporting of bundle forwarding.
- Request reporting of bundle delivery.
- Request reporting of bundle deletion.
If the bundle processing control flags say the bundle's ADU is an administrative record, then all status report request flag values MUST be zero. No requesting reports on the reports, periodt 🙈
Now, if the bundle's source node is omitted (so the source node ID is the ID of the null endpoint, which has no members as discussed below, and this option is what enables anonymous bundle transmission), then the bundle is not uniquely identifiable 👀 That means every Bundle Protocol feature that relies on bundle identity must therefore be disabled. Concretely, the "Bundle must not be fragmented" flag value MUST be 1, and all status report request flag values MUST be zero. Anonymous means no receipts, bestie 😭
Bundle processing control flags that are unrecognized MUST be ignored. The reason is iconic: future definitions of additional flags might not be integrated simultaneously into the Bundle Protocol implementations operating at all nodes, so nobody should freak out over a flag they don't know yet 💜
The bundle processing control flags SHALL be represented as a CBOR unsigned integer item. Its value SHALL be processed as a bit field that indicates the control flag values as follows. Note that the bit numbering here is reversed from the usual practice, starting with the low-order bit instead of the high-order bit, in recognition of the potential definition of additional control flag values in the future 🦋
Bit 0 (the low-order bit, 0x000001): Bundle is a fragment.
Bit 1 (0x000002): ADU is an administrative record.
Bit 2 (0x000004): Bundle must not be fragmented.
Bit 3 (0x000008): Reserved.
Bit 4 (0x000010): Reserved.
Bit 5 (0x000020): Acknowledgement by application is requested.
Bit 6 (0x000040): Status time requested in reports.
Bit 7 (0x000080): Reserved.
Bit 8 (0x000100): Reserved.
Bit 9 (0x000200): Reserved.
Bit 10 (0x000400): Reserved.
Bit 11 (0x000800): Reserved.
Bit 12 (0x001000): Reserved.
Bit 13 (0x002000): Reserved.
Bit 14 (0x004000): Request reporting of bundle reception.
Bit 15 (0x008000): Reserved.
Bit 16 (0x010000): Request reporting of bundle forwarding.
Bit 17 (0x020000): Request reporting of bundle delivery.
Bit 18 (0x040000): Request reporting of bundle deletion.
Bits 19-20: Reserved.
Bits 21-63: Unassigned.4.2.4. Block Processing Control Flags 💅
Block processing control flags assert properties of canonical bundle blocks. They're carried in the header of the block they belong to, so each block brings its own vibe 🌸
Block processing control flags that are unrecognized MUST be ignored. Same energy as before: future definitions of additional flags might not be integrated simultaneously into the Bundle Protocol implementations operating at all nodes, so unknown flags just get ignored, no tea spilled 🫶
The block processing control flags SHALL be represented as a CBOR unsigned integer item. Its value SHALL be processed as a bit field that indicates the control flag values as follows. Note that the bit numbering is reversed from the usual practice here too, starting with the low-order bit instead of the high-order bit, for agreement with the bit numbering of the bundle processing control flags 👑
Bit 0 (the low-order bit, 0x01): Block must be replicated in every
fragment.
Bit 1 (0x02): Transmit status report if block can't be processed.
Bit 2 (0x04): Delete bundle if block can't be processed.
Bit 3 (0x08): Reserved.
Bit 4 (0x10): Discard block if it can't be processed.
Bit 5 (0x20): Reserved.
Bit 6 (0x40): Reserved.
Bits 7-63: Unassigned.Here's the big one. For each bundle whose bundle processing control flags indicate that the bundle's ADU is an administrative record, or whose source node ID is the null endpoint ID as defined below, the value of the "Transmit status report if block can't be processed" flag in every canonical block of the bundle MUST be zero. No sneaky status reports from these bundles, ever 🙈
Quick reminder, bestie: these flag bits are the same ones you'll see again, so keep the bit numbers straight 💖
4.2.5. Identifiers 🦋
4.2.5.1. Endpoint ID 🌸
Bundles are delivered to bundle endpoints, which are identified by text strings called "endpoint IDs" (see Section 3.1). Each endpoint ID (EID) is a Uniform Resource Identifier [URI]. So every endpoint ID basically has this general structure ✨
< scheme name > : < scheme-specific part, or "SSP" >The scheme named by the < scheme name > in an endpoint ID is a set of syntactic and semantic rules that fully explain how to parse and interpret the scheme-specific part (SSP). Every scheme that may be used to form a BP endpoint ID must be added to the "Bundle Protocol URI Scheme Types" registry, which IANA maintains as described in Section 9.6. Giving each scheme name a unique URI scheme code number in this registry helps make endpoint IDs compact in bundle blocks, which is so clever 🧠 The set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be added to the registry of URI scheme code numbers and then used in a Bundle Protocol endpoint ID. It's giving open-invite energy 💅
Each entry in the registry of URI scheme code numbers MUST contain a reference to a scheme code number definition document. That document defines how the scheme-specific part of any URI formed in that scheme is parsed and interpreted, and it MUST be CBOR encoded for transmission as a BP endpoint ID. The scheme code number definition document may also contain information about (a) which convergence-layer protocol(s) may be used to forward a bundle to a BP destination endpoint identified by such an ID and (b) how the ID of the convergence-layer protocol endpoint to use for that purpose can be inferred from that destination endpoint ID. Okay, that's a lot of info in one doc, but it's giving thorough 🎀
Note that, although endpoint IDs are URIs, implementations of the BP service interface may support expressing endpoint IDs in some internationalized manner, for example Internationalized Resource Identifiers (IRIs); see [RFC3987]. Ooh, international bestie energy 🌍
Each BP endpoint ID (EID) SHALL be represented as a CBOR array comprising two items 🧚
The first item of the array SHALL be the code number identifying the endpoint ID's URI scheme, as defined in the registry of URI scheme code numbers for the Bundle Protocol. Each URI scheme code number SHALL be represented as a CBOR unsigned integer 🔢
The second item of the array SHALL be the applicable CBOR encoding of the scheme-specific part of the EID, defined as noted in the references(s) for the URI scheme code number registry entry for the EID's URI scheme. So the scheme's own entry tells you exactly how to encode that part 💖
4.2.5.1.1. The dtn URI Scheme ✨
Okay bestie, the dtn scheme is all about naming BP endpoints with basically any string you want 💖 It's specified like this:
Scheme syntax: This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. 🎀
dtn-uri = "dtn:" ("none" / dtn-hier-part)
dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
node-name = reg-name
name-delim = "/"
demux = *VCHARScheme semantics: URIs of the dtn scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in the present document. 🌸
The endpoint ID dtn:none is the null endpoint, the one that by definition never has any members. 🫥
Every other dtn-scheme endpoint ID whose demux starts with a character other than ~ (tilde) is a singleton endpoint. 👑 Endpoints whose first demux character is ~ (tilde) are not singleton endpoints. The vibe is totally different, so pay attention 👀
A dtn-scheme endpoint ID whose demux has length zero MAY identify the administrative endpoint for the node named by node-name, which means it can double as a node ID. 🧚 Any dtn-scheme endpoint ID with a non-zero-length demux may not do that.
Heads up: these syntax rules are stricter than what the original dtn scheme from [RFC5050] asked for. Most BP apps built on [RFC5050] probably don't break them, but the developers should know there's a chance their stuff won't interoperate cleanly. 🙈
Encoding considerations: For transmission as a BP endpoint ID, the scheme-specific part of a dtn-scheme URI SHALL be represented as a CBOR text string, unless the EID's SSP is none. In that case the SSP SHALL be represented as a CBOR unsigned integer with the value zero. Everywhere else, dtn URIs are encoded exclusively in US-ASCII characters. 💅
Interoperability considerations: None. 🍓
Security considerations:
- Reliability and consistency: None of the BP endpoints identified by dtn-scheme URIs are guaranteed to be reachable at any time, and the Bundle Protocol itself never guarantees the identity of the processing entities running on those endpoints. To check that, you need to verify the signature from the Block Integrity Block that targets the bundle's primary block, as defined by Bundle Protocol Security [BPSEC]. This is required. 😭
- Malicious construction: A malicious dtn-scheme URI can only be built by choosing node names and demux strings badly. A bad URI could send a bundle to an endpoint that gets damaged when the bundle arrives, or it could claim a fake source and make the receiving node process things incorrectly. In both cases, and honestly in all bundle processing, the node that receives a bundle should verify its authenticity and validity before doing anything with it. 🔥
- Back-end transcoding: Because dtn-scheme URIs are so limited in what they can say, the chance of threats from back-end transcoding errors is basically eliminated. 🦋
- Rare IP address formats: Not relevant, since IP addresses never show up in conformant dtn-scheme URIs. 💀
- Sensitive information: Dtn-scheme URIs only represent the identities of BP endpoints, so the risk of sensitive info leaking from someone intercepting them is pretty minimal. Still, looking at dtn-scheme URIs could help someone do traffic analysis. If traffic analysis is a real danger, bundles should go over secure convergence-layer protocols that don't expose endpoint IDs. 🕵️♀️
- Semantic attacks: The simple syntax of dtn-scheme URIs makes it much harder for a human to misread one. 🌈
4.2.5.1.2. The ipn URI Scheme 🦋
The ipn scheme identifies BP endpoints with pairs of unsigned integers, which makes them super compact to put in bundle blocks. Here's the spec:
Scheme syntax: This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], including the core ABNF syntax rule for DIGIT defined by that specification. 🎀
ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
node-nbr = 1*DIGIT
nbr-delim = "."
service-nbr = 1*DIGITScheme semantics: URIs of the ipn scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in the present document. 🌸
Every BP endpoint identified by an ipn-scheme endpoint ID is a singleton endpoint. 👑
An ipn-scheme endpoint ID whose service-nbr is zero MAY identify the administrative endpoint for the node named by node-nbr, so it can serve as a node ID. 🧚 No ipn-scheme endpoint ID with a non-zero service-nbr may do that.
Encoding considerations: For transmission as a BP endpoint ID, the scheme-specific part of an ipn-scheme URI SHALL be represented as a CBOR array with two items. The first item of that array SHALL be the EID's node number (the number that identifies the node), represented as a CBOR unsigned integer. The second item SHALL be the EID's service number (the number that identifies some application service), also represented as a CBOR unsigned integer. Everywhere else, ipn URIs are encoded exclusively in US-ASCII characters. 💅
Interoperability considerations: None. 🍓
Security considerations:
- Reliability and consistency: None of the BP endpoints identified by ipn-scheme URIs are guaranteed to be reachable at any time, and the Bundle Protocol itself never guarantees the identity of the processing entities on those endpoints. Verifying the signature from the Block Integrity Block that targets the bundle's primary block, as defined by Bundle Protocol Security [BPSEC], is required for this. 😭
- Malicious construction: A malicious ipn-scheme URI can only be built by picking node numbers and service numbers badly. That URI could send a bundle to an endpoint that gets damaged when the bundle arrives, or it could declare a false source and make the receiving node process things incorrectly. In both cases, and in all bundle processing, the node that receives a bundle should verify its authenticity and validity before operating on it in any way. 🔥
- Back-end transcoding: The limited expressiveness of ipn-scheme URIs effectively eliminates any threat from errors in back-end transcoding. 🦋
- Rare IP address formats: Not relevant, because IP addresses never appear in conformant ipn-scheme URIs. 💀
- Sensitive information: Ipn-scheme URIs only represent the identities of BP endpoints, so the risk of sensitive info being disclosed through interception is minimal. Examining ipn-scheme URIs could still support traffic analysis. Where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that don't expose endpoint IDs. 🕵️♀️
- Semantic attacks: The simplicity of ipn-scheme URI syntax minimizes the chance a human user misinterprets one. 🌈
4.2.5.2. Node ID 🪪
For lots of Bundle Protocol purposes, it matters a lot to know which node is operating in a given context. 👀
As discussed in Section 3.1, nodes are distinct from endpoints. An endpoint is a set of zero or more nodes. Instead of defining a separate namespace just for node identifiers, we use endpoint identifiers to identify nodes, as discussed in Section 3.2. Here's the formal version:
- Every node is, by definition, permanently registered in the singleton endpoint where administrative records get delivered to its application agent's administrative element. This is called the node's "administrative endpoint". 👑
- Because of that, the EID of a node's administrative endpoint SHALL uniquely identify that node. 🫶
- The EID of any singleton endpoint is allowed to serve as a "node ID" identifying the node that is the sole member of that endpoint. ✨
4.2.6. DTN Time ⏰
A DTN time is an unsigned integer showing how many milliseconds have passed since the DTN Epoch, which is 2000-01-01 00:00:00 +0000 (UTC). DTN time is not affected by leap seconds. 🧚
Each DTN time SHALL be represented as a CBOR unsigned integer item. Implementers need to know that DTN time values carried in CBOR inside bundles will almost always be bigger than (2^32 - 1). How a DTN time value is stored in memory is up to the implementation. The DTN time value zero means the time is unknown. 🌸
4.2.7. Creation Timestamp 🎀
Each bundle's creation timestamp SHALL be represented as a CBOR array with two items. 💖
The first item of the array, called the "bundle creation time", SHALL be the DTN time at which the transmission request that led to the bundle's creation was received. It's represented as a CBOR unsigned integer. 🕰️
The second item, called the creation timestamp's "sequence number", SHALL be the latest value of a monotonically increasing positive integer counter managed by the source node's BPA. That value is as of the moment the transmission request came in, and it's represented as a CBOR unsigned integer. The sequence counter MAY be reset to zero whenever the current time goes up by one millisecond. 🔢
For nodes without accurate clocks, it is recommended that bundle creation time be set to zero, and that the counter used as the source of the bundle sequence count never be reset to zero. 🕛
Here's a big one: in general, creating two different bundles with the same source node ID and bundle creation timestamp may lead to unexpected network behavior and/or suboptimal performance. The combination of source node ID and bundle creation timestamp identifies a single transmission request, which lets the receiving application acknowledge it (as long as the source node ID isn't the null endpoint ID). 🧾
4.2.8. Block-Type-Specific Data 🧩
Block-type-specific data in each block (other than the primary block) SHALL be the applicable CBOR encoding of the block's content. The specification that defines the block type includes the details of this representation. 💜
4.3. Block Structures ✨
okay so this section is where we get into what the blocks actually look like 🎀 we go deep on the primary block first, then talk about non-primary blocks in general. the rules for actually processing them live in Section 5, so bookmark that bestie 💅
heads up, supplementary DTN protocol specs (not just the ones listed, but like, not limited to Bundle Protocol Security [BPSEC]) may require that BP implementations following those specs build and process extra blocks too 👀 the block menu can grow!
4.3.1. Primary Bundle Block 💖
the primary bundle block is the one with the basic info needed to forward bundles to their destinations. main character energy 👑
every primary block SHALL be a CBOR array 🦋 and the number of elements in that array SHALL be 8 (if the bundle is not a fragment and the block has no CRC), 9 (if the block has a CRC and the bundle is not a fragment), 10 (if the bundle is a fragment and the block has no CRC), or 11 (if the bundle is a fragment and the block has a CRC).
the primary block of each bundle SHALL be immutable 🔒 the CBOR-encoded values of all fields in the primary block MUST stay unchanged from the moment the block is created until the moment it's delivered. no edits, no drama!
the fields of the primary bundle block SHALL be as follows, and they MUST appear in this exact order:
Version: an unsigned integer that tells you which version of the Bundle Protocol built this block. this doc is all about BPv7 🌈 the version number SHALL be represented as a CBOR unsigned integer item.
Bundle Processing Control Flags: these are discussed in Section 4.2.3 ✨
CRC Type: the CRC type codes are discussed in Section 4.2.1. the CRC type code for the primary block MAY be zero if the bundle contains a BPSec Block Integrity Block [BPSEC] whose target is the primary block 🫶 otherwise, the CRC type code for the primary block MUST be non-zero.
Destination EID: this identifies the bundle endpoint that's the bundle's destination, i.e., the endpoint that contains the node(s) where the bundle is supposed to be delivered 🎯
Source node ID: this identifies the bundle node where the bundle was first transmitted, except the source node ID can be the null endpoint ID if the bundle's source chooses to stay anonymous 🕶️
Report-to EID: this identifies the bundle endpoint where status reports about forwarding and delivering this bundle get sent 📨
Creation Timestamp: this one is two unsigned integers that, together with the source node ID and (if the bundle is a fragment) the fragment offset and payload length, identify the bundle. see Section 4.2.7 for the full definition 🕰️
Lifetime: an unsigned integer showing the time after which the bundle's payload is no longer useful, encoded as a number of milliseconds past the creation time. (for high-rate deployments with very brief disruptions, fine-grained lifetimes can be useful 🍓) when a bundle's age goes past its lifetime, bundle nodes don't need to keep or forward it anymore, and the bundle SHOULD be deleted from the network 🗑️
okay now the spicy lifetime stuff 🌶️ if the asserted lifetime for a received bundle is so long that holding it until it expires might mess up the node that received it, or if that node's BPA decides the bundle has to be deleted to stop network performance from degrading (like, the bundle looks like part of a denial-of-service attack 😭), then that BPA MAY impose a temporary overriding lifetime that's shorter. that overriding lifetime SHALL NOT replace the lifetime asserted in the bundle, but it SHALL act as the bundle's effective lifetime while the bundle is sitting at that node. how to impose lifetime overrides is out of scope for this spec, so nothing more on that here 🙅♀️
for bundles that come from nodes without accurate clocks, it's recommended that bundle age come from the Bundle Age extension block (see Section 4.4.2) instead of the difference between the current time and the bundle creation time ⏰ the bundle lifetime SHALL be represented as a CBOR unsigned integer item.
Fragment offset: if and only if this primary block's bundle processing control flags say the bundle is a fragment, the fragment offset SHALL be present in the primary block 🧩 it SHALL be represented as a CBOR unsigned integer showing the offset from the start of the original ADU where the bytes of this bundle's payload were located.
Total Application Data Unit Length: if and only if this primary block's bundle processing control flags say the bundle is a fragment, the total application data unit length SHALL be present in the primary block 📏 it SHALL be represented as a CBOR unsigned integer showing the total length of the original ADU that this bundle's payload is part of.
CRC: a CRC SHALL be present in the primary block unless the bundle includes a BPSec Block Integrity Block [BPSEC] whose target is the primary block. in that case, a CRC MAY be present in the primary block 💅 the length and nature of the CRC SHALL be whatever the CRC type says. the CRC SHALL be computed over the concatenation of all bytes of the primary block (including CBOR "break" characters), including the CRC field itself, which, for this purpose, SHALL be temporarily populated with all bytes set to zero 🧮 it's a whole thing, but it's giving precision!
4.3.2. Canonical Bundle Block Format 🎀
every block other than the primary block (these are all called "canonical" blocks, obviously iconic 👑) SHALL be represented as a CBOR array, and the number of elements in that array SHALL be 5 (if the CRC type is zero) or 6 (otherwise).
the fields of every canonical block SHALL be as follows, and they MUST appear in this exact order:
Block type code: an unsigned integer. bundle block type code 1 says the block is a Bundle Payload Block 📦 other block type codes are described in Section 9.1. block type codes 192 through 255 are not reserved, so they're free for private and/or experimental use 🧪 all other block type code values are reserved for future use.
Block number: an unsigned integer, as discussed in Section 4.1. the block number SHALL be represented as a CBOR unsigned integer.
Block processing control flags: as discussed in Section 4.2.4 ✨
CRC type: as discussed in Section 4.2.1 🔢
Block-type-specific data: represented as a single definite-length CBOR byte string, meaning a CBOR byte string that is not of indefinite length 🧶 for each type of block, this byte string is the serialization (done in a block-type-specific way) of the data that block type carries. definitions of blocks are required to define how their block-type-specific data gets serialized inside this field. for the Bundle Payload Block in particular (block type 1), the block-type-specific data field, called the "payload", SHALL be an ADU, or some contiguous extent of one, represented as a definite-length CBOR byte string 📬
if and only if this block's CRC type field is non-zero, there's a CRC 🔐 if it's present, the length and nature of the CRC SHALL be as indicated by the CRC type, and the CRC SHALL be computed over the concatenation of all bytes of the block (including CBOR "break" characters), including the CRC field itself, which, for this purpose, SHALL be temporarily populated with all bytes set to zero. same energy as the primary block, periodt 💜
4.4. Extension Blocks 🌸
"extension blocks" are all the blocks other than the primary and payload blocks. three types of extension blocks are defined below ✨ every BP implementation of this spec (this document) MUST include procedures for recognizing, parsing, and acting on these types of extension blocks, but it doesn't have to produce them 🙌
the specs for additional extension block types have to say whether BP implementations following them must recognize, parse, act on, and/or produce blocks of those types. not every node will run BP implementations that follow those extra specs, so a node might get a bundle with extension blocks it can't process 🤷♀️ the values of the block processing control flags tell the BPA what action to take when that happens.
no mandated procedure in this spec is unconditionally dependent on whether any extension block is present or absent 💫 so any BPA MAY insert or remove any extension block in any bundle, subject to all the mandates in the Bundle Protocol specification and all the extension block specs that the node's BP implementation conforms to. heads up though: removing an extension block will probably break one or more bundle processing elements that the BPA who inserted that block intended 😬 and removing an extension block that's one of the targets of a BPSec security block may make the bundle unverifiable. not a vibe!
the following extension blocks are defined in this doc:
4.4.1. Previous Node 🦋
the Previous Node Block, block type 6, identifies the node that forwarded this bundle to the local node (aka the node where the bundle is currently sitting) 🫸 its block-type-specific data is the node ID of that forwarder node. that node ID SHALL conform to Section 4.2.5.2. if the local node is the source of the bundle, then the bundle MUST NOT contain any Previous Node Block. otherwise, the bundle SHOULD contain one (1) occurrence of this block type and MUST NOT contain more than one 🙈
4.4.2. Bundle Age ⏳
the Bundle Age Block, block type 7, contains the number of milliseconds that have passed between when the bundle was created and when it was most recently forwarded ⏱️ it's meant for nodes that don't have access to an accurate clock, so they can figure out when a bundle's lifetime runs out. the block-type-specific data of this block is an unsigned integer holding the bundle's age in milliseconds, which SHALL be represented as a CBOR unsigned integer item. (the bundle's age is the sum of all known intervals the bundle spent residing at forwarding nodes, up to the time it was most recently forwarded, plus the sum of signal propagation time over all transmission episodes between forwarding nodes. how those values get determined is an implementation matter 🧠)
if the bundle's creation time is zero, then the bundle MUST contain exactly one (1) occurrence of this block type. otherwise, the bundle MAY contain at most one (1) occurrence of this block type. a bundle MUST NOT contain multiple occurrences of the Bundle Age Block, because that could cause processing anomalies 🚫 so keep it to one, bestie!
4.4.3. Hop Count 🎀
okay so the Hop Count Block is block type 10 💅 and it holds two unsigned integers: a hop limit and a hop count. A "hop" here just means one occasion where a bundle got forwarded from one node to another node 🦋. The hop limit MUST be in the range 1 through 255 💖. The hop limit value SHOULD NOT be changed at any time after the Hop Count Block is created 🙈, and the hop count value SHOULD start out at zero and SHOULD go up by 1 on each hop 🌸.
The Hop Count Block is mainly a safety mechanism 🛟, a way of spotting bundles that can never be delivered because of a persistent forwarding error so they can get removed from the network 🗑️. The hop count is especially valuable as a defense against routing anomalies that might bounce a bundle back and forth in a cyclical "ping-pong" fashion between two nodes 🏓. When a bundle's hop count exceeds its hop limit, the bundle SHOULD be deleted for the reason "Hop limit exceeded", following the Bundle Deletion procedure defined in Section 5.10 💀.
Procedures for determining the appropriate hop limit for a bundle are beyond the scope of this specification 🤷♀️.
The block-type-specific data in a Hop Count Block SHALL be represented as a CBOR array with two items 🧚. The first item SHALL be the bundle's hop limit, represented as a CBOR unsigned integer. The second item SHALL be the bundle's hop count, also represented as a CBOR unsigned integer. A bundle MAY contain one occurrence of this type of block 🌈, but it MUST NOT contain more than one ✋.
5. Bundle Processing ✨
The bundle-processing procedures in this section and in Section 6 govern how the BPA and the application agent administrative element of each bundle node operate 👑. They are neither exhaustive nor exclusive. Supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may augment, override, or supersede the mandates of this document 🫶.
5.1. Generation of Administrative Records 💌
All transmission of bundles happens in response to bundle transmission requests presented by nodes' application agents 📨. When required to "generate" an administrative record (such as a bundle status report), the BPA itself is responsible for causing a new bundle to be transmitted, carrying that record. In concept, the BPA handles this by directing the administrative element of the node's application agent to construct the record and request its transmission, as detailed in Section 6. In practice, how administrative record generation gets done is an implementation matter, as long as the constraints noted in Section 6 are observed 🛠️.
Status reports are relatively small bundles 🥰. Even when status report generation is enabled, the decision on whether or not to generate a requested status report is left to the discretion of the BPA. Still, requesting status reports for any single bundle might easily result in the generation of (1 + (2 *(N-1))) status report bundles, where N is the number of nodes on the path from the bundle's source to its destination, inclusive 😱. So requesting status reports for large numbers of bundles could cause an unacceptable increase in bundle traffic across the network 🚨. For this reason, the generation of status reports MUST be disabled by default 🔒, and enabled only when the risk of excessive network traffic is deemed acceptable. Mechanisms that could help assess and mitigate this risk, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification 📜.
Notes on administrative record terminology:
- A "bundle reception status report" is a bundle status report with the
Reporting node received bundleflag set to 1 📥. - A "bundle forwarding status report" is a bundle status report with the
Reporting node forwarded the bundleflag set to 1 📤. - A "bundle delivery status report" is a bundle status report with the
Reporting node delivered the bundleflag set to 1 🎉. - A "bundle deletion status report" is a bundle status report with the
Reporting node deleted the bundleflag set to 1 🗑️.
5.2. Bundle Transmission 🚀
The steps for processing a bundle transmission request go like this 💁♀️:
Step 1: Transmission of the bundle is initiated. An outbound bundle MUST be created per the parameters of the bundle transmission request, with the retention constraint Dispatch pending. The source node ID of the bundle MUST be either (a) the null endpoint ID, indicating that the source of the bundle is anonymous, or (b) the EID of a singleton endpoint whose only member is the node of which the BPA is a component 🕵️♀️.
Step 2: Processing proceeds from Step 1 of Section 5.4 ➡️.
5.3. Bundle Dispatching 📬
(Note that this procedure is initiated only following completion of Step 4 of Section 5.6. 👀)
The steps for dispatching a bundle are as follows 💖:
Step 1: If the bundle's destination endpoint is an endpoint of which the node is a member, the Bundle Delivery procedure defined in Section 5.7 MUST be followed. For all subsequent processing of this bundle at this node, the node's membership in the bundle's destination endpoint SHALL be disavowed 🙅♀️. Specifically, even though the node is a member of the bundle's destination endpoint, the node SHALL NOT undertake to forward the bundle to itself while performing the procedure described in Section 5.4 🔁.
Step 2: Processing proceeds from Step 1 of Section 5.4 ➡️.
5.4. Bundle Forwarding 🦋
The steps for forwarding a bundle are as follows 🧭:
Step 1: The retention constraint Forward pending MUST be added to the bundle, and the bundle's Dispatch pending retention constraint MUST be removed 🔄.
Step 2: The BPA MUST determine whether or not forwarding is contraindicated (that is, rendered inadvisable) for any of the reasons listed in the IANA "Bundle Status Report Reason Codes" registry (see Section 9.5), whose initial contents are listed in Table 1 📋. In particular:
- The BPA MAY choose to either forward the bundle directly to its destination node(s) (if possible), or forward the bundle to some other node(s) for further forwarding 🗺️. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID and/or on other state, but in any case it is beyond the scope of this document. One possible mechanism is described in [SABR] 🛰️. If the BPA elects to forward the bundle to some other node(s) for further forwarding but finds it impossible to select any node(s) to forward the bundle to, then forwarding is contraindicated 🙃.
- Provided the BPA succeeded in selecting the node or nodes to forward the bundle to, the BPA MUST subsequently select the CLA(s) whose services will enable the node to send the bundle to those nodes 📡. The manner in which specific appropriate CLAs are selected is beyond the scope of this document. The TCP CLA [TCPCL] MUST be implemented when some or all of the bundles forwarded by the BPA must be forwarded via the Internet, but it may not be appropriate for forwarding any particular bundle 🌐. If the agent finds it impossible to select any appropriate CLA(s) to use in forwarding this bundle, then forwarding is contraindicated 😭.
Step 3: If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in the IANA "Bundle Status Report Reason Codes" registry (see Section 9.5), then the Forwarding Contraindicated procedure defined in Section 5.4.1 MUST be followed. The remaining steps of this Bundle Forwarding procedure are skipped at this time ⏸️.
Step 4: For each node selected for forwarding, the BPA MUST invoke the services of the selected CLA(s) in order to effect the sending of the bundle to that node 📤. Determining the time at which the BPA invokes CLA services is a BPA implementation matter. Determining the time at which each CLA subsequently responds to this service invocation by sending the bundle is a CLA implementation matter. Note that:
- If the bundle has a Previous Node Block, as defined in Section 4.4.1, then that block MUST be removed from the bundle before the bundle is forwarded 👋.
- If the BPA is configured to attach Previous Node Blocks to forwarded bundles, then a Previous Node Block containing the node ID of the forwarding node MUST be inserted into the bundle before the bundle is forwarded 🏷️.
- If the bundle has a Bundle Age Block, as defined in Section 4.4.2, then at the last possible moment before the CLA initiates conveyance of the bundle via the CL protocol, the bundle age value MUST be increased by the difference between the current time and the time at which the bundle was received (or, if the local node is the source of the bundle, created) ⏰.
Step 5: When all selected CLAs have informed the BPA that they have concluded their data-sending procedures with regard to this bundle, processing may depend on the results of those procedures 🎬.
If completion of the data-sending procedures by all selected CLAs has not resulted in successful forwarding of the bundle (an implementation-specific determination that is beyond the scope of this specification), then the BPA MAY choose (in an implementation-specific manner, again beyond the scope of this specification) to initiate another attempt to forward the bundle 🔁. In that event, processing proceeds from Step 4. The minimum number of times a given node will initiate another forwarding attempt for any single bundle in this event (a number that may be zero) is a node configuration parameter that must be exposed to other nodes in the network to the extent that this is required by the operating environment 🔧.
If completion of the data-sending procedures by all selected CLAs HAS resulted in successful forwarding of the bundle, or if it has not but the BPA does not choose to initiate another attempt to forward the bundle, then 🏁:
- If the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1 and status reporting is enabled, then a bundle forwarding status report SHOULD be generated, destined for the bundle's report-to endpoint ID 📣. The reason code on this bundle forwarding status report MUST be "no additional information" 🙌.
- If any applicable Bundle Protocol extensions mandate generation of status reports upon conclusion of convergence-layer data-sending procedures, all such status reports SHOULD be generated with extension-mandated reason codes 🧩.
- The bundle's "Forward pending" retention constraint MUST be removed 🫧.
5.4.1. Forwarding Contraindicated ✨
okay so this is the part where the bundle is literally not allowed to move right now 🙅♀️💅 here's how the BPA handles it, step by step:
Step 1: The BPA MUST determine whether or not to declare failure in forwarding the bundle. Note: This decision is likely to be influenced by the reason for which forwarding is contraindicated. 🤔
Step 2: If forwarding failure is declared, then the Forwarding Failed procedure defined in Section 5.4.2 MUST be followed. 💀
Otherwise, when, at some future time, the forwarding of this bundle ceases to be contraindicated, processing proceeds from Step 4 of Section 5.4. 🦋 it's giving "wait your turn, we'll pick up again later" energy 💖
5.4.2. Forwarding Failed 🥀
okay this is the aftermath when a node has officially declared forwarding failure. the BPA gets a couple of options, and the vibes are very "closure or cleanup" 🧹
Step 1: The BPA MAY forward the bundle back to the node that sent it, as identified by the Previous Node Block, if present. This forwarding, if performed, SHALL be accomplished by performing Step 4 and Step 5 of Section 5.4 where the sole node selected for forwarding SHALL be the node that sent the bundle. 🔁 so it's like sending the bestie back the note they handed you 🫶
Step 2: If the bundle's destination endpoint is an endpoint of which the node is a member, then the bundle's "Forward pending" retention constraint MUST be removed. Otherwise, the bundle MUST be deleted: the Bundle Deletion procedure defined in Section 5.10 MUST be followed, citing the reason for which forwarding was determined to be contraindicated. 🗑️ bye bye bundle, but make it paperwork 📝
5.5. Bundle Expiration ⏳
okay so bundles don't last forever, bestie. a bundle expires once its age goes past its lifetime, whether that lifetime comes from the primary bundle block or from whatever the BPA decided to override it with ⌛✨
Bundle age MAY be determined by subtracting the bundle's creation timestamp time from the current time if (a) that timestamp time is not zero and (b) the local node's clock is known to be accurate. Otherwise, bundle age MUST be obtained from the Bundle Age extension block. 🕰️ it's all about trusting the clock, periodt 💅
Bundle expiration MAY occur at any point in the processing of a bundle. 🌀 it can literally happen whenever, so stay alert 👀
When a bundle expires, the BPA MUST delete the bundle for the reason "Lifetime expired" (when the expired lifetime is the lifetime as specified in the primary block) or "Traffic pared" (when the expired lifetime is a lifetime override as imposed by the BPA). The Bundle Deletion procedure defined in Section 5.10 MUST be followed. 💀 the reason code really depends on who set the timer, iykyk 🙈
5.6. Bundle Reception 📬
okay this is the welcome-to-the-node routine for a bundle that just came in from another node 🎀 here are the steps:
Step 1: The retention constraint "Dispatch pending" MUST be added to the bundle. 📌 it's basically a sticky note saying "go send this next" 💌
Step 2: If the "request reporting of bundle reception" flag in the bundle's status report request field is set to 1 and status reporting is enabled, then a bundle reception status report with reason code "No additional information" SHOULD be generated, destined for the bundle's report-to endpoint ID. 🧾 the little receipt, obsessed ✨
Step 3: CRCs SHOULD be computed for every block of the bundle that has an attached CRC. If any block of the bundle is malformed according to this specification (including syntactically invalid CBOR), or if any block has an attached CRC and the CRC computed for this block upon reception differs from that attached CRC, then the BPA MUST delete the bundle for the reason "Block unintelligible". The Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped. 🚨 if anything looks sus or corrupted, it's gone, no cap 🧹
Step 4: For each block in the bundle that is an extension block that the BPA cannot process:
- If the block processing control flags in that block indicate that a status report is requested in this event and if status reporting is enabled, then a bundle reception status report with reason code "Block unsupported" SHOULD be generated, destined for the bundle's report-to endpoint ID. 📣
- If the block processing control flags in that block indicate that the bundle must be deleted in this event, then the BPA MUST delete the bundle for the reason "Block unsupported"; the Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped. 💔 the unsupported block is THAT serious
- If the block processing control flags in that block NOT indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the BPA MUST remove this block from the bundle. 🗑️ the block gets yeeted, the bundle lives on
- If the block processing control flags in that block neither indicate that the bundle must be deleted nor indicate that the block must be discarded, then processing continues with the next extension block that the BPA cannot process, if any; otherwise, processing proceeds from Step 5. 🔄 keep it moving, bestie
Step 5: Processing proceeds from Step 1 of Section 5.3. 🦋 back to the dispatching queue we go
5.7. Local Bundle Delivery 🎁
okay so this is the part where the bundle has actually arrived at a destination endpoint this node is a member of. main character moment 👑 here's how it goes:
Step 1: If the received bundle is a fragment, the ADU Reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original ADU, processing of the fragmentary bundle whose payload has been replaced by the reassembled ADU (whether this bundle or a previously received fragment) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" MUST be added to the bundle, and all remaining steps of this procedure MUST be skipped. 🧩 puzzle pieces coming together, so satisfying 🥹
Step 2: Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle:
- An additional implementation-specific delivery deferral procedure MAY optionally be associated with the registration. ⏸️
- If the registration is in the Active state, then the bundle MUST be delivered automatically as soon as it is the next bundle that is due for delivery according to the BPA's bundle delivery scheduling policy (an implementation matter). 📦✨ the scheduling policy is the implementer's business, not ours 🙃
- If the registration is in the Passive state, or if delivery of the bundle fails for some implementation-specific reason, then the registration's delivery failure action MUST be taken. The delivery failure action MUST be one of the following:
- Defer delivery of the bundle subject to this registration until (a) this bundle is the least recently received of all bundles currently deliverable subject to this registration and (b) either the registration is polled or the registration is in the Active state, and also perform any additional delivery deferral procedure associated with the registration, or
- Abandon delivery of the bundle subject to this registration (as defined in Section 3.1). 🫠 it's a lot, but the options are clear
Step 3: As soon as the bundle has been delivered, if the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1 and bundle status reporting is enabled, then a bundle delivery status report SHOULD be generated, destined for the bundle's report-to endpoint ID. Note that this status report only states that the payload has been delivered to the application agent, not that the application agent has processed that payload. 📮 delivered does NOT mean read, sis 💅
5.8. Bundle Fragmentation ✂️
okay so sometimes a BPA wants to shrink a bundle so it can actually get forwarded, and honestly that makes total sense 🧸 for example, if the next node is only reachable through intermittent contacts and none of the upcoming contacts is long enough for the whole bundle, splitting it up is the move 🌸
The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" (new bundles with the same source node ID and creation timestamp as the original bundle) whose payloads MUST be the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M. 🪄 same source, same creation timestamp, just smaller pieces 🍰
Note that fragments are bundles and therefore may themselves be fragmented, so multiple episodes of fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one "level" of fragmentation, as in IP fragmentation.) 🧁 fragments can be fragmented again, but it's not a Russian doll situation, one level only 🪆
Any bundle whose primary block's bundle processing control flags do NOT indicate that it must not be fragmented MAY be fragmented at any time, for any purpose, at the discretion of the BPA. NOTE, however, that some combinations of bundle fragmentation, replication, and routing might result in unexpected traffic patterns. ⚠️ the BPA has the final say, but watch out for chaos 🌪️
Fragmentation SHALL be constrained as follows:
- The concatenation of the payloads of all fragments produced by fragmentation MUST always be identical to the payload of the fragmented bundle (that is, the bundle that is being fragmented). Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the fragmented bundle's payload. 🧩 the pieces always add back up to the original, even if they overlap across the network 💜
- The primary block of each fragment MUST differ from that of the fragmented bundle, in that the bundle processing control flags of the fragment MUST indicate that the bundle is a fragment and both fragment offset and total application data unit length must be provided. Additionally, the CRC of the primary block of the fragmented bundle, if any, MUST be replaced in each fragment by a new CRC computed for the primary block of that fragment. 🏷️ every fragment gets its own fresh label, obsessed with the organization 📋
- The payload blocks of fragments will differ from that of the fragmented bundle as noted above. 🎀
- If the fragmented bundle is not a fragment or is the fragment with offset zero, then all extension blocks of the fragmented bundle MUST be replicated in the fragment whose offset is zero. 🧷 the offset-zero fragment holds the extension blocks, that's the rule 🙌
- Each of the fragmented bundle's extension blocks whose "Block must be replicated in every fragment" flag is set to 1 MUST be replicated in every fragment. 🫧 this flag is basically a "don't leave me out" badge 🥺
- Beyond these rules, rules for the replication of extension blocks in the fragments must be defined in the specifications for those extension block types. 📜 for anything else, check the extension block's own spec, bestie 🌈
5.9. Application Data Unit Reassembly ✨
okay bestie, so Section 5.8 can turn ONE original bundle into an arbitrarily large pile of fragmentary bundles 🧩 but the original bundle's payload has to be stitched back together from those fragments before the destination can actually deliver it 💖
The "material extents" of a received fragment's payload are all the continuous runs of bytes in that payload that don't overlap with the material extents of any previously received fragments with the same source node ID and creation timestamp. If the concatenation (lined up by fragment offsets and payload lengths) of the material extents from this fragment and every previously received fragment with that same source node ID and creation timestamp forms one continuous byte array, and its length equals the total application data unit length noted in the fragment's primary block, then:
- This byte array (the reassembled ADU) MUST replace the payload of whichever fragment has material extents that include the extent at offset zero. This is what enables delivery of the reconstituted original bundle as described in Step 1 of Section 5.7 🎀
- The "Reassembly pending" retention constraint MUST be removed from every other fragment with the same source node ID and creation timestamp as this fragment 🧚
Note: Reassembly of ADUs from fragments happens at the nodes that are members of destination endpoints, as necessary. An ADU MAY also be reassembled at some other node on the path to the destination 🦋
5.10. Bundle Deletion 🗑️
here's how deleting a bundle goes, step by step 💅
Step 1: If the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1, and status reporting is enabled, then a bundle deletion status report citing the reason for deletion SHOULD be generated, destined for the bundle's report-to endpoint ID 📣
Step 2: All of the bundle's retention constraints MUST be removed 🌸
5.11. Discarding a Bundle
as soon as a bundle has no remaining retention constraints, it MAY be discarded, which releases any persistent storage that may have been allocated to it 🫧
5.12. Canceling a Transmission
when someone asks to cancel a specified transmission, and the bundle created when that transmission started hasn't been discarded yet, the BPA MUST delete that bundle for the reason "Transmission canceled" 🙅♀️ For this, the procedure defined in Section 5.10 MUST be followed 💜
6. Administrative Record Processing 📬
6.1. Administrative Records
administrative records are standard ADUs that help provide some of the features of the Bundle Protocol 🎀 The Bundle Protocol administrative record types are registered in the IANA "Bundle Administrative Record Types" registry [RFC5050]. Of those, only administrative record type 1, "Bundle status report", is defined for BPv7 right now. Additional administrative record types may be defined by supplementary DTN protocol specification documents 🌈
Every administrative record has two parts:
- A record type code (an unsigned integer, with valid values as defined below).
- Record content in a type-specific format.
Each BP administrative record SHALL be represented as a CBOR array with two items 🧁
The first item of the array SHALL be a record type code, and it SHALL be represented as a CBOR unsigned integer 🔢
The second element of this array SHALL be the applicable CBOR encoding of the record's content. The details of the CBOR encoding for administrative record type 1 are given below. The details for other administrative record types are included in the specifications that define those records ✨
6.1.1. Bundle Status Reports
"bundle status reports" are an option you can ask for when you request transmission of a bundle, and they're sent under specified conditions 🦋 They give info about how bundles are moving through the system, including notices of receipt, forwarding, final delivery, and deletion. They get sent to the report-to endpoints of bundles 📮
Each bundle status report SHALL be represented as a CBOR array. The number of elements in that array SHALL be either 6 (if the subject bundle is a fragment) or 4 (otherwise) 🌷
The first element of the bundle status report SHALL be bundle status information, represented as a CBOR array of at least four elements. The first four elements of that bundle status information provide information on these four status assertions, in this order:
- Reporting node received bundle.
- Reporting node forwarded the bundle.
- Reporting node delivered the bundle.
- Reporting node deleted the bundle.
Each element of the bundle status information SHALL be a bundle status item, encoded as a CBOR array 🍓
The number of elements in each bundle status item SHALL be either 2 (if the first element of the bundle status item is 1 AND the "Report status time" flag was set to 1 in the bundle processing control flags of the bundle whose status is being reported) or 1 (otherwise) 🙈
The first element of each bundle status item SHALL be a status indicator: a Boolean value saying whether or not the matching bundle status is asserted, encoded as a CBOR Boolean value. If it's present, the second element of each bundle status item SHALL indicate the time at which the status was asserted for this bundle. That time is as reported by the local system clock (this is an implementation matter), and it's represented as a DTN time as described in Section 4.2.6 ⏰
The second element of the bundle status report SHALL be the bundle status report reason code, which explains the value of the status indicator. It's represented as a CBOR unsigned integer. Valid status report reason codes are registered in the IANA "Bundle Status Report Reason Codes" subregistry in the "Bundle Protocol" registry (see Section 9.5). The initial contents of that registry are listed in Table 1. The list of status report reason codes provided here is neither exhaustive nor exclusive, though: supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may define additional reason codes 🔍
+========+============================================+
| Value | Meaning |
+========+============================================+
| 0 | No additional information. |
+--------+--------------------------------------------+
| 1 | Lifetime expired. |
+--------+--------------------------------------------+
| 2 | Forwarded over unidirectional link. |
+--------+--------------------------------------------+
| 3 | Transmission canceled. |
+--------+--------------------------------------------+
| 4 | Depleted storage. |
+--------+--------------------------------------------+
| 5 | Destination endpoint ID unavailable. |
+--------+--------------------------------------------+
| 6 | No known route to destination from here. |
+--------+--------------------------------------------+
| 7 | No timely contact with next node on route. |
+--------+--------------------------------------------+
| 8 | Block unintelligible. |
+--------+--------------------------------------------+
| 9 | Hop limit exceeded. |
+--------+--------------------------------------------+
| 10 | Traffic pared (e.g., status reports). |
+--------+--------------------------------------------+
| 11 | Block unsupported. |
+--------+--------------------------------------------+
| 17-254 | Unassigned |
+--------+--------------------------------------------+
| 255 | Reserved |
+--------+--------------------------------------------+
Table 1: Status Report Reason CodesThe third element of the bundle status report SHALL be the source node ID identifying the source of the bundle whose status is being reported, represented as described in Section 4.2.5.1.1 🧭
The fourth element of the bundle status report SHALL be the creation timestamp of the bundle whose status is being reported, represented as described in Section 4.2.7 🕰️
The fifth element of the bundle status report SHALL be present if and only if the bundle whose status is being reported contained a fragment offset. If it's present, it SHALL be the subject bundle's fragment offset, represented as a CBOR unsigned integer item 🧩
The sixth element of the bundle status report SHALL be present if and only if the bundle whose status is being reported contained a fragment offset. If it's present, it SHALL be the length of the subject bundle's payload, represented as a CBOR unsigned integer item 📏
Note: The forwarding parameters of the bundle whose status is being reported (such as lifetime, applicable security measures, etc.) MAY be reflected in the parameters governing the forwarding of the bundle that carries a status report. But that's an implementation matter, and Bundle Protocol deployment experience to date hasn't been enough to suggest any clear guidance on it 🤷♀️
6.2. Generation of Administrative Records 🛠️
whenever the application agent's administrative element is told by the BPA to generate an administrative record, the following procedure must be followed:
Step 1: The administrative record must be constructed. If the administrative record references a bundle and that referenced bundle is a fragment, the administrative record MUST contain the fragment offset and fragment length 🧩
Step 2: A request for transmission of a bundle whose payload is this administrative record MUST be presented to the BPA 📨
7. Services Required of the Convergence Layer 🌉
7.1. The Convergence Layer
the successful operation of the end-to-end Bundle Protocol depends on the operation of underlying protocols at what's called the "convergence layer" 🦋 These protocols are what get communication done between nodes. A wide variety of protocols can serve this purpose, as long as each CLA gives the BPA a defined minimal set of services. This convergence-layer service specification lists those services 💖
7.2. Summary of Convergence-Layer Services ✨
okay so every CLA is expected to do three things for the BPA, and they're giving main character energy 💅:
- sending a bundle to a bundle node that's reachable through the convergence-layer protocol 📦
- telling the BPA how its data-sending procedures for a bundle turned out, once those procedures wrap up 📣
- handing the BPA a bundle that a bundle node sent over the convergence-layer protocol 🫶
BUT the convergence-layer service interface here is NOT the whole story 🙈 It isn't exhaustive or exclusive, which means other DTN specs can ask CLAs for more. Bundle Protocol Security [BPSEC] is one of them, and CLAs serving BP implementations that follow those specs might also be expected to report on how a bundle's transmission or reception is going (all at once or bit by bit), retransmit data that got lost in transit, throw away bundle-carrying data units that the convergence-layer protocol decides are corrupt or inauthentic, or report on whether delivered bundles are intact and genuine 🔍✨
And here's the lowkey big one 🌈 The Bundle Protocol leans on convergence-layer protocols to keep congestion down in the store-carry-forward overlay network. Delay-tolerant networks have really long round-trip times, which clash with end-to-end, reactive congestion control, so convergence-layer protocols MUST provide rate limiting or congestion control. No exceptions, bestie 💖
8. Security Considerations 🔐
Okay, security time, and I'm going to be dramatic about it because it matters 😭 The Bundle Protocol security architecture and its available security services are laid out in a companion document, the Bundle Protocol Security (BPSec) specification [BPSEC]. Whenever Bundle Protocol security services are required (as opposed to the ones provided by overlying application protocols or underlying convergence-layer protocols), those services SHALL be provided by BPSec, and not by some other mechanism with the same or similar scope. Nobody gets to freelance here 🙅♀️
A Bundle Protocol Agent (BPA) that sources, cryptographically verifies, and/or accepts a bundle MUST implement support for BPSec. However, using BPSec for any single bundle is optional, so you pick your battles per bundle 🎀
The BPSec extensions let every block of a bundle (other than a BPSec extension block) be individually authenticated by a signature block, which is the Block Integrity Block, or BIB. They also let every block of a bundle other than the primary block (and the BPSec extension blocks themselves) be individually encrypted by a Block Confidentiality Block (BCB). Each block gets its own protection, which is so iconic 🔥
Since these security mechanisms are extension blocks that get inserted right into the bundle, the protections they give apply while the bundle is sitting at rest and waiting for the next forwarding opportunity, and not only while it's in transit. Protected at rest AND in transit, periodt ✨
Now the convergence layer 🛤️ Convergence-layer protocols that make sure communication between adjacent nodes in a BP network topology is authentic SHOULD be used wherever they're available, so unauthenticated nodes have a harder time sneaking inauthentic traffic into the network. Convergence-layer protocols that make sure that communication is confidential between adjacent nodes SHOULD also be used where available, which helps keep the primary block and other cleartext blocks from being exposed. That gives you some defense against traffic analysis 🕵️♀️
To get authenticity and/or confidentiality between BP nodes, the convergence-layer protocol needs the name or names of the expected communication peer(s) as input. The CLA has to supply those. How the CLA works out which CL endpoint name(s) to hand over is out of scope for this specification. But here's the tea ☕ When the CL endpoint names are a function of BP endpoint IDs, the correctness and authenticity of that mapping will be vital to the overall security properties the CL provides to the system. Guard that mapping like it's your phone passcode 🔒
Note that the primary block has to stay in the clear for routing purposes. Even so, the Bundle Protocol could be protected against traffic analysis to some extent by using bundle-in-bundle encapsulation [BIBE] to tunnel bundles to a safe forward distribution point. The encapsulated bundle could form the payload of an encapsulating bundle, and that payload block could be encrypted by a BCB. Tunnel-ception, but make it secure 🧚
Bundle status report generation is disabled by default, and for a very good reason 🚨 Malicious initiation of bundle status reporting could result in the transmission of extremely large numbers of bundles, which would be a denial-of-service attack. Imposing bundle lifetime overrides would be one defense against that.
Also, receiving large numbers of fragmentary bundles with very long lifetimes could be a denial-of-service attack too 😱 Storage gets eaten up while bundles sit pending reassembly that will never happen. Again, imposing bundle lifetime overrides would be one defense against this attack.
Last but not least, this protocol uses absolute timestamps for several purposes ⏰ Provisions are included so that nodes without accurate clocks can still keep most of the protocol functionality. Nodes that don't know their clock is inaccurate, though, may behave in unexpected ways, so check your clock, bestie 🙃
9. IANA Considerations 📚
The Bundle Protocol includes fields that need registries managed by IANA, so there's some paperwork involved 💅
9.1. Bundle Block Types 🧩
The "Bundle Block Types" subregistry in the "Bundle Protocol" registry got a new column that identifies the version of the Bundle Protocol (Bundle Protocol Version) that applies to each value. IANA added the following values, as described in Section 4.3.1, to the "Bundle Block Types" registry with a value of "7" for the Bundle Protocol Version. IANA also set the Bundle Protocol Version to "6" or "6,7" for the preexisting values in the "Bundle Block Types" registry, as shown below 📋
+=================+=========+=========================+===========+
| Bundle Protocol | Value | Description | Reference |
| Version | | | |
+=================+=========+=========================+===========+
| none | 0 | Reserved | [RFC6255] |
+-----------------+---------+-------------------------+-----------+
| 6,7 | 1 | Bundle Payload Block | [RFC5050] |
| | | | [RFC9171] |
+-----------------+---------+-------------------------+-----------+
| 6 | 2 | Bundle Authentication | [RFC6257] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 6 | 3 | Payload Integrity Block | [RFC6257] |
+-----------------+---------+-------------------------+-----------+
| 6 | 4 | Payload Confidentiality | [RFC6257] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 6 | 5 | Previous-Hop Insertion | [RFC6259] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 7 | 6 | Previous node | [RFC9171] |
| | | (proximate sender) | |
+-----------------+---------+-------------------------+-----------+
| 7 | 7 | Bundle age (in | [RFC9171] |
| | | milliseconds) | |
+-----------------+---------+-------------------------+-----------+
| 6 | 8 | Metadata Extension | [RFC6258] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 6 | 9 | Extension Security | [RFC6257] |
| | | Block | |
+-----------------+---------+-------------------------+-----------+
| 7 | 10 | Hop count (#prior xmit | [RFC9171] |
| | | attempts) | |
+-----------------+---------+-------------------------+-----------+
| 7 | 11-191 | Unassigned | |
+-----------------+---------+-------------------------+-----------+
| 6,7 | 192-255 | Reserved for Private | [RFC5050] |
| | | and/or Experimental Use | [RFC9171] |
+-----------------+---------+-------------------------+-----------+
Table 2: "Bundle Block Types" Registry9.2. Primary Bundle Protocol Version 🔢
IANA added the following value to the "Primary Bundle Protocol Version" subregistry in the "Bundle Protocol" registry ✨
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 7 | Assigned | [RFC9171] |
+-------+-------------+-----------+
Table 3: "Primary Bundle
Protocol Version" RegistryValues 8-255 (rather than 7-255) are now Unassigned 🫧
9.3. Bundle Processing Control Flags 🎀
okay so the "Bundle Processing Control Flags" subregistry in the "Bundle Protocol" registry got a glow-up 💖. It now has a new column that tells you which version of the Bundle Protocol (Bundle Protocol Version) each value applies to. IANA added the values from Section 4.2.3 to the "Bundle Processing Control Flags" registry with a Bundle Protocol Version of "7" ✨. For the preexisting values, IANA set the Bundle Protocol Version to "6" or "6,7", as shown below 💅.
+=================+=================+===================+===========+
| Bundle Protocol | Bit Position | Description | Reference |
| Version | (right to | | |
| | left) | | |
+=================+=================+===================+===========+
| 6,7 | 0 | Bundle is a | [RFC5050] |
| | | fragment | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 1 | ADU is an | [RFC5050] |
| | | administrative | [RFC9171] |
| | | record | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 2 | Bundle must not | [RFC5050] |
| | | be fragmented | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| 6 | 3 | Custody transfer | [RFC5050] |
| | | is requested | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 4 | Destination | [RFC5050] |
| | | endpoint is a | |
| | | singleton | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 5 | Acknowledgement | [RFC5050] |
| | | by application is | [RFC9171] |
| | | requested | |
+-----------------+-----------------+-------------------+-----------+
| 7 | 6 | Status time | [RFC9171] |
| | | requested in | |
| | | reports | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 7-8 | Class of service: | [RFC5050] |
| | | priority | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 9-13 | Class of service: | [RFC5050] |
| | | reserved | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 14 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | reception | |
+-----------------+-----------------+-------------------+-----------+
| 6 | 15 | Request reporting | [RFC5050] |
| | | of custody | |
| | | acceptance | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 16 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | forwarding | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 17 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | delivery | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 18 | Request reporting | [RFC5050] |
| | | of bundle | [RFC9171] |
| | | deletion | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 19 | Reserved | [RFC5050] |
| | | | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 20 | Reserved | [RFC5050] |
| | | | [RFC9171] |
+-----------------+-----------------+-------------------+-----------+
| | 21-63 | Unassigned | |
+-----------------+-----------------+-------------------+-----------+
Table 4: "Bundle Processing Control Flags" Registry9.4. Block Processing Control Flags 🌸
the "Block Processing Control Flags" subregistry in the "Bundle Protocol" registry got the same new column, so you can see which version of the Bundle Protocol (Bundle Protocol Version) applies to the related BP version 🦋. IANA set the Bundle Protocol Version to "6" or "6,7" for preexisting values in the "Bundle Processing Control Flags" registry, as shown below 🍓.
+=================+==============+====================+===========+
| Bundle Protocol | Bit Position | Description | Reference |
| Version | (right to | | |
| | left) | | |
+=================+==============+====================+===========+
| 6,7 | 0 | Block must be | [RFC5050] |
| | | replicated in | [RFC9171] |
| | | every fragment | |
+-----------------+--------------+--------------------+-----------+
| 6,7 | 1 | Transmit status | [RFC5050] |
| | | report if block | [RFC9171] |
| | | can't be processed | |
+-----------------+--------------+--------------------+-----------+
| 6,7 | 2 | Delete bundle if | [RFC5050] |
| | | block can't be | [RFC9171] |
| | | processed | |
+-----------------+--------------+--------------------+-----------+
| 6 | 3 | Last block | [RFC5050] |
+-----------------+--------------+--------------------+-----------+
| 6,7 | 4 | Discard block if | [RFC5050] |
| | | it can't be | [RFC9171] |
| | | processed | |
+-----------------+--------------+--------------------+-----------+
| 6 | 5 | Block was | [RFC5050] |
| | | forwarded without | |
| | | being processed | |
+-----------------+--------------+--------------------+-----------+
| 6 | 6 | Block contains an | [RFC5050] |
| | | EID-reference | |
| | | field | |
+-----------------+--------------+--------------------+-----------+
| | 7-63 | Unassigned | |
+-----------------+--------------+--------------------+-----------+
Table 5: "Block Processing Control Flags" Registry9.5. Bundle Status Report Reason Codes 💜
the "Bundle Status Report Reason Codes" subregistry in the "Bundle Protocol" registry also got the new Bundle Protocol Version column 🧚. IANA added the following values, as described in Section 6.1.1, to the "Bundle Status Report Reason Codes" registry with a Bundle Protocol Version of "7" 🌈. For the preexisting values, IANA set the Bundle Protocol Version to "6,7", as shown below 🫶.
+=================+========+========================+===========+
| Bundle Protocol | Value | Description | Reference |
| Version | | | |
+=================+========+========================+===========+
| 6,7 | 0 | No additional | [RFC5050] |
| | | information | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 1 | Lifetime expired | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 2 | Forwarded over | [RFC5050] |
| | | unidirectional link | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 3 | Transmission canceled | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 4 | Depleted storage | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 5 | Destination endpoint | [RFC5050] |
| | | ID unavailable | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 6 | No known route to | [RFC5050] |
| | | destination from here | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 7 | No timely contact with | [RFC5050] |
| | | next node on route | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 6,7 | 8 | Block unintelligible | [RFC5050] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 7 | 9 | Hop limit exceeded | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 7 | 10 | Traffic pared | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| 7 | 11 | Block unsupported | [RFC9171] |
+-----------------+--------+------------------------+-----------+
| | 17-254 | Unassigned | |
+-----------------+--------+------------------------+-----------+
| 6,7 | 255 | Reserved | [RFC6255] |
| | | | [RFC9171] |
+-----------------+--------+------------------------+-----------+
Table 6: "Bundle Status Report Reason Codes" Registry9.6. Bundle Protocol URI Scheme Types ✨
okay so the Bundle Protocol has a URI scheme type field 🦋 and it's an unsigned integer of indefinite length. IANA has created a brand new "Bundle Protocol URI Scheme Types" subregistry inside the "Bundle Protocol" registry, and IANA will keep maintaining it 💅. This registry governs a namespace of unsigned integers, and the starting values are listed below 🌸.
The registration policy is Standards Action [RFC8126]. An allocation should only be granted for a Standards Track RFC approved by the IESG 📜. The range of values is provided as unsigned integers 🔢.
Every assignment has a few parts: a URI scheme type name and its description, a reference to the document that defines the URI scheme, and a reference to the document that defines how that scheme gets used in BP endpoint IDs (including how those endpoint IDs are CBOR-encoded in transmitted bundles) 🎀.
+===========+==============+================+================+
| Value | Description | BP Utilization | URI Definition |
| | | Reference | Reference |
+===========+==============+================+================+
| 0 | Reserved | n/a | |
+-----------+--------------+----------------+----------------+
| 1 | dtn | [RFC9171] | [RFC9171] |
+-----------+--------------+----------------+----------------+
| 2 | ipn | [RFC9171] | [RFC6260] |
| | | | [RFC9171] |
+-----------+--------------+----------------+----------------+
| 3-254 | Unassigned | n/a | |
+-----------+--------------+----------------+----------------+
| 255-65535 | Reserved | n/a | |
+-----------+--------------+----------------+----------------+
| >65535 | Reserved for | n/a | |
| | Private Use | | |
+-----------+--------------+----------------+----------------+
Table 7: "Bundle Protocol URI Scheme Types" Registry9.7. dtn URI Scheme 🌈
okay this one's a bestie moment 🫶. IANA has updated the registration of the "dtn" URI scheme in the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) registry, and here's how it reads:
URI scheme name: "dtn"
Status: Permanent
Applications and/or protocols that use this URI scheme name: The
Delay-Tolerant Networking (DTN) Bundle Protocol (BP).
Contact: Scott Burleigh <sburleig.sb@gmail.com>
Change controller: IETF (iesg@ietf.org)
Reference: [RFC9171]9.8. ipn URI Scheme 🧚
same energy here 💖. IANA has updated the registration of the "ipn" URI scheme in the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) registry. This scheme was originally documented in RFC 6260 [RFC6260], and the updated entry looks like this:
URI scheme name: "ipn"
Status: Permanent
Applications and/or protocols that use this URI scheme name: The
Delay-Tolerant Networking (DTN) Bundle Protocol (BP).
Contact: Scott Burleigh <sburleig.sb@gmail.com>
Change controller: IETF (iesg@ietf.org)
Reference: [RFC9171]10. References 📚
10.1. Normative References 🔥
- [BPSEC] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022,
<https://www.rfc-editor.org/info/rfc9172>. - [CRC16] ITU-T, "X.25: Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", p. 9, Section 2.2.7.4, ITU-T Recommendation X.25, October 1996,
<https://www.itu.int/rec/T-REC-X.25-199610-I/>. - [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/info/rfc2119>. - [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. - [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/info/rfc8174>. - [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. - [SABR] Consultative Committee for Space Data Systems, "Schedule-Aware Bundle Routing", CCSDS Recommended Standard 734.3-B-1, July 2019,
<https://public.ccsds.org/Pubs/734x3b1.pdf>. - [TCPCL] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>. - [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. - [URIREG] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
10.2. Informative References 💜
- [ARCH] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007,
<https://www.rfc-editor.org/info/rfc4838>. - [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 February 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bibect-03>. - [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005,
<https://www.rfc-editor.org/info/rfc3987>. - [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007,
<https://www.rfc-editor.org/info/rfc5050>. - [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May 2011,
<https://www.rfc-editor.org/info/rfc6255>. - [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>. - [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, DOI 10.17487/RFC6258, May 2011,
<https://www.rfc-editor.org/info/rfc6258>. - [RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop Insertion Block", RFC 6259, DOI 10.17487/RFC6259, May 2011,
<https://www.rfc-editor.org/info/rfc6259>. - [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/info/rfc6260>. - [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014,
<https://www.rfc-editor.org/info/rfc7143>. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. - [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003, DOI 10.1145/863955.863960, August 2003,
<https://dl.acm.org/doi/10.1145/863955.863960>.
Appendix A. Significant Changes from RFC 5050 🦋
this doc makes these big glow-up changes from RFC 5050 💅 (lowkey the whole list is iconic):
- Clarifies the difference between transmission and forwarding.
- Migrates custody transfer to the bundle-in-bundle encapsulation specification [BIBE].
- Introduces the concept of "node ID" as functionally distinct from endpoint ID, while having the same syntax.
- Restructures primary block, making it immutable. Adds optional CRC.
- Adds optional CRCs to non-primary blocks.
- Adds block ID number to canonical block format (to support BPSec).
- Adds definition of Bundle Age extension block.
- Adds definition of Previous Node extension block.
- Adds definition of Hop Count extension block.
- Removes Quality of Service markings.
- Changes from Self-Delimiting Numeric Values (SDNVs) to CBOR encoding.
- Adds lifetime overrides.
- Clarifies that time values are denominated in milliseconds, not seconds ⏱️✨
Appendix B. CDDL Expression ✨
okay bestie, this is the bonus section and it's literally a gift 🎁 Carsten Bormann and Brian Sipos wrote a CDDL version of the whole Bundle Protocol spec, just for info purposes. Here's the big rule to remember: if the CDDL and the text earlier in the doc ever disagree, the text wins 💅 The CDDL is basically a cheat sheet, not the boss.
bpv7_start = bundle / #6.55799(bundle)
; Times before 2000 are invalid
dtn-time = uint
; CRC enumerated type
crc-type = &(
crc-none: 0,
crc-16bit: 1,
crc-32bit: 2
)
; Either 16-bit or 32-bit
crc-value = (bstr .size 2) / (bstr .size 4)
creation-timestamp = [
dtn-time, ; absolute time of creation
sequence: uint ; sequence within the time
]
eid = $eid .within eid-structure
eid-structure = [
uri-code: uint,
SSP: any
]
$eid /= [
uri-code: 1,
SSP: (tstr / 0)
]
$eid /= [
uri-code: 2,
SSP: [
nodenum: uint,
servicenum: uint
]
]
; The root bundle array
bundle = [primary-block, *extension-block, payload-block]
primary-block = [
version: 7,
bundle-control-flags,
crc-type,
destination: eid,
source-node: eid,
report-to: eid,
creation-timestamp,
lifetime: uint,
? (
fragment-offset: uint,
total-application-data-length: uint
),
? crc-value,
]
bundle-control-flags = uint .bits bundleflagbits
bundleflagbits = &(
reserved: 20,
reserved: 19,
bundle-deletion-status-reports-are-requested: 18,
bundle-delivery-status-reports-are-requested: 17,
bundle-forwarding-status-reports-are-requested: 16,
reserved: 15,
bundle-reception-status-reports-are-requested: 14,
reserved: 13,
reserved: 12,
reserved: 11,
reserved: 10,
reserved: 9,
reserved: 8,
reserved: 7,
status-time-is-requested-in-all-status-reports: 6,
user-application-acknowledgement-is-requested: 5,
reserved: 4,
reserved: 3,
bundle-must-not-be-fragmented: 2,
payload-is-an-administrative-record: 1,
bundle-is-a-fragment: 0
)
; Abstract shared structure of all non-primary blocks
canonical-block-structure = [
block-type-code: uint,
block-number: uint,
block-control-flags,
crc-type,
; Each block type defines the content within the byte string
block-type-specific-data,
? crc-value
]
block-control-flags = uint .bits blockflagbits
blockflagbits = &(
reserved: 7,
reserved: 6,
reserved: 5,
block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4,
reserved: 3,
bundle-must-be-deleted-if-block-cannot-be-processed: 2,
status-report-must-be-transmitted-if-block-cannot-be-processed: 1,
block-must-be-replicated-in-every-fragment: 0
)
block-type-specific-data = bstr / #6.24(bstr)
; Actual CBOR data embedded in a byte string, with optional tag to indicate so.
; Additional plain bstr allows ciphertext data.
embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) / bstr
; Extension block type, which does not specialize other than the code/number
extension-block = $extension-block .within canonical-block-structure
; Generic shared structure of all non-primary blocks
extension-block-use<CodeValue, BlockData> = [
block-type-code: CodeValue,
block-number: (uint .gt 1),
block-control-flags,
crc-type,
BlockData,
? crc-value
]
; Payload block type
payload-block = payload-block-structure .within canonical-block-structure
payload-block-structure = [
block-type-code: 1,
block-number: 1,
block-control-flags,
crc-type,
$payload-block-data,
? crc-value
]
; Arbitrary payload data, including non-CBOR byte string
$payload-block-data /= block-type-specific-data
; Administrative record as a payload data specialization
$payload-block-data /= embedded-cbor<admin-record>
admin-record = $admin-record .within admin-record-structure
admin-record-structure = [
record-type-code: uint,
record-content: any
]
; Only one defined record type
$admin-record /= [1, status-record-content]
status-record-content = [
bundle-status-information,
status-report-reason-code: uint,
source-node-eid: eid,
subject-creation-timestamp: creation-timestamp,
? (
subject-payload-offset: uint,
subject-payload-length: uint
)
]
bundle-status-information = [
reporting-node-received-bundle: status-info-content,
reporting-node-forwarded-bundle: status-info-content,
reporting-node-delivered-bundle: status-info-content,
reporting-node-deleted-bundle: status-info-content
]
status-info-content = [
status-indicator: bool,
? timestamp: dtn-time
]
; Previous Node extension block
$extension-block /= extension-block-use<6, embedded-cbor<ext-data-previous-node>>
ext-data-previous-node = eid
; Bundle Age extension block
$extension-block /= extension-block-use<7, embedded-cbor<ext-data-bundle-age>>
ext-data-bundle-age = uint
; Hop Count extension block
$extension-block /= extension-block-use<10, embedded-cbor<ext-data-hop-count>>
ext-data-hop-count = [
hop-limit: uint,
hop-count: uint
]Acknowledgments 🫶
this work is freely adapted from RFC 5050, which was an effort of the Delay-Tolerant Networking Research Group 🌈 a bunch of DTNRG people put in serious technical material and input, and they deserve all the flowers: Dr. Vinton Cerf of Google; Scott Burleigh, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory; Michael Demmer of the University of California at Berkeley; Robert Durst, Keith Scott, and Susan Symington of The MITRE Corporation; Kevin Fall of Carnegie Mellon University; Stephen Farrell of Trinity College Dublin; Howard Weiss and Peter Lovell of SPARTA, Inc.; and Manikantan Ramadas of Ohio University 👑
Scott Burleigh would like to thank the Jet Propulsion Laboratory, California Institute of Technology, for its generous and sustained support of this work 💜
Authors' Addresses 🦋
Scott Burleigh 🌸
IPNGROUP
1435 Woodhurst Blvd.
McLean, VA 22102
United States of America
Email: sburleig.sb@gmail.comKevin Fall 🌸
Roland Computing Services
3871 Piedmont Ave. Suite 8
Oakland, CA 94611
United States of America
Email: kfall+rcs@kfall.comEdward J. Birrane, III 🌸
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd
Laurel, MD 20723
United States of America
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu📦 where this page comes from
- ietf: rfc9171 2022-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms