An Architecture for IP in Deep Space

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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 3 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Deep-space communications involve long delays and intermittent connectivity due to the distances and orbital motion involved. For instance, Earth to Mars transmissions vary 4-24 minutes, and are unavailable periodically due to rotation, conjunctions, and other conditions.¶

Deep space communications have traditionally been done on a layer-2 point-to-point basis, sometimes using relays, but no layer-3 networking has been in routine use. [RFC4838] reports an assessment done around 25 years ago concluding that the IP protocol stack was not suitable for deep space networking. However, some things have changed since that time, as there has been evolution in multiple areas including Internet transport and security protocols (e.g. QUIC), routing (e.g. SDN), and forwarding technology (e.g. MPLS and Segment Routing), compression (e.g. SCHC), network management, and applications (e.g. HTTP and CoAP).¶

Currently, space agencies have published plans that include deploying IP networks on celestial bodies, such as the Moon [ioag] and Mars [ioag-mars], both on the surfaces and orbiting constellations, including link layer technologies such as Wi-Fi or 5G. On the surface, the plans involve dense networking around facilities and habitats. New mission concepts are also including clusters of multiple networked nodes co-located at Lagrange points.¶

Given the evolution of modern IP application protocol stacks and the new needs of deep space missions, this document describes an architecture for the use of IP in deep space, meeting needs described in [I-D.ietf-tiptop-usecase]. This includes:¶

• running IP over end-to-end paths that include high-latency, deep space layer-2 links,¶
• buffering of IP packets, when needed,¶
• IP addressing and routing,¶
• transport protocol configuration,¶
• application protocols,¶
• and other network services, including network management of deep space IP networks.¶

An aspect of this framework is the potential for queueing outbound packets for upcoming contact opportunities. In this case, the IP layer has to deal with the fact that a next-hop may not be currently reachable and that IP packets could be buffered for an unusual amount of time, such as minutes, hours, or days in the forwarding device waiting for next-hop reachability or a 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. General architecture concerns are described along with suitable ways to address them. Separate documents cover the details of configuring specific protocols, e.g. CoAP, DNS, QUIC, in accordance with this framework.¶

Applying the IP stack and its mature family of standards in deep space enables the reuse of many protocols, tools, and software currently used on the Internet. However, many components of the IP stack cannot be used as-is and require careful configuration and deployment considerations that are discussed in this document.¶

Since the Moon is within a few light seconds away from Earth, it is possible to configure and run typical Internet protocols and applications to basically "work", however, Mars with a much longer delay is more difficult. The framework in this document covers both, and would also work for longer delays, such as reaching Jupiter or the whole Solar System. The focus is on the Moon and Mars because those are where significant numbers of relevant missions are being developed presently.¶

This document uses "deep space" extensively as opposed to "space", as that more generally includes other topics such as terrestrial satellite access, earth-orbiting, and near-Earth missions, which are not covered in this document, and subject of other RFCs (e.g. [RFC2488], [RFC2760], [RFC3135], [RFC9717]). The scope of "deep space" in this document includes the Moon, although this is not strictly within the ITU's definition of the term.¶

The key characteristics of space communications and networking, the relevant use case aspects and requirements are discussed in [I-D.ietf-tiptop-usecase].¶

2. Architecture Overview

This section provides a short overview of this architecture for IP in deep space.¶

One of the key reasons to use IP is to maintain compatibility and potential smooth interoperability with other IP networks that exist terrestrially and within space vehicle onboard networks. While some nodes will require specific deep space protocol support, many nodes within the network can have traditional unmodified IP stacks that remain configured as if for typical Internet uses.¶

Within an end-to-end deep space application data flow, several different types of nodes can be involved:¶

• Unmodified / Internet nodes - These consists of existing "untuned" IP stacks (not necessarily modified in any way for deep space use versus typical Internet use). These can exist within planetary surface networks and spacecraft onboard networks, for example. For instance, these may be the majority of nodes within terrestrial ground systems, mission operations centers, ground stations, and terrestrial backbone networks. Given use of 3GPP architecture in some agency plans, these nodes may be present within onboard or surface core networks.¶

• TIPTOP end-hosts - These nodes include specially tuned transport/application protocol parameters in order to function in deep space scenarios. Within the network, these specially tuned nodes need only exist at application endpoints (or proxies).¶

• TIPTOP forwarding nodes - These are like typical IP forwarding nodes, except include queuing capabilities for IP packets that go beyond normal Internet use, as described more in Section 4. Within the total deep space network, these need only exist at transition points between well-connected regimes and the hops through deep space communication system links. For instance, these may be at the edge of onboard networks or ground station networks.¶

• TIPTOP-full nodes - These nodes combine aspects of TIPTOP end hosts and TIPTOP forwarding nodes. This combination may be useful in cases such as small spacecraft or other vehicles that consist of only a single node that must roam autonomously rather than functioning within a well-connected onboard or surface network regime.¶

• Scheduling/orchestration systems - These systems may typically operate out-of-band from application data flows, but are responsible for creating and distributing coordinated network plans based on projected application needs (e.g. to support planned mission operations schedules). These may only exist within terrestrial or other planetary core networks, but are essential, especially in early growth of deep space networks, in order to provide knowledge of expected connectivity schedules and associated stack parameters.¶

The figure below illustrates a simplified example set of end-to-end of mission network elements based on this taxonomy, with the data flow described following.¶

+------------+  +-------------------+   +--------------------+
|    MOC     |  | Comm Svc Provider |   | Spacecraft/Vehicle |
+------------+  +-------------------+   +--------------------+
|            |  |                   |   |                    |
| TIPTOP     |  |      TIPTOP       |   | TIPTOP    TIPTOP   |
| End-Host   |  |     Forwarder     |   | Forwarder End-Host |
|   |        |  |        |          |   |     |       |      |
| Unmodified |  |    Unmodified     |   |  Onboard Network   |
| LAN        |  |    IP Networks    |   |  Unmodified LAN    |
+---------\--+  +-/-------------\---+   +--/-----------------+
           \     /               \        /
          WAN/VPN              Relay Satellite
         Unmodified            or DWE Services

An example end-to-end command application flow might pass through many nodes, starting within a mission operations center (MOC) at (1) a TIPTOP end-host running command workstation software, and then traversing (2) an unmodified LAN within the MOC, which routes the command packet via (3) an unmodified WAN or VPN connection to a communication service provider (CSP) network. Within the CSP network, there may be (4) unmodified IP forwarding in other WAN, VPN, and LAN nodes, and (5) a TIPTOP forwarder that queues packets and routes according to schedule via (6) unmodified relay or direct communications services towards the destination spacecraft node. At the destination spacecraft/vehicle, there may be (7) a TIPTOP forwarder, (8) an unmodified onboard network, and (9) a TIPTOP end-host.¶

Within this example command path, there are 2 TIPTOP end hosts, 2 TIPTOP forwarders, and 5+ unmodified typical Internet stack nodes (since multiple hops can be involved in the several LAN and WAN traversals). This deep space IP architecture is incrementally deployable.¶

Making the end-to-end example command data flow possible, an orchestration system on Earth can use knowledge of the spacecraft mission and its commanding needs in order to ensure that at proper times there are scheduled communication system resources (antennas, modems, etc.) that are physically pointed, tracking, and otherwise configured to close a forward link to the spacecraft at the required data rate. The orchestration system can also set scheduled routing table entries for the relevant nodes within the path.¶

3. Layer 2 in Deep Space

4. 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.¶

This architecture can support IPv4 and/or IPv6. While some may prefer one version or another, there are important considerations that complicate matters. Deep space links are very low bandwidth. The additional overhead of an IPv6 packet will have a bandwidth and performance impact that needs to be considered early in mission planning. From a future-proofing perspective, IPv6 is to be preferred. Eventually, as technology evolves and the bandwidth constraints are relieved, it would be preferable to not have to retrofit existing, deployed spacecraft with IPv6. Ultimately, however, the IETF does not have authority over this decision. The various space agencies, working in unison, should make this joint decision and select one version for interoperability.¶

7. Applications

While many Web applications already use REST, operating them in deep space requires a concrete deployment and design model that differs from terrestrial assumptions. A functional deep-space Web system would consist of RESTful HTTP (or CoAP) services with explicitly configured timeouts, caching behavior, and asynchronous request handling. Application endpoints are designed to accept long request–response delays, return idempotent resources, and avoid chatty multi-RTT interactions. Content is aggressively pre-cached and replicated at planetary or orbital gateways so that most REST interactions are satisfied locally, while end-to-end exchanges tolerate hours or days of delay. In this model, a “Web app” is not an interactive browser session, but a set of asynchronous REST resources whose state can be fetched, updated, or synchronized opportunistically as connectivity becomes available. This section describes the specific protocol configurations and application patterns needed to adapt existing REST-based systems into such a deep-space-capable Web architecture.¶

9. IANA Considerations

This memo includes no request to IANA.¶

10. 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. Since no change is made in the protocols, this architecture does not bring new security issues on the protocols themselves.¶

However, with longer delays and intermittence, deep space networking brings additional considerations. Security designs must tolerate long validation delays and potentially operate in a disconnected trust model.¶

Certificates and keys need to be renewed before their expiration, taking into account the delay to send, receive and confirm. Protocols such as OCSP[RFC6960] providing on-line real-time validation and revocation check will likely not work given the too long delays, therefore certificates need to be validated using local trust anchors.¶

The use of long term keys, such as ones set prior to launch, may create exposure, therefore keys should be renewed at appropriate frequency.¶

Given possible lower frequency of time synchronization, clock drifts may affect expiration and validation.¶

Intermediate forwarding nodes may buffer packets for a significant time. While it is presumed that most IP packet payloads will be encrypted by IP or transport security, data-at-rest becomes a possible exposure. If the intermediate node is compromised, the data-at-rest becomes available for the bad actor. This is new and not expected on terrestrial Internet intermediate nodes.¶

If bad traffic is injected sufficiently to fill out the intermediate nodes buffer, then this becomes a denial-of-service attack.¶

If some packets are buffered in one intermediate node, If multiple paths are possible to a destination, then bad packet injection may use an alternate faster path that would result in the destination receiving the injected bad packets before the proper ones, which may become denial-of-service attacks of various kinds (destination endpoints buffer full, connection resets, ...). While this scenario can happen on terrestrial Internet, the bad traffic level and the duration window may be orders of magnitude larger than on Internet, therefore having a potentially much larger impact.¶

Given possible short contact windows and relatively few alternate paths, an attacker may flood a link during the whole contact window, disabling any remediation during that contact window, which means the actual impact will remain longer than the actual attack duration.¶

Given relatively few alternate paths, malicious injection of routes may have a larger impact than on terrestrial Internet.¶

Given a sparse network of few nodes and more predictable traffic patterns than terrestrial Internet, traffic analysis may become more effective, even for encrypted traffic.¶

Security considerations of each transport protocol are discussed in their respective transport protocol profile document.¶

Given low bandwidth, low number of alternate paths, high costs of links and nodes high value, access control to the deep space network and related policies should be in place. For example, at the beginning of the deployment, 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 tiptop forwarding node, such as 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.¶

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: Padma Pillay-Esnault, Marius Feldmann, Britta Hale, Carles Gomez Montenegro, Meiling Chen, Marshall Eubanks, Eric Rescorla, Johnson Liu.¶

Authors' Addresses