[arin-ppml] Addressing for other planets

Fri Feb 20 20:46:02 EST 2026

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 <scott at solarnetone.org> 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 <fhfrediani at gmail.com>
> 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, <
> arin-ppml at arin.net> 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 <tony.li at tony.li> 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 (ARIN-PPML at arin.net).
> >> 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 info at arin.net if you experience any issues.
> >> _______________________________________________
> >> ARIN-PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> 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 info at arin.net 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 (ARIN-PPML at arin.net).
> >> 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 info at arin.net if you experience any issues.
> >
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > 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 info at arin.net if you experience any
> issues._______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> 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 info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260221/3b868928/attachment-0001.htm>