[arin-ppml] Addressing for other planets

[Daryll Swer]

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 <
alejandroacostaalamo at gmail.com> 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 <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
>> <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 (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/b797cf2006b76fefc5570004428285e50c281890?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/71422d60639247323da91e07a7492f203d97e2cc?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/80aa7d1fa73cab6f147abb79995efb94875029fd?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/20260220/8af5aa9d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ietf-logo-nor-180.png
Type: image/png
Size: 3345 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260220/8af5aa9d/attachment-0001.png>