| Internet-Draft | Address Space for Space | May 2026 |
| Kumari & Linkova | Expires 24 November 2026 | [Page] |
{Editor note (To be removed before publication): The high-level summary of this document is that the IANA allocates a block of IPv6 address space specifically for use in space environments.¶
IP communication in space environments is fundamentally different from terrestrial communication; e.g., the speed-of-light RTT from Earth to Mars ranges from ~6 minutes to ~45 minutes, which means that traditional connections (e.g Telnet over TCP) won't work. For an IP stack to know that a connection will require special handling (e.g. adjusting timers, or using different protocols), it needs to know that the latency to the remote peer is going to be significantly higher than typical terrestrial latencies. By allocating a specific block of IPv6 address space for use in space environments, IP stacks can easily identify when they are communicating with a peer in space, and adjust their behavior accordingly.¶
This document requests that the IANA allocate a block of IPv6 address space specifically for use in space environments and then delegate from that block to the existing RIRs. The RIRs can then set policies for address allocation and assignment within the space address block and make address allocations to their members from this block.¶
This approach leverages the existing RIR systems, including their policy development processes, governance structures, and existing relationships with their members. This includes relationships with governments within their regions, thus bypassing many of the geopolitical issues, including dealing with sanctioned countries, etc. The only real change is that the RIRs would be allocating from a different block of addresses, and setting policies for that block; the overall process would be the same as it is today. This is a much simpler and more efficient approach than creating a new registry for space use, or having a single RIR manage the entire space address block, along with all of the geo-political issues that would entail.¶
WK: This editor note seems to actually be most of the document... :-) }¶
IP communication in space environments is fundamentally different from terrestrial communication; a primary difference is the likelihood of long round-trip times, potentially minutes or even hours, depending on the distance between the endpoints.¶
Existing protocols are not designed for such environments and so may not work as expected. For example, TCP connections will fail due to timeouts unless IP stacks know that the remote peer is in space, and adjust their behavior accordingly.¶
This document requests that the IANA allocate a block of IPv6 address space specifically for use in space environments, and then delegate from that block to Regional Internet Registries (RIRs) for space use.¶
The RIRs can then set policies for address allocation and assignment within the space address block, and make address allocations to their members from this block.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kumari-tiptop-address-space/.¶
Discussion of this document takes place on the WG Working Group mailing list (mailto:deepspace@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/deepspace/. Subscribe at https://www.ietf.org/mailman/listinfo/deepspace/.¶
Source for this draft and an issue tracker can be found at https://github.com/wkumari/draft-kumari-tiptop-address-space.¶
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 24 November 2026.¶
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.¶
In order to allow IP stacks to easily identify when they are communicating with a peer in space, this document requests that the IANA allocate a block of IPv6 address space specifically for use in space environments.¶
The IANA will delegate from this block to Regional Internet Registries (RIRs) the task of making specific address allocations for space use to network service providers and other subregional registries.¶
The RIRs will then be responsible for setting policies for address allocation and assignment within the space address block, and for making specific address allocations to network service providers and other subregional registries.¶
Individuals and organizations may obtain address allocations for space use directly from their appropriate RIR (or other) registry, or from their service provider.¶
{Ed note: The text below is adapted from [RFC1881]. } Delegation of address space by the IANA is not irrevocable. If, in the judgment of the IANA, a registry has seriously mishandled the address space delegated to it, the IANA may revoke the delegation, with due notice and with due consideration of the operational implications. IANA will make every effort in such a case not to revoke addresses that are in active use, unless there are overwhelming technical reasons for doing so.¶
The definition of what constitutes "space use", the size of the block to be allocated, and the policies for address allocation and assignment within the space address block are outside the scope of this document, and are left to the RIRs to determine. The RIRs are already responsible for setting policies for address allocation and assignment within the existing IPv6 address space, and so are well placed to set policies for the new space address block as well.¶
There are two primary approaches possible for how the IANA can delegate address space for space use to the RIRs. {Ed note: The authors prefer the first approach, as it is simpler and more efficient, but it does result in probably 2-5 prefixes per planet. While a single aggregate per planet would be nice, 5ish doesn't seem overly difficult to manage. Which approach to choose is of course up to the WG / IESG, probably with input from the IANA as to complexity, etc.}:¶
The IANA can delegate a single large block for space use, and RIRs can request large blocks from that block as needed. The RIRs can then designate sub-blocks for different planetary bodies and allocate from those sub-blocks as needed. This does mean that there will be more than one prefix per planet - probably up to five (the number of RIRs). If an RIR were to exhaust their allocation for a particular planet, they could request more from the IANA, or recarve their existing allocations, but this seems unlikely given the size of the block that would be allocated.¶
The IANA can delegate a separate block for each planetary body, and then delegate from those blocks to the RIRs as needed. This would mean that there would be a single prefix per planet, which may be desirable for operational reasons, but it does mean that the IANA would need to make multiple delegations, the RIRs would need to manage multiple blocks, and the address allocation would be significantly less efficient, as each block would need to be large enough to accommodate the future needs of all RIRs for that planet, which may be difficult to predict.¶
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.¶
TODO Security¶
This entire document is an IANA considerations document.¶
The IANA is requested to delegate a block of IPv6 address space specifically for use in space environments, and then allocate from that block to RIRs for space use.¶
{Ed note: This document does not specify the size of the block to be delegated for space use, nor what size blocks to delegate to each RIR as needed - this is left to the IANA to determine. The authors (and WG) will be happy to provide input on this if the IANA would like, but ultimately this is a matter for the IANA to decide.}¶
The authors would like to thank the members of the TIPTOP working group for their feedback and suggestions on this document, and for their work on the broader topic of IP communication in space environments. In addition, the authors would sincerely like to thank Kim Davies, John Curran and Geoff Huston for helping us understand the history, complexity and sensitivities around IP address governance. In addition, we would like to thank the members of the RIPE Address Policy Working Group for their feedback and suggestions on this topic. One of the authors (Warren) has an awful memory for names and faces, and is embarrassed that he can't remember who all he spoke to about this topic, but he is grateful to everyone who provided feedback and suggestions - please drop me a note and I'll be happy to add you to this list.¶