Address Space for Space
draft-kumari-tiptop-address-space-00

TIPTOP                                                         W. Kumari
Internet-Draft                                              Google, Inc.
Intended status: Informational                                J. Linkova
Expires: 24 November 2026                                    Google, LLC
                                                             23 May 2026

                        Address Space for Space
                  draft-kumari-tiptop-address-space-00

Abstract

   {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... :-)
   }

Kumari & Linkova        Expires 24 November 2026                [Page 1]
Internet-Draft           Address Space for Space                May 2026

   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.

About This Document

   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.

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/.

Kumari & Linkova        Expires 24 November 2026                [Page 2]
Internet-Draft           Address Space for Space                May 2026

   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 Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   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.

Kumari & Linkova        Expires 24 November 2026                [Page 3]
Internet-Draft           Address Space for Space                May 2026

   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.}:

   1.  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.

   2.  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

Kumari & Linkova        Expires 24 November 2026                [Page 4]
Internet-Draft           Address Space for Space                May 2026

       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.

2.  Conventions and Definitions

   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.

3.  Security Considerations

   TODO Security

4.  IANA Considerations

   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.}

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

5.2.  Informative References

Kumari & Linkova        Expires 24 November 2026                [Page 5]
Internet-Draft           Address Space for Space                May 2026

   [RFC1881]  IAB and IESG, "IPv6 Address Allocation Management",
              RFC 1881, DOI 10.17487/RFC1881, December 1995,
              <https://www.rfc-editor.org/rfc/rfc1881>.

Acknowledgments

   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.

Authors' Addresses

   W. Kumari
   Google, Inc.
   Email: warren@kumari.net

   Jen Linkova
   Google, LLC
   Email: furry13@gmail.com

Kumari & Linkova        Expires 24 November 2026                [Page 6]