The 'imc' URI Scheme for Bundle Protocol Multicast

3.1. 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 Section 3.2 of [RFC9758], 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 (Section 3.2.2 of [RFC9758]).¶

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 Section 10.4. This registry reserves some values as defined in Section 3.3 below.¶

If a system does not require interoperable deployment of 'imc' scheme URIs, then the Private Use Group Numbers (Section 3.3.3), reserved by the Default Allocator for this purpose, are to be used.¶

3.2. 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 (Section 3.5).¶

Unlike the Fully Qualified Node Number of an 'ipn' URI (Section 3.3.1 of [RFC9758]), 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.¶

3.3. Special Group Numbers

Some special-case Group Numbers are defined by the Default Allocator; see Section 10.4.¶

3.4. Service Numbers

A Service Number is an unsigned integer, as defined in Section 3.5 of [RFC9758]. 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.¶

3.5. 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 Section 9.4.¶

4.1. 'imc' URI Scheme Text Syntax

The text syntax of an imc URI MUST comply with the following ABNF syntax from [RFC5234] and repeats the core ABNF syntax rule for DIGIT defined by that specification:¶

imc-uri = "imc:" imc-hier-part

imc-hier-part = group-part "." service-number

group-part = [allocator-identifier "."] group-number

allocator-identifier = number

group-number = number

service-number = number

number = "0" / non-zero-number

non-zero-number = (%x31-39 *DIGIT)

DIGIT = %x30-39

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 [I-D.burleigh-dtn-multicast] 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 [RFC9758]: the single-number form is a Group Number assigned by the Default Allocator, and no packed form is defined (Section 3.2).¶

Unlike the 'ipn' URI scheme, the 'imc' URI scheme has no '!' form, because it has no equivalent of LocalNode ipn URIs; see Section 3.3.2.¶

5.1. Multicast Endpoint Membership

The members of a multicast endpoint are those bundle nodes that have a registration (Section 3.1 of [RFC9171]) 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 (Section 3.3 of [RFC9171]), 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 (Section 8). 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 (Section 7.2).¶

As noted in Section 3.1 of [RFC9171], 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.¶

5.2. The Null Multicast Endpoint

When the Null imc URI (Section 3.5) 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" (Section 6.1.1 of [RFC9171]) SHOULD be used.¶

The null multicast endpoint is distinct from the BPv7 null endpoint ("dtn:none", Section 4.2.5.1.1 of [RFC9171]). 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 (Section 5.2 of [RFC9758]) are not imc EIDs.¶

5.3. Node IDs and Bundle Sources

Section 4.2.5.2 of [RFC9171] 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 (Section 5.2 of [RFC9171]), as the node ID carried in a Previous Node Block (Section 4.4.1 of [RFC9171]), or as the security source of a Bundle Protocol Security (BPSec) [RFC9172] security block.¶

5.4. 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 (Section 3.3.3) 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.¶

5.5. Administrative Multicast Endpoints

The administrative endpoint of a node is a singleton endpoint, and its EID can serve as the node's Node ID (Section 3.2 of [RFC9171]). No imc EID identifies the administrative endpoint of any node.¶

However, consistent with the meaning of Service Number zero (0) in 'ipn' EIDs (Section 5.7 of [RFC9758]), 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 (Section 6.1 of [RFC9171]), and are delivered at each member to the administrative element of its application agent (Section 3.1 of [RFC9171]), 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 (Section 5.1), 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 (Section 4.2.3 of [RFC9171]) 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 Section 5.7 of [RFC9758].¶

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 (Section 6.1.1 of [RFC9171]) 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 (Section 5.3).¶

Appendix A of [I-D.burleigh-dtn-multicast] 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 (Section 5.2, Section 9.4).¶

5.6. 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 (Section 5.6 of [RFC9758]) 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 (Section 5.5).¶

[I-D.cavallini-dtn-iac] 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'.¶

6.1. 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 (Section 6.1.2 of [RFC9758]). There is no equivalent of the two-element scheme-specific encoding of 'ipn' EIDs (Section 6.1.1 of [RFC9758]): 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:¶

82                # 2-Element Endpoint Encoding
   03             # uri-code: 3 ('imc' URI scheme)
   83             # 3-Element imc EID encoding
      1A 000EE868 # Allocator Identifier
      11          # Group Number
      01          # Service Number

Further examples are provided in Appendix B.¶

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

[I-D.burleigh-dtn-multicast] 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.¶

6.2. 'imc' URI Scheme CBOR Syntax

When encoded in CBOR [RFC8949], a BPv7 endpoint identified by an imc URI MUST comply with the following Concise Data Definition Language (CDDL) [RFC8610] specification:¶

eid = $eid .within eid-structure

eid-structure = [
  uri-code: uint,
  SSP: any
]

; ... Syntax for other uri-code values defined in RFC 9171 ...

$eid /= [
  uri-code: 3,  ; placeholder pending IANA assignment (TBD1)
  SSP: imc-ssp
]
imc-ssp = [
  allocator-identifier: uint .lt 4294967296,
  group-number: uint .lt 4294967296,
  service-number: uint
]

6.3. 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 Section 4.1 of [RFC9171] requires the core deterministic encoding of [RFC8949] for bundle blocks, each imc EID has exactly one CBOR representation. Unlike 'ipn' EIDs (Section 6.4 of [RFC9758]), no imc EID can be represented by different encodings that need to be treated as equivalent.¶

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

[I-D.cavallini-dtn-iac] 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.¶

7.2. Late Binding

[RFC9171] 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.¶

8.1. 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 (Section 2.4 of [I-D.ietf-dtn-eid-pattern]), with the Group Number taking the place of the Node Number.¶

8.2. EID Matching and Pattern Set Logic

An imc pattern matches an imc EID according to the rules of Section 2.4.1 of [I-D.ietf-dtn-eid-pattern], 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 (Section 7.1).¶

Set logic between imc patterns is as defined for IPN patterns in Section 2.4.2 of [I-D.ietf-dtn-eid-pattern].¶

8.3. Text Form

The text form of the imc pattern is identical to the three-element text form of the IPN pattern defined in Section 2.4.3 of [I-D.ietf-dtn-eid-pattern], 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 [I-D.ietf-dtn-eid-pattern]:¶

eid-pattern-item =/ imc-pat-item
imc-pat-item = "imc:" (imc-pat-ssp3 / imc-pat-ssp2)

; Full pattern for three elements
imc-pat-ssp3 = ipn-part-pat
               nbr-delim ipn-part-pat
               nbr-delim ipn-part-pat

; Accept a single EID in two-element text form
imc-pat-ssp2 = ipn-decimal nbr-delim ipn-decimal

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 (Section 4). 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 Section 2.1.1 of [I-D.ietf-dtn-eid-pattern].¶

For example, the following imc pattern matches every Service Number of the group with Group Number 17 assigned by Allocator 977000:¶

imc:977000.17.*

The following imc pattern matches Service Number 1 of every group assigned by the Default Allocator from the first Private Use range (Section 10.4):¶

imc:0.[1-127].1

8.4. CBOR Form

The CBOR form of the imc pattern is identical to the CBOR form of the IPN pattern defined in Section 2.4.4 of [I-D.ietf-dtn-eid-pattern], including the encoding of specific values, ranges, and wildcards, except that the scheme number is the 'imc' URI scheme type (Section 10.2) 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 [I-D.ietf-dtn-eid-pattern]:¶

$eid-pat-item /= [
  scheme-num: 3,  ; placeholder pending IANA assignment (TBD1)
  SSP: imc-pat-ssp
]
imc-pat-ssp = [
  ; This CDDL representation does not restrict to the
  ; true domain of each element.
  3*3 ipn-part-pat,
]

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:¶

81                   # EID Pattern with one item
   82                # imc pattern item
      03             # scheme-num: 3 ('imc' URI scheme)
      83             # 3-Element imc pattern SSP
         1A 000EE868 # Allocator Identifier
         11          # Group Number
         F5          # Service Number: wildcard (true)

This section depends normatively on [I-D.ietf-dtn-eid-pattern]. If the WG prefers not to create that dependency, this section could instead be moved to that document, or to a separate document.¶

9.1. 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 [RFC9172], is required for this purpose.¶

9.2. 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 (Section 5.3). 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.¶

9.3. Unauthorized Membership

Membership of a multicast endpoint is determined by local registrations (Section 5.1), 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 [RFC9172], and multicast protocols should authenticate membership information before acting on it.¶

9.4. 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 (Section 3.5), which earlier specifications suggested for such a purpose, instead identifies the null multicast endpoint, which never has any members (Section 5.2).¶

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

9.5. Status Report Implosion

Section 6.1.1 of [RFC9171] 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. Section 8 of [RFC9171] 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 Section 6.1.1 of [RFC9171] 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 (Section 5.5) 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 [RFC9172] allows a node to verify that status reports were genuinely requested by the source of a bundle.¶

9.6. Private Use imc EIDs

Private Use (Section 3.3.3) 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 Section 5.4 for required behaviors to mitigate against this form of abuse.¶

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

9.8. Rare IP Address Formats

Not relevant, as IP addresses do not appear anywhere in conformant imc URIs.¶

9.9. 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 [I-D.ietf-dtn-bibe] or by secure convergence-layer protocols that do not expose endpoint IDs, such as TCPCLv4 [RFC9174].¶

9.10. Semantic Attacks

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

9.11. EID Patterns

The security considerations of Section 5 of [I-D.ietf-dtn-eid-pattern] apply to imc patterns (Section 8). 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.¶

10.1. 'imc' URI Scheme

IANA is requested to register the following URI scheme in the "Uniform Resource Identifier (URI) Schemes" registry, using the template in Section 7.4 of [RFC7595]:¶

Scheme name:

imc¶

Status:

Permanent¶

Applications/protocols that use this scheme name:

The Delay-Tolerant Networking (DTN) Bundle Protocol Version 7 (BPv7) [RFC9171].¶

Contact:

IESG <iesg@ietf.org>¶

Change controller:

IETF¶

References:

This document.¶

10.2. 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 Section 6.1 of [I-D.ietf-dtn-eid-pattern]:¶

ION already uses the value 3 for 'imc' in its implementation of [I-D.burleigh-dtn-multicast], although that document does not request a value from IANA, and [I-D.cavallini-dtn-iac] 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 [I-D.burleigh-dtnrg-imc]), and that 'iac' request the next available value. Note that this document is already not wire-compatible with existing implementations for Default Allocator EIDs (Section 6.1) or for imc:0.0 (Section 5.2), 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 [RFC7120].¶

10.3. '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.¶

10.4. '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 [RFC8126], the registration procedures for this registry are:¶

These ranges follow the CBOR encoding of unsigned integers (Section 3 of [RFC8949]), 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 (Section 9.3 of [RFC9758]).¶

The initial values in the registry are:¶

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 [RFC9758]) 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 [I-D.cavallini-dtn-iac], which uses the same CBOR-aligned ranges, is to be decided.¶

11.1. Normative References

[I-D.ietf-dtn-eid-pattern]

Sipos, B., "Bundle Protocol Endpoint ID Patterns", Work in Progress, Internet-Draft, draft-ietf-dtn-eid-pattern-11, 23 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-eid-pattern-11>.

[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/rfc/rfc2119>.

[RFC3986]

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/rfc/rfc3986>.

[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/rfc/rfc5234>.

[RFC7595]

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/rfc/rfc7595>.

[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/rfc/rfc8126>.

[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/rfc/rfc8174>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[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/rfc/rfc8949>.

[RFC9171]

Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.

[RFC9758]

Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025, <https://www.rfc-editor.org/rfc/rfc9758>.

11.2. Informative References

[I-D.burleigh-dtn-multicast]

Burleigh, S., "Bundle Multicast", Work in Progress, Internet-Draft, draft-burleigh-dtn-multicast-00, 10 October 2026, <https://datatracker.ietf.org/doc/html/draft-burleigh-dtn-multicast-00>.

[I-D.burleigh-dtnrg-imc]

Burleigh, S., "CBHE-Compatible Bundle Multicast", Work in Progress, Internet-Draft, draft-burleigh-dtnrg-imc-00, 7 November 2012, <https://datatracker.ietf.org/doc/html/draft-burleigh-dtnrg-imc-00>.

[I-D.cavallini-dtn-iac]

Cavallini, D. and F. Flentge, "DTN Interplanetary Anycast Scheme", Work in Progress, Internet-Draft, draft-cavallini-dtn-iac-00, 17 September 2025, <https://datatracker.ietf.org/doc/html/draft-cavallini-dtn-iac-00>.

[I-D.ietf-dtn-bibe]

Taylor, R. and A. Montilla, "Bundle-in-Bundle Encapsulation", Work in Progress, Internet-Draft, draft-ietf-dtn-bibe-01, 23 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bibe-01>.

[RFC7120]

Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/rfc/rfc7120>.

[RFC9172]

Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, <https://www.rfc-editor.org/rfc/rfc9172>.

[RFC9174]

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/rfc/rfc9174>.

A.1. 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:¶

imc:5.1

The nine-character representation of this URI, with the explicit Allocator Identifier, would be as follows:¶

imc:0.5.1

A.2. 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:¶

imc:977000.17.1

A.3. The Null imc URI

The Null imc URI (Section 3.5) is represented as:¶

imc:0.0

B.1. 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:¶

82       # 2-Element Endpoint Encoding
   03    # uri-code: 3 ('imc' URI scheme)
   83    # 3-Element imc EID encoding
      00 # Default Allocator
      05 # Group Number
      01 # Service Number

B.2. 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:¶

82                # 2-Element Endpoint Encoding
   03             # uri-code: 3 ('imc' URI scheme)
   83             # 3-Element imc EID encoding
      1A 000EE868 # Allocator Identifier
      11          # Group Number
      01          # Service Number

B.3. The Null imc EID

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

82       # 2-Element Endpoint Encoding
   03    # uri-code: 3 ('imc' URI scheme)
   83    # 3-Element imc EID encoding
      00 # Default Allocator
      00 # Group Number
      00 # Service Number