IP in Deep Space: Key Characteristics, Use Cases and Requirements
draft-ietf-tiptop-usecase-03
| Document | Type | Active Internet-Draft (tiptop WG) | |
|---|---|---|---|
| Authors | Marc Blanchet , Wesley Eddy , Marshall Eubanks | ||
| Last updated | 2026-09-29 (Latest revision 2026-09-24) | ||
| Replaces | draft-many-tiptop-usecase | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | In WG Last Call | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-tiptop-usecase-03
Internet Engineering Task Force M. Blanchet
Internet-Draft Viagenie
Intended status: Informational W. Eddy
Expires: 28 March 2027 Aalyria Technologies
M. Eubanks
Space Initiatives Inc
24 September 2026
IP in Deep Space: Key Characteristics, Use Cases and Requirements
draft-ietf-tiptop-usecase-03
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. Most of the IP protocol stack
used on the Internet, in particular reliable transport protocols and
applications, 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 28 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Blanchet, et al. Expires 28 March 2027 [Page 1]
Internet-Draft IP in Deep Space September 2026
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
1.1. Limitations of this document . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Document and Discussion Locations . . . . . . . . . . . . 5
2. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Common Aspects . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 8
2.2. Moon . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Mars . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Lagrange Points . . . . . . . . . . . . . . . . . . . . . 14
2.5. Cruising Spacecraft . . . . . . . . . . . . . . . . . . . 14
2.6. Spacecraft Onboard . . . . . . . . . . . . . . . . . . . 14
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Connectivity Scenarios . . . . . . . . . . . . . . . . . . . 17
4.1. Earth to Cruising Spacecraft (CS) . . . . . . . . . . . . 17
4.2. Earth-Moon with Full Connectivity (LF) . . . . . . . . . 17
4.3. Earth-Moon with Intermittent Connectivity (LI) . . . . . 18
4.4. Earth-Mars with Full Connectivity (MF) . . . . . . . . . 18
4.5. Earth-Mars with Intermittent Connectivity (MI) . . . . . 18
4.6. Solar Conjunction (SC) . . . . . . . . . . . . . . . . . 18
5. Path Characteristics Calculations . . . . . . . . . . . . . . 19
5.1. RTT Calculation . . . . . . . . . . . . . . . . . . . . . 20
5.2. Bandwidth-Delay Product (BDP) Calculation . . . . . . . . 21
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Buffers and Store-and-Forward Capabilities . . . . . . . 23
6.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Location . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4. Signaling and Exchanges . . . . . . . . . . . . . . . . . 25
6.5. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 26
6.6. Transport . . . . . . . . . . . . . . . . . . . . . . . . 26
6.7. Addressing and Routing . . . . . . . . . . . . . . . . . 26
6.8. Recovery on Reboot . . . . . . . . . . . . . . . . . . . 27
6.9. Energy . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.10. Asynchronous Operation and Power Save Modes . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Blanchet, et al. Expires 28 March 2027 [Page 2]
Internet-Draft IP in Deep Space September 2026
9.1. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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
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].
Blanchet, et al. Expires 28 March 2027 [Page 3]
Internet-Draft IP in Deep Space September 2026
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. Near-
Earth satellite networking, including 3GPP Non-Terrestrial Networks
(NTN), operates with round-trip times of milliseconds to hundreds of
milliseconds and generally continuous connectivity through
constellation handover; techniques developed there do not address the
minutes-to-hours delays and scheduled multi-day disruptions
characteristic of deep space, which are the focus of this document.
However, the same 3GPP NTN technologies are expected to be used in
low orbits around other celestial bodies; in that context, orbiting a
celestial body and serving its surface and orbital assets, they are
in scope of this document. In addition, 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 international array of giant radio
antennas that supports interplanetary spacecraft missions [DSN].
Blanchet, et al. Expires 28 March 2027 [Page 4]
Internet-Draft IP in Deep Space September 2026
* 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].
* Lagrange Points: special points in the gravitational fields
between bodies (e.g. Earth-Moon, Earth-Sun, etc.), that are
popular mission locations due to stability (i.e. low fuel usage),
visibility for communications or science instruments, or other
reasons. Also known as "libration points".
* Lunar Gateway: a space station orbiting the Moon, that can serve
as a waypoint or other supporting infrastructure for lunar
exploration [Gateway].
* Surface network: a network interconnecting assets on or near the
surface of a celestial body, using terrestrial-style link
technologies (e.g., IEEE 802.11, 3GPP). Its users include
habitats, landers, rovers, crew equipment, and low-altitude mobile
assets such as drones or hoppers, which are regarded as surface
assets.
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
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.
Blanchet, et al. Expires 28 March 2027 [Page 5]
Internet-Draft IP in Deep Space September 2026
* 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 28 March 2027 [Page 6]
Internet-Draft IP in Deep Space September 2026
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).
Blanchet, et al. Expires 28 March 2027 [Page 7]
Internet-Draft IP in Deep Space September 2026
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 (discussed in more
detail in Section 2.1.1). Delivery of packets is generally in-order.
Queuing in modems, gateways, and other systems may be significant in
comparison to typical terrestrial device queues, while the memory
available for such queues on space-qualified hardware is often
severely constrained; both the depth and the sizing of these buffers
should be considered. 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. See Section 6.2 for
requirements related to timers used for loss detection.
2.1.1. Link Model
This subsection includes further details on the "link model"
assumptions for deep space data links. While there are diverse
connectivity scenarios described later in this document, this "link
model" is generally applicable across the whole set (and includes
both RF and optical links). This subsection includes deeper
consideration into how IP packets are encpasulated within the data
link layer, MTU settings, and what impacts physical layer errors in a
received stream of bits may have on IP packet streams.
Commonly, the space data link layer is split between an upper portion
that provides framing (allowing multiple virtual channels to be
multiplexed, etc.), and a lower portion that provides error
correction and synchronization functionality on "codeblocks" (e.g.
see Section 2.3 of [CCSDS_SDLP] for CCSDS radio links). For decades,
very powerful block error correction codes have been specifically
developed and used for deep space missions, and can be further
layered via "concatenated" coding (e.g. an outer block code and inner
convolutional code), and interleaved for robustness to burst error
patterns (e.g. see [CCSDS_130.1-G] for some CCSDS RF links).
Frames and code blocks traditionally aligned one-to-one, however,
this is no longer true in all cases (a recent optional "slicing"
capability adds a secondary level of synchronization for the stream
of frames within codeblock data [CCSDS_131.0-B]). Additionally,
space data link layer frames have historically mixed the use of fixed
length frames in some cases (such as telemetry links) and variable
length frames in other cases (such as telecommand links), but
recently there has been symmetrical use of fixed length frames in
both directions (e.g. with the AOS data link). Since IP packets can
Blanchet, et al. Expires 28 March 2027 [Page 8]
Internet-Draft IP in Deep Space September 2026
vary in length, addtional protocol methods are needed in order to
transfer a stream of IP packets over a data link with fixed frame
sizes. Generally, the expected means to encapsulate either IPv4 or
IPv6 packets into data link layer frames is via CCSDS Encapsulation
Packets [IPoverCCSDSSpaceLinks]. The Encapsulation Packet provides a
means to signal each packet's protocol type and its total size, and
can support flexibly packing IP packets into frames such that a given
IP packet may either:
1. Fit into a single frame, e.g. if the IP packet is ~1kB in size
and an 8kb codeblock is used, along with a 1:1 mapping between
frames and codeblocks.
2. Span multiple frames, e.g. for a large IP packet and a small
fixed-length frame size. The beginning (or end) of a packet may
be in the same frame as the end (or beginning) of another packet.
3. If small, e.g. like a simple "ACK" or an ICMP packet, be packed
into a single frame with multiple other small packets.
The link MTU versus the frame size and codeblock size are set in
order to balance between different goals of:
* Having an MTU large enough to support packet sizes needed for
modern upper layer protocols (e.g. >1200 bytes of UDP payload size
for QUIC). MTUs that are much larger than the codeblock size
will, however, potentially lead to a higher packet loss rate, as
loss of a single codeblock will cause the entire packet to be
lost.
* Having an MTU small enough to not cause large head-of-line
blocking problems when packets from real-time flows need to be
multiplexed on a link. This depends on the link rate, and is
mainly an issue for lower capacity links.
* Having either a fixed frame size large enough to efficiently hold
packets of MTU length (after encapsulation), or having variable
frame size (with an upper limit).
* Using codeblock sizes that correspond to standardized / common
block codes that have well-known performance and efficient
algorithms in proper hardware/software.
Blanchet, et al. Expires 28 March 2027 [Page 9]
Internet-Draft IP in Deep Space September 2026
As an example, the LunaNet Interoperability Specification (LNIS)
version 5 [LNIS] has some block code options including 1024, 4096,
7136, or 16384 bits of payload (128, 512, 892, or 2048 bytes). This
would lead to most QUIC data packets spanning from 1 to 10 or more
codeblocks, for instance, depending on the specific code selection,
even if only the minimal MTU is supported.
Due to the typical one-to-one relationship between frames and
codeblocks, the frame error rate that would impact user data could be
directly established from the probability of an uncorrectable
codeblock, so a frame error rate is a typical figure of merit (though
with variable length frames and secondary synchronization, the
relationship is broken). An uncorrectable codeblock typically
generates a failure resulting in loss/discard of the data, rather
than passing data with bit errors through to be processed by upper
layers. As a point of reference, the DSN catalog [DSN_catalog]
includes a table of example frame rejection rates, with example of
less than 1 in 10**-6 frames when using a common concatenated code
selections. Actual results can be much better than this due to
circumstances discussed below.
Modern coding options in common use for RF and optical links have
very steep performance curves, such that within only a few dB, there
can be a difference of many orders of magnitude in the error rate
performance. This means practically that the error rates are either
negligibly small (e.g. below 1e**-12), or high enough to prevent
proper synchronization / locking. Significant mission design and
analysis activities are performed in order to provide strong
confidence that communications will be reliable, and maintain
operating points within the nearly error-free regime. This includes
computing detailed link budgets in order to determine received power
levels and signal to noise ratios, generally reserving decent margins
to provide high confidence of performance meeting expectations.
Through this analysis, the expected bit error rates and codeblock
error rates can be determined. The margins designed in may often be
multiple dB, enabling much better actual error performance than the
designed upper bounds on error rate. Further, since links are highly
planned and coordinated, they can often be scheduled in order to
avoid circumstances that would lead to higher potential errors.
Anecdotally, often missions do not see upper-layer retransmission
mechanisms needing to be triggered because links perform well enough
to avoid losses apparent to the upper layers.
Blanchet, et al. Expires 28 March 2027 [Page 10]
Internet-Draft IP in Deep Space September 2026
In the future, more use of variable and/or adaptive modulation and
coding (VCM or ACM) may become common. At present, this has started
to become common for LEO use, but realtime control is also supporting
use in LEO, so deep space usage may differ. In any case, it is still
good for work on IP in deep space to assume the possibility of VCM or
ACM that will cause data to be sent often at high rates but with
lower link margins, resulting in a potentially observable error rate.
In conslusion, deep space links can support typical Internet MTU-
sized packets (e.g. 1500 or 2k bytes), and nominal error rates. For
protocol design, simulation, analysis, etc., it is advisable to
consider different possible cases of error behaviors, either where
margin is high and error rates are so small as to be neglibible, or
cases where errors may be present, but bounded by a value such as
1e-6 probability of uniform randomly distributed packet losses.
While other cases such as correlated burst losses are possible, they
do not seem to bear special consideration at this time, due to
factors described above. An error-free or very low packet error rate
is representative for nominal cases where RF or optical links are
designed using traditional practicies, operationally scheduled to
avoid known interference, blockages, etc., and use current
technologies.
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.
Blanchet, et al. Expires 28 March 2027 [Page 11]
Internet-Draft IP in Deep Space September 2026
The LunaNet Interoperability Specification (LNIS) [LNIS] is a
framework including IP networking support for lunar service providers
and users to acheive interoperability.
NASA has described plans for a sustained lunar surface base, the Moon
Base program, near the lunar south pole, deployed in phases and
comprising commercial landers, crewed and uncrewed rovers, drones,
and later pressurized habitats and power infrastructure
[nasamoonbase]. The networking use cases described in this document,
including surface networks interconnecting habitats, rovers, drones
and other surface assets, surface-to-orbiter relaying, and direct-
with-Earth links, are intended to cover such deployments.
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.
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.
Blanchet, et al. Expires 28 March 2027 [Page 12]
Internet-Draft IP in Deep Space September 2026
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 operate 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 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 generally 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
Blanchet, et al. Expires 28 March 2027 [Page 13]
Internet-Draft IP in Deep Space September 2026
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 26 months, a solar conjunction happens for a period of
around two weeks, where the Sun is between Earth and Mars, therefore
causing the interruption of communications between Earth and Mars, as
described in Section 4.6.
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.
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,
Blanchet, et al. Expires 28 March 2027 [Page 14]
Internet-Draft IP in Deep Space September 2026
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.
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:
Blanchet, et al. Expires 28 March 2027 [Page 15]
Internet-Draft IP in Deep Space September 2026
* 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 carry
within 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 buffered within 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
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. Unlike most traffic, emergency
messages may have no useful expiration: they should not be dropped
from network storage on lifetime grounds, and drop policies under
storage exhaustion should preserve them ahead of all other traffic
classes.
* 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
Blanchet, et al. Expires 28 March 2027 [Page 16]
Internet-Draft IP in Deep Space September 2026
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, buffer capacities, etc.
4. Connectivity Scenarios
This section describes example connectivity scenarios in deep space.
Each scenario is labeled with a two-letter acronym so that other
documents, such as protocol profiles, can refer to them. This list
is not intended to be exhaustive.
4.1. Earth to Cruising Spacecraft (CS)
A spacecraft cruising towards a deep space destination communicates
directly with Earth. The one-way delay increases over time, but at
orders of magnitude lower speed than the speed of light; therefore
the round-trip time increases "slowly".
4.2. Earth-Moon with Full Connectivity (LF)
Moon assets are mostly always reachable, as with the terrestrial
Internet. This can be accomplished in various ways, such as a
constellation of low Moon orbit satellites connected together with
Optical Inter-Satellite Links (OISL). For example, many rovers,
drones and habitats on the Moon surface are connected to a 3GPP 6G
network provided by such a constellation. At any single point in
time, one or many of these satellites are communicating with Earth,
providing full connectivity on the Moon and between the Moon and
Earth. The Earth to Moon one-way delay is around 1.3 seconds. This
scenario is the end goal for both the Moon and Mars. Given announced
Blanchet, et al. Expires 28 March 2027 [Page 17]
Internet-Draft IP in Deep Space September 2026
constellation deployment plans, essentially full coverage of the
relevant lunar sites may be achieved in the near future. In such
deployments, intermittence becomes an exception to be handled (e.g.,
equipment failures, contingencies, or power-save periods) rather than
the general rule. Documents profiling protocols for these
environments should therefore provide recommendations for both the
intermittent and the full-connectivity regimes.
4.3. Earth-Moon with Intermittent Connectivity (LI)
Moon assets are reachable by intermittence from Earth. This can
happen when there is a limited number of satellites which do not
provide full-time connectivity. The Earth to Moon one-way delay is
around 1.3 seconds.
4.4. Earth-Mars with Full Connectivity (MF)
Mars assets are mostly always reachable, as with the terrestrial
Internet. As for the Moon, this can be accomplished in various ways,
such as a constellation of satellites around Mars connected together
with Optical Inter-Satellite Links (OISL). The Earth to Mars one-way
delay is between 4 and 24 minutes, depending on the relative position
of each planet. That one-way delay changes "slowly" as the planets
are orbiting around the Sun.
4.5. Earth-Mars with Intermittent Connectivity (MI)
Mars assets are reachable by intermittence from Earth. For example,
a rover on the Mars surface is connected to a Mars surface IP network
which receives intermittent connectivity from a few orbiters, with an
average of one contact every 6 hours. Some of those orbiters have
circular orbits, others elliptical; the latter means that the
overpasses are not at a fixed frequency. The orbiters are connected
to Earth ground stations while they are in line of sight with Earth.
The Earth to Mars one-way delay is between 4 and 24 minutes,
depending on the relative position of each planet, and changes
"slowly" as the planets are orbiting around the Sun.
4.6. Solar Conjunction (SC)
A solar conjunction happens when the Sun is between Earth and another
celestial body, blocking or degrading direct communications between
Earth and the assets at that body. For Mars, a solar conjunction
occurs approximately every 26 months, which is the Earth-Mars synodic
period. As the Sun-Earth-Mars angle becomes small, the charged
particles of the solar corona increasingly corrupt the radio signals
crossing near the Sun, degrading communications before interrupting
them completely. Mission operators typically observe a
Blanchet, et al. Expires 28 March 2027 [Page 18]
Internet-Draft IP in Deep Space September 2026
communications moratorium of around two weeks, during which no
commands are sent to Mars assets [marsconjunction].
Solar conjunctions are precisely predictable years in advance. This
scenario is therefore a scheduled, total interruption of the Earth-
to-body communications that is much longer than the interruptions of
the intermittent connectivity scenarios.
Other celestial bodies undergo the same phenomenon at a recurrence
equal to their synodic period, such as approximately every 13 months
for Jupiter and approximately every 12.4 months for Saturn; the
duration of the interruption depends on the geometry and on how fast
the body moves relative to the Sun as seen from Earth.
Communications between Earth and the Moon are not subject to solar
conjunctions, since the Moon orbits Earth. Communications local to
the celestial body, such as between surface assets and orbiters, are
not affected and continue to operate during a conjunction; only the
long-haul links crossing near the Sun are interrupted. In the
future, relay spacecraft located away from the direct Earth-to-body
line, for example in heliocentric orbit or at Lagrange points, could
provide an alternate path around a conjunction, at the cost of a
longer path.
During a conjunction blackout, traffic sources that continue to
generate data (e.g., steady telemetry or science flows) can fill the
buffer capacity of relays and orbiters; buffer capacity planning and
source throttling policies should take these multi-week interruptions
into account (see Section 6). Cruising spacecraft on long-distance
trajectories may also experience solar conjunctions when the Sun
crosses the Earth-spacecraft line. A study of communication delays,
disruptions and blackouts for crewed Mars missions is available in
[conjunctionstudy].
5. Path Characteristics Calculations
Protocols and applications use the expected round-trip time (RTT) and
the expected bandwidth of a path for various purposes, such as
configuring timers for loss detection, retransmissions, keep-alives
and idle timeouts, or sizing windows and buffers. Since space
missions and their communications are planned in advance, these path
characteristics can be calculated in advance of the mission. This
section describes how to calculate the minimum and maximum RTT
(minRTT, maxRTT) and the minimum and maximum bandwidth-delay product
(minBDP, maxBDP) of a path, so that other documents, such as protocol
profiles, can refer to these definitions. Examples are given using
the connectivity scenarios described in Section 4.
Blanchet, et al. Expires 28 March 2027 [Page 19]
Internet-Draft IP in Deep Space September 2026
5.1. RTT Calculation
In deep space, the RTT between two nodes has two main components: the
two-way propagation delay, which varies with the distance between the
nodes, and the waiting time, when the path is subject to intermittent
connectivity: a packet, or its response, may be buffered within the
network (see Section 6.1) until the next communication opportunity.
Both components are known in advance, from the orbital dynamics and
from the contact schedule respectively.
The minimum RTT of a path, named minRTT, is the minimum two-way
propagation delay, with no waiting time, since the whole path is
available at some point in time in all scenarios except during a
solar conjunction.
The maximum RTT of a path, named maxRTT, is the sum of the maximum
two-way propagation delay and the maximum waiting time before a
communication opportunity, the latter derived from the contact
schedule, such as the time between orbiter overpasses.
For example, in the Earth-Mars with intermittent connectivity (MI)
scenario (Section 4.5), the minimum two-way propagation delay is 8
minutes, twice the 4-minute minimum one-way delay; therefore, minRTT
is 8 minutes. The maximum two-way propagation delay is 48 minutes,
twice the 24-minute maximum one-way delay, and the maximum waiting
time with an overpass every 6 hours is 6 hours; therefore, maxRTT is
6 hours 48 minutes.
The waiting time of a deployed system may vary much more than its
propagation delay. For example, over three months in 2024, the
calculated RTT of the various combinations of Mars orbiters and
rovers varied from 30 minutes to 170 hours [marscommstudy].
Therefore, maxRTT should be calculated using the actual contact
schedule of the mission. Table 1 summarizes minRTT and maxRTT for
the connectivity scenarios of Section 4.
Blanchet, et al. Expires 28 March 2027 [Page 20]
Internet-Draft IP in Deep Space September 2026
+==============+=================+===============================+
| Scenario | minRTT | maxRTT |
+==============+=================+===============================+
| Earth to | two-way | two-way propagation delay at |
| Cruising | propagation | the farthest planned |
| Spacecraft | delay at the | distance, increasing slowly |
| (CS) | closest planned | over the mission |
| | distance | |
+--------------+-----------------+-------------------------------+
| Earth-Moon | around 2.6 | around 2.6 seconds |
| Full | seconds | |
| Connectivity | | |
| (LF) | | |
+--------------+-----------------+-------------------------------+
| Earth-Moon | around 2.6 | around 2.6 seconds plus the |
| Intermittent | seconds | maximum contact gap |
| Connectivity | | |
| (LI) | | |
+--------------+-----------------+-------------------------------+
| Earth-Mars | 8 minutes | 48 minutes |
| Full | | |
| Connectivity | | |
| (MF) | | |
+--------------+-----------------+-------------------------------+
| Earth-Mars | 8 minutes | 48 minutes plus the maximum |
| Intermittent | | contact gap; 6 hours 48 |
| Connectivity | | minutes with an overpass |
| (MI) | | every 6 hours |
+--------------+-----------------+-------------------------------+
| Solar | not applicable | the conjunction duration, |
| Conjunction | (no direct | around two weeks for Mars, |
| (SC) | path) | plus the maximum two-way |
| | | propagation delay, if the |
| | | communications are kept |
| | | active across the conjunction |
+--------------+-----------------+-------------------------------+
Table 1: minRTT and maxRTT for the Connectivity Scenarios
5.2. Bandwidth-Delay Product (BDP) Calculation
The bandwidth-delay product (BDP) of a path is the product of its
bandwidth and its RTT. It corresponds to the amount of data sent
before receiving the first acknowledgement or response, and is
therefore used, for example, to size transport windows and buffers so
that the available bandwidth of the path can be fully used. For a
path composed of several links, the path bandwidth is the bandwidth
of its bottleneck link. Under intermittent connectivity, part of
Blanchet, et al. Expires 28 March 2027 [Page 21]
Internet-Draft IP in Deep Space September 2026
that data is not in transit but buffered within the network (see
Section 6.1); the BDP is then also an input to sizing the buffers of
the intermediate nodes.
The minimum BDP of a path, named minBDP, is the product of minRTT and
the minimum bandwidth used during those times. The maximum BDP of a
path, named maxBDP, is the product of maxRTT and the maximum
bandwidth.
For example, in the Earth-Moon with full connectivity (LF) scenario
(Section 4.2) with a 100 Mbps radio link, the BDP is around 2.6
seconds times 100 Mbps, that is 260 megabits or around 33 megabytes;
with a 1 Gbps optical link, the BDP is around 325 megabytes.
In the Earth-Mars with intermittent connectivity (MI) scenario
(Section 4.5), assuming a 1 Mbps bottleneck link between the surface
asset and the orbiter, minBDP is 8 minutes (480 seconds) times 1
Mbps, that is 480 megabits or 60 megabytes, and maxBDP is 6 hours 48
minutes (24480 seconds) times 1 Mbps, that is around 24.5 gigabits or
around 3 gigabytes, most of which is buffered within the network
while waiting for the next contact rather than in transit.
6. Requirements
The characteristics described in this document (latency, bandwidth,
unidirectionality, intermittence, topology) vary greatly between
connectivity scenarios; no single set of constraints applies to all
deployments. When evaluating protocol or security solutions against
these requirements, the applicable connectivity scenario (see
Section 4) should be identified first, since the constraints pull
designs in different directions: very low bandwidth links make
handshake-heavy mechanisms impractical, while unidirectional links
preclude interactive exchanges entirely. Requirements in this
section should be read as scenario-dependent and prioritized per
deployment rather than simultaneously binding. Table 2 summarizes
the main constraints of each scenario.
Blanchet, et al. Expires 28 March 2027 [Page 22]
Internet-Draft IP in Deep Space September 2026
+===================+==================+===========================+
| Scenario | One-way delay | Intermittence |
+===================+==================+===========================+
| Earth to Cruising | increases slowly | rare; solar conjunctions |
| Spacecraft (CS) | over the mission | possible on long-distance |
| | | trajectories |
+-------------------+------------------+---------------------------+
| Earth-Moon Full | around 1.3 | exceptional (equipment |
| Connectivity (LF) | seconds | failures, contingencies, |
| | | power-save periods) |
+-------------------+------------------+---------------------------+
| Earth-Moon | around 1.3 | frequent, mostly |
| Intermittent | seconds | scheduled |
| Connectivity (LI) | | |
+-------------------+------------------+---------------------------+
| Earth-Mars Full | 4 to 24 minutes | exceptional (equipment |
| Connectivity (MF) | | failures, contingencies, |
| | | power-save periods) |
+-------------------+------------------+---------------------------+
| Earth-Mars | 4 to 24 minutes | frequent, mostly |
| Intermittent | | scheduled |
| Connectivity (MI) | | |
+-------------------+------------------+---------------------------+
| Solar Conjunction | not applicable | total, scheduled |
| (SC) | (no direct path) | interruption; around two |
| | | weeks in the case of Mars |
+-------------------+------------------+---------------------------+
Table 2: Connectivity Scenarios and their Main Constraints
6.1. Buffers and Store-and-Forward Capabilities
Since full coverage by constellations is expensive to acheive for
each celestial body, any orbiters, surface nodes, or other assets
that are facing intermittent communications may provide a buffering
capability rather than discarding packets when an outgoing route or
link is not immediately available. Buffering packets for a planned
later transmission rather than dropping packets is a type of "store
and forward" behavior. This document uses the term "buffering" in
order to avoid confusion with other uses of the "store and forward"
terminology, and for consistency with how queue management in layer-2
and layer-3 is generally discussed. Implementations might provide
buffering at different layers:
* Layer-1 buffering data to be transmitted without distinction to
frame boundaries ("bag of bits") has been supported in the past,
e.g. by some Mars obiters. In this case, the buffered data can
only follow pre-planned segments, and the processing of upper
Blanchet, et al. Expires 28 March 2027 [Page 23]
Internet-Draft IP in Deep Space September 2026
layers need to be coordinated beyond the relay platform. The
benefit is that relays can be simplified in not processing or
being fully compatible at higher layers.
* Layer-2 buffering outgoing frames is similar to layer-1 in lacking
flexibility for routing, but permitting simplicity and limiting
compatibility needs to the link layer only.
* Layer-3 buffering IP packets enables more versatile, agile, and
policy-based routing. By permitting the IP forwading decision to
be (re)evaluated at the time of tranmission, any changes can be
considered that might have occured since the packet was first
buffered.
In all cases, the buffering capacity is a key consideration in the
node and network design. Mechanisms should be provided to protect
buffer resources, similar to the protection that Active Queue
Management (AQM) and signalling such as Explicit Congestion
Notification (ECN) typically provides in the terrestrial Internet.
Packet addresses, traffic class, flow IDs, or other fields may be
used in determining treatment. This may be needed to support
differentiation of trafic such as Emergency and Search and Rescue.
Proper guards should be designed to avoid denial-of-service attacks
that fill buffers within the network This may include authentication
and authorization of the traffic sources allowed to consume buffer
space, and accounting of storage usage per source or traffic class.
Even though nominal transmission schedules can be calculated based on
known orbits, there is potential for unplanned events resulting in
missed communication windows. For example, a rover may be in a low
battery charge state lacking enough energy to communicate. Different
types of events can randomly disturb plans, such as unpredicted space
weather events, or rescheduling of assets. Even though nominal
communications windows can be calculated, any system should be able
to cope with random long interruption events.
6.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 (see Section 5.1). Given variations
and possible dynamic changes in the network that can cause much
longer latency, appropriate safeguards should be put for timer
values.
Blanchet, et al. Expires 28 March 2027 [Page 24]
Internet-Draft IP in Deep Space September 2026
There are two main challenges that deep space networks pose for use
of timers in loss detection. First, for cases like Mars, the time
needed to infer a loss and request retransmission is much longer than
what protocols are designed for in the Internet, and can be so long
as to preclude retransmission within the same contact window.
Second, for cases where the timing can vary widely, finding
appropriate timeout values and adjusting them automatically may be a
challenge. Mitigating the long propagation delays could be
approached through various techniques such as higher-level erasure
coding (e.g. in application or transport protocols), more aggressive
retransmission policies, or other methods. Mitigating varying delays
can be approached through the use of planning/orchestration systems
to provide guidance on proper values over time, or other methods.
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
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.
6.3. Location
Some IETF protocols such as [RFC5870][RFC8805] use a Earth coordinate
system such as [WGS84] or address-based reference[RFC8805] for
encoding location. Deep space uses various coordinate systems such
as celestial body references[SANACelestialBodyReference] or orbit-
relative references[SANAOrbitRelativeReference]. Therefore, IETF
protocols carrying location information may need to be updated to
also support space coordinate reference systems. An example of such
space coordinate reference system addition for IETF protocols is in
[RFC9179].
6.4. 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.
Blanchet, et al. Expires 28 March 2027 [Page 25]
Internet-Draft IP in Deep Space September 2026
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.
6.5. 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.
6.6. Transport
Since IP (and UDP) do not provide reliable transport services, such
as recovery from against packet loss, duplication, or reordering, a
reliable transport should be used and configured properly for space
delays and intermittence for applications and protocols requiring it.
Congestion control algorithms may sense congestion based on
heuristics like increasing delays or loss/retransmission timer
firings. In response, sources reduce their congestion window or
sending rates to decrease their usage of the network capacity.
However, given that forwarders in space may experience intermittent
connectivity and buffer significantly, typical round trip
measurements may be misleading and loss timer firings may be
spurious. Due to these complications, when connectivity is
intermittent, traditional congestion control should be adapted or
administratively controlled. At least early on, while the networks
are small scale, coordinated resource planning and management may be
performed to avoid creating congestion.
6.7. 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.
Blanchet, et al. Expires 28 March 2027 [Page 26]
Internet-Draft IP in Deep Space September 2026
6.8. 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.
6.9. Energy
Electrical power and energy are constrained in systems operating in
deep space compared to the terrestrial Internet, although with
increasing growth of the Internet of Things (IoT) on Earth, similar
constraints are also present in many terrestrial systems.
Since there are a variety of different types and sizes of deep space
exploration hardware systems, there are different options to generate
power including solar panels or radioisotope thermoelectric
generators (RTGs). Operating off of batteries is common, since
sufficient power is not always able to be generated. In any case,
the available power is limited and when transmitting, a substantial
amount must go to operating amplifiers and other communications
system hardware. Transmissions may be limited to specific times in
order to conserve power and budget it during times when more is not
available to generate (e.g. when operating in lunar "night" on a part
of the moon not exposed to sunlight). Some links and physical layer
protocols operate synchronously and transmit continuously when active
(e.g. using idle frames), while others transmit only data frames and
use "Barker codes" or other burst transmission synchronization
methods.
The implications of this are that there are a variety of different
modes that networking nodes may be in at any time, and some could
manifest as temporary "disconnections", even if there is antenna
visibility and connectivity would otherwise have been schedulable.
Blanchet, et al. Expires 28 March 2027 [Page 27]
Internet-Draft IP in Deep Space September 2026
Since transmission dominates the power budget, protocols may need
asymmetrical behavior to protect the energy resources of constrained
nodes: for example, minimizing the number and size of transmissions
required from the constrained side of an exchange, even at the cost
of additional transmissions from the well-resourced side.
6.10. Asynchronous Operation and Power Save Modes
Spacecraft frequently use power save modes with asymmetric radio
states: the transmitter may be turned off (transmission dominates
power usage) while the receiver remains on, or the node may be
entirely asleep. Combined with network-layer buffering, a
destination may not be listening at the time packets are sent yet
still receive them later. Protocols and applications should
therefore not assume that a peer is continuously reachable or that a
request implies a timely response; since buffered packets are
delivered when the destination is listening again, the notion of the
peers being simultaneously online does not apply. Key exchange and
re-keying mechanisms should be usable asynchronously, tolerating
exchanges that complete over an arbitrary delay.
7. Security Considerations
The CCSDS has created a reference document covering general security
threats against space missions, as well as classes of mitigations
[CCSDS-Threats]. This is a useful high-level reference, though it
does not go into depth on networking protocols.
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.
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.
Blanchet, et al. Expires 28 March 2027 [Page 28]
Internet-Draft IP in Deep Space September 2026
Forward secrecy and post-compromise security have different
properties and requirements and should be considered separately.
Because physical access to deep space assets is generally impossible,
recovery from compromise depends on remote means: mechanisms to
update trust anchors and credentials over the network, designed to
operate under long delays and intermittence, should be part of the
security architecture.
Some envisioned applications are inherently multi-party: astronaut
suit radio networks, space weather alerts, and broadcast navigation
or almanac signals (e.g., the LunaNet Augmented Forward Signal).
Where such one-to-many traffic requires confidentiality or
authentication, group key management adapted to long delays and
intermittence would be needed; the specific protocol layers and
mechanisms are out of scope of this document.
Key establishment and key update mechanisms should be usable
asynchronously: given long RTTs and intermittence, mechanisms
requiring interactive exchanges before new keys take effect create
long windows during which a compromised key remains in use.
Moreover, because packets may be buffered in intermediate nodes, a
peer that is not reachable at the time of transmission may still
receive and process a key update later; key management should
therefore not depend on any notion of the peers being simultaneously
online, but rather tolerate exchanges that complete over an arbitrary
delay. Mechanisms that can establish keys in advance of their use,
or complete key updates without an interactive exchange, should be
preferred.
Devices operating in deep space often have limited computational and
memory resources. Key agreement - especially key updates - should be
efficient and scalable. Given the potential lifetime of space
systems and risk of quantum computing to cryptography, this includes
requirements for efficiency and scalability in use of post quantum
cryptography.
8. IANA Considerations
There are no actions for IANA in this document.
9. References
9.1. Informative References
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Identifier for Geographic Locations ('geo' URI)",
RFC 5870, DOI 10.17487/RFC5870, June 2010,
<https://www.rfc-editor.org/info/rfc5870>.
Blanchet, et al. Expires 28 March 2027 [Page 29]
Internet-Draft IP in Deep Space September 2026
[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>.
[RFC8805] Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
Kumari, "A Format for Self-Published IP Geolocation
Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
<https://www.rfc-editor.org/info/rfc8805>.
[RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations",
RFC 9179, DOI 10.17487/RFC9179, February 2022,
<https://www.rfc-editor.org/info/rfc9179>.
[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]
Space Assigned Numbers Authority, "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>.
[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>.
Blanchet, et al. Expires 28 March 2027 [Page 30]
Internet-Draft IP in Deep Space September 2026
[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_SDLP]
Consultative Committee on Space Data Systems (CCSDS),
"Space Data Link Protocols -- Summary of Concept and
Rationale, Green Book 130.2-G-3", September 2015.
[CCSDS_130.1-G]
Consultative Committee on Space Data Systems (CCSDS), "TM
Synchronization and Channel Coding -- Summary of Concept
and Rationale, Green Book 130.1-G-3", June 2020.
[CCSDS_131.0-B]
Consultative Committee on Space Data Systems (CCSDS), "TM
Synchronization and Channel Coding, Blue Book 131.0-B-6",
June 2020.
[DSN_catalog]
"Deep Space Network Services Catalog, DSN No. 820-100, Rev
F/", February 2015,
<https://deepspace.jpl.nasa.gov/files/820-100-F1.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>.
[SANACelestialBodyReference]
Space Assigned Numbers Authority, "Celestial Body
Reference Frames", May 2023, <https://sanaregistry.org/r/
celestial_body_reference_frames/>.
[SANAOrbitRelativeReference]
Space Assigned Numbers Authority, "Orbit-Relative
Reference Frames", July 2025, <https://sanaregistry.org/r/
orbit_relative_reference_frames/>.
Blanchet, et al. Expires 28 March 2027 [Page 31]
Internet-Draft IP in Deep Space September 2026
[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%20communications%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/>.
[marscommstudy]
Blanchet, M., "Earth-Mars Communication Windows Usage
Study", October 2024,
<https://deepspaceip.github.io/meetings/ietf121/ietf121-
deepspaceip-mars-communications-study.pdf>.
[conjunctionstudy]
McBrayer, K.T., Chai, P.R., and E.L. Judd, "Communication
Delays, Disruptions, and Blackouts for Crewed Mars
Missions", ASCEND 2022, August 2022,
<https://ntrs.nasa.gov/citations/20220013418>.
[marsconjunction]
NASA Jet Propulsion Laboratory, "What's Mars Solar
Conjunction, and Why Does It Matter?", August 2019,
<https://www.jpl.nasa.gov/news/whats-mars-solar-
conjunction-and-why-does-it-matter/>.
[idsis] "International Communication System Interoperability
Standards (ICSIS)", September 2020,
<https://internationaldeepspacestandards.com/wp-
content/uploads/2024/02/
communication_reva_final_9-2020.pdf>.
Blanchet, et al. Expires 28 March 2027 [Page 32]
Internet-Draft IP in Deep Space September 2026
[LNIS] "LunaNet Interoperability Specification - Version 5",
February 2025, <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/>.
[nasamoonbase]
NASA, "Moon Base", June 2026,
<https://www.nasa.gov/moonbase/>.
[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>.
[WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Third Edition, NIMA
TR8350.2", January 2000.
[CCSDS-Threats]
Consultative Committee on Space Data Systems (CCSDS),
"Security Threats Against Space Missions, Green Book
350.1-G-3", February 2022,
<https://ccsds.org/Pubs/350x1g3.pdf>.
[Gateway] Lehnhardt, E. and D. Connell, "The Gateway Program as Part
of NASA's Plans for Human Exploration Beyond Low Earth
Orbit", July 2023,
<https://ntrs.nasa.gov/api/citations/20230014342/
downloads/
IEEE%20-%20Gateway%20Overview%20FINAL%20100223.pdf>.
Blanchet, et al. Expires 28 March 2027 [Page 33]
Internet-Draft IP in Deep Space September 2026
Acknowledgements
This following people have provided valuable feedback and comments,
in no specific order: Roy Gladden, Padma Pillay-Esnault, Tomek
Mrugalski, Atsushi Tagami, Pascal Thubert, Carles Gomez Montenegro,
Martin Duke, Xisen Tian, Dan York, Meiling Chen, Tony Li, Britta
Hale, Eric Rescorla, Michael Richardson, and John Mattsson.
Authors' Addresses
Marc Blanchet
Viagenie
Canada
Email: marc.blanchet@viagenie.ca
Wesley Eddy
Aalyria Technologies
United States of America
Email: wes@aalyria.com
Marshall Eubanks
Space Initiatives Inc
United States of America
Email: tme@space-initiatives.com
Blanchet, et al. Expires 28 March 2027 [Page 34]