Internet Engineering Task Force M. Blanchet
Internet-Draft Viagenie
Intended status: Informational W. Eddy
Expires: 2 September 2025 MTI Systems
T. Li
Juniper Networks
1 March 2025
An Architecture for IP in Deep Space
draft-many-tiptop-ip-architecture-00
Abstract
Deep space communications involve long delays (e.g., Earth to Mars is
4-24 minutes) and intermittent communications, because of orbital
dynamics. The IP protocol stack used on Earth's Internet is based on
assumptions of shorter delays and mostly uninterrupted
communications. This document describes the architecture of the IP
protocol stack tailored for its use in deep space. It involves
buffering IP packets in IP forwarders facing intermittent links and
adjusting transport protocol configuration and application protocol
timers. This architecture applies to the Moon, Mars, or general
interplanetary networking.
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 2 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Blanchet, et al. Expires 2 September 2025 [Page 1]
Internet-Draft IP in Deep Space March 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document and Discussion Location . . . . . . . . . . . . 4
2. Layer 2 in Deep Space . . . . . . . . . . . . . . . . . . . . 4
2.1. Celestial Body Surface . . . . . . . . . . . . . . . . . 4
2.2. Deep Space Links . . . . . . . . . . . . . . . . . . . . 5
2.3. Celestial Body Orbits . . . . . . . . . . . . . . . . . . 5
3. Internet Protocol . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IP Forwarding and Store-and-Forward . . . . . . . . . . . 5
3.2. Header Compression . . . . . . . . . . . . . . . . . . . 6
4. IP Addressing and Routing . . . . . . . . . . . . . . . . . . 6
4.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Other Transports . . . . . . . . . . . . . . . . . . . . 8
6. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Network services . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Network Management . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Deep space communications involve long delays (e.g., Earth to Mars is
4-20 minutes) and intermittent communications, because of orbital
dynamics. Up to now, communications have been done on a layer-2
point-to-point basis, with sometimes the use of relays, but no
layer-3 networking has been in use. [RFC4838] reports an assessment
done around 25 years ago concluding that the IP protocol stack was
not suitable for deep space networking. This result led to the
definition of a completely new protocol stack based on a store-and-
Blanchet, et al. Expires 2 September 2025 [Page 2]
Internet-Draft IP in Deep Space March 2025
forward paradigm implemented in the Bundle Protocol(BP) [RFC9171] and
its various components, such as convergence-layer adapters
([RFC9174], [RFC7122]) and BP Security (BPSEC) [RFC9172].
More recently, space agencies plan to deploy IP networks on celestial
bodies, such as the Moon [ioag] or Mars[ioag-mars], on the surface
and in orbital vicinity, using layer 2 technologies such as Wi-Fi or
5G. On the surface, the plan is to have a dense network around
facilities and habitats.
Mission concepts are also based on a cluster of multiple network
nodes nearby at Lagrange points.
A previous document [I-D.many-deepspace-ip-assessment] revisited the
initial assessment of not using IP and concluded that the IP stack is
viable in deep space, given the IP stack evolution that happened
since the original evaluation.
This document defines an architecture to use IP in deep space
networking. IP in deep space means running IP over deep space
layer-2 links, a reliable transport over IP, applications protocols
over that transport, and applying proper routing, security, and
network management on that IP network. Reusing the whole IP stack in
deep space enables the reuse of all protocols, tools, and software
currently used on the Internet. However, as one might already argue,
many components of the IP stack cannot be used as is and therefore
requires careful configuration and deployment considerations that are
discussed in this document.
Delay-Tolerant Networking (DTN), also known as Delay and Disruption-
Tolerant Networking, has been used to identify the problem space, and
since the solution was based on the Bundle protocol, DTN has also
been associated with the Bundle protocol. This document tries to
solve the DTN problem using the Internet Protocol stack. Therefore,
in this document, the DTN keyword is used to name the problem space,
not the Bundle protocol solution.
Since the Moon is a few light seconds away from Earth, it is possible
to configure and run various IP-based protocols and applications to
make it "work". Mars with a much longer delay is more difficult.
This framework would also work for longer delays, such as reaching
Jupiter or the whole Solar System Internet (SSI), but it is not
specifically discussed. This document uses "deep space" extensively
as opposed to "space" which often includes earth-orbiting
communications, which are not covered in this document. Even if the
definition of deep space per the ITU does not include the Moon, this
document applies to IP networks on the Moon.
Blanchet, et al. Expires 2 September 2025 [Page 3]
Internet-Draft IP in Deep Space March 2025
It should also be noted that DTN and BP were also designed for non-
space use cases. While this document focuses on the deep space use
case, it shall work for the other use cases of BP, but these use
cases are outside of the scope of this document.
As with the Bundle protocol, this framework proposes to use IP in
deep space with a similar store-and-forward paradigm. Therefore, the
IP layer has to deal with the fact that a destination may not be
currently reachable and that IP packets could be stored for an
unusual amount of time, such as minutes, hours, or days, in the
forwarding device waiting for reachability back because of a new
link-up opportunity. The transport layer should be able to work with
long and variable delays, including intermittent communications. The
application protocols and the applications themselves should be
properly set to wait a longer time than on the current Internet to
receive a response to a query. Finally, all network services such as
routing, security, naming, and network management should also be
adapted to this new context. This document is structured around
these layers.
The key characteristics of space communications and networking, its
use case and its requirements are discussed in another
document[I-D.many-tiptop-usecase].
1.1. Document and Discussion Location
The source of this document is located at
https://github.com/marcblanchet/draft-deepspace-ip-architecture.
Comments or changes are welcomed using a PR or an issue.
This subject should be discussed on the deepspace@ietf.org mailing
list.
2. Layer 2 in Deep Space
2.1. Celestial Body Surface
The Interagency Operations Advisory Group (IOAG) [ioag] has defined
the communications architecture for the Moon and Mars. On the
celestial body surface, it is planned to use 3GPP and Wi-Fi link
layer protocols. IP will be used over these link layers.
Blanchet, et al. Expires 2 September 2025 [Page 4]
Internet-Draft IP in Deep Space March 2025
2.2. Deep Space Links
Deep space links typically use the Consultative Committee for Space
Data Standards (CCSDS) [CCSDSWEB] standards for link layers, such as
Telecommand (TC) [CCSDS_TC], Telemetry (TM) [CCSDS_TM], Advanced
Orbiting Systems (AOS) [CCSDS_AOS], Proximity1 (Prox1) [CCSDS_PROX1]
or the Unified Space Data Link Protocol (USLP) [CCSDS_USLP]. CCSDS
has defined a generic encapsulation mechanism for the payloads for
all these link layer protocols with IP as an encapsulated protocol
[IPoverCCSDSSpaceLinks] [SANAIPEHeaderRegistry]. Therefore, IP
packets can be transported over any CCSDS link layers.
2.3. Celestial Body Orbits
For celestial body orbits, IOAG has planned the use of CCSDS link
layer protocols. However, as on Earth, it may be possible to use 6G-
NTN technology around celestial bodies, such as in lunar or Martian
orbits. 6G-NTN technologies use IP as its layer 3 technology.
3. Internet Protocol
IPv4 or IPv6 packets can be carried as is over long delays and
disruptions, as IP has no notion of time. Originally, the Time To
Live (TTL) field of IPv4 was defined based on time [STD5], but it has
been effectively implemented as a hop count, which was renamed as
"Hop Count" in IPv6 [STD86]. Nothing needs to be changed to the IP
protocol or its packet format.
3.1. IP Forwarding and Store-and-Forward
For deep space applications, an IP packet may need to be stored
temporarily over much longer periods than are typical for the
Internet when the next hop is currently unreachable or undefined,
which can happen due to orbital dynamics. This is commonly referred
to as "store-and-forward" and bears no relationship to the same term
when used regarding switch architectures.
This store and forward mechanism may be implemented at layer 2 as is
currently done by the Mars orbiters. In this case, the frames are
stored, regardless of payload type. In this case, IP packets are
unaware of the store-and-forward and no changes are needed in the IP
forwarding function. The L2 network is just behaving as a point-to-
point link with a large and variable latency.
If an IP forwarder has an interface on an intermittent link, and that
link is down, some destinations may become unreachable when there is
no alternate route. In this case, the forwarder store the packets
locally instead of dropping them. This might be implemented as a
Blanchet, et al. Expires 2 September 2025 [Page 5]
Internet-Draft IP in Deep Space March 2025
deep queue with active queue management (AQM) [RFC7567]. When the
route to the destination is back, on the same link or a different
link, maybe minutes or hours later, the stored packets can be
transmitted.
This store-and-forward mechanism requires proper provisioning of
storage for the target deployment and usage. If the storage is full,
then packets must be dropped. The choice of which packets to drop
depends on the policies configured on the node, which may be a
function of traffic class, source or destination IP addresses, flow
labels, or other parameters. An example is described in
[I-D.blanchet-tvr-forwarding].
3.2. Header Compression
Deep space links are point-to-point links and bandwidth in space is
very valuable, so header compression is very effective. Static
Context Header Compression (SCHC) [I-D.ietf-schc-architecture] is a
header compression technique that relies on rules in a static context
and is, therefore, more efficient for deep space. SCHC should be
considered on a deep space point-to-point link or a string of L2
links.
4. IP Addressing and Routing
4.1. Addressing
The IP address space is a hierarchical namespace where ranges of
addresses are encoded as "prefixes". Individual domains advertise
prefixes to the broader Internet and assign these addresses
internally. Prefixes may be aggregated into less-specific prefixes,
which makes the routing subsystem more efficient by decreasing
overhead.
Space networks provide a unique opportunity to provide extremely
efficient routing by assigning a unique prefix or block of addresses
per celestial body and its proximal orbits. Management of the IP
address space is currently documented in [RFC7020], but this only
covers continental regions and does not provide for addressing for
space.
Address space for outer space should be managed by a Regional
Internet Registry (RIR) and blocks of address space should be
allocated for each celestial body of interest. Space service
providers should use prefixes assigned by this RIR.
Blanchet, et al. Expires 2 September 2025 [Page 6]
Internet-Draft IP in Deep Space March 2025
4.2. Routing
Existing routing protocols require proof of liveness between protocol
partners, implemented through the periodic exchange of packets
between partners. This is impractical on long-delay or intermittent
links, so a PCE [RFC4655] based approach seems appropriate for those
domains possibly supplemented by contact plan
schedules[I-D.ietf-tvr-schedule-yang]. Interconnection between
domains can still be done with BGP [RFC4271], but long-delay or
intermittent links should be avoided. Domains straddling such links
must provide proxy advertisements for prefixes reachable across such
links.
Optimal routing for domains with intermittent links is out of scope
for this document.
On the surface of celestial bodies and in proximal orbit, traditional
protocols are applicable and should be used (e.g., [RFC9717]).
5. Transport
5.1. UDP
UDP [RFC768] has no notion of time and, therefore can be used as-is
in deep space. Hence, protocols using UDP transport can be used in
space as-is, if they do not rely on time or can be configured with
timeouts appropriate in deep space.
5.2. QUIC
QUIC [RFC9000] like most IP transport protocols implements congestion
control mechanisms, which, based on various metrics such as
calculated delays or packet loss, pace the rate of sending packets at
the source node to decrease the perceived congestion in the network.
QUIC supports many new features suitable and useful in deep space
such as 1 RTT for connection establishment and security, mobility, 0
RTT, streams, user space, etc. [TLI: This sentence needs more words
to explain these references.]
Blanchet, et al. Expires 2 September 2025 [Page 7]
Internet-Draft IP in Deep Space March 2025
Current implementations of QUIC typically set various transport
configuration parameters suitable for the Internet environment,
expecting an RTT to be in the hundreds of milliseconds and a normally
always-connected network. Therefore, QUIC stacks using default
configurations will not work in deep space. However, studies and
simulations [quic-sim] showed that with proper configuration of
parameters, QUIC stacks can support the delays and disruptions in
deep space. [I-D.many-deepspace-quic-profile] describes how to
properly configure a QUIC stack for deep space applications, where
QUIC is unaware of disruptions. If the transport is aware of the
disruptions, further optimizations are possible.
Having multiple streams and applications within a single QUIC
connection is valuable and useful for deep space. A ground station
may set up the initial QUIC connection with a spacecraft and then
carry all needed applications and streams over that same connection
for the whole duration of the mission.
Session keys and certificate lifetimes together with certificate
validation and trust chain anchors need to be carefully configured
and handled.
QUIC proxies [I-D.ietf-masque-quic-proxy] can be used at the edge of
space to isolate, apply policies, or optimize traffic at the ingress/
egress to a celestial body network.
5.3. Other Transports
Other transports such as TCP [RFC9293], SCTP [RFC9260], DCCP
[RFC4340] and others were not investigated for their suitability in
space.
6. HTTP
HTTP by itself has no notion of time. An HTTP request and response
may take minutes or hours to be completed. However, current
infrastructure and software on the Internet have various time-related
configurations that will not work well in the deep space context.
HTTP headers containing time, such as Cache-Control and Expires
[RFC9111], should not be used or if used, must be set to large enough
values to cover the longest delay so that expiration does not happen
before the actual data arrives at the destination. As with any HTTP
application and content on the Internet, these headers should be set
properly based on the deployment use case, which is even more
important for deep space. Similarly, when continuous content
transfer is used, as with 100-Continue [RFC9110], proper values for
headers should be set.
Blanchet, et al. Expires 2 September 2025 [Page 8]
Internet-Draft IP in Deep Space March 2025
HTTP clients and servers typically have default timeouts that should
be modified. For example, curl [curl] has the "-m" option for this
use case. Similarly, HTTP server implementations have various
timeout configuration variables that must be set properly. Testing
with HTTP client Curl and HTTP server nginx and an introduced network
delay of minutes, hours and days showed[quic-sim] that HTTP
communications work well with basic configuration changes.
HTTP applications themselves must be developed using an asynchronous
pattern and if they have timeouts, they should be adjusted
appropriately.
Internet websites are designed with the assumption of hundreds of
milliseconds delay and relatively always connected, where pages
contain multiple queries to get further resources, media, queries to
web services, and downloading additional code and frameworks. This
could work in theory in space, but it will not be optimal, as
multiple queries will be generated and therefore take multiple RTT
before the whole page is received complete. This issue can be
mitigated by using various techniques such as Web Assembly [wasm] or
pre-caching. Moreover, it could be possible to have simple HTML
pages with no or very few references and no media content that was
not locally cached. An example would be a rover on Mars presenting
an HTTP server with a base and bare HTML page to offer basic info on
its status (maybe all in text) and some additional detailed pages,
most likely also in base HTML text. However, it is foreseen that
most applications based on QUIC-HTTP transport in deep space would be
using REST or similar asynchronous patterns and not typical web
browsing.
Caching should be used extensively on space networks to maximize
local fetching. Preemptive caching by pre-populating caches with
data that shall be used locally on the celestial body network shall
be done as much as possible to provide better response time on the
local celestial body network.
QPACK [RFC9204] should be considered for higher bandwidth efficiency.
7. Network services
7.1. Naming
For small-scale deployments, one can use IP addresses directly or a
mapping from a name to an IP address such as /etc/hosts. However,
this does not provide easy dynamic updates, scaling by hierarchy,
service discovery, authentication of records, etc. Therefore, the
Domain Name System (DNS) shall be considered early on in the space
deployment. However, naming hierarchy and infrastructure must be
Blanchet, et al. Expires 2 September 2025 [Page 9]
Internet-Draft IP in Deep Space March 2025
carefully designed to avoid name resolution over deep space links,
given that answers may come after minutes or hours. There are clear
advantages of having the space name hierarchy anchored to the current
Internet root, as it enables DNSSEC through the same security
infrastructure currently used and deployed. Using the same root also
does not require new policies. A new TLD or a new root is way more
complicated and does not bring any significant value compared to
using the current domain tree.
Care must be taken to manage key lifecycles and resource record
lifetimes. [I-D.many-dnsop-dns-isolated-networks] discusses the
various methods and the naming hierarchy that should be used in
space.
7.2. Network Management
NETCONF [RFC6241] and RESTCONF [RFC8040] shall be used with proper
configuration values to avoid timeouts and appropriate transport.
NETCONF over QUIC transport [I-D.ietf-netconf-over-quic] or RESTCONF
over HTTP over QUIC transport shall be configured with appropriate
QUIC transport parameters as discussed in Section 5.2.
While being declared historic in IETF, SNMP[RFC1157] runs over UDP
and has no notion of time. Therefore, with proper configuration of
client timeout, it can be used as is to manage nodes and services in
deep space.
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
Using the current IP protocol stack in deep space inherits all the
work on privacy, cryptography, key management, firewalls, and
scrutiny of protocols that are deployed on the Internet. As an
example, TLS has been more carefully examined than almost any other
secure transport protocol. Moreover, given that no changes are made
in the protocols, this architecture does not bring new security
issues on the protocols themselves. Deep space security requirements
are different than on the existing Internet, but nothing has been
found to prevent the conformance of the IP protocol stack to those
requirements.
As it is currently planned, the deep space network shall be isolated
from the current Internet by an "air gap", to disable any direct
communications from the Internet to deep space. Moreover,
destination IP prefix filtering shall be used to restrict the traffic
Blanchet, et al. Expires 2 September 2025 [Page 10]
Internet-Draft IP in Deep Space March 2025
to only the relevant one for each link. Note that this shall also be
implemented in the routing control plane, but additional security
might be appropriate to further protect the deep space links.
Each celestial network edge device shall have firewall rules to
prevent inappropriate traffic from entering deep space links. If
communications from Mars may only occur to Earth, but not to the
Moon, then appropriate filtering based on destination IP prefixes
shall be used.
Storage in IP forwarders may become full by normal traffic or by
malicious traffic that could become a denial-of-service attack.
Appropriate policies and measures should be put in place in those
forwarders to drop packets in advance to avoid the depletion of
storage space and to mitigate such attacks.
10. References
10.1. Informative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990,
<https://www.rfc-editor.org/info/rfc1157>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
Blanchet, et al. Expires 2 September 2025 [Page 11]
Internet-Draft IP in Deep Space March 2025
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020,
DOI 10.17487/RFC7020, August 2013,
<https://www.rfc-editor.org/info/rfc7020>.
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122,
DOI 10.17487/RFC7122, March 2014,
<https://www.rfc-editor.org/info/rfc7122>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
Blanchet, et al. Expires 2 September 2025 [Page 12]
Internet-Draft IP in Deep Space March 2025
[RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence-Layer Protocol Version
4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>.
[RFC9204] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022,
<https://www.rfc-editor.org/info/rfc9204>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9717] Li, T., "A Routing Architecture for Satellite Networks",
RFC 9717, DOI 10.17487/RFC9717, January 2025,
<https://www.rfc-editor.org/info/rfc9717>.
[STD5] Internet Standard 5,
<https://www.rfc-editor.org/info/std5>.
At the time of writing, this STD comprises the following:
Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<https://www.rfc-editor.org/info/rfc919>.
Mogul, J., "Broadcasting Internet datagrams in the
presence of subnets", STD 5, RFC 922,
DOI 10.17487/RFC0922, October 1984,
<https://www.rfc-editor.org/info/rfc922>.
Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August
1985, <https://www.rfc-editor.org/info/rfc950>.
Blanchet, et al. Expires 2 September 2025 [Page 13]
Internet-Draft IP in Deep Space March 2025
Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[STD86] Internet Standard 86,
<https://www.rfc-editor.org/info/std86>.
At the time of writing, this STD comprises the following:
Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[I-D.blanchet-tvr-forwarding]
Blanchet, M., "Forwarding in the context of Time-Variant
Routing(TVR)", Work in Progress, Internet-Draft, draft-
blanchet-tvr-forwarding-00, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-blanchet-tvr-
forwarding-00>.
[I-D.ietf-masque-quic-proxy]
Pauly, T., Rosenberg, E., and D. Schinazi, "QUIC-Aware
Proxying Using HTTP", Work in Progress, Internet-Draft,
draft-ietf-masque-quic-proxy-04, 18 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
quic-proxy-04>.
[I-D.ietf-netconf-over-quic]
Dai, J., Yu, S., Cheng, W., Blanchet, M., and P.
Andersson, "NETCONF over QUIC", Work in Progress,
Internet-Draft, draft-ietf-netconf-over-quic-02, 25
February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-over-quic-02>.
[I-D.ietf-schc-architecture]
Pelov, A., Thubert, P., and A. Minaburo, "Static Context
Header Compression (SCHC) Architecture", Work in Progress,
Internet-Draft, draft-ietf-schc-architecture-04, 6
February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-schc-architecture-04>.
[I-D.ietf-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "YANG Data Model for Scheduled Attributes", Work
in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang-
03, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
schedule-yang-03>.
Blanchet, et al. Expires 2 September 2025 [Page 14]
Internet-Draft IP in Deep Space March 2025
[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>.
[I-D.many-tiptop-usecase]
Blanchet, M., Eddy, W., and M. Eubanks, "IP in Deep Space:
Key Characteristics, Use Cases and Requirements", Work in
Progress, Internet-Draft, draft-many-tiptop-usecase-00, 21
February 2025, <https://datatracker.ietf.org/doc/html/
draft-many-tiptop-usecase-00>.
[I-D.many-deepspace-quic-profile]
Blanchet, M., "QUIC Profile for Deep Space", Work in
Progress, Internet-Draft, draft-many-deepspace-quic-
profile-00, 19 October 2024,
<https://datatracker.ietf.org/doc/html/draft-many-
deepspace-quic-profile-00>.
[I-D.many-dnsop-dns-isolated-networks]
Blanchet, M., "Domain Name System in Mostly Isolated
Networks", Work in Progress, Internet-Draft, draft-many-
dnsop-dns-isolated-networks-01, 5 November 2023,
<https://datatracker.ietf.org/doc/html/draft-many-dnsop-
dns-isolated-networks-01>.
[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>.
[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>.
Blanchet, et al. Expires 2 September 2025 [Page 15]
Internet-Draft IP in Deep Space March 2025
[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>.
[wasm] World Wide Web Consortium(W3C), "WebAssembly
Specifications", <https://github.com/webassembly/spec>.
[ioag] 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>.
[ioag-mars]
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>.
[curl] "Curl", <https://curl.se>.
[CCSDSWEB] CCSDS, "Consultative Committee for Space Data Systems",
<https://ccsds.org>.
[quic-sim] Blanchet, M., "Deep Space IP: Some simulation results",
July 2024,
<https://deepspaceip.github.io/meetings/ietf120/ietf120-
deepspaceip-simulation-results.pdf>.
Blanchet, et al. Expires 2 September 2025 [Page 16]
Internet-Draft IP in Deep Space March 2025
Acknowledgements
This work started by reassessing the use of the whole IP stack in the
context of deep space discussed in [I-D.many-deepspace-ip-assessment]
where early contributors are acknowledged.
This document and its underlying work has been reviewed and discussed
by many, who have provided valuable feedback and comments, including
disagreements, and made an overall more solid document. These people
are, in no specific order: Padme Pillay-Esnault, Marius Feldmann,
Britta Hale.
Authors' Addresses
Marc Blanchet
Viagenie
Canada
Email: marc.blanchet@viagenie.ca
Wesley Eddy
MTI Systems
United States of America
Email: wes@mti-systems.com
Tony Li
Juniper Networks
United States of America
Email: tony.li@tony.li
Blanchet, et al. Expires 2 September 2025 [Page 17]