A separate entity from traditional RIRs that exclusively handles space-related numbered resources sounds ideal to me. Clear demarcation is good.
b) crafting resource management and governance policy which is agnostic of > which option in a) above eventually winds up most widely implemented, if > any. I like this option the most; it offers flexibility and separates network implementation from numbered resource management. *--* Best Regards Daryll Swer Website: daryllswer.com <https://l.shortlink.es/l/9b8164b9469b1fb5342d29f062e15ade71b4be58?u=2153471> On Sat, 21 Feb 2026 at 04:25, scott <[email protected]> wrote: > 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 > <https://l.shortlink.es/l/b1a4f23ea8fce31d3469f1bd6ce576d04e9e3149?u=2153471> > >> > >> > >> 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 > <https://l.shortlink.es/l/01380f7bccde35061c1f1116def4656437ce163f?u=2153471><ietf-logo-nor-180.png>IP > Address Space for Outer Space > >> datatracker.ietf.org > <https://l.shortlink.es/l/f2cc431e7b28bfa3f16a91451cee0c314f5c1825?u=2153471> > <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 > <https://l.shortlink.es/l/c0f9a2bf0140a82bd0bacdaadcb34e73ca3bf6cf?u=2153471> > >> 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 > <https://l.shortlink.es/l/f070bb3bb6c5c27ed94fbf7a6e54f6c656014b3a?u=2153471> > >> 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 > <https://l.shortlink.es/l/eb2429eb4ef000b90cc7022818aaac1fae5d81b7?u=2153471> > >> 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 > <https://l.shortlink.es/l/78f1e542812cb686cbd85e09696d1b92c92479ec?u=2153471> > > 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 > <https://l.shortlink.es/l/2cb7b324acad9cf8ef41e220fdb06d4f58aace33?u=2153471> > 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.
