| Internet-Draft | IP in Deep Space | March 2025 |
| Blanchet, et al. | Expires 2 September 2025 | [Page] |
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.¶
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 (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. 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.¶
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-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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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].¶
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.¶
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.¶
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]).¶
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.¶
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.]¶
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.¶
Other transports such as TCP [RFC9293], SCTP [RFC9260], DCCP [RFC4340] and others were not investigated for their suitability in space.¶
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.¶
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.¶
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 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.¶
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.¶
This memo includes no request to IANA.¶
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 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.¶
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.¶