]> Asteroid International B.V.

Netherlands remco@asteroidhq.com

INT Internet Area Working Group space addressing numbering registry deep space Ongoing IETF work on networking in non-terrestrial and deep-space environments treats addressing, numbering, and registry policy as a greenfield. It is not. Three decades of operational practice, registry governance, and routing security infrastructure exist, and any space-segment architecture that ignores them will recreate, badly, the coordination mechanisms the Internet already has. This document describes the problem and motivates chartering a working group to address it.

Introduction Current work on IP connectivity for cislunar, interplanetary, and other space environments focuses on transport behaviour under extreme delay and disruption, building on the Bundle Protocol and related work. That work is necessary. It is not, however, sufficient: it proceeds on an implicit assumption that number resources used in space segments are unconstrained by the existing addressing architecture, the registry system , or routing security infrastructure . This assumption, referred to here as the planetary locality assumption, holds that address uniqueness, registration, and attribution are properties of terrestrial networking that need not extend beyond it. This document argues the opposite: the properties that made the Internet a single interoperable system are exactly the properties that must be preserved as it extends off-planet.

What Three Decades of Numbers Policy Actually Provides

Global uniqueness:

IANA and the five RIRs provide a single, hierarchical, collision-free delegation system for IPv4, IPv6, and AS numbers . Uniqueness is not a convenience; it is the precondition for a single routing system.

Registration and attribution:

Public registries bind number resources to responsible operators, enabling operational contact, abuse handling, and legal accountability.

Aggregation and routing scalability:

Allocation policy is deliberately structured to keep the global routing table tractable .

Routing security:

The RPKI binds resources to holders cryptographically; route origin validation deployment is now operationally significant. None of this infrastructure assumes low latency, but all of it assumes a single, coherent resource hierarchy.

A functioning policy development process:

Bottom-up, community-driven policy development processes at the RIRs have absorbed IPv4 runout, transfers, inter-RIR movement, and repeated governance challenges.

The Gap Space networking work to date exhibits the following gaps:

No registration model:

No defined mechanism exists for how number resources used on space segments are delegated, registered, or attributed within (or alongside) the existing IANA/RIR hierarchy.

Implicit parallel registries:

Mission-specific or agency-specific address plans risk hardening into de facto parallel registries with no uniqueness guarantee against the terrestrial Internet.

Squat-space temptation:

Reserved and special-use space (e.g. 240/4, ULA-style constructs) is an obvious and dangerous shortcut; history shows such usage leaks.

Routing security discontinuity:

No consideration exists of how RPKI object lifetimes, publication, and validation behave across delay/disruption-dominated paths, nor of who is authoritative for space-segment resources.

Address space fragmentation:

Per-mission and per-agency address plans, assigned without a common delegation structure, fragment the address space and destroy aggregation before a space-segment routing table even exists. Terrestrial experience shows fragmentation is effectively irreversible once deployed.

Traffic tromboning:

Architectures that implicitly treat Earth as the default interconnection point force space-to-space traffic through terrestrial gateways. At interplanetary distances a tromboned path is not an inefficiency measured in milliseconds but in tens of minutes per detour, and in some geometries in availability itself.

Geopolitical partition risk:

Gateways, relays, and ground segments are owned by national agencies and jurisdictionally bound operators. Sanctions regimes, export controls, and national security law will apply to non-terrestrial internetworking exactly as they do terrestrially. An architecture with no neutral interconnection model and no jurisdiction-aware routing policy framework will be partitioned by treaty and statute rather than by engineering.

Mobility of non-fixed platforms:

Spacecraft on transfer trajectories, and any platform not in a fixed solar orbit, present addressing and routing problems current work does not touch: topological adjacency changes continuously, relative velocity constrains contact windows and link scheduling, and binding addresses to orbital position repeats, at solar-system scale, the locator/identifier conflation the Internet has struggled with for decades.

High-churn resource lifecycles:

Extraction and survey operations (asteroid mining, transient platforms) require dynamic assignment models with lifecycles measured in mission phases. Current registration practice assumes decadal stability; assignment, mobility, and return must become routine operations, not exceptions.

Infrastructure-less peering:

Absent a fixed backbone, connectivity is peer-to-peer by physics: any-to-any, intermittent, opportunistic adjacency. Requirements for mutual transit and peering without fixed interconnection points, or settlement frameworks that assume them, are undefined.

No interconnection architecture:

Gravitationally stable locations (Lagrange points, notably Sun-Earth and Earth-Moon L4/L5) are the natural interconnection hubs of a solar-system topology: the IXPs of space. No work exists on how such hubs are numbered, registered, operated, or kept jurisdictionally neutral -- the precise questions terrestrial interconnection spent thirty years answering.

Terra-rooted hierarchy:

The delegation hierarchy is operationally rooted on Earth. That is an accident of history, not an architectural requirement. A design that structurally encodes Earth -- or, one level up, Sol -- as the permanent root of addressing and routing repeats the planetary locality assumption at larger scale. The hierarchy must be relocatable and partition-tolerant by design, so that the architecture outlives the primacy of its birthplace.

Governance capture risk:

In the absence of IETF/RIR-anchored work, addressing and numbering for space segments will be defined elsewhere -- by treaty bodies, national agencies, or single vendors -- outside the open, bottom-up processes that built the Internet.

Why This Belongs in the IETF The IETF defines the addressing architecture; IANA and the RIRs operate the registry function under community-set policy. Extending that architecture across space ecosystems is a technical-framework question (IETF), which then enables policy work in the appropriate registry communities. Neither can proceed sanely without the other, and neither is served by transport-focused work silently making architectural addressing decisions as a side effect.

Requirements for a Solution A chartered effort should:

1. Document the applicability of the existing addressing and numbering architecture (IPv6 in particular) to space segments.
2. Define requirements for registration, uniqueness, and attribution of number resources used off-planet, within the existing hierarchy.
3. Analyse RPKI and routing-security behaviour under delay/disruption-dominated conditions.
4. Define an addressing and routing model for non-fixed platforms (spacecraft, transfer trajectories), including locator/identifier separation where warranted, that preserves aggregation and avoids per-mission fragmentation.
5. Specify requirements that space-to-space traffic not be forced through terrestrial gateways (anti-tromboning), and describe an interconnection architecture for gravitationally stable hub locations, including registration and neutrality models.
6. Document the interaction of jurisdiction and routing policy on non-terrestrial segments, so that partition risk is an engineered property rather than an accident.
7. Provide guidance to IANA and the RIR communities sufficient for them to conduct policy development, without the IETF doing that policy development itself.
8. Establish liaison with relevant bodies (CCSDS, space agencies) so that architectural coherence survives contact with mission engineering.

Long-Horizon Considerations This section is informative. Two considerations exceed any near-term charter but constrain architectural choices made now:

Consensus under delay:

Mechanisms that assume interactive agreement -- routing convergence, RPKI publication and validation, distributed databases, and ultimately the standards and policy processes themselves -- degrade as one-way delay grows from minutes toward years. Documents produced under this effort should state their delay envelope explicitly, so that a mechanism sound at light-minutes is not silently assumed sound at light-years.

Propagation scoping:

Unbounded announcement is disclosure. Discovery, beaconing, and routing announcements reveal the existence, position, and capability of the announcer. Terrestrially this is a privacy concern; at astronomical scale it becomes a strategic one. The architecture should default to scoped propagation rather than default-flood, making the reach of any announcement an explicit, bounded decision.

Mechanisms in this framework assume causal packet ordering. Deployments involving superluminal transport are out of scope and, per current physics, expected to remain so.

Security Considerations Fragmenting the number resource hierarchy fragments routing security. A parallel or unregistered space-segment numbering system is unattributable, unverifiable, and unfilterable -- properties attackers value considerably more than mission planners do. Additionally, routing and discovery announcements constitute existence disclosure. Architectures with unbounded propagation leak topology, position, and capability to any listener within reach; propagation scope should therefore be treated as a security parameter, not an implementation detail.

IANA Considerations This document makes no requests of IANA, which is precisely the point: future documents should make well-formed ones.

Informative References This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.

Acknowledgements TODO acknowledge.