Delay-Tolerant Networking Working Group Scott Burleigh Internet Draft IPNSIG Inc. Intended status: Standards Track October 10, 2026 Expires: April 13, 2027 Bundle Multicast draft-burleigh-dtn-multicast-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 13, 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Burleigh Expires April 2027 [Page 1] Internet-Draft Bundle Multicast 2026 Abstract This document describes Bundle Multicast, a protocol that reduces network resource consumption in the forwarding of copies of a given Bundle Protocol (BP) data unit - a "bundle" - to all BP nodes that are members of a BP endpoint whose ID is formed in the "imc" URI scheme, here termed a BP "multicast group". Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. IMC Design Elements............................................3 3.1. IMC Endpoints.............................................3 3.2. Destination Sets..........................................6 3.3. The IMC Extension Block...................................7 4. IMC Procedures.................................................7 4.1. IMC source procedure......................................7 4.2. IMC delegate procedure....................................8 4.3. IMC delegation procedure..................................8 4.4. IMC batching procedure....................................9 5. Security Considerations........................................9 6. IANA Considerations............................................9 7. References....................................................10 7.1. Normative References.....................................10 7.2. Informative References...................................10 8. Acknowledgments...............................................10 Appendix A. Multicast Group Membership Announcement..............11 1. Introduction This document describes Bundle Multicast (IMC), a protocol designed to reduce network resource consumption in the forwarding of a given Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC9171] protocol data unit - "bundle" - to multiple destinations. The operation of the protocol rests on three innovations: . A new BP endpoint identification scheme (that is, URI scheme) named "imc", for "interplanetary multicast". Endpoints identified by imc-scheme endpoint IDs are never singleton endpoints; each such endpoint may have zero or more members. These endpoints are termed "bundle multicast groups" (or, for the purposes of this document, simply "multicast groups"). A BP node "joins" a multicast group by registering in the endpoint identified by that group's imc-scheme endpoint ID; a Burleigh Expires April 2027 [Page 2] Internet-Draft Bundle Multicast 2026 node that is a member of a multicast group leaves it by unregistering in that endpoint. . A new type of BP extension block, the "imc" extension block, which conveys the identities of some subset of the nodes that are members of the multicast group identified by the extended bundle's destination endpoint ID. . Definition of the procedures by which a bundle protocol agent selects the node(s) to which copies of a bundle destined for a multicast group are to be forwarded. The intent of IMC is to reduce network resource consumption by clustering destination nodes, so that the forwarding of bundles to multiple nodes is largely delegated to "downstream" bundle protocol agents. That is, for a given source multicast bundle destined for a multicast group containing N nodes, bundle traffic between any forwarding node and any one of its topological neighbors may be reduced from as many as N bundles to just 1 bundle. Conformance to the bundle multicast specification is OPTIONAL for BP nodes. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. IMC Design Elements 3.1. IMC Endpoints IMC endpoints - that is, bundle multicast groups - are identified by URIs formed in the "imc" scheme. This scheme is specified as follows: 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. imc-uri = "imc:" imc-hier-part Burleigh Expires April 2027 [Page 3] Internet-Draft Bundle Multicast 2026 imc-hier-part = group-label "." service-number group-label = "!" / group-id group-id = brief-group-id / fqgn ; "fqgn" is "fully-qualified group number" brief-group-id = allocator-identifier "." group-number allocator-identifier = number group-number = number fqgn = number service-number = number number = "0" / non-zero-number non-zero-number = (%x31-39 *DIGIT) DIGIT = %x30-39 Scheme semantics: URIs of the imc scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in [RFC9171]. No BP endpoints identified by imc-scheme endpoint IDs are singleton endpoints. Encoding considerations: For transmission as a BP endpoint ID, the scheme-specific part of a URI of the imc scheme SHALL be represented as a CBOR array comprising either two or three items. If the number of items in the array is 3, the first element of the array SHALL be an encoding of the Allocator Identifier associated with the imc EID, the second element of the array SHALL be an encoding of the Group Number associated with the imc EID, and the third element of the array SHALL be the imc EID Service Number. If the number of items in the array is 2, the first element of the array SHALL be an encoding of the imc EID FQGN and the second element of the array SHALL be the imc EID Service Number. In this Burleigh Expires April 2027 [Page 4] Internet-Draft Bundle Multicast 2026 instance, the encoded FQGN MUST be a 64-bit unsigned integer constructed in the following way: . The least significant 32 bits MUST represent the Group Number associated with the imc EID. . The most significant 32 bits MUST represent the Allocator Identifier associated with the imc EID. For all other purposes, URIs of the imc scheme are encoded exclusively in USASCII characters. Interoperability considerations: None. Security considerations: Reliability and consistency: None of the BP endpoints identified by the URIs of the imc scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by Bundle Protocol Security, is required for this purpose. Malicious construction: Malicious construction of a conformant imc-scheme URI is limited to the malicious selection of group and allocator numbers and the malicious selection of service numbers. That is, a maliciously constructed imc-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed 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 URIs of the imc scheme effectively eliminates the possibility of threat due to errors in back-end transcoding. Rare IP address formats: Not relevant, as IP addresses do not appear anywhere in conformant imc-scheme URIs. Burleigh Expires April 2027 [Page 5] Internet-Draft Bundle Multicast 2026 Sensitive information: Because imc-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of imc-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by bundle-in-bundle encapsulation or by secure convergence-layer protocols that do not expose endpoint IDs. Semantic attacks: The simplicity of imc-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user. 3.2. Destination Sets The objective of IMC is to cause one copy of a given bundle that is destined for a multicast group to be forwarded to every member of that group. Clearly the bundle's source node could forward copies of the bundle to all group members individually. But this could cause multiple identical copies to be forwarded between the same pair of topologically adjacent network nodes en route to the final destination nodes, unnecessarily exhausting transmission opportunities. For the purposes of this specification, we define the "topological neighbors" of a given BP node as all nodes to which that node is able to send bundles directly by invoking the services of convergence-layer adapters. As such, the first node on the best route from that node to any other node in the network is necessarily one of that node's topological neighbors. The basic concept of IMC is to condense transmission, delegating forwarding responsibility wherever possible. That is, IMC is realized by forwarding between any pair of topologically neighboring nodes normally only a single copy of any multicast bundle, together with a list of all member nodes to which the receiver of the bundle is in turn responsible for forwarding copies in the same manner. Such a list of member nodes is termed a "destination set". At the source node of a multicast bundle, the destination set is the entire destination multicast group. The source node uses the known unicast routes to all members of the group as the basis for segregating the Burleigh Expires April 2027 [Page 6] Internet-Draft Bundle Multicast 2026 group members into smaller disjoint destination sets, as described later, and forwards copies of the bundle - together with the applicable destination sets - to the source node's topological neighbors. Those neighboring nodes, upon receiving the bundle, do the same. 3.3. The IMC Extension Block The IMC Block, block type number TBD, serves to convey destination set information to the node receiving the extended bundle. The IMC Block SHALL contain a single CBOR definite-length array. Each element of that array SHALL be a CBOR definite-length array identifying one member of the multicast group identified by the extended bundle's destination EID. Each node-identifying array shall comprise two CBOR unsigned integers that uniquely identify the multicast group member node in ipn-scheme fashion: allocator number and node number as defined in [RFC9758]. 4. IMC Procedures 4.1. IMC source procedure The source node of a multicast bundle SHALL forward the bundle as follows: . If the bundle's destination multicast group is known to have no members, forwarding of the bundle is deemed to have succeeded. NOTE that the means by which the source node knows the membership of a multicast group is an implementation matter; a proposed mechanism is described in Appendix A. . Otherwise: . If the source node is itself a member of the destination multicast group, the multicast bundle SHALL be delivered. . If the source node is the sole member of the destination multicast group, forwarding of the bundle is deemed to have succeeded. . Otherwise, the source node SHALL send at least one copy of the bundle to every "delegate node" identified by applying the IMC delegation procedure (see 4.3 below) to the destination set that comprises all members of the multicast group except the source node itself. The number and nature of the copies sent to a given delegate node SHALL be determined by applying the IMC batching procedure (see 4.4 Burleigh Expires April 2027 [Page 7] Internet-Draft Bundle Multicast 2026 below) to the consignment computed for that delegate. Every bundle copy sent to a delegate SHALL contain an IMC extension block listing all nodes in one "batch" of the nodes in the consignment that was computed for that delegate. 4.2. IMC delegate procedure Each node that receives a multicast bundle - that is, each IMC delegate node - SHALL forward the bundle as follows: . If the delegate node is itself a member of the destination set in the bundle's IMC extension block, the multicast bundle SHALL be delivered. . If the delegate node is the sole member of the destination set in the bundle's IMC extension block, forwarding of the bundle is deemed to have succeeded. . Otherwise, the delegate node SHALL send at least one copy of the bundle to every delegate node identified by applying the IMC delegation procedure (see 4.3 below) to the destination set that comprises all members of the destination set in the bundle's IMC extension block except the delegate node itself. Again the number and nature of the copies sent to a given delegate node SHALL be determined by applying the IMC batching procedure (see 4.4 below) to the consignment computed for that delegate. Every bundle copy sent to a delegate SHALL contain an IMC extension block listing all nodes in one batch of the nodes in the consignment that was computed for that delegate. 4.3. IMC delegation procedure For each member of the destination set: . If and only if at least one route to that node can be identified: o The first node on the best such route (a topological neighbor) is identified as a delegate node. o This destination set member is appended to the "consignment" of destination nodes assigned to that delegate node. NOTE that the identification of a route to a given member of the destination set and the determination of the "best" such route are both beyond the scope of this specification. Extensive research and development in DTN route computation has been documented and implemented; managed mandates ("static routes"), schedule-aware bundle routing, opportunistic forwarding algorithms, and a variety Burleigh Expires April 2027 [Page 8] Internet-Draft Bundle Multicast 2026 of other approaches are wholly consonant with IMC forwarding procedures. 4.4. IMC batching procedure Attaching an IMC extension block to a bundle increases the bundle's length. In some environments and/or for multicast groups whose membership is very large, encoding in a bundle's IMC extension block the entire consignment computed for a given delegate node may render the extended bundle unacceptably lengthy. An implementation of IMC MAY divide a delegate node's computed consignment into multiple disjoint batches, each comprising some subset of the destination set nodes in the consignment, and send to the delegate node one bundle copy per batch. The manner in which consignment batching is performed, if at all, is an implementation matter. By default, only a single bundle copy listing all nodes in the consignment - the default batch - is sent to each delegate node. 5. Security Considerations Removal or modification of a bundle's IMC extension block could cause the failure of multicast bundle delivery to multicast group members or the delivery of multicast bundles to adversary nodes. The integrity of an IMC extension block should be protected by a BPSec Block Integrity Block targeting both the IMC block and the Previous Node block. The forwarding of IMC bundles by a delegate node under the control of an adversary could have similar effects. The threat and the possible mitigations are similar to those for other attacks on the forwarding fabric of the network. Bundle-in-bundle encapsulation of multicast bundles while in transit across untrusted network segments may be the best defense. As noted earlier, in defense against traffic analysis it would be prudent to convey multicast bundles by bundle-in-bundle encapsulation or by secure convergence-layer protocols that do not expose endpoint IDs. 6. IANA Considerations The IMC specification requires IANA registration of the new "imc" URI scheme defined above. Burleigh Expires April 2027 [Page 9] Internet-Draft Bundle Multicast 2026 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC9171] Burleigh, S., Fall, K., and Birrane, E., "Bundle Protocol Version 7", RFC 9171, January 2022. [RFC9758] Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025. 7.2. Informative References None. 8. Acknowledgments The multicast protocol specification presented here is deeply indebted to research performed by Oliver de Jonckere and, earlier, Marc Sanchez Net and Marius Feldmann. That research in turn was inspired in part by the "xcast" ideas presented in 2007 by R. Boivie, N. Feldman, Y. Imai, W. Livens, and D. Ooms. Early concepts for bundle multicast date back at least to Internet Drafts authored by Susan Symington, Bob Durst, and Keith Scott in 2006 and 2009. While the procedures discussed here differ from those concepts, their influence is gratefully acknowledged. This document was prepared using 2-Word-v2.0.template.dot. Burleigh Expires April 2027 [Page 10] Internet-Draft Bundle Multicast 2026 Appendix A. Multicast Group Membership Announcement Because joining and leaving an IMC multicast group is merely a matter of registering and unregistering in an endpoint (one that is identified by an imc-scheme URI), as fully characterized in [RFC9171], all BP implementations already have means of detecting a node's own changes in multicast group membership. What is lacking is a mechanism for communicating those changes to all other nodes in the network. One possible mechanism would be to "bootstrap" multicast group membership by declaring an implicit, pre-existing, universally recognized multicast group - for example, a group named "imc:0.0" - of which all IMC-capable nodes in the network are automatically members. Given such a pre-existing multicast group, changes in the membership of any other group can be encoded in messages that are simply multicast to "imc:0.0". This mechanism has been implemented and used successfully in the Interplanetary Overlay Network implementation of BPv7, but it is not yet a standard. Authors' Address Scott Burleigh IPNSIG Inc. 8649 Via Alta Way Elk Grove, CA 95624-2541 US Email: sburleig.sb@gmail.com Burleigh Expires April 2027 [Page 11]