Hello Daryll, inline:
On 20/2/26 10:42 AM, Daryll Swer wrote:
I agree with Alejandro's suggested model; this keeps it simple at the
allocation level from IANA and simple for aggregating at RIR
Thanks!
(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.
Maybe it's time to put together a sort of WG for creating such an
important IP address plan
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.
That's a good one.
Also perhaps it's wise to assume RFC9663 may become widely used for
space networking endpoints in the future.
Anything is possible
Count me in—happy to help with this topic
Alejandro,
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>
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>
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 [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.
