



Internet Engineering Task Force                              M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Informational                                   W. Eddy
Expires: 21 January 2026                                     MTI Systems
                                                              M. Eubanks
                                                   Space Initiatives Inc
                                                            20 July 2025


   IP in Deep Space: Key Characteristics, Use Cases and Requirements
                      draft-ietf-tiptop-usecase-00

Abstract

   Deep space communications involve long delays (e.g., Earth to Mars
   has one-way delays 4-24 minutes) and intermittent communications,
   mainly because of orbital dynamics.  The IP protocol stack used on
   the Internet is based on the assumptions of shorter delays and mostly
   uninterrupted communications.  This document describes the key
   characteristics, use cases, and requirements for deep space
   networking, intended to help when profiling IP protocols in such
   environment.

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 21 January 2026.

Copyright Notice

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



Blanchet, et al.         Expires 21 January 2026                [Page 1]

Internet-Draft              IP in Deep Space                   July 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Limitations of this document  . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Document and Discussion Locations . . . . . . . . . . . .   4
   2.  Characteristics . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Common Aspects  . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Moon  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Mars  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.4.  Lagrange Points . . . . . . . . . . . . . . . . . . . . .   9
     2.5.  Cruising Spacecraft . . . . . . . . . . . . . . . . . . .   9
     2.6.  Spacecraft Onboard  . . . . . . . . . . . . . . . . . . .  10
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Store-and-Forward . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Time  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Signaling and Exchanges . . . . . . . . . . . . . . . . .  14
     4.4.  Bandwidth . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.5.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.6.  Addressing and Routing  . . . . . . . . . . . . . . . . .  15
     4.7.  Recovery on Reboot  . . . . . . . . . . . . . . . . . . .  15
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Informative References  . . . . . . . . . . . . . . . . .  16
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Deep space communications involve long delays (e.g., Earth to Mars is
   4-24 minutes one way) and intermittent communications, mainly because
   of orbital dynamics.  Up to now, communications have typically been
   done on a layer-2 point to point basis, in some cases with relays
   operating at layer-2 or below.  Most missions have operated on their
   own, without direct data exchanges between spacecrafts at higher
   layers.

   Use of networking technologies, including IP, has become established
   within space vehicles that have their own onboard networks.  Complex
   human exploration and collaborative science missions are driving



Blanchet, et al.         Expires 21 January 2026                [Page 2]

Internet-Draft              IP in Deep Space                   July 2025


   increased networking between vehicles.  Additionally, there is a
   rising need for interoperability between mission end-users and
   multiple service providers.  As the scale of missions, link
   interconnections, and application interactions grows, it will be
   increasingly important to support standard IP-based network data
   flows.

   This document describes the key characteristics and use cases for
   networking in deep space.  It provides examples taken from the
   current communications facilities to reach the Moon and Mars, as well
   as future plans.  While these examples provide great insight on what
   is possible today, the resulting architecture should also consider
   future possibilities and farther celestial bodies.  For example,
   while the number of relays and orbiters around the Moon and Mars is
   currently limited, it is expected that their number will increase
   significantly, therefore providing improved coverage around those
   celestial bodies, resulting in an impact on communications and
   networking traffic patterns, intermittence and alternate paths.

   Initially the needs considered in this document are to support IP-
   based applications in or between private networks, without assumption
   of reachability to/from the global Internet.  At least initially,
   interplanetary IP networks are likely to be protected from the
   Internet, and vice-versa the Internet is protected from them (since
   they may have unique routing, congestion control, and other
   behaviors).  However, over time it is possible that connectivity to
   the Internet may become available for some mission assets, and
   eventually interplanetary networks could become part of the Internet.

   This work is a followup of an assessment on the use of the IP
   protocol stack in deep space [I-D.many-deepspace-ip-assessment].

1.1.  Limitations of this document

   Communication in deep space is vastly different than on Earth.  This
   document does not describe space communication technologies below IP,
   but only the information relevant from the IP protocol stack
   viewpoint for the purpose of its engineering.  More information is
   available for the Moon [ioagmoon] and Mars [ioagmars].

   Position, Navigation and Timing (PNT) is not directly discussed in
   this memo, but is a vital offering from space network service
   providers, in addition to data communications.  Networking can
   support some of the data exchanges that facilitate PNT services.

   Near Earth orbits, such as Low Earth Orbit (LEO), Medium Earth Orbit
   (MEO), and Geosynchronous Earth Orbit (GEO) communications and
   networking to and from Earth are out of scope for this memo.



Blanchet, et al.         Expires 21 January 2026                [Page 3]

Internet-Draft              IP in Deep Space                   July 2025


   However, given the relatively small distance to the Moon, there are
   possibilities to use spacecraft around Earth or at Lagrange points as
   relays to communicate with lunar assets.  In this context, these
   possibilities are in scope.

1.2.  Terminology

   *  Deep space: while the ITU definition [deepspacewikipedia] of deep
      space is beyond 2 million km, in this document, the Moon and its
      environs are included since networking for this regime bears more
      similarities to other deep space bodies than to terrestrial and
      Earth-orbiting conditions.

   *  Direct-with-Earth (DWE): communications from/to a spacecraft
      directly to/from Earth, without the use of relays.

   *  Moon, Lunar: refers to Earth's Moon.

   *  Deep Space Network (DSN): NASA’s international array of giant
      radio antennas that supports interplanetary spacecraft missions
      [DSN].

   *  LunaNet Service Providers (LNSP): service providers to the lunar
      surface and orbital regions, including private commercial
      operators, as defined in the LunaNet Interoperability
      Specification [lnis].

1.3.  Document and Discussion Locations

   The source of this document is located at
   https://github.com/marcblanchet/draft-tiptop-usecase.  Comments or
   changes are welcomed by filing a PR or an issue against that
   repository.

   This subject should be discussed on the IETF tiptop working group
   mailing list.

2.  Characteristics

   Compared to Internet on Earth, deep space communications and
   networking have multiple challenges, such as:

   *  Significant and variable delays (e.g. round trips of multiple
      seconds, minutes, or hours).

   *  Frequent and long interruptions of communications, often with no
      alternate path.  Because of orbital dynamics, a spacecraft may not
      be reachable from Earth because it is occluded by a celestial



Blanchet, et al.         Expires 21 January 2026                [Page 4]

Internet-Draft              IP in Deep Space                   July 2025


      body.  However, spacecraft location and reachability can be
      generally precalculated so that the communication windows can be
      planned between pairs of spacecraft or between a spacecraft and a
      celestial body such as Earth, Moon or Mars.

   *  Lower bandwidth, sometimes even measured in "bits per second"
      rather than typical terrestrial Mbps and Gbps rates.

   *  One-way / unidirectional links are sometimes used.

   *  Highly asymmetrical bandwidth and data rates are often present
      between uplink (DWE to a spacecraft) and downlink (DWE from a
      spacecraft), due to varying transmission power levels, antenna
      sizes, and other physical link properties.

   *  Limited onboard computing resources can lead to simplified or
      streamlined protocol implementations.

   *  Limited energy supply can further reduce contact opportunities and
      performance.

   Without any changes, a typical Internet application will not work in
   this environment, though some Internet stack protocols are more
   suitable than others.  Among the challenges in this list, the primary
   factors impacting Internet stack protocols are delays and
   disruptions, discussed in this memo.

   This section describes the following cases of mission operating
   environments: Moon (surface and orbiting), Mars (surface and
   orbiting), Lagrange points, cruising spacecraft, and onboard
   spacecraft, starting with some commonality between all cases.

2.1.  Common Aspects

   The Consultative Committee for Space Data Systems (CCSDS) is an
   organization comprised of many space agencies that has developed
   various link-layer protocols used on the links between Earth,
   orbiters and surface assets.  Examples include Telecommand (TC)
   [CCSDS_TC], Telemetry (TM) [CCSDS_TM], Advanced Orbiting Systems
   (AOS) [CCSDS_AOS], and Proximity1 (Prox1) [CCSDS_PROX1]].  A newer
   Unified Space Data Link Protocol (USLP) [CCSDS_USLP], has been
   designed to replace these in the future.  A generic encapsulation
   mechanism is defined by CCSDS to support networking and other uses
   over these link layer protocols, including IPv4, IPv6, and IP header
   compression options [IPoverCCSDSSpaceLinks][SANAIPEHeaderRegistry].
   IP packets can be transported over any CCSDS link layers.





Blanchet, et al.         Expires 21 January 2026                [Page 5]

Internet-Draft              IP in Deep Space                   July 2025


   Surface assets on celestial bodies, such as habitats, rovers,
   stations and others may communicate with each other while on the
   surface network using Earth terrestrial technologies such as IEEE
   802.11 and 3GPP technologies [ioagmoon][ioagmars] using IP, similar
   to the Internet, where links are almost always connected and there
   are no significant delays.  They may also communicate using a relay
   orbiter.

   Multiple providers, such as the LNSPs for the Moon, will provide
   various services including communications and networking.

   Orbiters acting as communications relays are already deployed or
   planned for both the Moon and Mars.  A sufficient number of orbiters
   can create a constellation which may provide full coverage of the
   celestial body surface [ioagmoon][ioagmars], or at least key regions
   (e.g. the lunar south pole).  Relaying from one surface asset to
   another surface asset through these orbiters may use either CCSDS
   link-layers or link-layers similar to LEO constellations on Earth.

   Space missions are typically planned many years in advance and are
   long-lived, spanning over many years or decades.  Spacecraft are
   controlled from Earth and therefore should always be manageable from
   Earth.  Given the remoteness and the difficulty to physically access
   the spacecraft, software upgrades and configuration changes are
   avoided whenever possible and backward compatibility is paramount.

   Space exploration is more than ever carried by multiple stakeholders.
   A mixture of assets operated by government, commercial, and academic/
   research organizations from multiple nations are deployed.  They will
   operate largely independently, but collaboration over time is
   expected to meet shared science goals, joint exploration missions,
   and mission cross-support needs (e.g. in contingency and emergency
   cases).

   While links can be noisy due to weak signals, interference, etc.,
   often packet delivery is actually virtually error-free due to the
   strong coding available within the link layer.  Delivery is generally
   in-order.  Queuing in modems, gateways, and other systems may be
   significant in comparison to typical terrestrial device queues.  In
   some planetary proximity regimes, CCSDS COP-1 or COP-P link layer
   retransmissions may be performed, further improving reliability at
   the IP layer (at some expense to delays).  Packet losses might be
   more common in some specific cases of either very low link margins or
   aggressive Adaptive Coding and Modulation (ACM), even though they
   might generally be avoided through physical link engineering and
   contact planning.





Blanchet, et al.         Expires 21 January 2026                [Page 6]

Internet-Draft              IP in Deep Space                   July 2025


2.2.  Moon

   There are currently very few orbiters around Moon but there are plans
   to establish multiple constellations of them to be used as
   communication relays.  As few as 5 cooperating orbiters at the right
   orbits is sufficient to provide full coverage [ioagmoon], and smaller
   sets of orbiters can be targeted to provide full coverage of specific
   limited regions such as the far side or the polar regions
   [imconstellation].  Until full coverage is accomplished,
   interruptions of communications are expected.  While Earth ground
   stations are able to directly cover assets on the near side of Moon,
   use of relays may still be desirable to improve power usage, data
   capacity, and spectrum efficiency.

   Different types of networking nodes are expected on the lunar
   surface, with a wide range of capabilities, from those that have very
   limited functionality (similar to IoT devices on Earth), up to more
   highly-capable infrastructure hub nodes that provide access for other
   surface users (e.g. in a habitat or lander), and in-between cases
   such as crewed or uncrewed rovers that may have combinations of
   direct-to-Earth, with proximity orbiters, or via local wireless LAN
   or cellular capabilities.

   The LunaNet Interoperability Specification (LNIS) [lnis] is a
   framework including IP networking support for lunar service providers
   and users to acheive interoperability.

   For human / crewed operations, nearly continuous coverage and data
   flows might be expected.  However, for other types of network users
   (such as science missions), only limited communication opportunities
   may be available.

   Some nodes (such as those supporting human missions) may have
   multiple/redundant links available simultaneously, but this should
   not be expected in general, and even then it is likely to be more for
   failover use than for multipath network transport.

   Data link operation is scheduled in advance through coordination
   between the end-user mission operations centers and LNSPs.  The time
   windows for operation and data rates are well-known in advance
   (typically days or more).  Successful link operation generally
   requires both directional pointing/tracking (with knowledge of
   vehicle locations and motion) of antenna systems, as well as pre-
   configuration of modem / signal processing and gateway systems that
   require prior coordination on many parameters.  Ad hoc or random
   access may be available at some later point, but is likely to be rare
   for at least proximity and direct-with-Earth links.




Blanchet, et al.         Expires 21 January 2026                [Page 7]

Internet-Draft              IP in Deep Space                   July 2025


   Near or on the surface, it is currently expected that the mobile
   spacecraft such as rovers or humans will be moving slowly compared to
   fast-moving vehicules on terrestrial networks where specific
   requirements are needed for handover.

   While interoperability and cross support are frequently expected,
   there is no assumption in-general that different parties can simply
   connect at the link layer or trade packets at the network layer
   (either directly or through intermediaries).  Network routing and
   interconnection is likely to be closely coordinated and limited by
   policies established jointly between cooperating organizations.  It
   is not likely to be directly like the Internet, with BGP, DNS, etc.
   generally available to support interdomain operations.

   One-way delay from Earth to Moon is around 1.3 seconds.

   Capacity is expected to eventually be in the range of hundreds of
   Mbps over radio links and Gbps via optical links between Earth and
   Moon assets [ioagmoon].

2.3.  Mars

   There are currently some orbiters around Mars, of which 4 are
   actively in use as relays, and 2 active rovers.  Multiple missions
   are planned[ioagmars] in the coming years.  Communications are from
   ground stations on Earth, such as the DSN, to Mars orbiters acting as
   layer0-1 relays to surface assets such as rovers, and reverse.  The
   relays do not have notion of frames, and only forward bits at
   different frequencies for each segment, a mechanism named "bag of
   bits"[ioagmars].  These orbiters can do as "bent-pipe" when the two
   segments are active, or by storing the bits as "store-and-forward"
   until the next segment becomes available.  Since the current set of
   orbiters do not provide full coverage of Mars, the communication
   windows are calculated and planned between Earth and each orbiter,
   and between each orbiter and each surface asset.  Currently, only one
   rover can use a relay link at any given time.  The MaROS
   project[maros] sponsored by the Jet Propulsion Laboratory acts as a
   broker to enable missions to enter data about the communications
   capabilities such as frequencies, bandwidth, window of communication
   time, ... so that rover missions can schedule the available
   communications windows for transmitting and receiving.  Most orbiters
   are used and scheduled in MaROS.  One of the Mars orbiters is Mars
   Reconnaissance Orbiter(MRO)[mro].  It was launched in 2005 and has a
   single 40Mhz processor but over 100G of solid state memory.  MaROS
   experience over years shows that the current bottleneck is not the
   temporary storage of the relays but the bandwidth from Mars surface
   assets to Mars orbiter relays.  As demonstrated by a
   study[marscommstudy] on Mars communication windows, the communication



Blanchet, et al.         Expires 21 January 2026                [Page 8]

Internet-Draft              IP in Deep Space                   July 2025


   windows seem to happen at a constant frequency, but the reality shows
   that the timing is pretty variable, which means a very large range of
   resulting round-trip time (RTT) for communications from Earth to Mars
   and back.  For example, within 3 months in 2024, the calculated RTT
   of the various combinations of orbiters and rovers varied from 30
   minutes to 170 hours.

   Surface assets are commanded directly from Earth but at a very low
   rate.  The traffic from the assets to Earth goes through relays.

   It is expected that future constellations of Mars orbiters acting as
   relays will also have optical inter-satellite links[ioagmars].  The
   current orbiters were put in various orbits for the purpose of
   science, and usually have a small number of short relay opportunities
   per day.  However, dedicated relay orbiters could be put at much
   higher altitudes to provide much better coverage.

   About every two years, a solar conjunction happens for a period of
   around 2 weeks, where the Sun is between Earth and Mars, therefore
   causing the interruption of communications between Earth and Mars.

   One-way delay from Earth to Mars is from 4 to 24 minutes, depending
   on the actual relative distance between them.

   It is envisioned that optical links between Earth and Mars may
   deliver hundreds of Mbps[ioagmars].

2.4.  Lagrange Points

   Sun-Earth and Earth-Moon Lagrange points, such as Earth-Moon (EML)-
   1,2,4,5 and Earth-Sun (ESL)-1,2, are popular for science mission
   objectives and also being considered for communication relays and
   therefore potential network forwarders.

   Sets of cooperating spacecraft may also be used to increase data
   return and streamline operations for science missions co-located at
   Lagrange points, by networking locally and sharing a common DWE
   "trunk link".

2.5.  Cruising Spacecraft

   Spacecraft that are cruising towards a deep space destination are
   assumed to generally be reached via direct point-to-point links from
   Earth using CCSDS link-layers.







Blanchet, et al.         Expires 21 January 2026                [Page 9]

Internet-Draft              IP in Deep Space                   July 2025


2.6.  Spacecraft Onboard

   Modern spacecraft generally contain multiple computers typically
   linked with wired realtime buses or links such as CAN, SpaceWire, RS-
   422, and others, but also increasingly using Ethernet or Time-
   Triggered Ethernet [tte] (TTE), with IP as the networking layer.
   Especially in complex human-crewed vehicles, WiFi is becoming
   important, and has been used extensively in the International Space
   Station and planned for the Lunar Gateway.

   IP networking onboard a spacecraft (or within a habitat) can support
   applications within the local network, without experiencing most of
   the typical space communications challenges described prior.
   Considerations need to be made, however, in order to make sure these
   applications do not rely on typical wider infrastructure (e.g. DNS,
   NTP, etc.) that may not be externally available in space.
   Additionally, some nodes on the network may be mobile/dynamic, such
   as astronaut suits and personal electronics, rovers, etc.

3.  Use Cases

   Multiple countries are developing systems aimed for a sustained lunar
   presence combining crewed and robotic missions.  The technologies
   developed for lunar use are intended to be applied later for Mars as
   well, and might equally apply for missions to asteroids and other
   deep space bodies.  IP has been included in the stack for the
   International Deep Space Interoperability Standards [idsis], and the
   LunaNet Interoperability Specification [lnis].  There is a general
   intention to extend and reuse systems developed for lunar use to
   later Mars use.

   Separate space agencies and private companies are deploying lunar
   space stations, orbiters, landers, rovers, habitats, crewed mission
   elements, and other assets.  Due to pervasive use and support of IP
   in modern computing systems, it is used onboard many space systems
   already, and between co-located systems (e.g. onboard ISS), and
   planned to be needed for networking on the Lunar Gateway, in Lunar
   3GPP surface networks, and in Lunar habitat LAN and WLAN networks.

   As more-and-more IP-enabled assets become deployed in lunar vicinity,
   it will increasingly create opportunities to interconnect them.  In
   fact, internetworking of lunar (and future Mars) systems is becoming
   essential, as plans call explicitly for cooperation between mission
   elements and communications/navigation system assets operated by
   different space agencies and/or private companies acting as service
   providers.





Blanchet, et al.         Expires 21 January 2026               [Page 10]

Internet-Draft              IP in Deep Space                   July 2025


   There are expected to be several different interoperable LNSPs
   offering a variety of relay and/or DWE services, to provide wide
   coverage and cross-support opportunities.  As more significant
   numbers of missions target Mars and other bodies, the same concepts
   should apply.

   It may be expected that planetary IP networks should over time become
   united into larger aggregates, and even into a single interoperable
   network (as intended within the LunaNet conception).

   It is expected that surface assets (for Moon, Mars, asteroids, etc.)
   will communicate with other surface assets on the same body through
   typical Earth-based wireless technologies such as WiFi or 4G/5G/6G,
   or via a orbiting relays.

   Regarding applications, the following is an incomplete list:

   *  Telecommand: Commanding can take different forms, either
      individual commands or batching commands together.  Individual
      commands sent to a mission/spacecraft from Earth are typically
      small (may fit within a single packet in many cases), and should
      typically be received reliably and in-order to be processed.
      Commands with dependencies or other relations may be grouped
      together for transmission and to help assure coherent execution
      rather than sent individually.  This can resemble small file
      transfer, for instance.  Commands may be time-sensitive, or have
      an "expiration date" after which they are not useful to store/
      carry in the network.  Required data rates may typically be in
      kbps and bursty.

   *  Telemetry: Spacecraft stream telemetry data (periodically measured
      onboard status, metrics, etc.) to Earth for monitoring and other
      purposes.  Timely delivery is useful, but storage in the network
      is fine, if needed.  Required data rates may be approaching the
      Mbps range, and often a constant/steady stream of data is
      produced.

   *  On-demand/real-time media(audio, video, ...): when a active path
      from the asset to Earth, the asset sends a media feed.  The delay
      is only the propagation delay.

   *  Delayed media: the asset sends the media, but it is expected that
      there is no active path from the asset to Earth, so data may be
      temporarily stored in the network.

   *  Emergency and Search and Rescue (SAR) messaging: sent from an
      asset to one or many other assets (e.g. via broadcast or
      multicast) that support emergency operations.  Since crew or



Blanchet, et al.         Expires 21 January 2026               [Page 11]

Internet-Draft              IP in Deep Space                   July 2025


      mission safety may be at risk, this traffic should be prioritized
      over most other types of packets when encountering queuing or
      storage within the network.  Timely delivery is necessary, but it
      should also be delivered reliably.

   *  Science data: Typically science data may take the form of large
      bulk file transfers unicasted from a spacecraft to Earth.  In many
      cases, storage and large delays in delivery can be tolerated.
      File transfer applications such as CCSDS File Delivery Protocol
      (CFDP)[CCSDS_CFDP] are typically used, that might be configured to
      either operate unidirectionally or may provide reliability through
      retransmissions, and require at least small amount of feedback.
      Some science applications may also use messaging patterns to
      collaborate between different types of instruments in order to
      draw attention to events (e.g. gamma ray bursts, etc.) and bring
      different types of instruments to bear.  These messages may need
      to be quickly delivered and/or multicasted.

   *  Messaging: Many different types of machine-to-machine messaging
      need to be supported, including for uses such as (1) providing PNT
      data/measurements to feed positioning, orbit determination, and
      time transfer or clock calibration, (2) providing space weather
      alerts, (3) providing advisory or other network information (e.g.
      almanac data such as ephemeris data for relay and other network
      elements, scheduled future contacts, or other service management
      related messaging).  Messages are generally small (though may vary
      depending on type) and might be unicast, broadcast, or multicast.
      In cases where they are advisory, for instance, they may not need
      reliable transport, though often it will be important to provide
      timely transmission.

   *  Network and Asset management: sending requests and getting answers
      from assets about their overall status, status of their
      components, energy levels, storage capacities, etc.

4.  Requirements

4.1.  Store-and-Forward

   Until full coverage by orbiter constellations is achieved around a
   celestial body, the orbiters and other assets that are facing
   intermittent communications should provide store-and-forward
   capability.  These can be implemented at - layer-1, like the current
   Mars orbiters, where frames are not seen ("bag of bits"), at layer-2
   doing frame storage or at layer-3 doing packet storage.  Storage
   higher in the stack enables more versatile, agile and policy-based
   routing.  A key factor for designing the store and forward capability
   of an orbiter is its storage capacity.



Blanchet, et al.         Expires 21 January 2026               [Page 12]

Internet-Draft              IP in Deep Space                   July 2025


   Surface assets that are facing intermittent communications also need
   the store-and-forward capability.

   Mechanisms should be defined to avoid as much as possible storage
   full events on a relay.  This may include some in-advance signaling
   to the network about future full storage event, so that the network
   and/or the source can throttle down or reroute packets to avoid that
   event.

   In the event of full storage, a policy should be determined on which
   packets should be dropped, such as the last one in the queue, the
   first one in the queue, ones based on policies related to packet or
   transport fields like source or destination addresses, traffic
   classes, flow ids, etc. , similar to queue management used in
   terrestrial networks.  These policies are important for
   differentiated trafic such as Emergency and Search and Rescue.

   Even if calculations can be done based on known orbital dynamics,
   events happen that result in missed communication windows.  For
   example, some communication windows were not used on Mars because a
   rover may be still charging and therefore does not have enough energy
   to perform communications.  Random events can also happen because of
   space weather.  Therefore, while the window of comms can be
   calculated and used, the system should be able to cope with random
   long interruption events.

   Proper guards should be designed to avoid denial-of-service attacks
   by filling storage in the network.

4.2.  Time

   Timers are used in transport protocols, application protocols and
   applications themselves for various purposes, such as detecting/
   presuming packet loss or data lifetime.  Timers should be therefore
   adjusted and configured based on the expected travel time and RTT
   from the source to destination.  Given variations and possible
   dynamic changes in the network that can cause much longer latency,
   appropriate safeguards should be put for timer values.

   Lifetime is also attached to some data, such as content, security
   keys, certificates, tokens, session keys and naming records.
   Similarly, the lifetime should be adjusted and configured based on
   the characteristics of the applications and expected travel time and
   RTT.

   Current Internet protocols and applications typically use UTC as
   their time reference.  There are currently work to define Lunar
   Standard Time, also called Coordinated Lunar Time and Mars Standard



Blanchet, et al.         Expires 21 January 2026               [Page 13]

Internet-Draft              IP in Deep Space                   July 2025


   Time [lunartime].  Depending on the application and use case, it may
   be necessary to adapt the protocol or the application to use another
   time reference.

4.3.  Signaling and Exchanges

   Given the large latency of space communications, multiple steps of
   exchanges or handshakes may still work but are far from optimal and
   may never converge.  Therefore, applications and protocols should be
   adapted to minimize the number of exchanges.

   Similarly, applications, protocols or networking stack that depend on
   signaling back to the source or to somewhere in the path may arrive
   too late for any usefulness, because of the latency.  Therefore, any
   signaling should be carefully designed based on the expected latency.

4.4.  Bandwidth

   Given that space communications will always have much lower bandwidth
   than what is possible in shorter distances such as on Earth,
   optimization of the bandwidth usage is important.  This can be
   implemented at many levels in the networking stack, starting from
   layer-2 to IP header compression to transport and application data
   compression.

4.5.  Transport

   Since IP (and UDP) does not provide reliable transport services, such
   as loss, duplicates and reordered recovery, a reliable transport
   should be used and configured properly for space delays and
   intermittence for applications and protocols requiring it.

   Congestion control algorithms may declare congestion based on
   heuristics such as when delays are increasing.  In that case, sources
   pace down to decrease their usage of the bandwidth.  However, given
   that forwarders in space apply the store-and-forward technique when
   link intermittence happen, the congestion seen by the source is not
   actually congestion in the typical Internet sense, but deep buffer
   usage in forwarders, as a normal and expected operation.  Therefore,
   congestion control should be adapted or not used because of
   intermittence.  At least early on, while the networks are small
   scale, coordinated resource planning and management may be performed
   to avoid creating congestion.








Blanchet, et al.         Expires 21 January 2026               [Page 14]

Internet-Draft              IP in Deep Space                   July 2025


4.6.  Addressing and Routing

   To minimize routing and forwarding tables, optimal address
   aggregation is preferred, and it starts with proper allocation of
   addresses.

   The network in deep space, not including the surface networks on
   celestial bodies, will grow at a small pace, which does not warrant
   complex routing schemes.  However, over time, the network will become
   sufficiently complex not only because of the number of forwarders but
   also because of the intrinsic intermittent and delay communication
   patterns, which may warrant more complex routing solutions and
   orchestration.

4.7.  Recovery on Reboot

   On a well-connected and low delay network such as Internet, an
   unexpected reboot of an intermediate node or a endpoint is recovered
   relatively fast: adjacency can be restored with neighbors for
   intermediate nodes, and endpoints can resume or restart their
   connections with their peers within short time.  On the contrary,
   given the intermittence and long delays in deep space, this fast
   recovery is unlikely.

   For intermediate nodes, storing in permanent memory the contact
   schedule or the expected next opportunities for neighbors may help
   faster recovery.

   For endpoints, applications may keep a state context in permanent
   memory, either at the application layer or at the transport layer or
   both.

5.  Security Considerations

   Security protocols and mitigations are most often based on time, such
   as keys and certificate lifetimes, tokens lifetime, firewall opened
   ports time windows, etc.  Keys and certificates have also a lifecycle
   where they should be renewed.

   Given the delays to act, for example from Earth to a celestial body,
   notifications of security issues and mitigation actions will be
   delayed, which may increase the impact of security issues such as
   denial of service attacks.








Blanchet, et al.         Expires 21 January 2026               [Page 15]

Internet-Draft              IP in Deep Space                   July 2025


   Security validation, such as certificate validation, based on on-line
   immediate queries to validation databases, such as done with
   OCSP[RFC6960], or with a certificate chain will likely take too long
   if the validation database is far from the validation querier.
   Techniques such as preemptive caching of validation chain and certs
   should be investigated.

   Certificate lifecycle should be well planned to take into account
   delays and intermittence, so that for example certificate renewals
   are done sufficiently in advance.

6.  IANA Considerations

   There are no actions for IANA in this document.

7.  References

7.1.  Informative References

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.

   [I-D.many-deepspace-ip-assessment]
              Blanchet, M., Huitema, C., and D. Bogdanović, "Revisiting
              the Use of the IP Protocol Stack in Deep Space: Assessment
              and Possible Solutions", Work in Progress, Internet-Draft,
              draft-many-deepspace-ip-assessment-02, 10 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-many-
              deepspace-ip-assessment-02>.

   [IPoverCCSDSSpaceLinks]
              Consultative Committee on Space Data Systems(CCSDS), "IP
              OVER CCSDS SPACE LINKS, Blue Book 702", September 2012,
              <https://public.ccsds.org/Pubs/702x1b1c2.pdf>.

   [SANAIPEHeaderRegistry]
              "Internet Protocol Extension Header",
              <https://sanaregistry.org/r/ipe_header/>.

   [CCSDS_AOS]
              Consultative Committee on Space Data Systems(CCSDS), "AOS
              Space Data Link Protocol, Blue Book 732.0-B-4", October
              2021, <https://public.ccsds.org/Pubs/732x0b4.pdf>.





Blanchet, et al.         Expires 21 January 2026               [Page 16]

Internet-Draft              IP in Deep Space                   July 2025


   [CCSDS_TM] Consultative Committee on Space Data Systems(CCSDS), "TM
              Space Data Link Protocol, Blue Book 132.0-B-3", October
              2021, <https://public.ccsds.org/Pubs/132x0b3.pdf>.

   [CCSDS_TC] Consultative Committee on Space Data Systems(CCSDS), "TC
              Space Data Link Protocol, Blue Book 232.0-B-4", October
              2021, <https://public.ccsds.org/Pubs/232x0b4e1c1.pdf>.

   [CCSDS_PROX1]
              Consultative Committee on Space Data Systems(CCSDS),
              "Proximity-1 Space Link Protocol—Data Link Layer, Blue
              Book 211.0-B-6", July 2020,
              <https://public.ccsds.org/Pubs/211x0b6e1.pdf>.

   [CCSDS_USLP]
              Consultative Committee on Space Data Systems(CCSDS),
              "Unified Space Data Link Protocol, Blue Book 732.1-B-2",
              October 2021,
              <https://public.ccsds.org/Pubs/732x1b2s.pdf>.

   [CCSDS_CFDP]
              Consultative Committee on Space Data Systems(CCSDS), "File
              Delivery Protocol, Blue Book 727.0-B-5", July 2020,
              <https://public.ccsds.org/Pubs/727x0b5e1.pdf>.

   [ioagmoon] Lunar Communications Architecture Working Group,
              Interagency Operations Advisory Group, "The Future Lunar
              Communications Architecture, Report of the Interagency
              Operations Advisory Group", January 2022,
              <https://www.ioag.org/Public%20Documents/Lunar%20communica
              tions%20architecture%20study%20report%20FINAL%20v1.3.pdf>.

   [ioagmars] Mars and Beyond Communications Architecture Working Group,
              Interagency Operations Advisory Group, "The Future Mars
              Communications Architecture, Report of the Interagency
              Operations Advisory Group", February 2022,
              <https://www.ioag.org/Public%20Documents/
              MBC%20architecture%20report%20final%20version%20PDF.pdf>.

   [mro]      "Mars Reconnaissance Orbiter",
              <https://science.nasa.gov/mission/mars-reconnaissance-
              orbiter/>.

   [DSN]      "Deep Space Network",
              <https://www.nasa.gov/directorates/somd/space-
              communications-navigation-program/what-is-the-deep-space-
              network/>.




Blanchet, et al.         Expires 21 January 2026               [Page 17]

Internet-Draft              IP in Deep Space                   July 2025


   [marscommstudy]
              Blanchet, M., "Earth-Mars Communication Windows Usage
              Study", October 2024,
              <https://deepspaceip.github.io/meetings/ietf121/ietf121-
              deepspaceip-mars-communications-study.pdf>.

   [idsis]    "International Communication System Interoperability
              Standards (ICSIS)", September 2020,
              <https://internationaldeepspacestandards.com/wp-
              content/uploads/2024/02/
              communication_reva_final_9-2020.pdf>.

   [lnis]     "LunaNet Interoperability Specification", September 2022,
              <https://www.nasa.gov/directorates/somd/space-
              communications-navigation-program/lunanet-
              interoperability-specification/>.

   [deepspacewikipedia]
              "Deep space exploration",
              <https://en.wikipedia.org/wiki/Deep_space_exploration>.

   [maros]    Gladden, R., "Mars Relay Operations Service (MaROS): A
              Present Service Preparing for the Future", May 2014.

   [tte]      Wikipedia, "TTEthernet",
              <https://en.wikipedia.org/wiki/TTEthernet>.

   [lunartime]
              NASA, "NASA to Develop Lunar Time Standard for Exploration
              Initiatives", September 2024,
              <https://www.nasa.gov/general/nasa-to-develop-lunar-time-
              standard-for-exploration-initiatives/#:~:text=The%20lunar%
              20time%20will%20be,Coordinated%20Universal%20Time%20(UTC)>
              .

   [imconstellation]
              Intuitive Machines, "Intuitive Machines Expands Data
              Transmission Services for Lunar and Deep Space Mission",
              April 2025, <https://www.intuitivemachines.com/post/
              intuitive-machines-expands-data-transmission-services-for-
              lunar-and-deep-space-missions>.

Acknowledgements

   This following people have provided valuable feedback and comments,
   in no specific order: Roy Gladden, Padma Pillay-Esnault, Tomek
   Mrugalski.




Blanchet, et al.         Expires 21 January 2026               [Page 18]

Internet-Draft              IP in Deep Space                   July 2025


Authors' Addresses

   Marc Blanchet
   Viagenie
   Canada
   Email: marc.blanchet@viagenie.ca


   Wesley Eddy
   MTI Systems
   United States of America
   Email: wes@mti-systems.com


   Marshall Eubanks
   Space Initiatives Inc
   United States of America
   Email: tme@space-initiatives.com

































Blanchet, et al.         Expires 21 January 2026               [Page 19]
