Internet Engineering Task Force D. Cavallini Internet-Draft F. Flentge Intended status: Informational European Space Operations Centre (ESOC) Expires: 19 March 2026 15 September 2025 DTN Interplanetary Anycast Scheme draft-cavallini-dtn-iac-00 Abstract 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. Requirements Language 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 [RFC2119] 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 19 March 2026. Cavallini & Flentge Expires 19 March 2026 [Page 1] Internet-Draft iac September 2025 Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. iac Design Element . . . . . . . . . . . . . . . . . . . . . 3 2.1. Core Concept . . . . . . . . . . . . . . . . . . . . . . 3 2.2. The "iac" Endpoint ID Scheme . . . . . . . . . . . . . . 4 2.3. Allocator Identifier . . . . . . . . . . . . . . . . . . 5 2.4. Group Number . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Service Number . . . . . . . . . . . . . . . . . . . . . 7 2.5.1. Well-Known Service Numbers . . . . . . . . . . . . . 7 3. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7 3.1. iac URI Scheme . . . . . . . . . . . . . . . . . . . . . 8 3.2. Bundle Protocol URI Scheme Types . . . . . . . . . . . . 8 3.3. Bundle Protocol Well-Known Group Number . . . . . . . . . 9 4. CBOR Representation of iac URIs with BPv7 . . . . . . . . . . 10 4.1. iac EID CBOR encoding . . . . . . . . . . . . . . . . . . 10 4.1.1. iac scheme-specific Encoding . . . . . . . . . . . . 11 4.1.2. 'iac' URI Scheme CBOR Syntax . . . . . . . . . . . . 11 5. List Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. iac EID examples . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Nominative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. iac EID CBOR decoding . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Cavallini & Flentge Expires 19 March 2026 [Page 2] Internet-Draft iac September 2025 1. Introduction This document describes a new scheme for Delay-Tolerant Networking (DTN) anycast; the scheme, named "Interplanetary Anycast" (iac), is designed to be a simple, efficient anycast naming capability operating in the context of the Delay-Tolerant Networking (DTN) Bundle Protocol Version 7 (BPv7) [RFC9171], this document is intended to specify the iac anycast scheme only for the Bundle Protocol Version 7 and not the previous versions. The iac anycast scheme is intended to offer the following features: * Describe a anycast mechanism for Delayed Tolerant Networks * Give the capability to the Bundle Protocol to address a single service on a BP Node that is a member of a specific iac anycast group specified in the Bundle EID. * As with its IP-based counterpart, the Interplanetary Anycast Communication (iac) mechanism provides the capability to address a single resource via its Endpoint Identifier (EID) that could be either a member of a designated iac anycast group or any immediate neighbor Bundle Protocol (BP) Node ( immediate neighbor: meaning one that is a next bundle hop of the source BP Node ). * Data intended for an iac (Interplanetary Anycast Communication) anycast group can be transmitted using Delay/Disruption-Tolerant Networking (DTN) protocols that can ensure successful data delivery, even in environments where end-to-end connectivity is intermittent or unavailable for extended periods of time. * Give the possibility to BP Nodes to register to a specific iac group, becoming then an eligible destination for a bundle with the specified iac group EID . 2. iac Design Element 2.1. Core Concept Every iac 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 Cavallini & Flentge Expires 19 March 2026 [Page 3] Internet-Draft iac September 2025 The Allocator Identifier will permit to different organizations to create their own iac anycast address hierarchies; it is the same as the one specified in Section 3.2 of [RFC9758], in this document explained in (Section 2.3) The Group Number is a shared identifier that identifies an iac anycast group, in this document explained in (Section 2.4) The Service Number is an identifier to distinguish between resources on a given node; it is the same as the one is Section 3.5 of [RFC9758], in this document explained in (Section 2.5) 2.2. The "iac" Endpoint ID Scheme A BP endpoint identifier (EID) is a Uniform Record Identifier (URI) as defined by [RFC3986]. More specifically, each BP EID is a URI consisting of a "scheme name" followed by ":", followed by a sequence of characters termed the "scheme-specific part" (SSP) in DTN specifications, conforming to the URI syntax as defined by [RFC3986] All EIDs identifying iac endpoints MUST conform to the "iac" URI scheme described below. As noted below in (Section 3), IANA registration is requested for this new URI scheme. The scheme identifier is "iac", and the scheme-specific parts are represented as a sequence of numeric components separated with the '.' character. A formal definition is provided below and can be informally considered as: iac:.. The SSP of every URI formed within the "iac" scheme MUST comprise: 1. A sequence of ASCII numeric digits representing a unique unsigned integer in the range 0 to 2^(32-1), termed the "allocator- identifier" of the URI. 2. An ASCII period ('.') character. 3. A sequence of ASCII numeric digits representing an unsigned integer in the range 0 to 2^(32-1), termed the "group-number" of the URI. 4. An ASCII period ('.') character. 5. A sequence of ASCII numeric digits representing an unsigned integer, termed the "service number" of the URI. Cavallini & Flentge Expires 19 March 2026 [Page 4] Internet-Draft iac September 2025 To keep the text representation concise, the following rules apply: 1. All leading '0' characters MUST be omitted. A single '0' is valid. The Allocator Identifier has the same structure, purpose and meaning as the one in IPN scheme Section 3.2 of [RFC9758] The Group Number in the iac scheme is intended to carry the same semantic meaning as in other naming scheme addressing group of nodes, such as multi-destination naming schemes like IMC (interplanetary multicast), are expected to define groups in the same way to allow aligning the definition of groups of nodes across multiple naming schemes.. The Service Number has the same, structure, purpose and meaning as the one in IPN scheme [RFC9758] 2.3. Allocator Identifier The Allocator Identifier defined in this Document MUST be the exact same one as the one defined in the ipn scheme Section 3.2 of [RFC9758] In the [RFC9758] an Allocator is an entity authorized to assign Node Numbers for use with the 'ipn' URI scheme. This authorization is granted through the assignment of a unique Allocator Identifier (an unsigned integer within the 32-bit range) by the Internet Assigned Numbers Authority (IANA) to the registry called 'ipn' Scheme URI Allocator Identifiers. This authorization SHALL be extended to include authorization to the assignment of group numbers. It is requested to rename the IANA registry to 'ipn & iac' Scheme URI Allocator Identifiers Each Allocator is permitted to assign Node Numbers by its own internal policies without requiring coordination with other Allocators, provided the assigned numbers are unique within its scope. For non-interoperable deployments, a predefined private-use range is available via the Default Allocator. The usage in the iac scheme is the equivalent to ipn, so every Allocator can decide to assign iac scheme hierarchies (without violating the scheme rules in this Document), also a DefaultAllocator is defined which is the Allocator Number zero (0), this Allocator is privately defined but can be used by anyone Cavallini & Flentge Expires 19 March 2026 [Page 5] Internet-Draft iac September 2025 In iac scheme the Allocator Identifier 0 MUST be declared, unlike the ipn scheme [RFC9758], in ipn it is recommended to omit the allocator from the URI if it is 0, leading to 2-3 parts URI, the iac URI is always 3 elements 2.4. Group Number An iac anycast group is a non-singleton BP endpoint that is identified by a URI that conforms to the "iac" scheme. A BP node joins an iac anycast group by registering with the corresponding endpoint, and it leaves the group by unregistering from that endpoint. A BP node that is registered in an iac anycast group MUST deliver bundles only to endpoints which are members of the anycast group specified as destination eid in the bundle's primary header; After delivery to the service application identified by the service number, the bundle MUST NOT be forwarded to any other BP Node If the bundle anycast group destination differs, then the bundle MUST NOT be accepted; the bundle SHOULD be routed and forwarded to another iac-capable BP node or, if the node is not iac compliant, it MAY be discarded. The Group Number with the number zero (0) is reserved and each node supporting the iac naming scheme SHALL be implicitly registered in all EID with the group number `0`.This will result that any bundle with an iac destination endpoint id having group number `0` will be delivered at the next iac-compliant hop. In particular, any bundle with a destination eid with group and service number `0` will be delivered to the administrative element of the next hop supporting the iac naming scheme. An iac bundle with the destination eid 0 should be routed to the nearest BP node that MUST differ from the the local one. This rule is valid only for the iac group 0, if a bundle has any other iac group number as endpoint eid than it can also be routed to the local BP node if it matches the local registered group numbers. An iac anycast group may at any time have zero, one, or many members, the members of the group A new IANA registry is requested for "Bundle Protocol Well-Known Group Number", to define the registration of Group Numbers in the Bundle Protocol, see Section 3.3, the Well-Known Group Numbers set in this registry MUST be valid for every Allocator, not only the Default one. Cavallini & Flentge Expires 19 March 2026 [Page 6] Internet-Draft iac September 2025 2.5. Service Number The iac scheme Service Number MUST be the same as the one specified in Section 3.2 of [RFC9758] The service number is an unsigned integer that identifies a particular resource on a node. It serves a role analogous to a port number in traditional IP networking. It allows multiple services or applications to coexist on the same BP node and ensures that a received bundle is delivered to the correct service endpoint. In the iac context, when a bundle is received, if the BP Node has joined the correct iac anycast group, then the bundle MUST be retained by the BP Node and SHALL then be delivered to the service registered under the Service Number specified in the EID. Another interesting usage of the Service Number in the iac context is the service number zero (0) (example: iac:0.0), a bundle with this EID is trying to deliver a bundle to the administrative element of a BP Node; the mechanism could allow interesting use for reporting and custody matters in the BP context. 2.5.1. Well-Known Service Numbers For Bundle Protocol Version 7 (BPv7) services that are publicly specified and widely adopted, it is advantageous to assign a predefined default Service Number. That allows such services to be assumed already operative by default on a BP Node in the absence of explicit configuration. The iac scheme SHALL share the same well-known service numbers as those in IANA registry, "'ipn' Scheme URI Well-Known Service Numbers for Section 5.6 of [RFC8126]. This registry formalizes the assignment of Service Numbers to well-known BPv7 services and includes reserved ranges for both experimental purposes and private use. It is requested to rename this registry to "'ipn and iac' Scheme URI Well-Known Service Numbers for BPv7" To support this mechanism, a new IANA registry entitled "'ipn' Scheme URI Well-Known Service Numbers for BPv7" specified in Section 9.3 of [RFC9758]. 3. IANA Consideration Cavallini & Flentge Expires 19 March 2026 [Page 7] Internet-Draft iac September 2025 3.1. iac URI Scheme Provisional registration (per [RFC4395]) for a URI scheme is requested, with the string "iac" as the suggested scheme name, as follows. URI scheme name: "iac". Status: permanent. URI 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. iac-uri = "iac:" iac-hier-part iac-hier-part = allocator-identifier "." group-number "." service- 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 iac scheme. Encoding considerations: URIs of the IMC scheme are encoded exclusively in US-ASCII characters. Applications and/or protocols that use this URI scheme name: the Delay-Tolerant Networking (DTN) Bundle Protocol Version 7 (BP) [RFC9171]. Interoperability considerations: as noted above, URIs of the iac scheme are encoded exclusively in US-ASCII characters. 3.2. Bundle Protocol URI Scheme Types A new URI scheme code (proposal for value 3) in the "Bundle Protocol URI Scheme Types" IANA registry for the iac scheme is hereby requested to enable the definition of an efficient encoding and decoding mechanism for the iac scheme in CBOR. Cavallini & Flentge Expires 19 March 2026 [Page 8] Internet-Draft iac September 2025 This specification re-uses the "Bundle Protocol URI Scheme Types" registry within the "Bundle Protocol" registry group [IANA-BP] for the CBOR encoding of EID Patterns and adds an informative column "EID Pattern Reference" as in the following table for iac scheme URI code. Specifications of new EID Pattern schemes SHALL define all of the required items from Section 2.2 to ensure that pattern behavior is consistent across different schemes. +=======+=============+=====+==============================+ | Value | Description | ... | EID Pattern Reference | +=======+=============+=====+==============================+ | TBD1 | iac | | Section 2.2 of this Document | +-------+-------------+-----+------------------------------+ Table 1: CBOR Tag Values for EID Schemes 3.3. Bundle Protocol Well-Known Group Number IANA is requested to create a new registry entitled "Bundle Protocol Well-Known Group Numbers" under the namespace "Uniform Resource Identifier (URI) Schemes". The registration policy for this registry, using terms defined in [RFC8126], is: +====================+===============================+ | Range | Registration Policy | +====================+===============================+ | 0 | Reserved for the "Any Group" | +--------------------+-------------------------------+ | 1-127 | Private Use | +--------------------+-------------------------------+ | 128-255 | Standards Action | +--------------------+-------------------------------+ | 0x0100-0x7FFF | Private Use | +--------------------+-------------------------------+ | 0x8000-0xFFFF | Specification Required | +--------------------+-------------------------------+ | 0x10000-0xFFFFFFFF | Private Use | +--------------------+-------------------------------+ | >=0x100000000 | Reserved for future expansion | +--------------------+-------------------------------+ Table 2: Bundle Protocol Well-Known Group Number registration policies Each entry in this registry represents a group number. This group number MUST still hold value across all different Allocator, not only on the Default Allocator. Cavallini & Flentge Expires 19 March 2026 [Page 9] Internet-Draft iac September 2025 It is expected that each identified organization publishes some listing of allocated group numbers - the pointer to which is listed in the "Reference" field of the registry. The initial values for the registry are: +======+=================+===========================+ | Name | Description | Reference | +======+=================+===========================+ | 0 | The "Any" Group | [[this RFC]](Section 2.4) | +------+-----------------+---------------------------+ Table 3: Bundle Protocol Well-Known Group Number initial values 4. CBOR Representation of iac URIs with BPv7 Section 4.2.5.1 of [RFC9171] 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)[RFC8949]. To meet this requirement, this section describes the CBOR encoding and decoding approach for iac EIDs. Even if the uri-code of iac scheme is TBD1 (to be defined), for just example purposes, the document will use the unsigned int value (3) as the uri-code for the iac scheme, any other value that will be allocated by IANA will still output the same CBOR structures 4.1. iac EID CBOR encoding This scheme was specifically designed to enable compact representation and efficient processing, and its encoding methods preserve these goals. As defined in [RFC9171], iac EIDs consist of a sequence of numeric identifiers. In textual form, these identifiers are separated by periods (.). In CBOR, this sequence can be naturally represented as an array. Therefore, when encoding iac EIDs for Bundle Protocol Version 7 (BPv7), the scheme-specific part of the URI MUST be a CBOR array containing three elements. Each element MUST be a CBOR unsigned integer. The details of the encoding are described below. Cavallini & Flentge Expires 19 March 2026 [Page 10] Internet-Draft iac September 2025 4.1.1. iac scheme-specific Encoding In the three-element scheme-specific encoding of an ipn EID, the first element of the array is the Allocator identifer (Section 2.3), the second is the iac Group Number (Section 2.4), and the third element of the array is the iac (same as ipn scheme) Service Number (Section 2.5). For example, the iac EID of iac:2.14.1 would be encoded in CBOR as the following 6-octet sequence: 82 # 2-Element Endpoint Encoding 03 # uri-code: 3 ('iac' URI scheme) 83 # 3-Element iac EID encoding 02 # allocator-identifier 0E # group-number 01 # service-number 4.1.2. 'iac' URI Scheme CBOR Syntax When encoded in CBOR [RFC8949], a BPv7 endpoint identified by an iac URI MUST comply with the following Concise Data Definition Language (CDDL) [RFC8610] specification: eid-structure = [ uri-code: uint, SSP: any ] ; ... Syntax for other uri-code values defined in RFC 9171 ... $eid /= [ uri-code: 3, SSP: iac-ssp3 ] iac-ssp3 = [ allocator-identifier: uint .lt 4294967296, group-number: uint .lt 4294967296, service-number: uint ] 5. List Examples 5.1. iac EID examples iac Complete EID Cavallini & Flentge Expires 19 March 2026 [Page 11] Internet-Draft iac September 2025 (a) iac:2.4.22 iac EID with the "Any Group", with this syntax any "next iac hop" can be specified (a) iac:0.0.3 iac any administrative endpoint special case (a) iac:0.0.0 (b) iac:0.4.0 6. Security Considerations This document should not affect the security of the Internet. Route Manipulation: In a DTN anycast environment, BP nodes may opportunistically advertise their availability to receive bundles addressed to a shared anycast identifier. This dynamic and decentralized behavior introduces the risk of route manipulation, wherein a malicious or compromised node could falsely present itself as the optimal or nearest anycast recipient. Such unauthorized advertisements could lead to traffic interception, blackholing, or intentional delay of bundle delivery, thereby undermining the reliability and integrity of the communication system. To mitigate these risks, it is essential to employ robust cryptographic mechanisms that authenticate node identities and verify routing advertisements, such as the Bundle Protocol Security. Impersonation: In a DTN anycast environment, where multiple nodes share a common service identifier, the lack of strong endpoint authentication creates a significant risk of impersonation and spoofing. A malicious actor could masquerade as a legitimate anycast group member and accept bundles intended for trusted nodes, potentially leading to unauthorized data access, manipulation, or service disruption. This threat is amplified in intermittently connected or low-trust environments—such as military or remote sensing networks—where verifying node authenticity in real time may be infeasible. To counter this, it is critical to implement robust authentication mechanisms for both endpoints and transmitted bundles, leveraging cryptographic signatures and identity verification protocols provided by DTN security extensions like BPSec. Traffic Stealing: Unlike multicast (but like unicast), anycast allows traffic stealing. With multicast, joining a multicast group doesn't prevent anyone else who was receiving the traffic from continuing to receive the traffic. With anycast, adding an anycasted node to the Cavallini & Flentge Expires 19 March 2026 [Page 12] Internet-Draft iac September 2025 routing system can prevent a previous recipient from continuing to receive traffic because it may now be delivered to the new node instead. As such, if an unauthorized anycast node can inject a route into the network traffic can be diverted thereby triggering DoS or other attacks. 7. References 7.1. Nominative References [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [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, . [RFC9171] Burleigh, S., Ed., Fall, K., and E. J. Birrane, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9758] Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025, . [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, . [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, DOI 10.17487/RFC4395, February 2006, . Cavallini & Flentge Expires 19 March 2026 [Page 13] Internet-Draft iac September 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References Appendix A. iac EID CBOR decoding An iac EID CBOR decoder can reconstruct an ipn EID using the following logic. In this description, the term enc_eid refers to the CBOR-encoded iac EID, and the term iac_eid refers to the decoded ipn EID. iac_eid.allocator_identifier := enc_eid[0]; iac_eid.node_number := enc_eid[1]; iac_eid.service_number := enc_eid[2]; Acknowledgements Special thanks to Scott, Rick et al. The design and specifications of the anycast naming scheme were notably influenced and inspired by the foundational work on the imc naming scheme created by Scott et al. and the ipn scheme and subsequent updates by Rick et al. Contributors Thanks to all of the contributors. Authors' Addresses Danilo Cavallini European Space Operations Centre (ESOC) Via Tranquillo Cremona 6 40137 Bologna Emilia-Romagna Italy Phone: +393428851345 Email: danilo.cavallini.01@gmail.com Felix Flentge European Space Operations Centre (ESOC) Germany Phone: +496151904075 Email: Felix.Flentge@esa.int Cavallini & Flentge Expires 19 March 2026 [Page 14]