Seeing Moon base internet functionality in Worldbuilding reminded me of how I began an old Space SE question Are there discussions or plans for extending the internet into space beyond Earth?

Many years ago I remember reading about the upcoming implementation of the internet protocol IPv6 - which is now in place. In that article it mentioned that there was some discussion about space - I mean outer space, not namespace. At the time, it seemed that the author was not just speculating, but that they were actually referring to some plans or at least calculations.

I would still like to see if this can be tracked down, and to find out if I'm mis-remembering, or mis-understood, or if the development of IPv6 or earlier explicitly took interplanetary distances or needing enough IP addresses for the whole solar system into consideration, or if it was just some creative journalism.


6 Answers 6


The address space is only one (maybe the easiest to solve) problem you'd have when extending Internet protocols beyond earth, especially with a supposed pretty low number of projected extraterrestrial nodes for the foreseeable future.

A much bigger problem is the end-to-end delay. With anticipated packet delays of several minutes, the concept of the traditional TCP/IP networks is not able to cope - Traditional TCP/IP (regardless of whether it's v4 or v6) will try and open up the TCP window to immense sizes in order to accomodate throughput, requiring immensely large buffers on both ends of the connection.

Other concepts that address the store-and-forward problem on both ends of the high-latency connections would be needed. There indeed have been studies in various places (like the "Interplanetary Internet" study at NASA's JPL) to address such issues. These studies are, however, not directly connected to IPv6 development (or were rather put in place after the IPv6 standardisation).

Also note that, courtesy of Mr. Kepler, an interplanetary network is a mobile network (albeit with relatively predictable mobility) by nature - something IP (v4 or v6) has not exactly been designed for. It has no mechanisms to detect a shortest path across several hops that are moving dynamically. So, IP is probably not well-prepared for this use case.

There's even a standard body that standardizes encapsulation of IP packets into space-grade transmission protocols.

All of the above are strategies to keep connectivity alive even on long-roundtrip, low-stability connections.

Then again, that is only a very small aspect of what makes up "the Internet". Today, a lot of Internet applications are interactive and thus directly rely on response times. When we go as far with development of the human race as evolving into a spacefaring society, we might just as well extrapolate the development of artifical intelligence - A server application should, in that far future, be able to "guess" the far-away user's next potential action(s) with high accuracy and already provide the proper answer(s) to that, rolling back on the server side in case the user actually decides on something different on the next round-trip.

You could, however, assume that once we've left the solar system (with, like 8 or 9 possible hops), we'd have acquired a method to travel faster than light, and would consequently have developed a method to communicate faster than light, thus leading to a re-introduction of IPv6 once the Warp drive is invented ;)

  • Thanks, this is helpful. I understand that it may be difficult now to find out "...if the development... explicitly took interplanetary distances or needing enough IP addresses for the whole solar system into consideration" which is different than "would they have" or "could they have" or "has anyone else". It's hard to prove a negative and "I read somewhere that..." questions are not very helpful. A smoking gun would be a list that different planets had different IP blocks reserved for them or something like that.
    – uhoh
    Commented Oct 22, 2020 at 8:54
  • 9
    @uhoh You very probably won't find that smoking gun. One of the main failures with IPv4 in hindsight was "we have so many addresses, let's segment them in Class A, B and C networks, for huge, medium and small bodies", a decision which wasted so much of the actual address space that it exhausted the IPv4 pool earlier than actually necessary (or at least led to a very unfair distribution of this space). IPv6 has avoided this segmenting from the ground up.
    – tofro
    Commented Oct 22, 2020 at 9:05
  • 5
    obligatory link en.wikipedia.org/wiki/IP_over_Avian_Carriers
    – Carsten S
    Commented Oct 23, 2020 at 16:13
  • @tofro: Another issue is that IP was set up based on the concept that all devices have the same kind of directly-routable address, even though the dominant usage pattern involves client-server relationships where servers need to be globally reachable from anywhere, but clients only need to be reachable by servers with whom they have initiated communications. If there were a TCP/UDP hybrid which was connection oriented (like TCP), but would send discrete datagrams over established connections without ordering or delivery guarantees (like UDP), then the message used to establish a connection...
    – supercat
    Commented Oct 23, 2020 at 19:05
  • 1
    Have you heard of IPFS? decentralized content-based addressing, instead of location based. Commented Oct 23, 2020 at 22:19


One of the members of the committee designing ipv6, Andrew S Tanenbaum, wrote many about their decision processes and considerations in his book "Computer Networks". The for us important part is in the chapter 5.6.3:

  1. Interplanetary communication is not even mentioned. Not even indirectly.
  2. Nothing is mentioned what is a real problem of the current ipv4 system, not even indirectly.
  3. Their "standard" "solved" a lot of problems (for example, the so-named "exhausting of the ipv4 address space"), which were solved long ago, without them.
  4. On a "language of flowers", one can read upon the text, that this committee was very far from thinking even into the short future, and Tanenbaum, indirectly, admits it.

About the interplanetary distances: they cause a huge, unavoidable packet delay on an ip network. The design of the IP standard has nothing to do about the delays, or it would require at most the tuning of some timeout constants (for example, maybe arp cache timeouts should be increased; but these will surely happen in practical system even without a standard change, and have little to do to ipv6).

Ip (v4 or v6, does not matter) could work with such packet delays without any problem. The applications using it would not. The problems are on higher levels - for example, file transfer over a TCP connection would surely need more sophisticated algorithms. To increase the perceived response time, probably

  • large caching
  • error fixing data coding
  • multicasting
  • and re-sending of the bad packets

will be also needed. Probably an increase of the unidirectional protocols (like a radio sending) will be also useful.

These all happen over the IP level today, ipv6 did not improve anything in this matter.

P.s. Moon is a special case to other planets - signal transfer causes $\approx$ 1.2s delay there. Between the Moon and the Earth, even an unmodified IP network is possible, for example, by laser communication. This will be a slow, but usable network. To the Mars, the delay is at least 20 minutes, and this is already too much, and most apps would timeout. Against, these don't depend on the IP parameters, but on the usual behavior of most network applications.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Commented Oct 23, 2020 at 17:15

There was no need, because an appropriate protocol was created instead.

Licklider Transmission Protocol (LTP) was explicitly designed to replace TCP/IP and UDP for long-distance networked communications in space. LTP was conceived in 2008, which was still some time before IPv4 address exhaustion and the more widespread adoption of IPv6. It also predated any serious possibility of longer-term trips to the Moon or Mars. (And it was also before this website existed!)

LTP has the concept of "red" and "green" parts, where "red" parts require error-checking and handshaking to ensure lossless transmission, and "green" parts are allowed to contain errors (or even not arrive at all). These correspond fairly closely to the requirements of TCP/IP and UDP respectively.

One significant difference is that LTP is a point-to-point protocol. In practise of course this is not an obstacle, because communications beyond Earth require a dedicated transmitter aimed accurately at the receiver, and there is little possibility of multiple transmission paths.

  • If I were a colonist on Mars, I'd probably consider the availability of multiple transmission paths - e.g. relaying the signal via different satellites in orbit around Mars, and rockets en route through the solar system - as rather a useful feature.
    – IMSoP
    Commented Oct 23, 2020 at 16:53
  • @IMSoP Why? How do you think that would help, or even be physically possible? Remember that every transmission path needs a dedicated antenna transmitting a narrow beam at that precise location, so the kind of ad-hoc routing of TCP/IP is impossible.
    – Graham
    Commented Oct 23, 2020 at 17:54
  • @Graham Well, if you assume a full solar system of populated planets needing connectivity, that definitively makes sense. If you also consider that planets tend to move relative to each other, you might imagine that a connection from Uranus to Mercury would need to be routed via different planets (and maybe additional relay stations) depending on the exact momentary constellation of planets. A peer-to-peer link between Earth and Mars obviously wouldn't require that.
    – tofro
    Commented Oct 24, 2020 at 22:36
  • @tofro Still not convinced, I'm afraid. Automatic network-scanning multi-path routing like TCP/IP requires very low delays on all paths, and also requires that the cost of traffic on all paths is zero. (Or at least so cheap as to be irrelevant.) Both those assumptions can't be true for deep-space links.
    – Graham
    Commented Oct 25, 2020 at 0:24
  • @tofro As for routing, the orientation of planets is known. It's trivial to work out what routing options are most effective for the target planet (or possible, considering eclipses) and send on the best transmitter path. That needs plotting of orbits to pick the right transmitter, not spewing packets on all transmitters.
    – Graham
    Commented Oct 25, 2020 at 0:30


No, as IPv6 does not work that way.

The Long Read

While IPv6 does carry several changes and enhancements/simplifications of protocol handling, none of them are about latency. It's main feature is an increased address size to 128 bit. That's more than enough to give each possible planet in the visible universe a dedicated address range the size of the IPv4 network (*1). More so right now only 1/8th of this range can be used at all.

More important here is that segmentation of IPv6 does not of the same hard structured kind as with IPv4. Block allocation is way more dynamic and 'rightsized'. There is no need to give 'territorial' addresses but rather provider orientated, so feel free to open one or multiple providers on the moon (*2).

What it does not solve are basic interplanetary communication issues. Store and forward systems like mail - or basically anything batch (file transfer) orientated (*3) - will work fine and at line speed (*4), even over interplanetary distances. But any kind of interactive services that requires genuine user input will suffer full round trip time, no matter what protocol (*5).

*1 - Back of an envelope calculation:

  • There are about 10^78 atoms in the visible universe.
  • 10^25 atoms are roughly in a kg of matter
  • Earth got about 6*10^24 kg, so lets use 10^25
  • This gives us enough matter for 10^(78-25-25) or 10^28 planets.
  • An IPv6 address is 128 bit,
  • IPv4 is 32 bit,
  • leaving 2^96 IPv4 sized networks (or names) for planets.
  • 2^96 is 8*10^28

And yes, like any such estimation there are many arguments to push it a few magnitudes to either side - like that only a rather small amount of matter would exist in form of planets - still, 2^128 is a pretty big number way past anything mankind needs ... then again, we are known to be rather wasteful, so I'd better hedge my bets :))

*2 - For world building this means provider wars and great firewalls do work on the moon as well :)

*3 - This includes any database like news aggregation or, well, Wikipedia. Of course, concurrent edited databases experience way more colliding edits, but will work quite fine in reading mode. I expect any future manned spacecraft and colony to have read only copies of Wikipedia maintained by continuous update service. And at some point (world building) a bad mood about cultural domination by Earth :)

*4 - Simply by using (much) larger packet windows (local buffer memory isn't expensive in such a setting), as well as multiple hops each doing store and forward.

*5 - One my envision some kind of 'user support' AI that returns possible answers, before the full request has been received. Of course that only works with requests that includes a lot of data, providing a chance to answer ahead of receiving the full request.

Similar when a request results in multiple answers, they could be sent interleaved and in a refining way. Much like sending first a low resolution image and then adding to it, so a decision how to proceed can be taken early on. Much like (good) web pages are made to work well on slow connections.

  • Re your last paragraph: When packet delay is a large (main) issue, you'll probably want to do exactly the opposite of what you propose: Instead of sending a response that gives a preliminary impression of what to expect, applications may want to send as much of a detailed response back (that contains all information the requestor might probably want to know) as bandwidth allows, instead of waiting just another roundtrip for the details.
    – tofro
    Commented Oct 22, 2020 at 10:18
  • Inerplanetary connections are not necessarily slow (laser transmission, for example, can provide pretty impressive bandwidth, even on such long trajectories), but are, thanks to Mr. Einstein, bound to the speed of light, such that round-trip delay is a much more serious issue.
    – tofro
    Commented Oct 22, 2020 at 10:18
  • It's possible that all I'd read at the time is a sentence very similar to "That's more than enough to give each possible planet in the visible universe a dedicated address range the size of the IPv4 network" and that's what I'm remembering.
    – uhoh
    Commented Oct 22, 2020 at 10:39
  • @tofro Err. No. I guess that could be misinterpreted. The idea is not sending a smaler dataset and then waiting for a request for details, as this would, as you rightful mention, increase response. The point is about sending the data progressive, i.e. in an order that allows preliminary display, even when only part of the answer is received. thus giving the receiver a chance to formulate a finer selection before all data is received. Or ignore unwanted parts of the message, eventually canceling the transmission from the last intermediate station saving bandwidth.
    – Raffzahn
    Commented Oct 22, 2020 at 12:41
  • 2
    For a clear and amusing characterization of the interplanetary RTT problem, read Asimov's story "My Son, the Physicist." (Collected in Nightfall and Other Stories)
    – Mark Wood
    Commented Oct 22, 2020 at 18:21


Not an answer about IPv6, per se, but apropos to "IP in space" is a recent Quanta interview with Vincent Cerf, where he mentions the development of Delay-Tolerant Networking, which uses "bundle protocols". It's packet-switched like IP, but allows nodes to store packets rather than dropping them, waiting for an opportune time to reconnect with the rest of the network. It is neither an evolution of nor a competitor to IPv6 because the protocol is more expensive in a high-reliability, high-throughput environment. They are complementary, so it would not have been advantageous for the IPv6 designers to consider a DTN mode.

  • 2
    I saw a presentation from Vinton Cerf some 20 years ago where he was talking about this at a conference. Very cool stuff. As I remember it, he did tie it to IPv6, but it's possible I'm misremembering. He also had some neat photos of some 50 bps packet-radio-in-a-van from like the 60s.
    – Brad
    Commented Oct 23, 2020 at 4:36
  • 1
    And if we are talking about other protocols, higher level protocols like NNTP (Usenet) or SMTP (Email) would work just fine on a planetary scale - after all, they worked on dial-up connections. Store-and-forward doesn't have to happen on the packet level.
    – dirkt
    Commented Oct 24, 2020 at 10:43
  • @dirkt For TCP, it does have to be at the packet level. The sender tries to "fill" the complete path with unacknowledged packets in order to eliminate round-trip-delay throughput degradations. Obviously, it must store all of these unacknowledged packets for retransmission. So, a Mars-Earth transmission would have to store in the best case 12 minutes worth of data on both the sender and receiver side for TCP. Depending on the bandwidth, this can be quite a lot. (And remember, 12 minutes is the minimum - in case Mars happens to be in an orbit position opposite of the sun, it's magnitudes more.
    – tofro
    Commented Oct 24, 2020 at 20:46
  • @tofro I don't mean TCP, I mean higher levels. Yes, TCP over long-latency connections doesn't work. So don't use TCP over long-latency connections. Simple. Don't expect to be able to use a modern webapp in a browser when you are on Venus, and the server is on Neptune. Not going to work, even with "TCP on the packet level".
    – dirkt
    Commented Oct 25, 2020 at 9:05

There should be no problem sending IPv6 packets to or from Mars. So long as you have a suitable underlying physical transmission system. The same is true for IPv4 packets.

However given the latency (measured in minutes instead of the normal milliseconds) you are not going to be sending TCP over the top of these IP packets. You would need some alternate transport protocol that can handle the delay. QUIC would have the same issue as TCP. Not suitable.

UDP packets should be fine. But UDP is generally serving some application that cares about latency. So using it in a meaningful way would depend on the application.

Basically layer 3 would be just fine but everything above that would require re-engineering.

Perhaps the first protocol you might like to invent is an alternative to SMTP that can connect a mail server on Mars to a mail server on the Earth. Being able to send email back and forth would be an enabler for a lot of other things. And email that has a delay of ten minutes or so generally isn't a problem. Just using SMTP won't work because it relies on TCP.

You also want a protocol so a DNS on Mars can replicate with a DNS on Earth. And vice versa. DNS lets the mail server know if it is sending to another mail server on the same planet. Or at least it does indirectly if IP addresses are segmented by planet.

With DNS and Email working you can build a lot on top of that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .