Internet-Draft iac September 2025
Cavallini & Flentge Expires 19 March 2026 [Page]
Workgroup:
Internet Engineering Task Force
rfc:
draft-cavallini-dtn-iac-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Cavallini
European Space Operations Centre (ESOC)
F. Flentge
European Space Operations Centre (ESOC)

DTN Interplanetary Anycast Scheme

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.

▲

Table of Contents

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:

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

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.

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

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.

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.

Table 1: CBOR Tag Values for EID Schemes
Value Description ... EID Pattern Reference
TBD1 iac Section 2.2 of this Document

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:

Table 2: 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:

Table 3: Bundle Protocol Well-Known Group Number initial values
Name Description Reference
0 The "Any" Group [[this RFC]](Section 2.4)

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.

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

(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 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, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/info/rfc5234>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.
[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, , <https://www.rfc-editor.org/info/rfc8610>.
[RFC9171]
Burleigh, S., Ed., Fall, K., and E. J. Birrane, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, , <https://www.rfc-editor.org/info/rfc9171>.
[RFC9758]
Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, , <https://www.rfc-editor.org/info/rfc9758>.
[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, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC4395]
Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, DOI 10.17487/RFC4395, , <https://www.rfc-editor.org/info/rfc4395>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

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
Felix Flentge
European Space Operations Centre (ESOC)
Germany
Phone: +496151904075