]> Deepspace Registry Project

alejandro@lacnic.net

General Internet Engineering Task Force celestial registry deepspace addressing This document proposes the creation of a formalized registry for celestial bodies within the Internet Assigned Numbers Authority (IANA) to support routing and address allocation in deep space networks. As internet architecture expands to interplanetary scales, routing protocols rely on hierarchical aggregation based on planetary and celestial entities. However, the IETF currently lacks a standardized taxonomical framework or mapping mechanism to uniquely identify these entities. This document outlines the requirements for establishing such a registry, suggests leveraging definitions from the International Astronomical Union (IAU), and discusses the integration of these identifiers into the deep space routing architecture.

Introduction Recent efforts in the IETF, such as the architecture discussed within the Deep Space Working Group, have highlighted the necessity of adapting internet protocols for interplanetary communication. Due to the vast distances and unique constraints of deep space networking, efficient routing requires hierarchical IP address aggregation centered around celestial objects (e.g., planets, moons, asteroids). While current drafts propose delegating address space based on these celestial entities, there is no existing IETF or IANA standard to define, categorize, or systematically index what constitutes a valid "planetary body" or "celestial object" for networking purposes. Relying on ad-hoc naming or arbitrary definitions risks causing routing fragmentation and interoperability issues across multi-agency space missions. To resolve this technical gap, this document proposes the establishment of an official IANA Celestial Bodies Registry. Furthermore, it introduces a framework to align IETF networking requirements with the astronomical standards established by the International Astronomical Union (IAU), effectively serving as an "ISO 3166 equivalent" for deep space internet architecture.

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 BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document introduces and utilizes the following terms:

• CBID: Celestial Body Identifier. A unique numeric or alphanumeric token assigned to a celestial entity.
• IAU: International Astronomical Union.
• IANA: Internet Assigned Numbers Authority.

Core Proposal

Registry Structure The IANA Celestial Bodies Registry SHALL serve as a single, authoritative source of truth mapping celestial objects to unique network identifiers. To maintain interoperability with existing international astronomical standards, the registry will synchronize its taxonomy with the International Astronomical Union (IAU). Each entry in the registry MUST contain the following fields:

• Celestial Body Identifier (CBID): A unique numeric or alphanumeric code assigned to the body (e.g., 001 for Earth, 002 for Moon, 004 for Mars).
• Official IAU Name: The standardized name approved by the IAU.
• Body Type: The classification of the entity (e.g., Planet, Natural Satellite, Dwarf Planet, Asteroid).
• Parent Body: The identifier of the primary body it orbits (if applicable, to allow hierarchical network topology mapping).

Registration Policy New allocations or changes to the registry will follow the "Expert Review" or "Specification Required" policies defined in . The appointed expert will coordinate with IAU working groups to ensure that any new body assigned a network prefix has been formally recognized in planetary science.

IANA Considerations This document requests IANA to establish a new registry titled the "Celestial Bodies Registry". The registry will be maintained under a new or existing category related to Deep Space Internet Parameters. The initial policy for creating or modifying entries in this registry SHALL be "Expert Review" as defined in Section 4.5 of . The designated expert SHOULD consult with relevant working groups of the International Astronomical Union (IAU) before approving allocations. The registry will store and display the fields defined in Section 4.1 of this document: Celestial Body Identifier (CBID), Official IAU Name, Body Type, and Parent Body.

Security Considerations The Celestial Bodies Registry serves as the foundational taxonomy for hierarchical address aggregation in deep space routing. Consequently, its integrity is critical to the stability of interplanetary networks. Malicious injection, tampering, or spoofing of data within this registry could lead to severe routing misconfigurations, causing data packets destined for one planet or moon to be blackholed or misrouted to an incorrect celestial entity. Such failures in deep space environments are highly critical due to extreme latency constraints and limited recovery windows. Implementations utilizing this registry MUST ensure that the data is retrieved through cryptographically secured and authenticated channels, such as DNSSEC or signed IANA registry distributions. Security issues regarding the operational use of these identifiers within specific routing protocols are outside the scope of this document and must be addressed by the protocols themselves.

Normative References 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. 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.