Remco van Mook

The /3 Body Problem

Author image
Remco van Mook(community contributor)

8 min read

0
Article lead image

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 ICP2, 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 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.
0

You may also like

View more

About the author

Author image
Remco van Mook Based in The Netherlands

Technology executive with a passion for Internet and how the pieces come together - going down that rabbit hole for 25+ years. Prolific policy author, former chair of the Connect working group in the RIPE community and board member of RIPE NCC from 2010 to 2025.

Comments 0