]> European Space Operations Centre (ESOC)

Via Tranquillo Cremona 6 Bologna Emilia-Romagna 40137 Italy +393428851345 danilo.cavallini.01@gmail.com

European Space Operations Centre (ESOC)

Germany +496151904075 Felix.Flentge@esa.int

General Internet Engineering Task Force Anycast DTN iac RFC BP Bundle Protocol 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

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) , 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 .

iac Design Element

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

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 , in this document explained in () The Group Number is a shared identifier that identifies an iac anycast group, in this document explained in () The Service Number is an identifier to distinguish between resources on a given node; it is the same as the one is , in this document explained in ()

The "iac" Endpoint ID Scheme A BP endpoint identifier (EID) is a Uniform Record Identifier (URI) as defined by . 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 All EIDs identifying iac endpoints MUST conform to the "iac" URI scheme described below. As noted below in (), 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:<allocator-identifier>.<group-number>.<service-number> 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.

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

Allocator Identifier The Allocator Identifier defined in this Document MUST be the exact same one as the one defined in the ipn scheme In the 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 In iac scheme the Allocator Identifier 0 MUST be declared, unlike the ipn scheme , 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

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 , the Well-Known Group Numbers set in this registry MUST be valid for every Allocator, not only the Default one.

Service Number The iac scheme Service Number MUST be the same as the one specified in 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.

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

IANA Consideration

iac URI Scheme Provisional registration (per ) 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 , 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) . Interoperability considerations: as noted above, URIs of the iac scheme are encoded exclusively in US-ASCII characters.

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. 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 to ensure that pattern behavior is consistent across different schemes. CBOR Tag Values for EID Schemes

Value	Description	...	EID Pattern Reference
TBD1	iac		of this Document

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 , is: Bundle Protocol Well-Known Group Number registration policies

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

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. 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: Bundle Protocol Well-Known Group Number initial values

Name	Description	Reference
0	The "Any" Group	[[this RFC]]()

CBOR Representation of iac 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 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

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.

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 (), the second is the iac Group Number (), and the third element of the array is the iac (same as ipn scheme) Service Number (). 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

'iac' URI Scheme CBOR Syntax When encoded in CBOR , a BPv7 endpoint identified by an iac URI MUST comply with the following Concise Data Definition Language (CDDL) 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 ]

List Examples

iac EID examples iac Complete EID

1. iac:2.4.22

iac EID with the "Any Group", with this syntax any "next iac hop" can be specified

1. iac:0.0.3

iac any administrative endpoint special case

1. iac:0.0.0
2. iac:0.4.0

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

References Nominative 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] 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 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. 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. 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 provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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. Informative References

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.