A large chunk of IPv6 is heading for space, and every policy question about it is currently going to be deferred to the RIR communities. This article outlines what those questions look like, and argues why now is the time to start asking them.
If you think IPv6 is big, try applying the current v6 mechanisms to the Solar System.
Start generously: take a /3. Keep the conventions we actually operate: a /64 at the bottom because RFC 4291 says so, 16 bits of subnetting above it because that is what a non-residential endsite looks like, and everything from IANA down to the customer /48 has to fit into 45 bits.
On Earth, those 45 bits carry IANA to RIR to LIR to site with room to spare. Off Earth, they also have to specify around which body, in which orbit, where along it and how far off it, for an endpoint moving at tens of kilometres per second with no fixed relationship to any ground station, jurisdiction or registry. 45 bits is not really the problem. The problem is that nearly every mechanism we would spend them on assumes something that stops being true above low Earth orbit.
A better acronym
The TIPTOP working group met at nine on the Wednesday of IETF 126. I wasn’t there, because my focus was on my presentation at INTAREA later that day. I arrived for the coffee break and listened to the RIR people that attended the session. Each of them told me the same thing in their own words: everything under discussion treated the addressing as somebody else's problem, and that somebody was, at present, not the IETF. There was a presentation on a draft to give an IPv6 block to space, and then hand it over to the RIRs to figure out the rest - details TBD.
What can possibly be the answer to the working group with the best acronym in the entire IETF? A working group with a better acronym! The name didn't take long to turn up: EXPANSE (Extending Policy, Addressing and Numbering across Space Ecosystems). The problem statement pretty much assembled itself while I was sitting in the GROW session, and went up before the session was done. I asked the area director responsible for TIPTOP for a meeting. Joke or not, the problem itself had substance.
What space networking is missing
The problem statement I published catalogues fourteen gaps. Most reduce to the same shape: something the terrestrial internet spent thirty years building is assumed not to be needed off-planet or is about to get reinvented, badly. Four of them deserve spelling out here:
No registration model. There is no defined mechanism for how number resources used on space segments are delegated, registered or attributed, within or alongside the IANA/RIR hierarchy. In its absence, mission-specific and agency-specific address plans are already hardening into de facto parallel registries with no uniqueness guarantee against the terrestrial Internet. And terrestrial experience says that fragmentation, once deployed, is effectively irreversible. The obvious shortcut, squatting on reserved or special-use space, is also the historically proven one: such usage leaks, every time, especially when it’s most inconvenient.
Earth as the default interconnection point. At interplanetary distances, a tromboned path means inefficiencies are no longer measured in milliseconds but in tens of minutes per detour, and in some geometries in availability itself. The natural interconnection hubs of a solar-system topology are the gravitationally stable locations: Lagrange points, notably Sun-Earth and Earth-Moon L4/L5, the IXPs of space. No work exists on how such hubs should be numbered, registered, operated or kept jurisdictionally neutral, which are precisely the questions terrestrial interconnection spent thirty years answering. Mars to Ceres should not take up to 80 minutes and very expensive bandwidth to trombone.
Jurisdiction as an unengineered partition. Gateways, relays and ground segments are owned by national agencies and other jurisdictionally bound operators. Sanctions regimes, export controls and national security law will apply to non-terrestrial internetworking exactly as they do terrestrially. An architecture with no neutral interconnection model and no jurisdiction-aware routing policy will be partitioned by treaty and statute rather than by engineering.
Nothing is standing still. Spacecraft on transfer trajectories, extraction platforms with lifecycles measured in mission phases, and peer-to-peer adjacency where no fixed backbone exists are all outside current work. Registration practice assumes decadal stability. Off-planet assignment, mobility and return must be routine operations, not exceptions. Binding addresses to orbital position repeats, at solar-system scale, the locator/identifier conflation the Internet has struggled with for decades.
There is one more gap, and the current TIPTOP draft already recognises it. Endpoints and applications need to know when a correspondent sits at interplanetary distance. Because everything is tuned for terrestrial latency, such as timers, retransmission, congestion behaviour, the application above them. They break silently when the round trip is measured in minutes instead of milliseconds. A dedicated block answers that with a boolean: the correspondent is in the space prefix, so it is far away. But ‘far away’ is not a distance. How the address space should carry that information, and how much of it, is exactly the kind of question that gets settled by accident if nobody asks it on purpose.
Planetism
The assumption underneath nearly all current work on space networking is that address uniqueness, registration and routing policy are terrestrial phenomena, to be extended off-planet mission by mission. Call it planetism.
The consequences are visible already. Per-mission address plans will not aggregate, traffic trombones through Earth gateways, and partition risk concentrates in ground stations that sit in one jurisdiction each.
Two of these consequences are deployed infrastructure rather than missing mechanisms, and those are the two this audience feels first. The Internet Numbers Registry System is operationally rooted on Earth. It is codified in RFC 7020 and ICP-2, and none of those documents offer any guidance on this topic. On top of that, RPKI freshness machinery is built for minute-scale propagation, which at eight light-minutes to Mars, forty at worst, makes a certificate revocation a historical document.
What the effort would actually do
The proposed charter is deliberately narrow:
- A technical framework in the IETF that enables policy work in the registry communities, with neither doing the other's job.
- Document where the existing addressing architecture applies off-planet and where it does not.
- Define requirements for registration, uniqueness and attribution within the existing hierarchy.
- Analyse how RPKI and routing security behave when validation cannot outrun light.
- Define addressing and routing for platforms that never stop moving, in a way that provides stability and preserves aggregation.
- Specify that space-to-space traffic must not be forced through terrestrial gateways, and describe an interconnection architecture for the stable hub locations.
- Provide sufficient guidance to IANA and the RIR communities for them to conduct policy development, without the IETF doing that policy development itself.
The alternative to doing this work in the IETF and the RIR communities is not that the work goes undone. It is that the addressing and numbering for space segments get defined elsewhere, by treaty bodies, national agencies or single vendors - outside the open, bottom-up processes that built the Internet.
Why now, and why here?
The reflex objection is that this is decades away, even though our own history counters that. IPv6 address policy was written when IPv6 deployment was decades away. That lead time is exactly why the v6 space is more coherent today instead of the accreted mess v4 became. Early is the lesson, not the error.
It is also less hypothetical than it looks. A draft in front of the IETF right now proposes that IANA carve a block of IPv6 space for space use and delegate it to the five RIRs, with every policy question explicitly deferred to the RIR policy development processes (PDPs). That draft made the premise speakable. A large chunk of v6 is going to space, and the hierarchy inside it is marked TBD.
That TBD is an address policy question that would then land in our PDPs, which is the reason for this article. The RIR institutions are aware of this work; while the policy-forming communities are mostly not, because it plays in a different forum. This gap is the wrong way round for a bottom-up system. What does registration mean for something that never stops moving? What counts as evidence of occupancy? Should the registry function off-planet look anything like the one we run here? These are all about address policy, all in scope, and all much easier to think about while still theoretical.
This community is usually asked whether they could do the work. But when it comes to administering addressing in the Solar System, the first question that should be asked is whether the RIRs actually want to do this work. It is entirely possible that a full analysis concludes the registry function off-planet is much smaller, or very different from the one on Earth, that physics does more of the work and adjudication does less. It is also possible it concludes the opposite. Either answer is fine. What is not fine is finding it out by accident; or repeating RPKI, where the original IETF work had all sorts of undesirable side effects for the RIR system; or finding out after something is already flying with a per-mission address plan that will never aggregate with anyone else's.
Better to find it all out now, while it is still (mostly) theoretical.
The problem statement is on the IETF datatracker as draft-vanmook-expanse-problem-statement, with a number of drafts pending alongside it. Objections and better ideas are both welcome, especially the second kind.
Comments 13
Jordi Palet Martinez •
I would not start form /64 neither /3. I think every "space object/mission" (to use somename) should have its own /48, as we aren't talking about planets, right? I don't know if they expect that several space objects, for example in the moon, from the same "provider" will aggregate multiple /48s, in something shorter and how they manage, but this is another discussion. I think the real problem is to do an approximation of how many /48s will be needed in "n" years. They could be aggregated in "n" /32 (we are used to that number, so for this example considering this one as well). And then how many "providers" are expected in total for those "n" years. 100 or 1.000 ? Which that we get something like /16 (just an example). The IETF defines a single /16 reservation for TIPTOP, but in a different /3. Only if 80% is already allocated then can be extended to a /15, and so on. This way we don't have the risk to waste a complete /3 in a single shot. And we have been there. It is a mix of IETF standards to define how IANA manage that, and a global policy that needs to be agreed among all the RIRs for the "space providers". Of course, there are a lot of additional technical difficulties as you mention in your draft (and article), but I don't think the IETF+global policy part is so different than what we have already done before. The point here is to consider a new type of "provider" the "space providers" in a common way among all the RIRs.
Remco van Mook •
Thanks Jordi. This is exactly the exercise the article hopes the community starts running. One calibration though: what you sketch is not what the current IETF discussion is about. The object of discourse there is not a single flying vehicle needing a /48 from its provider; it is a multi-agency Mars colony: one place, several agencies, and the question whether it can be one route. Per-object /48s under per-provider /32s answer a different question and land on the wrong side of that one: three agencies arrive holding three providers' blocks from three RIR pools, and the colony is three routes forever, unless every colony renumbers into coordination the day it is founded. Provider aggregation assumes the provider owns the path; out there nobody owns the vacuum, and what a relay needs from an address is where, not from whom. Where your instinct is exactly right: whatever the answer, it has to be common across the RIRs, and settled before rather than after the IETF hands us the output. Your reply is also evidence on the timing question: the exercise is evidently runnable today.
named bird •
The idea to carve out a block and let the RIR's handle it is already making an assumption. Who says that there are only 5? Why wouldn't the moon or Mars have their own registries when they get colonized? One of the reasons i was so annoyed at ARIN handing out a /16 is because that way we WILL run out. Assume we figure out FTL and colonize a thousand planets, each having their own Planetary Internet Registry. If you hand out 64 /16's each on a thousand planets, congratulations, you've just exhausted the inexhaustible IPv6! Routing is a not-trivial issue, but filtering is one as well. When your spacecraft has limited bandwidth, do you allow the entire internet to ping/poke it? Looking forward to the interesting things that this problem will bring forth...
Jordi Palet Martinez •
That's why I was indicating "objects/missions" and restricting the usage, so not for planets. I think they are a very different scope. In any case, if a planet is colonized, considering the cost of communications with earth, probably it makes sense to have just a few "space providers" for that planet. They will be like our current LIRs and they can assign /48s from their /32 or whatever bigger block they got. It is clear than in hundreds of years (I don't expect this happening just in 50-100 years) we may colonize not one but several planets. However in that time frame, probably we had another IP version, not just because we exhausted the addresses, but because we have many other technical requirements that we couldn't fulfill with IPv6.
Remco van Mook •
Hi Jordi, whatever comes after IPv6 will inherit what we do now, the way IPv6 inherited its shape from IPv4: a successor is a follow-up, not a clean sheet. And 25 years into the IPv6 transition, I fully expect to still find IPv4 in the wild in a century. Address plans don't get replaced; they get built on top of. Allocations aren't a century away; given the current state of progress they'll come out of the IETF process this decade still. That is exactly why the exercise runs now, while the plan is still ours to shape.
Remco van Mook •
Five is indeed an assumption: registries multiply with jurisdictions, and any plan that hardwires today's institutional count is broken before launch. The machinery for growing the count doesn't travel either: ICP-2, current or revised, forms new RIRs on community consensus at continental scale - good luck finding a continent out there, or a few hundred million people. Your exhaustion arithmetic checks out - there are 65,536 /16s in all of IPv6, so a thousand planetary registries at 64 each is 98% of them. Any scheme that spends top-level address space per institution diverges, because institutions are unbounded. Places aren't. A plan that numbers places, and lets institutions multiply within a place rather than beside it, adds worlds without spending new top-level space at all - a thousand colonised planets is then structure, not subtraction. On filtering: with link budgets as they are, filtering at the receiver is already the loss. Whatever the reachability default, the discipline has to sit on the send side: nothing transmitted that nobody agreed to receive. That is an architecture question rather than a firewall question, which is exactly why it belongs in the exercise you're looking forward to.
Saiidnajib Saidislomzoda •
This article actually looks interesting. I have a question and a suggestion. What prevents RIR from distributing IP addresses for space agencies in their regions? For example RIPE NCC - ESA, ARIN - NASA, APNIC for JAXA and CNSA. We can use cellular technology to distribute IP addresses. For example, let's put one satellite or several satellites (as base stations to cover a certain territory) between the Earth and the Moon. You can also use the technology used in Starlink, using a group of satellites.
Remco van Mook •
Handing out addresses is an administrative task, done long before any radio is switched on, and it does not depend on connectivity at all - a base station only assigns from a block that was allocated earlier. Cellular or Starlink-style coverage between Earth and the Moon is link technology; it answers how the last hop works, not where the block comes from. And there is a reason to keep those blocks visibly distinct: an address that might be light-minutes away must not look like an ordinary one, or every application on Earth will wait milliseconds for a reply that takes minutes.
Andrew McConachie •
I find this article and much of the discussion on the tiptop mailing list suffers greatly from a kind of techno-utopianism that assumes humans will colonize space. I don't buy it. I'm willing to bet that by the time of my death (let's say 30 years) there will not have been a single BGP peering session in space. Perhaps I'm wrong and space will be colonized, but in your attempt to reestablish a baseline for this work by questioning assumptions you've left out the most important one: Why design a network when we don't yet have users? I don't want to dig into the reasoning and speculation surrounding the inevitability of space colonization, and I don't think this work in the IETF should either. But I do find it rather weird that this work just assumes users are going to show up in space at some point and need an Internet. More importantly, the assumptions about how many users there will be, what those users will need, where they will be, and whether they will be humans or machines underpin much of this work. Yet the vast majority of discourse I've read on this topic simply ignores these fundamental questions. Instead, everyone approaching this work has a different idea about how space exploration is going to play out. These assumptions then shape their design choices, and since everyone is looking into a different crystal ball, arguments over design become a proxy for arguments over futurism. Consider this question: If I were going to develop software for a bunch of users that didn't exist, but with an expectation that they would exist in the future, what should be my first step? Answer: Describe these future users and their environment. State your assumptions about these users. Only then can you begin to understand their needs and draft requirements for the software that will address those needs. Designing a network is no different. No one is proposing extending the Internet to the Mariana Trench. Maybe giant squids need Internet even more than asteroids? And we can laugh at this suggestion, but there's really no reason why colonizing one is more inevitable than colonizing the other.
Remco van Mook •
Hi Andrew, I couldn't agree more. Most of what will be out there for the foreseeable future is machines, in my opinion. What makes the discussion necessary at the moment is that there IS ongoing work within the IETF in this area, and if that leads to an instruction to IANA for an allocation with a delegation to the RIR system, ignoring it is not an option. The main reason I wrote this article is that IF this is a thing that's going to go ahead, we need to make sure it gets done correctly, and actually gives the RIRs something workable. The current state of the draft in the IETF is, in my opinion, not. Remco
Andrew McConachie •
Thanks Remco. I think I understand a bit more now your article and proposal. My main issue is that people are looking into different crystal balls and imagining different futures. And nothing in your proposal or anything I've seen in tiptop really addresses this. Predicting the future will inevitably fail, but we should still spend time describing the future that we're designing for. Otherwise all of these design questions degrade into arguments about which future we're designing for. I remember many of the discussions around IoT from 5-10 years ago or so, and many of them started with things like, "We expect dozens of devices in the average home." Or something like that. I don't understand how this space Internet thing can even start without people making declarative statements like that. A lot of what was predicted for IoT didn't actually happen, but that's not the point. The point is that there was a foundational baseline from which network nerds could begin developing user expectations and requirements. Typical of consensus based efforts there will be disagreements over how abstract or specific the declarative predictions of space colonization can be. Maybe only very abstract statements can be agreed upon about the future, but that's still better than nothing.
Remco van Mook •
There's no declared baseline in terms of numbers or even user model in the ongoing discussion that I can clearly discern; having a concrete user model/number, even if proven to be wildly incorrect later on, would be helpful in validating some of the assertions and design right now. The main arguments so far are about delay, aggregation, interdomain and movement. The space agencies themselves are not participating in the discussion as their current stated preference for the DSN is the Bundle Protocol, not IP. I don't disagree with the assertion that there probably will be a role for IPv6, eventually: the one recurring lesson from technology is that commodity always wins.
Jochen Peter Bern •
> I find this article and much of the discussion [...] suffers greatly from > a kind of techno-utopianism that assumes humans will colonize space. Actually, the *relevant* dubitable assumption is that humans will *communicate through* space in some FTL way. For distances that do not need *that*, "space Internet" is something that people build, or at least tout, today - even if the Mars Telecommunications Orbiter project was scrapped. As long as the light speed barrier doesn't get broken, interstellar communication will not ever be *able* to take place in a homogenous technical infrastructure that extends from the galactic(?) backbone all the way down to specific institutions. You can't do DNS lookups over an RTT that large, lots of traffic would arrive someplace way after it ceased to announce the corresponding prefix, no way to make/disseminate assignments in whatever definition of a "timely" manner, even a majority of RFCs will get superseded in place A before they ever became known in place B. End users will be sending messages to recipients that can, and *will*, switch places, providers, names, contractual obligations present and legacy, and possibly even cease to exist while the data still is en route to the proper solar system. In such a setting, you *cannot* "internetwork" the merry islands of less-than-a-couple-years RTTs in the same sense Earth has evolved an Internet - by agreeing on standards that shall (mostly) be implemented from the "backbone" all the way down to individual participants' uplinks, if not their LANs and terminals. What you hopefully *can* do is to nail down standards that permit to inter*connect* such more-or-less-homogenous islands, and won't turn inoperational within less than the long-haul RTT. Nobody but whatever star system's gateways to the interstellar net will ever need to implement those, and having to translate for the local-solar Internet will definitely be a formidable task. (Who's the legal successor of that recipient, some terraforming corp. that finished its work and dissolved three centuries ago, again?) I remember seeing an "Interplanetary Internet" working group back when I was at university, 40-ish years ago (no, *not* the organization of the same name of today - nice demonstration of the issue, by the way ;-) that included interstellar distances but *not* FTL into its scope. Alas, their work essentially stopped (and has since disappeared from the WWW, it seems) when they realized that sending and receiving data to/from interstellar space costs *serious* money, and concluded that transmitted data would need to carry some sort of payment for its own propagation with it. Back then, "micropayments" were a hot CS/cryptography topic, so they left things at "let's look at what comes out of *that*" ...