IP Address Space for Outer Space

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 30 May 2025.¶

Copyright Notice

Copyright (c) 2024 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

The exploration of outer space depends heavily upon communications technology and in many cases, uses IP. IP address allocation was formally assigned to Regional Internet Registries (RIRs) by [RFC7020] for each continent, but no provision was made to reserve address space for outer space. As a result, address space for missions to outer space will likely be allocated by the various space agencies on a a per-mission basis, resulting in a haphazard patchwork. As connectivity in outer space improves, this address allocation will prevent effective address aggregation, resulting in inefficient routing for all parties.¶

Historically, addressing in the IPv4 address space prior to the introduction of CIDR was done in a similar manner. This has led to a very large number of unaggregated /24 prefixes distributed globally that is colloquially known as "the swamp". This has contributed to the IPv4 routing table's growth of up to a million prefixes as of this writing. This document proposes avoiding a repeat of this for outer space by having a consistent and aggregatable address allocation plan.¶

2. Efficient Routing

Address aggregation was first documented in [RFC1518]. Aggregation allows the combining of multiple address prefixes that are closely topologically related into a single, less-specific, prefix. Carrying fewer prefixes in the global routing infrastructure to cover the same amount of deployed address space is advantageous because it decreases routing protocol overhead, forwarding table space, and router CPU cycles. All of these resources will be in short supply in outer space, so it benefits everyone to have routing be done efficiently.¶

To understand how to aggregate prefixes in outer space, we need to anticipate what the topology of the networks in space will eventually become. The historical growth of the Internet can help us in this regard. As we can see from today's Internet topology, we have very good connectivity on land on most continents, where links are relatively easily deployed. Continents are inter-connected by far fewer submarine fibers that cover larger distances and are much harder to deploy than land-based fiber. We can generalize this observation and expect to see links where they are easier and cheaper to deploy, with fewer links in expensive, hard-to-deploy situations.¶

In outer space then, we might expect that connectivity in and around celestial bodies will be much more common than links between bodies. Due to this expected topological relationship, and the desire to aggregate around topologically related networks, we should then expect that aggregation will be easiest around celestial bodies.¶

3. Per Body Address Allocation

To enable aggregation around celestial bodies, we would then like to have a prefix per celestial body. The following regions should each receive a prefix:¶

• The moon and its environs¶

• Earth's Lagrange points¶

• The asteroid belt¶

• Each other planet¶

• Other regions not covered by the above¶

4. Administration

Administration of the IP address space for outer space should be done in much the same manner as is being done today by RIRs, according to the priniciples laid out in [RFC8720]. Because the amount of address space needed for outer space is minimal for the immediate future, IANA may choose to delegate address space assignment for outer space to one of the existing RIRs. Creating a separate, new RIR is also acceptable, but would seem to be organizationally less efficient.¶

The RIR for outer space should operate in a manner similar to other RIRs, allocating address space to qualified requests for those operating or with credible, demonstrable near-term plans for operating in Outer Space. The RIR should have a single address space for all of outer space, and from the block allocate smaller blocks for each celestial body. Allocations for each request should come from the relevant block for the celestial body. In the case where there are multiple operators per body, this would then result in a set of prefixes from each operator, all from one common block for the body.¶

5. Security Considerations

This document creates no new security issues.¶

6. IANA Considerations

This document requests that IANA delegate allocation of IP address space for outer space to an existing or new Regional Internet Registry and direct the registry to allocate IP address space for outer space in accordance with this document.¶

Authors' Addresses