I agree with Alejandro's suggested model; this keeps it simple at the allocation level from IANA and simple for aggregating at RIR (or whoever is the authority) and simple for celestial-body-type segmentation: /3 for planet-like+moons and /3 for non-planet (asteroids or a small rock large enough for human operations such as 1-month resource mining and then auto-remove assignment as soon as human presence is gone, etc.) – perhaps that old standard "Mobile IPv6", which was never really used in real operations, might also come into play for space networking, enabling the auto-mobility of subnets from one asteroid/rock to another as human operations move that way.
The contention point then becomes: What is the prefix length per planet? /10? /11? /16? It has to be large enough for future scaling on the planet but small enough not to cause exhaustion. Likewise, prefix length or aggregation for non-planet-type bodies. Perhaps someone can run calculations based on real numbers of celestial bodies to determine the optimal prefix length allocation and sizing for minimised wastage, without introducing IPv4 psychosis into space. Also perhaps it's wise to assume RFC9663 may become widely used for space networking endpoints in the future. This would greatly impact subnet modelling. I'd think it's unlikely other planets will have 8.3 billion humans anytime soon, and by the time it happens, we'll probably have moved beyond 128 bits. *--* Best Regards Daryll Swer Website: daryllswer.com <https://l.shortlink.es/l/491acc4f24e6ad057c5284ee3da28e8f464790a0?u=2153471> On Fri, 20 Feb 2026 at 19:52, Alejandro Acosta < [email protected]> wrote: > For me, it makes a lot of sense. However, I’d add one more layer: I would > suggest a separate `/3` subnet just for planets (unfortunately other > planets than earth) and another `/3` for other objects (like asteroids or > Pluto, which isn’t actually a planet). Addresses for natural satellites > would fall within the address space of their respective planets.” > > Alejandro, > > > On 20/2/26 9:54 AM, Daryll Swer via ARIN-PPML 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/19174986ed03cd89016996337141dbbdd6d81d1f?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 >> <https://l.shortlink.es/l/1813710a45f7ad72c654d1b8969aabb76b2dbe22?u=2153471> >> datatracker.ietf.org >> <https://l.shortlink.es/l/f580ac31fc41293e66404782d04f732f152894b7?u=2153471> >> [image: ietf-logo-nor-180.png] >> <https://l.shortlink.es/l/6ee9737ad750a5813c6b12f219cecf793f629eba?u=2153471> >> <https://l.shortlink.es/l/bb3f349606709332df0d907e89aff9dc4b7929e6?u=2153471> >> IP Address Space for Outer Space >> <https://l.shortlink.es/l/dfcc23dabc86dcb97704246bd5d4021672db38ae?u=2153471> >> datatracker.ietf.org >> <https://l.shortlink.es/l/bd548e3926b6d9a2b5aa00c5aff588aa31036816?u=2153471> >> [image: ietf-logo-nor-180.png] >> <https://l.shortlink.es/l/a6be19550bc26f1ed1a4c70512c05f8660594abd?u=2153471> >> <https://l.shortlink.es/l/82399640efdcef95edca46fbe1251937a241d506?u=2153471> >> >> 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/b797cf2006b76fefc5570004428285e50c281890?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/71422d60639247323da91e07a7492f203d97e2cc?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/80aa7d1fa73cab6f147abb79995efb94875029fd?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.
