Hi Chris,
On Fri, 20 Feb 2026, Chris Woodfield wrote:
I’m finding the concept of a new RIR - I’ll dub it “SpaceNIC” - that
manages interplanetary number resources is an interesting one
conceptually, and I believe it’s an intuitive argument that
interplanetary space should be considered its own Capital-R region and
should not simply be extensions of the earthbound operators of network
infrastructure using those resources, particularly for the purpose of
aggregation efficiency - the world's FIBs have gotten enough abuse
already. The concept of an organization that’s entirely extraterrestrial
isn’t something we should ignore either, regardless of whether we could
expect that in our lifetimes or not.
Of course, this goes against the colloquial understanding of an RIR’s
founding function as that of managing IPv4 resources; SpaceNIC would
most likely be managing solely IPv6 resources and 32-bit ASNs.
Agreed on v6 and ASNs.
I would add Bundle Protocol pecific identifiers, like Allocator IDs, Node
Numbers, and Region IDs as resources which also would require
multi-stakeholder management.
I am in
support of this… it’s like the only way a new RIR *could* be established
practically, short of reclassifying Class E to global unicast (please,
don’t).
IPv6 is sufficient to number off-world IP networks, I would wager.
The next bit of the thought experiment is: do the NRO’s governing
documents (ICP-2) allow for such an RIR? The answer, from my reading,
appears to be no. While there’s no specific requirement that a RIR
manage IPv4 resources - that’s a good thing - there is this:
"It must be demonstrated that when established the new RIR's membership
will include a significant percentage of the existing LIRs within the
new RIR's region of coverage, specifically including those LIRs already
receiving IP address registration services and/or other related services
from an existing RIR.”
This suggests that in order to establish SpaceNIC, there must be an
existing community of established LIRs in space
I would say far enough away in space that standard services cease to
function, so we are talking beyond GEO, basically. To the Moon works with
existing implementations so long as your application does not timeout, and
you have 0 packet loss, otherwise, the performance penalty can be
significant, or even total.
in support, which
there’s a good chance may not be the case.
It takes 3 ASs to make an IXP, right? How many discrete operators on the
Lunar surface, each with a network, does it take? Granted, in the absence
of direct, continuous, routable IP connectivity to Earth, these Lunar
surface networks become "islands" of IP, or what we term "internets."
Notwithstanding, to interoperate as they do on the terrestrial Internet,
they will still need to perfect routing between themselves locally, a job
best done with BGP, necessitating ASN management. I ask you to consider
that propagating these routes across interplanetary space may have a
significant performance penalty, and as such, may not be the wisest way to
attempt interoperability between these Lunar (or Martian, or Europan)
internets and the Internet.
Language to the same effect
can be found in the current proposed language for the revised ICP-2
document, albeit dropping the LIR terminology.
So, regardless of the merits, he policy wonk in me is recognizing that
there may be required updated language in ICP-2 to account for the
potential establishment of an RIR in “frontier” space where there are no
established resource holders.
Not going to argue on this one, however I will note that this places, at
present, the responsibility on ARIN, which manages resources for all
places not covered by another RIR?
The biggest difficulty, IMHO, is either:
a) building concensus around the
technical mechanisms which will comprise the Solar System Internet:
1. a purely IP approach, such as Tony and TIPTOP suggest,
2. a purely BP approach, such as other industry participants suggest,
or
3. a hybrid BP/IP approach using IP and BP networks were each are most
applicable, which I (speaking for myself) suggest.
OR
b) crafting resource management and governance policy which is agnostic of
which option in a) above eventually winds up most widely implemented, if
any.
Thanks,
Scott Johnson
As always, I’m open to suggested alternative readings :)
-Chris
P.S. See also: a fully-populated Antarctica after the snow caps melt.
On Feb 20, 2026, at 07:43, Fernando Frediani <[email protected]> wrote:
I am following this and not beleiving this is serious. Forgive me if not but it
looks like April's fools day
On Fri, 20 Feb 2026, 10:55 Daryll Swer via ARIN-PPML, <[email protected]>
wrote:
If we create GUA aggregates per planet (like we did on Earth with 2000::/3),
should we also create /10s per planet, excluding Earth? I'm curious to hear
what people think we should do for prefix length allocation to large bodies
(planets) and possibly moons as well.
I don't think we should use 2000::/3 for anything outside Earth's immediate
orbit, maybe the Moon at most. I think a different /3 from IANA should be used
for space networking. This would allow clean aggregation per large body (planet
or equivalent) and clean segmentations across RIRs (if we decide RIRs have
allocation authority for space networking).
--
Best Regards
Daryll Swer
Website: daryllswer.com
On Fri, 20 Feb 2026 at 02:32, Tony Li <[email protected]> wrote:
Hi,
As part of the IETF TIPTOP working group, we are working towards enabling the
Internet in outer space. We would like to direct your attention to a couple of
recent Internet drafts that may be of interest:
An Architecture for IP in Deep Space
datatracker.ietf.org<ietf-logo-nor-180.png>IP Address Space for Outer Space
datatracker.ietf.org<ietf-logo-nor-180.png>
The latter has direct implications for the ARIN community,
I would welcome any and all comments.
Regards,
Tony
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
<ietf-logo-nor-180.png>_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
