<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.42 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-acosta-deepspace-celestial-bodies-registry-01" category="info" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="Deep Space Celestial Registry">Defining a Celestial Bodies Registry for Deep Space Internet Addressing</title>
    <seriesInfo name="Internet-Draft" value="draft-acosta-deepspace-celestial-bodies-registry-01"/>
    <author initials="A." surname="Acosta" fullname="Alejandro Acosta">
      <organization>LACNIC</organization>
      <address>
        <email>alejandro@lacnic.net</email>
      </address>
    </author>
    <date year="2026" month="August" day="27"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>celestial</keyword>
    <keyword>registry</keyword>
    <keyword>deepspace</keyword>
    <keyword>addressing</keyword>
    <abstract>
      <?line 21?>

<t>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.</t>
    </abstract>
  </front>
  <middle>
    <?line 25?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>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).</t>
      <t>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.</t>
      <t>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.</t>
    </section>
    <section anchor="requirements-language">
      <name>Requirements Language</name>
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This document introduces and utilizes the following terms:</t>
      <ul spacing="normal">
        <li>
          <t><strong>CBID</strong>: Celestial Body Identifier. A unique numeric or alphanumeric token assigned to a celestial entity.</t>
        </li>
        <li>
          <t><strong>IAU</strong>: International Astronomical Union.</t>
        </li>
        <li>
          <t><strong>IANA</strong>: Internet Assigned Numbers Authority.</t>
        </li>
      </ul>
    </section>
    <section anchor="core-proposal">
      <name>Core Proposal</name>
      <section anchor="registry-structure">
        <name>Registry Structure</name>
        <t>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).</t>
        <t>Each entry in the registry MUST contain the following fields:</t>
        <ul spacing="normal">
          <li>
            <t><strong>Celestial Body Identifier (CBID)</strong>: A unique numeric or alphanumeric code assigned to the body (e.g., 001 for Earth, 002 for Moon, 004 for Mars).</t>
          </li>
          <li>
            <t><strong>Official IAU Name</strong>: The standardized name approved by the IAU.</t>
          </li>
          <li>
            <t><strong>Body Type</strong>: The classification of the entity (e.g., Planet, Natural Satellite, Dwarf Planet, Asteroid).</t>
          </li>
          <li>
            <t><strong>Parent Body</strong>: The identifier of the primary body it orbits (if applicable, to allow hierarchical network topology mapping).</t>
          </li>
        </ul>
      </section>
      <section anchor="registration-policy">
        <name>Registration Policy</name>
        <t>New allocations or changes to the registry will follow the "Expert Review" or "Specification Required" policies defined in <xref target="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.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>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.</t>
      <t>The initial policy for creating or modifying entries in this registry SHALL be "Expert Review" as defined in Section 4.5 of <xref target="RFC8126"/>. The designated expert SHOULD consult with relevant working groups of the International Astronomical Union (IAU) before approving allocations.</t>
      <t>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.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author fullname="M. Cotton" initials="M." surname="Cotton"/>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <author fullname="T. Narten" initials="T." surname="Narten"/>
          <date month="June" year="2017"/>
          <abstract>
            <t>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).</t>
            <t>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.</t>
            <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="26"/>
        <seriesInfo name="RFC" value="8126"/>
        <seriesInfo name="DOI" value="10.17487/RFC8126"/>
      </reference>
    </references>
    <?line 80?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VYTXPbOBK981dglUviklS2N5uZ0WkV25moyl9r2TW1tbUH
iIQoxCTBAUDJmlT++75ugB+ynczswWVRAoHu169fd2MymSRe+0LNxLla60pX
uZDiTBXKeS0L8dFkWjlxp3LtvN2LtbFYqGqxrGWqxKLyylbKi3mWWeUcXk/k
amXVdjZc1u/XbpRkJq1kiWMzK9d+IlPjvJxkeMfRK5O0fWWyYhMmNr45OT5J
Munx5unx6YfJ8c+T05+SFF/kxu5nQldrk7hmVWpYY6r7fY2Vi4v7TwleVrKM
D7q2M+Ft4/zp8fEvx6eJxI8z8auqlJVFsjP2MbemqWe9ixdVriulLEF0L92j
+GRsqpJHtcfqbCb+M+psHo3FqLWXPndu0YPsoBr9N0lk4zfGzhIhJvgTsN/N
xHwq5gwIfxVwmhfqi6wya4Y/GZvLSv8hPVydicv52fXijH9QpdTFTMj2pX8W
Mq10OoUjSTKZTIRcwTiZ4ul+o51AOJpSVV7U1tTGIeR+o0QKUGhrYdZgBWJf
ykL/oTJhh3zo3BYhVGKn/UZXvENPEHicV3j1uilXyjoxZ8e134u3i/n1/J3w
Rrimro31Ash7ZmKViQgXXClMGqzB3oSoYEgFdqdwOWDm8FM8T9p0o71KfWOV
UE81tnJ0BC+oC4k1Eva7FBC5cXci3PcmNYWDi8Ve4LCNBiNoM6wUMs/herBi
JR3cwYd+N7K3RwNwag88puKz2amtsuMACfgn0sZa/I4jEJhHeCcQ0iqTNmN8
vXwylSn5zLVF/MlDRFuUsq7JzlKlG0TeleRTU+nfGzJXZ3Tmek/nODUw4DDG
8LUAlUOMrfq90VbRD47DCevlqtBuQ+e4Jt3AuDbeY3yR51jhREEeyZwWZawc
BAp2sKYcRJ6hghNzvN159FARfgj7w7sxY5ZplzauZR2FKLcd8YIv0TVN1MEC
wysHLOgoM4j7NFC91FlWqCR5QzZZkzUpbZ0kdyolNNQaXnvatQvPOPod7Dmg
UmtqNmT5QOp+Q6DIjl9JPcZiI7cKFMo3Bf48RXZDjE1JAEB9yqtM1mx5R92e
gxSOZ4RNTVki3iETpuK8USKCsZXOk3ngEbZnXAMx8E5Fya4pwjjxZe7g+DHh
oFNNiLRYRmq4wxxY3PY5OUgHwlJZeCjx+kEemNUXgOfEWzXNp+OYLsi50sAu
EMDhPaMz924qkuS3jS5Umx6hOLhWlGB5wcdRnKMJwY8uFwNZXuYgpx7ChzSo
DPQAMNEunIsAmRSoy0AClCmtxiIWFiTlmNa5PYwtYQGAoHyrMvUkdhvpA8ba
N56gRywKnYlRHzYo435EO4ye4zLiKPeBEHVjWYGnKJbFnr6BXzKbbExKpYC/
sEB5pRFTbD3MPqsdxCSVjeP4xThCQXLK7xAoIgaTytSI6koXRERUy4YsT60B
qGVTeD2RuarSfUQ41lOHnLo3YIYzBZjtSVeQGpuKqZHLehy+e72edNISZAjk
pwwn2hGvKAbf7Tym4lNjKYalsYiF9uQDJzMD3oskggfw8yrEdoDrgdBR8obk
HgpTywDXWwparfb/l6AhjxBWvSVBdspuma2Uj2K0WN6Iv598+CDIFHAEpoTw
D1Ly1Qo2JfW6GzpwKau8QYSofiuBJkRQF+LE6OpheU9tBv0X1zf8+e7iXw+L
u4tz+rz8PL+87D60K5afbx4uz/tP/ZtnN1dXF9fn4WV8K559dTX/9yio+Ojm
9n5xcz2/HAUtHdIA7RVFZhX9q60iMQQsmXKp1StFnBQfz27FyXvx9evf7j6d
nZ6c/PLtW3z4+eSn93jYbVQVDjMV4A2PCA5Kb10rSWpJjQIyoNZeFqwuwm3M
DnVcRRjvwSFdmcLk++fNz5BSJJ9eU7sTuLs2aEB2FEzYX7pZkhyJo6Ozj4vz
o6PZIW/3YtFVK3QlrQxXOMTqlLO3qFG+47M3jwpmtw0SEfi5gu2nfBoIRof9
GRPbxdfzfvUPWzDG5QyJJW45XdEBJ2/e9F3/Ep0y8zCw7ceZKgKxiPqKiS9I
jAokrYznScoO4UyD/pkrvMUPXWvzsnB0LU6bzsNuAM2NwbsIHf5eChsneqf3
+gC513N/HNui6M1Og09uX6UbrAUbID2u7c/2vY78NXUA0BcSnQWst/u24+iO
4pRFIWFPDjkHV4usI933yCbeEh/fUdT/lHWpydQB6ehAKlNtnT4+PmFtupDQ
XXo85ccrVG16eh+epEXdZqtueiF/ENeQYzKD6HLQ2dIwQ8lqzXYgrfOHsAf7
QzNb+25akInr2O/EdjDmRGvoLVfZMc4ERXH+EjW7QPDBuPOdtOtuwTx2GtHg
W8k9Bp3ZHtfzqj2qtrpsCzhVHUN1F72MXpMXBQxbEbW56iBWh61SS1ePpCK9
aTlOPOjzK7h2a7AZFOla7QazjqO4UaufK9cG6ZCagSP8w+jiCcz32Her1S60
G8tapT1+sYRkI1HTcZS2odNh+W2l9vTDt29TxgPmGsqZjEYo2pqPTA1KjQbZ
VeA/Bbytsjw1s6mqctQwe+qOZLUHGLuAYkc62QGEerDWT+iWHUoExDCMmlB4
q1KTV8wcPZy0HHWqaRD0IEfACtELYLrnwk61n6cWXkvGtfWdjdj1mPJlSGjT
R9+VuFFA5zAQqG2tDClqvWFM3JyGqlaB2psKmi+lD5n32oUKyIlM8SRwQXS5
x4MpHLg4ePN4HvrBEhauuVskbSFj2xpsD3V59ZIn8oAFS8XzkXg//Qclwdev
zziBio3wyQEpYstALTAax8AJuKe2EtA/I0ZMq78mlzB2TVUp6AU3Un1mRFye
CbXn9WGmBF2CvgT1fN3Jk2DSgC0/qOZRYMfihdiNRaddoUEZqAuzFCc2fN3x
kqnqB8WUy6hrR9E1jVYtal0RIi4cXlO8Mp8dXprE0WDK1lBy0F3EmGtbGL/D
UACKaR52Wu2htAmFFag9G027i5gkuZKkLqah3b4EqKGRsqz5+iyMUrUxayYv
JlLpZT9PDzmbmqbIRKEkJ4qjO4d+1sdMAs6tdd5EMMfd6MM7wtNHTJrEWM+B
J6BMpaKOhLShoZEb0xXdxGwMZT/9oB0dE/sxgi81mElT/7I1E0u6LFhLXTQ2
5N0AaFVtNbgdmnbqgvkyYN8Dm4UJXj15au0FiQJNXcOZnehU6FJ7vnlLUTmZ
7lVmdgT2oqwL1c13Lrat3KkeYMntxVCV+QqFgOJVpBpblj44nm9g4b72Jrey
3sRx1xGFSbfpWg4tG/mfshBQhaoU9dvtxcn59XJ5ccaBDmLPytvZQvcUaPub
kMl9csQ5lFhLJSZnG7mfi6RvnHr9UijSx8V698qNHqGPLyn5ApdTbPwi+9m7
snGeOBETqe9U+t3wVDqFIdjFa6YV6JMkyf8ALT1Q/1IXAAA=

-->

</rfc>
