<div dir="ltr"><img width="0" height="0" class="mailtrack-img" alt="" style="display:flex" src="https://mailtrack.io/trace/mail/241fdd93d084d2fe7c19285acb7055864532e945.png?u=2153471"><div dir="ltr"><div>A separate entity from traditional RIRs that exclusively handles space-related numbered resources sounds ideal to me. Clear demarcation is good.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">b) crafting resource management and governance policy which is agnostic of<br>which option in a) above eventually winds up most widely implemented, if<br>any.</blockquote><div>I like this option the most; it offers flexibility and separates network implementation from numbered resource management. </div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font color="#000000" face="arial, sans-serif"><br><b>--</b><br></font><div><font color="#000000" face="arial, sans-serif">Best Regards</font></div><div><font color="#000000" face="arial, sans-serif">Daryll Swer</font></div><div><font color="#000000" face="arial, sans-serif">Website: <a href="https://l.shortlink.es/l/9b8164b9469b1fb5342d29f062e15ade71b4be58?u=2153471" target="_blank">daryllswer.com</a></font></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, 21 Feb 2026 at 04:25, scott <<a href="mailto:scott@solarnetone.org">scott@solarnetone.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
On Fri, 20 Feb 2026, Chris Woodfield wrote:<br>
<br>
> I’m finding the concept of a new RIR - I’ll dub it “SpaceNIC” - that <br>
> manages interplanetary number resources is an interesting one <br>
> conceptually, and I believe it’s an intuitive argument that <br>
> interplanetary space should be considered its own Capital-R region and <br>
> should not simply be extensions of the earthbound operators of network <br>
> infrastructure using those resources, particularly for the purpose of <br>
> aggregation efficiency - the world's FIBs have gotten enough abuse <br>
> already. The concept of an organization that’s entirely extraterrestrial <br>
> isn’t something we should ignore either, regardless of whether we could <br>
> expect that in our lifetimes or not.<br>
><br>
> Of course, this goes against the colloquial understanding of an RIR’s <br>
> founding function as that of managing IPv4 resources; SpaceNIC would <br>
> most likely be managing solely IPv6 resources and 32-bit ASNs.<br>
<br>
Agreed on v6 and ASNs.<br>
<br>
I would add Bundle Protocol pecific identifiers, like Allocator IDs, Node <br>
Numbers, and Region IDs as resources which also would require <br>
multi-stakeholder management.<br>
<br>
> I am in <br>
> support of this… it’s like the only way a new RIR *could* be established <br>
> practically, short of reclassifying Class E to global unicast (please, <br>
> don’t).<br>
<br>
IPv6 is sufficient to number off-world IP networks, I would wager.<br>
<br>
> The next bit of the thought experiment is: do the NRO’s governing <br>
> documents (ICP-2) allow for such an RIR? The answer, from my reading, <br>
> appears to be no. While there’s no specific requirement that a RIR <br>
> manage IPv4 resources - that’s a good thing - there is this:<br>
><br>
> "It must be demonstrated that when established the new RIR's membership <br>
> will include a significant percentage of the existing LIRs within the <br>
> new RIR's region of coverage, specifically including those LIRs already <br>
> receiving IP address registration services and/or other related services <br>
> from an existing RIR.”<br>
><br>
> This suggests that in order to establish SpaceNIC, there must be an <br>
> existing community of established LIRs in space<br>
<br>
I would say far enough away in space that standard services cease to <br>
function, so we are talking beyond GEO, basically.  To the Moon works with <br>
existing implementations so long as your application does not timeout, and <br>
you have 0 packet loss, otherwise, the performance penalty can be <br>
significant, or even total.<br>
<br>
> in support, which <br>
> there’s a good chance may not be the case.<br>
<br>
It takes 3 ASs to make an IXP, right?  How many discrete operators on the <br>
Lunar surface, each with a network, does it take?  Granted, in the absence <br>
of direct, continuous, routable IP connectivity to Earth, these Lunar <br>
surface networks become "islands" of IP, or what we term "internets." <br>
Notwithstanding, to interoperate as they do on the terrestrial Internet, <br>
they will still need to perfect routing between themselves locally, a job <br>
best done with BGP, necessitating ASN management.  I ask you to consider <br>
that propagating these routes across interplanetary space may have a <br>
significant performance penalty, and as such, may not be the wisest way to<br>
attempt interoperability between these Lunar (or Martian, or Europan) <br>
internets and the Internet.<br>
<br>
> Language to the same effect <br>
> can be found in the current proposed language for the revised ICP-2 <br>
> document, albeit dropping the LIR terminology.<br>
><br>
> So, regardless of the merits, he policy wonk in me is recognizing that <br>
> there may be required updated language in ICP-2 to account for the <br>
> potential establishment of an RIR in “frontier” space where there are no <br>
> established resource holders.<br>
<br>
Not going to argue on this one, however I will note that this places, at <br>
present, the responsibility on ARIN, which manages resources for all <br>
places not covered by another RIR?<br>
<br>
The biggest difficulty, IMHO, is either:<br>
<br>
a) building concensus around the <br>
technical mechanisms which will comprise the Solar System Internet:<br>
<br>
1. a purely IP approach, such as Tony and TIPTOP suggest,<br>
2. a purely BP approach, such as other industry participants suggest,<br>
or<br>
3. a hybrid BP/IP approach using IP and BP networks were each are most <br>
applicable, which I (speaking for myself) suggest.<br>
<br>
OR<br>
<br>
b) crafting resource management and governance policy which is agnostic of <br>
which option in a) above eventually winds up most widely implemented, if <br>
any.<br>
<br>
Thanks,<br>
Scott Johnson<br>
<br>
><br>
> As always, I’m open to suggested alternative readings :)<br>
><br>
> -Chris<br>
><br>
> P.S. See also: a fully-populated Antarctica after the snow caps melt.<br>
><br>
>> On Feb 20, 2026, at 07:43, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>> wrote:<br>
>> <br>
>> I am following this and not beleiving this is serious. Forgive me if not but it looks like April's fools day<br>
>> <br>
>> On Fri, 20 Feb 2026, 10:55 Daryll Swer via ARIN-PPML, <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:<br>
>> 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.<br>
>> <br>
>> 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).<br>
>> <br>
>> --<br>
>> Best Regards<br>
>> Daryll Swer<br>
>> Website: <a href="https://l.shortlink.es/l/b1a4f23ea8fce31d3469f1bd6ce576d04e9e3149?u=2153471" rel="noreferrer" target="_blank">daryllswer.com</a><br>
>> <br>
>> <br>
>> On Fri, 20 Feb 2026 at 02:32, Tony Li <<a href="mailto:tony.li@tony.li" target="_blank">tony.li@tony.li</a>> wrote:<br>
>> Hi,<br>
>> <br>
>> 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:<br>
>> <br>
>> An Architecture for IP in Deep Space<br>
>> <a href="https://l.shortlink.es/l/01380f7bccde35061c1f1116def4656437ce163f?u=2153471" rel="noreferrer" target="_blank">datatracker.ietf.org</a><ietf-logo-nor-180.png>IP Address Space for Outer Space<br>
>> <a href="https://l.shortlink.es/l/f2cc431e7b28bfa3f16a91451cee0c314f5c1825?u=2153471" rel="noreferrer" target="_blank">datatracker.ietf.org</a><ietf-logo-nor-180.png><br>
>> <br>
>> The latter has direct implications for the ARIN community,<br>
>> <br>
>> I would welcome any and all comments.<br>
>> <br>
>> Regards,<br>
>> Tony<br>
>> _______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://l.shortlink.es/l/c0f9a2bf0140a82bd0bacdaadcb34e73ca3bf6cf?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
>> _______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://l.shortlink.es/l/f070bb3bb6c5c27ed94fbf7a6e54f6c656014b3a?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
>> <ietf-logo-nor-180.png>_______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://l.shortlink.es/l/eb2429eb4ef000b90cc7022818aaac1fae5d81b7?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
><br>
><br>
> _______________________________________________<br>
> ARIN-PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://l.shortlink.es/l/78f1e542812cb686cbd85e09696d1b92c92479ec?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues._______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://l.shortlink.es/l/2cb7b324acad9cf8ef41e220fdb06d4f58aace33?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>