DTN Interplanetary Anycast Scheme
draft-cavallini-dtn-iac-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Danilo Cavallini , Felix Flentge | ||
| Last updated | 2025-09-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cavallini-dtn-iac-00
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:<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.
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,
<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, January 2008,
<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, December 2020,
<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,
June 2019, <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,
January 2022, <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, May 2025,
<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, June 2017,
<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, February 2006,
<https://www.rfc-editor.org/info/rfc4395>.
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,
<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
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]