]> Aalyria Technologies

rtaylor@aalyria.com

Internet Delay/Disruption Tolerant Networking DTN Bundle Protocol BPv7 multicast URI scheme This document defines the 'imc' URI scheme, a concise integer-based scheme for identifying Bundle Protocol Version 7 (BPv7) endpoints that are not singleton endpoints, termed multicast endpoints. The structure of 'imc' URIs mirrors that of the 'ipn' URI scheme: each 'imc' URI comprises an Allocator Identifier, a Group Number, and a Service Number. This document specifies the textual syntax of 'imc' URIs, their interpretation when used as BPv7 Endpoint Identifiers, their CBOR encoding, and the corresponding EID Pattern, and requests the associated IANA registrations. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Bundle Protocol Version 7 (BPv7) identifies the destination of every bundle by an Endpoint Identifier (EID), which is a URI. A bundle endpoint is a set of zero or more bundle nodes, the members of which are determined by their registrations in it. Although BPv7 permits endpoints with any number of members, the 'ipn' URI scheme , the scheme most commonly used in deployed BPv7 networks, only identifies singleton endpoints. There is no equivalently concise scheme for identifying endpoints that may have many members. This document defines the 'imc' URI scheme for this purpose. An 'imc' URI identifies an endpoint that is never a singleton endpoint; such an endpoint is termed a "multicast endpoint". The name 'imc' is derived from "InterPlanetary MultiCast", in the same way that 'ipn' was derived from "InterPlanetary Network", but like 'ipn' the term is now used as a non-acronymous name. The structure of an imc URI mirrors that of an 'ipn' URI, with a Group Number in place of the 'ipn' Node Number. However, whereas a Node Number identifies a node, a Group Number identifies neither a node nor a set of nodes. As throughout BPv7, it is endpoints that are addressed, and nodes are members of endpoints: each imc URI identifies a single multicast endpoint, with its own membership, and the Group Number names a group of related multicast endpoints. The 'imc' scheme was first proposed in for use with Compressed Bundle Header Encoding and the experimental Bundle Protocol version 6, and was subsequently specified for BPv7 as part of the Bundle Multicast protocol . This document separates the definition of the 'imc' scheme from that protocol, so that the scheme can be standardized independently of any particular multicast forwarding mechanism, and aligns its structure, terminology, and encodings with the 'ipn' URI scheme as updated by . Like the 'ipn' URI scheme, the 'imc' URI scheme defines identifiers only. An 'imc' URI does not carry any topological information describing how to route bundles to the members of the identified multicast endpoint. The procedures by which bundles destined for multicast endpoints are forwarded, and by which information about membership is distributed, are out of scope for this document; one such set of procedures is defined in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. For the remainder of this document, the term "imc URI" is used to refer to a URI that uses the 'imc' URI scheme, and the term "imc EID" is used to refer to an imc URI that is used as a BPv7 EID. The term "multicast endpoint" refers to the BPv7 endpoint identified by an imc EID. The members of a multicast endpoint are the bundle nodes that have a registration () in that imc EID (); a multicast endpoint is therefore never a singleton endpoint (). The term "group" refers to the set of all multicast endpoints whose imc EIDs share the same Allocator Identifier and Group Number, differing only in their Service Numbers (). A group has no members of its own. The terms "Allocator", "Allocator Identifier", "Default Allocator", "Node Number", and "Service Number" are used as defined in .

Core Concepts Every imc URI, no matter whether it is expressed with a textual representation or a binary encoding, MUST be considered as a tuple of the following three components:

• The Allocator Identifier
• The Group Number
• The Service Number

The Allocator Identifier indicates the entity responsible for assigning Group Numbers, maintaining uniqueness whilst avoiding the need for a single registry for all assigned Group Numbers. See . The Group Number names a group of multicast endpoints in the context of an Allocator. See . The Service Number distinguishes between the multicast endpoints of a group. See . The combination of all three components identifies a single multicast endpoint. The combination of the Allocator Identifier and the Group Number uniquely identifies a group. See . Membership is a property of each multicast endpoint, not of a group: the multicast endpoints of a group can have entirely different members. See .

Allocator Identifiers The Allocator Identifier of an imc URI has the same structure, purpose, and range as the Allocator Identifier of an 'ipn' URI defined in , and is drawn from the same "'ipn' Scheme URI Allocator Identifiers" registry. An Allocator Identifier is an unsigned integer in the range 0 to 2^32-1. An Allocator that has been assigned an Allocator Identifier is authorized to assign Group Numbers for use with the 'imc' URI scheme, in addition to Node Numbers for use with the 'ipn' URI scheme. Each Allocator assigns Group Numbers according to its own policies. Other than ensuring that any Group Numbers it assigns are unique amongst all Group Numbers it assigns, an Allocator does not need to coordinate its assignments with other Allocators. Group Numbers and Node Numbers are distinct namespaces. An Allocator may assign the same numeric value as both a Group Number and a Node Number, and there is no relationship between a group and a node that happen to share the same Allocator Identifier and number. In any case where an encoded imc URI does not explicitly include an Allocator Identifier, an implementation MUST assume that the Group Number has been assigned by the Default Allocator (). A new IANA registry, "'imc' Scheme URI Default Allocator Group Numbers", is defined to control the assignment of Group Number values by the Default Allocator; see . This registry reserves some values as defined in below. If a system does not require interoperable deployment of 'imc' scheme URIs, then the Private Use Group Numbers (), reserved by the Default Allocator for this purpose, are to be used.

Group Numbers A Group Number names a group in the context of an Allocator. A Group Number is an unsigned integer. A single Group Number assigned by a single Allocator MUST refer to a single group. A group is the set of all multicast endpoints whose imc EIDs share an Allocator Identifier and Group Number, distinguished by their Service Numbers, in the same way that an 'ipn' FQNN names a node whose services are distinguished by their Service Numbers. An Allocator might assign a Group Number to a community of interest, a mission, or a function, with the multicast endpoints of the group identifying the services of that community. A Group Number does not identify any node or set of nodes, and assigning it does not make any node a member of any multicast endpoint. All Group Number assignments, by all Allocators, MUST be in the range 0 to 2^32-1. It is RECOMMENDED that Group Number zero (0) not be assigned by an Allocator, to avoid confusion with the Null imc URI (). Unlike the Fully Qualified Node Number of an 'ipn' URI (), this document defines no representation of an Allocator Identifier and Group Number packed together as a single integer, in either the text or the CBOR representation of imc URIs.

Special Group Numbers Some special-case Group Numbers are defined by the Default Allocator; see .

The Zero Group Number The Default Allocator assigns the use of Group Number zero (0) solely for identifying the Null imc URI (). This means that any imc URI with a zero (0) Allocator Identifier and a zero (0) Group Number, but a non-zero Service Number component, is invalid. Such imc URIs MUST NOT be composed, and processors of such imc URIs MUST consider them as the Null imc URI. Appendix A of suggests that imc:0.0 could identify an implicit multicast group of which every IMC-capable node is a member, to be used for distributing group membership information, and ION uses imc:0.0 in this way today. This document instead defines imc:0.0 as the null multicast endpoint, which never has any members (see and ), so that usage is not interoperable with this specification.

The Maximum Group Number The Default Allocator reserves Group Number 2^32-1 (0xFFFFFFFF) as invalid. This Group Number MUST NOT be assigned, and any imc URI with a zero (0) Allocator Identifier and a Group Number of 2^32-1 is invalid and MUST NOT be composed. This reservation exists solely to guard against confusion with LocalNode ipn URIs (), which use the same Node Number. For example, if this Group Number were assignable, the mistyped URI imc:4294967295.7, intended as the LocalNode ipn URI ipn:4294967295.7, could silently identify a real multicast endpoint. Reserving it ensures that such an error causes the bundle to be discarded rather than delivered to unintended recipients. The reservation does not give imc URIs any LocalNode semantics, and the 'imc' URI scheme has no equivalent of LocalNode ipn URIs. Services do not receive bundles; they receive the application data units (ADUs) of bundles delivered to them by their local bundle protocol agent (). An imc URI identifying "the local services" would therefore not identify anything to which a bundle could meaningfully be sent. A bundle node that receives or originates a bundle whose destination is an imc EID with a zero (0) Allocator Identifier and a Group Number of 2^32-1 MUST NOT forward or deliver it, and MUST delete it (). If a bundle deletion status report is requested, the reason code "Destination endpoint ID unavailable" () SHOULD be used. This reservation applies only to the Default Allocator. Other Allocators MAY assign Group Number 2^32-1 according to their own policies.

Private Use Group Numbers The Default Allocator reserves several ranges of Group Numbers for Private Use, as defined in . These ranges are interleaved with ranges of registered Group Numbers, so that Private Use Group Numbers are available at each length of CBOR encoding; see . Any imc URI with a zero (0) Allocator Identifier and a Group Number reserved for Private Use is not guaranteed to be unique beyond a single administrative domain. An administrative domain, as used here, is defined as the set of nodes that share a unique allocation of Private Use Group Numbers. Because of this lack of uniqueness, any implementation of a protocol using imc URIs that resides on the border between administrative domains MUST have suitable mechanisms in place to prevent protocol units using such Private Use Group Numbers from crossing between different administrative domains.

Service Numbers A Service Number is an unsigned integer, as defined in . In an imc URI, the Service Number distinguishes the multicast endpoints of a group, and so identifies the service to which a bundle destined for that multicast endpoint is delivered at each of its members.

The Null imc URI There is value in defining a unique imc URI that identifies a multicast endpoint that can never have any members. This imc URI is termed the "Null imc URI" and has all three components (the Allocator Identifier, Group Number, and Service Number) set to the value zero (0). The multicast endpoint identified by the Null imc URI is termed the "null multicast endpoint". No node is ever a member of the null multicast endpoint, and any destination identified by the Null imc URI is therefore by definition unreachable. In particular, the Null imc URI MUST NOT be interpreted as identifying a multicast endpoint of which all nodes, or all nodes supporting the 'imc' scheme, are implicitly members. See .

Textual Representation of imc URIs All 'imc' scheme URIs comply with and are therefore represented by a scheme identifier and a scheme-specific part. The scheme identifier is imc, and the scheme-specific parts are represented as a sequence of numeric components separated with the '.' character. A formal definition is provided below (see ) and can be informally considered as: .]. ]]> To keep the text representation concise, the following rules apply:

• All leading '0' characters MUST be omitted. A single '0' is valid.
• If the Allocator Identifier is zero (0), then the <allocator-identifier> and '.' MAY be omitted.

Examples of the textual representation of imc URIs can be found in .

'imc' URI Scheme Text Syntax The text syntax of an imc URI MUST comply with the following ABNF syntax from and repeats the core ABNF syntax rule for DIGIT defined by that specification: None of the reserved characters defined in the generic URI syntax are used as delimiters within URIs of the 'imc' scheme, other than '.'. The ABNF in names the single-number form of the group label "fqgn", implying that it carries a packed 64-bit Allocator Identifier and Group Number. This document instead follows Section 4 of : the single-number form is a Group Number assigned by the Default Allocator, and no packed form is defined (). Unlike the 'ipn' URI scheme, the 'imc' URI scheme has no '!' form, because it has no equivalent of LocalNode ipn URIs; see .

Usage of imc URIs with BPv7 This section identifies the behavior and interpretation of 'imc' scheme URIs that MUST be followed when using this URI scheme to represent EIDs in BPv7. This document does not define the use of imc URIs with the experimental Bundle Protocol version 6.

Multicast Endpoint Membership The members of a multicast endpoint are those bundle nodes that have a registration () in its imc EID. A single bundle node may be a member of any number of multicast endpoints. This document does not define any mechanism by which a node joins or leaves a multicast endpoint. As for any BPv7 endpoint, the means by which a registration is created or removed is an implementation matter (), and may for example be a local application interface, configuration, or a separately specified protocol. Membership is determined separately for each imc EID. Being a member of one multicast endpoint of a group does not make a node a member of any other multicast endpoint of that group: for example, the members of imc:977000.17.1 and of imc:977000.17.2 are independent sets of nodes, either of which may be empty. A bundle destined for an imc EID is delivered only at members of that multicast endpoint. Forwarding implementations may nevertheless aggregate state, such as distribution trees or membership information, across the multicast endpoints of a group, or across any other set of multicast endpoints, for example one described by an EID Pattern (). Such aggregation is an implementation choice that does not alter which nodes are members of each multicast endpoint, and does not imply that Group Numbers carry topological information (). As noted in , registrations are local, and BPv7 does not include a mechanism for distributing information about registrations. Mechanisms by which information about the membership of multicast endpoints is distributed are out of scope for this document.

The Null Multicast Endpoint When the Null imc URI () is used as a BPv7 EID, it is termed the "Null imc EID", and the endpoint it identifies is the null multicast endpoint. The null multicast endpoint never has any members: a bundle node MUST NOT hold a registration in the Null imc EID, by whatever means registrations are made. Because the null multicast endpoint has no members, a bundle destined for the Null imc EID can never be delivered. Such a bundle SHOULD NOT be created, and a bundle node that receives or originates such a bundle MUST NOT forward it to any other node. If such a bundle is deleted and a bundle deletion status report is requested, the reason code "Destination endpoint ID unavailable" () SHOULD be used. The null multicast endpoint is distinct from the BPv7 null endpoint ("dtn:none", ). Although both identify endpoints that never have any members, the Null imc EID MUST NOT be used in place of the null endpoint ID, for example to indicate an anonymous bundle source or that no status reports are to be sent. Equally, the null endpoint ID and the Null ipn EID () are not imc EIDs.

Node IDs and Bundle Sources requires that a Node ID be the EID of a singleton endpoint. Because a multicast endpoint is never a singleton endpoint, an imc EID MUST NOT be used as a Node ID. As a consequence, an imc EID MUST NOT be used as the source node ID of a bundle (), as the node ID carried in a Previous Node Block (), or as the security source of a Bundle Protocol Security (BPSec) security block.

Private Use imc EIDs Bundles destined for imc EIDs with a zero (0) Allocator Identifier and a Group Number within the Private Use ranges of the Default Allocator () are not universally unique; therefore, they are only valid within the scope of the current administrative domain. This means that any bundle using a Private Use imc EID as a bundle destination MUST NOT be allowed to cross administrative domains. All implementations that could be deployed as a gateway between administrative domains MUST be sufficiently configurable to ensure that this is enforced, and operators MUST ensure correct configuration. Private Use imc EIDs MUST NOT be present in any other part of a bundle that is destined for another administrative domain when the lack of uniqueness prevents correct operation.

Administrative Multicast Endpoints The administrative endpoint of a node is a singleton endpoint, and its EID can serve as the node's Node ID (). No imc EID identifies the administrative endpoint of any node. However, consistent with the meaning of Service Number zero (0) in 'ipn' EIDs (), the multicast endpoint of a group with Service Number zero (0), for example imc:977000.17.0, is the "administrative multicast endpoint" of that group. Bundles destined for an administrative multicast endpoint carry administrative records (), and are delivered at each member to the administrative element of its application agent (), rather than to any application-specific element. As for every multicast endpoint, the members of an administrative multicast endpoint are the nodes registered in its imc EID (), and its membership is independent of that of the other multicast endpoints of the group. A node is not implicitly a member of the administrative multicast endpoint of any group, including a group of whose other multicast endpoints it is a member. The "ADU is an administrative record" bundle processing control flag () MUST be set in every bundle destined for an administrative multicast endpoint, and a bundle destined for an administrative multicast endpoint without that flag set MUST NOT be delivered. Conversely, a bundle with that flag set MUST NOT be destined for an imc EID whose Service Number is not zero (0), consistent with the rule for 'ipn' EIDs in . The receiver of an administrative record delivered from an administrative multicast endpoint MUST be prepared for the same record to be delivered to many nodes. A specification of an administrative record type that is intended to be sent to administrative multicast endpoints SHOULD state so, and administrative record types not so specified SHOULD NOT be sent to them. This document specifies that bundle status reports () MAY be sent to an administrative multicast endpoint: the report-to EID of a bundle MAY be an administrative multicast endpoint, so that a set of monitoring nodes all receive its status reports. Because an administrative multicast endpoint is not the administrative endpoint of any node, it cannot be used as a Node ID (). Appendix A of uses imc:0.0 to convey administrative information about membership. Under this document, that function would use the administrative multicast endpoint of an explicitly assigned group, whose membership is determined by the deployment, rather than the null multicast endpoint (, ).

Well-Known Service Numbers The Service Number of an imc EID is interpreted in the same way as the Service Number of an 'ipn' EID. In particular, the well-known Service Numbers registered in the "'ipn' Scheme URI Well-Known Service Numbers for BPv7" registry () identify the same services when they appear in imc EIDs. Service Number zero (0), registered there as the Administrative Endpoint, identifies the administrative multicast endpoint of a group (). requests that the registries shared by 'ipn' and 'iac' be renamed. The WG needs to coordinate how these shared registries are named and referenced across 'ipn', 'imc', and 'iac'.

CBOR Representation of imc URIs with BPv7 requires that any URI scheme used to represent BPv7 EIDs MUST define how the scheme-specific part of the URI scheme is encoded with Concise Binary Object Representation (CBOR) . To meet this requirement, this section describes the CBOR encoding of imc EIDs. The formal definition of the CBOR representation is specified in . The examples in this section use the value 3 as the BPv7 URI scheme type of the 'imc' scheme. This value is a placeholder pending assignment by IANA; see .

imc EID CBOR Encoding When encoding imc EIDs for use with BPv7, the scheme-specific part of an imc URI MUST be represented as a CBOR array of exactly three (3) elements, regardless of the Allocator Identifier. Each element of the array MUST be encoded as a single CBOR unsigned integer, and:

• the first element of the array is the Allocator Identifier,
• the second element of the array is the Group Number, and
• the third element of the array is the Service Number.

This encoding corresponds to the three-element scheme-specific encoding of 'ipn' EIDs (). There is no equivalent of the two-element scheme-specific encoding of 'ipn' EIDs (): the Allocator Identifier is always encoded, including when it is zero (0), and no element packs the Allocator Identifier and Group Number into a single integer. For example, the imc EID of imc:977000.17.1 would result in the three-element array of [977000,17,1], which would be encoded in CBOR as the following 10-octet sequence: Further examples are provided in . An imc EID whose scheme-specific part is not a CBOR array of exactly three (3) unsigned integers, or whose Allocator Identifier or Group Number is not less than 2^32, is malformed. In particular, a two-element array is malformed. A bundle containing a malformed imc EID in its primary block MUST be treated as malformed. defines a two-element encoding whose first element packs the Allocator Identifier and Group Number into a single 64-bit integer, mirroring the 'ipn' scheme, and ION implements it. The 'ipn' two-element encoding was retained in RFC 9758 only for backwards compatibility with ION, and CCSDS is already deprecating it, so this document does not carry it into the new scheme, in either its packed form or an unpacked form for the Default Allocator. The cost is one additional octet for imc EIDs using the Default Allocator, in exchange for each imc EID having a single encoding. Implementations that emit the two-element form will not interoperate with this specification.

'imc' URI Scheme CBOR Syntax When encoded in CBOR , a BPv7 endpoint identified by an imc URI MUST comply with the following Concise Data Definition Language (CDDL) specification:

imc EID Matching imc EID matching MUST be performed on the decoded EID information itself: two imc EIDs are equal if and only if their Allocator Identifiers, Group Numbers, and Service Numbers are equal. Because there is a single scheme-specific encoding, and requires the core deterministic encoding of for bundle blocks, each imc EID has exactly one CBOR representation. Unlike 'ipn' EIDs (), no imc EID can be represented by different encodings that need to be treated as equivalent.

Special Considerations

Relationship to Other URI Schemes Although imc URIs share their structure, Allocator Identifiers, and Service Numbers with 'ipn' URIs, the two schemes identify different kinds of endpoint. An imc EID and an 'ipn' EID with identical numeric components, such as imc:977000.17.1 and ipn:977000.17.1, identify unrelated endpoints. proposes that Group Numbers have the same meaning in the 'iac' anycast scheme and in multi-destination schemes such as 'imc', so that one Group Number can be used with either scheme. The WG needs to decide whether to adopt that alignment.

Late Binding mandates the concept of the "late binding" of an EID, whereby the address of the destination of a bundle is resolved from its identifier hop-by-hop as it transits a BPv7 network. The concept of late binding is preserved in the 'imc' URI scheme. Elements of an imc URI MUST NOT be regarded as carrying information relating to the location or reachability of the members of a multicast endpoint, or other addressing or routing concerns.

imc EID Patterns defines EID Patterns, a means of matching sets of BPv7 EIDs, and requires that each URI scheme supporting patterns define a scheme-specific pattern item, comprising a logical information model, EID matching logic, pattern set logic, and both text and CBOR forms (). This section defines the scheme-specific pattern item for the 'imc' URI scheme, termed the "imc pattern". Because the information model of an imc URI is identical to that of an 'ipn' URI, being three unsigned integer elements with the same domains, the imc pattern is defined by reference to the IPN Scheme Pattern Item defined in , termed the "IPN pattern". Except as specified in this section, every requirement of that section and its subsections applies to the imc pattern, with "imc" substituted for "IPN" or "ipn".

Information Model An imc pattern SHALL logically contain exactly three elements corresponding to the elements of an imc EID:

• Allocator Identifier, with domain 0 to 2^32-1 inclusive
• Group Number, with domain 0 to 2^32-1 inclusive
• Service Number, with domain 0 to 2^64-1 inclusive

Each element is matched as a specific value, a range, or a wildcard, and is subject to the same constraints on ranges, normalization, decoding failure, and minimum supported number of intervals as the corresponding element of an IPN pattern (), with the Group Number taking the place of the Node Number.

EID Matching and Pattern Set Logic An imc pattern matches an imc EID according to the rules of , applied to the decoded Allocator Identifier, Group Number, and Service Number of the EID. An imc pattern never matches an EID of any other scheme; in particular, an imc pattern and an IPN pattern with identical elements match disjoint sets of EIDs (). Set logic between imc patterns is as defined for IPN patterns in .

Text Form The text form of the imc pattern is identical to the three-element text form of the IPN pattern defined in , except that the scheme name is "imc" rather than "ipn", and that there is no two-element form containing a packed value or the '!' character. It conforms to the following ABNF, which reuses the rules ipn-part-pat, ipn-decimal, and nbr-delim (and the rules on which they depend) from Figure 1 of : When decoding a two-element imc pattern, the first element SHALL be treated as a Group Number assigned by the Default Allocator, and the pattern SHALL be treated as the three-element pattern whose Allocator Identifier element is the specific value zero (0), consistent with the two-element text form of an imc URI (). Unlike a two-element IPN pattern, the first element is not a packed value, and has the domain of a Group Number. As for the IPN pattern, the canonical text form of an imc pattern SHALL use three elements, and every imc URI is itself a valid imc pattern that matches only that imc URI, satisfying . For example, the following imc pattern matches every Service Number of the group with Group Number 17 assigned by Allocator 977000: The following imc pattern matches Service Number 1 of every group assigned by the Default Allocator from the first Private Use range ():

CBOR Form The CBOR form of the imc pattern is identical to the CBOR form of the IPN pattern defined in , including the encoding of specific values, ranges, and wildcards, except that the scheme number is the 'imc' URI scheme type () rather than 2. It conforms to the following CDDL, which reuses the rule ipn-part-pat (and the rules on which it depends) from Figure 2 of : As for the IPN pattern, the CBOR form always has three elements; there is no two-element CBOR form of an imc pattern. For example, the imc pattern imc:977000.17.* would be encoded in CBOR as the following 11-octet sequence, using the placeholder value 3 for the 'imc' URI scheme type: This section depends normatively on . If the WG prefers not to create that dependency, this section could instead be moved to that document, or to a separate document.

Security Considerations This section is derived from the security considerations for the 'imc' scheme in , and follows the structure of .

Reliability and Consistency None of the BPv7 endpoints identified by imc EIDs 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 (BIB) targeting the bundle's primary block, as defined by BPSec , is required for this purpose.

Malicious Construction Malicious construction of a conformant imc URI is limited to the malicious selection of Allocator Identifiers, Group Numbers, and Service Numbers. That is, a maliciously constructed imc EID could be used to direct a bundle to a multicast endpoint whose members might be damaged by the arrival of that bundle. A bundle that asserts an imc EID as its source node ID is not valid (). In all 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.

Unauthorized Membership Membership of a multicast endpoint is determined by local registrations (), and the 'imc' URI scheme itself provides no means of restricting which nodes may become members of a multicast endpoint. Bundles destined for a multicast endpoint may therefore be delivered to nodes that are not intended recipients. Where this is a concern, the confidentiality of bundle contents should be protected using BPSec , and multicast protocols should authenticate membership information before acting on it.

Implicit Membership This document does not define any multicast endpoint of which all nodes, or all nodes supporting the 'imc' scheme, are implicitly members. In particular, the Null imc URI (), which earlier specifications suggested for such a purpose, instead identifies the null multicast endpoint, which never has any members (). Such an endpoint would allow any node able to inject a single bundle into a BPv7 network to cause that bundle to be replicated to, and delivered at, every node in the network. This is an amplification mechanism that could be used to exhaust transmission opportunities, storage, and power across the whole network, which is a particularly severe threat in networks with scarce or scheduled connectivity. Because membership would be implicit rather than determined by local registrations, no node could decline to receive such bundles, and the scope of the endpoint could not be confined to a single administrative domain. Mechanisms that require communication with many nodes, such as the distribution of membership information, should instead use multicast endpoints of explicitly assigned groups, whose membership and origination can be controlled by the deployment.

Status Report Implosion notes that requesting status reports for a single unicast bundle can result in (1 + (2 * (N-1))) status report bundles, where N is the number of nodes on the path to its destination, and for that reason requires that the generation of status reports be disabled by default and enabled only when the risk of excessive network traffic is deemed acceptable. further notes that malicious initiation of status reporting could be used to effect a denial-of-service attack. These risks are multiplied for bundles destined for multicast endpoints. A single bundle destined for an imc EID may be replicated along many paths and delivered at every member of the multicast endpoint, and each node that receives, forwards, delivers, or deletes a copy may generate a status report. The number of status reports generated by a single bundle can therefore grow with the number of members of the multicast endpoint as well as with the length of each path, and all of those reports converge on the single report-to endpoint, which may be overwhelmed. A bundle destined for a multicast endpoint that requests status reports is also an amplification mechanism, since a single bundle sent by an attacker can cause a much larger number of bundles to be sent to a victim named as its report-to endpoint. Implementations of the 'imc' scheme MUST retain the default of that status report generation is disabled, and SHOULD NOT generate status reports in response to bundles destined for imc EIDs unless explicitly configured to do so for the multicast endpoints concerned. Where status reporting for bundles destined for multicast endpoints is enabled, operators should take into account the number of members and the capacity of the report-to endpoint. Naming an administrative multicast endpoint () as the report-to endpoint distributes the reports to a set of monitoring nodes, but does not reduce their number, and further multiplies the resulting traffic. Integrity protection of the primary block using BPSec allows a node to verify that status reports were genuinely requested by the source of a bundle.

Private Use imc EIDs Private Use () imc URIs present a risk to the stability of deployed BPv7 networks. If such imc URIs are allowed to propagate beyond the domain in which they are valid, then the required uniqueness of imc URIs no longer holds, and bundles may be delivered to unintended multicast endpoints in other administrative domains. See for required behaviors to mitigate against this form of abuse.

Back-End Transcoding The limited expressiveness of URIs of the 'imc' scheme effectively eliminates the possibility of threats due to errors in back-end transcoding.

Rare IP Address Formats Not relevant, as IP addresses do not appear anywhere in conformant imc URIs.

Sensitive Information Because imc URIs are used only to represent the numeric identities of multicast endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of imc 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, such as TCPCLv4 .

Semantic Attacks The simplicity of the 'imc' URI scheme syntax minimizes the possibility of misinterpretation of a URI by a human user.

EID Patterns The security considerations of apply to imc patterns (). Because the text forms of imc and IPN patterns differ only in their scheme name, care is needed that a pattern intended to match 'ipn' EIDs is not written with the 'imc' scheme name, or vice versa, as the two match disjoint sets of EIDs.

IANA Considerations

'imc' URI Scheme IANA is requested to register the following URI scheme in the "Uniform Resource Identifier (URI) Schemes" registry, using the template in :

Scheme name:

imc

Status:

Permanent

Applications/protocols that use this scheme name:

The Delay-Tolerant Networking (DTN) Bundle Protocol Version 7 (BPv7) .

Contact:

IESG <iesg@ietf.org>

Change controller:

IETF

References:

This document.

Bundle Protocol URI Scheme Types IANA is requested to assign the following value in the "Bundle Protocol URI Scheme Types" registry within the "Bundle Protocol" registry group, including the "EID Pattern Reference" column added by : New Value in the Bundle Protocol URI Scheme Types Registry

Value	Description	BP Utilization Reference	URI Definition Reference	EID Pattern Reference
TBD1	imc	This document	This document	This document,

ION already uses the value 3 for 'imc' in its implementation of , although that document does not request a value from IANA, and requests the value 3 for 'iac'. Because 'imc' and 'iac' EIDs share the same three-element structure, assigning 3 to 'iac' would cause existing three-element 'imc' EIDs to be silently interpreted as valid 'iac' EIDs, rather than failing to decode. The author suggests that 'imc' retain the value 3, as the longer-established use (the 'imc' scheme dates from ), and that 'iac' request the next available value. Note that this document is already not wire-compatible with existing implementations for Default Allocator EIDs () or for imc:0.0 (), so the WG could instead choose a new value to separate this specification cleanly from deployed practice. As the registry requires Standards Action, the value could be secured following WG adoption by an early allocation .

'ipn' Scheme URI Allocator Identifiers IANA is requested to add this document as a reference to the "'ipn' Scheme URI Allocator Identifiers" registry, and to add the following note to that registry:

• Allocator Identifiers in this registry are also used to identify the Allocators of Group Numbers for the 'imc' URI scheme.

'imc' Scheme URI Default Allocator Group Numbers Registry IANA is requested to create a new registry titled "'imc' Scheme URI Default Allocator Group Numbers" in the "Uniform Resource Identifier (URI) Schemes" registry group. Using terms defined in , the registration procedures for this registry are: Registration Procedures for the 'imc' Scheme URI Default Allocator Group Numbers Registry

Range	Registration Procedures
1..127	Private Use
128..255	Standards Action
0x0100..0x7FFF	Private Use
0x8000..0xFFFF	Specification Required
0x10000..0xFFFFFFFE	Private Use
>=0x100000000	Invalid

These ranges follow the CBOR encoding of unsigned integers (), in which values less than 24 are encoded in one octet, values less than 256 in two octets, values less than 65536 in three octets, and values less than 2^32 in five octets. The two-octet and three-octet encoded lengths are each divided between Private Use and registered Group Numbers, so that deployments using Private Use Group Numbers are not forced to use less efficiently encoded values than registered groups. All one-octet values other than zero (0), and all five-octet values other than 2^32-1, are reserved for Private Use. This is the same structure as the "'ipn' Scheme URI Well-Known Service Numbers for BPv7" registry (). The initial values in the registry are: Initial Values in the 'imc' Scheme URI Default Allocator Group Numbers Registry

Value	Description	Reference
0	Reserved for the Null imc URI	This document,
4294967295	Invalid; avoids confusion with LocalNode ipn URIs	This document,

Each entry in this registry associates a single Group Number with a group of interest to the wider BPv7 community. Within the registry, the group is identified using the "Description" field, and the "Reference" field identifies a publicly available specification of the purpose of the group. The ranges of the "'ipn' Scheme URI Default Allocator Node Numbers" registry (Section 9.2 of ) are not used as a model, because that registry retains its pre-existing structure and assignments rather than following CBOR encoding lengths. How this registry relates to the "Bundle Protocol Well-Known Group Numbers" registry proposed by , which uses the same CBOR-aligned ranges, is to be decided.

Guidance for Designated Experts Due to the nature of the CBOR encoding of unsigned integers used for Group Numbers with BPv7, Group Numbers with a low value are encoded more efficiently than larger numbers. The two-octet registered range (128..255) is therefore reserved for Standards Action. Designated experts reviewing requests in the three-octet registered range (0x8000..0xFFFF) are strongly recommended to familiarize themselves with the CBOR encoding of unsigned integers in . Group Numbers assigned by the Default Allocator are intended for multicast groups that are of use to the entire BPv7 community. Each registration outside the Private Use ranges MUST have a corresponding publicly available specification describing the purpose of the group. Multicast groups that are specific to a particular deployment or organization are expected to use Group Numbers assigned by that organization's own Allocator, or Private Use Group Numbers, and do not require an entry in this registry. Designated experts MUST NOT approve the registration of any Group Number whose specification requires bundle nodes to be implicitly members of the multicast endpoints of the identified group (see ).

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116. It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme. The Johns Hopkins University Applied Physics Laboratory This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. The Other Name form is used to update the PKIX profiles of RFC 9174 and [I-D.ietf-dtn-bpsec-cose]. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms. IPNSIG Inc. 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". Jet Propulsion Laboratory This document describes a mechanism for Delay-Tolerant Networking (DTN) multicast that is compatible with Compressed Bundle Header Encoding (CBHE). The mechanism, named "Interplanetary Multicast" (IMC), comprises (a) a single network-wide multicast spanning tree overlaid on any single Bundle Protocol (BP)-based network, (b) multicast groups that take the form of ordinary BP non-singleton endpoints, (c) a new CBHE-compatible URI scheme, "imc", for expressing the identities of these endpoints, (d) a new type of BP administrative record that propagates multicast "petitions" (announcements regarding nodes' membership in IMC endpoints) through the multicast tree, and (e) a new bundle forwarding procedure by which bundles whose destinations are multicast groups are forwarded through the multicast tree in accord with previously received petitions. IMC is designed to provide simple and efficient multi-source, generally reliable, delay-tolerant multi-point data delivery in a network of arbitrary size. Anycast, content-centric networking, persistent messages, and similar research challenges are not explicitly supported. For research purposes and small-scale deployment, it is anticipated that multicast tree construction and maintenance can be manual. For larger networks an automated protocol for IMC tree management would be required; the design of such a protocol is beyond the scope of this specification. European Space Operations Centre (ESOC) European Space Operations Centre (ESOC) This document describe a new anycast addressing scheme for Delay- Tolerant Networking (DTN), named Interplanetary Anycast Communication (iac). Designed for use within the DTN Bundle Protocol Version 7 (BPv7), iac enables IP Anycast-like funcionality in the Context of Delayed Tolerant Network, so this mechanism enables the routing and delivery of bundles to a single member of a specified iac anycast group based on a structured Endpoint Identifier (EID) URI scheme. The document formally defines the "iac" URI scheme, made of three main components, an Allocator Identifier, a Group Number, and a Service Number, details registration requirements with IANA addressing formats, and service numbering conventions while maintaining compatibility with existing IPN/IMC-based identifiers. Aalyria Technologies Spatiam Corporation This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) tunneling mechanism by which a bundle is carried as the payload of one or more encapsulating bundles, allowing security measures and routing policy to be applied to the encapsulating bundle without modification of the encapsulated bundle. The protocol includes an optional segmentation mechanism, allowing a large encapsulated bundle to be carried in multiple encapsulating bundles.

'imc' URI Scheme Text Representation Examples This section provides some example imc URIs in their textual representation.

Using the Default Allocator Consider the imc URI identifying the multicast endpoint with Service Number 1 of the group with Group Number 5 assigned by the Default Allocator (0). The recommended seven-character representation of this URI would be as follows: The nine-character representation of this URI, with the explicit Allocator Identifier, would be as follows:

Using a Non-Default Allocator Consider the imc URI identifying the multicast endpoint with Service Number 1 of the group with Group Number 17 assigned by Allocator 977000. The 15-character representation of this URI would be as follows:

The Null imc URI The Null imc URI () is represented as:

'imc' URI Scheme CBOR Encoding Examples This section provides some example CBOR encodings of imc EIDs. As in , these examples use the placeholder value 3 for the 'imc' URI scheme type.

Using the Default Allocator Consider the imc EID imc:5.1. This textual representation of an imc EID identifies the multicast endpoint with Service Number 1 of the group with Group Number 5 assigned by the Default Allocator (0). The six-octet encoding of this EID would be as follows:

Using a Non-Default Allocator Consider the imc EID imc:977000.17.1. This textual representation of an imc EID identifies the multicast endpoint with Service Number 1 of the group with Group Number 17 assigned by Allocator 977000. The 10-octet encoding of this EID would be as follows:

The Null imc EID The six-octet encoding of the Null imc EID () of imc:0.0 would be as follows:

Acknowledgments The 'imc' URI scheme was designed by Scott Burleigh, and much of the text of this document is derived from and . The structure of this document follows .