| Internet-Draft | Deep Space Celestial Registry | August 2026 |
| Acosta | Expires 28 February 2027 | [Page] |
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.¶
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 28 February 2027.¶
Copyright (c) 2026 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.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document introduces and utilizes the following terms:¶
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).¶
New allocations or changes to the registry will follow the "Expert Review" or "Specification Required" policies defined in [RFC8126]. 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.¶
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 [RFC8126]. 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.¶
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.¶