<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi</p>
<div class="moz-cite-prefix">On 5/12/2026 3:58 AM, scott wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8381593d-1e03-ac3b-7d56-88fbe04a9649@solarnetone.org">Hi
Fernando,
<br>
<br>
On Sun, 10 May 2026, Fernando Frediani wrote:
<br>
<br>
<br>
Point of order: Space agencies are no longer the only players. <br>
</blockquote>
No problem. It is always a legal entity in one of the 5 RIR regions.
Get IP space from the respective RIR.
<blockquote type="cite"
cite="mid:8381593d-1e03-ac3b-7d56-88fbe04a9649@solarnetone.org"><br>
<blockquote type="cite">It doesn't justify by far to think of
another RIR or something specific to
<br>
address something that doesn't have any near a demand that
justifies it.
<br>
Aggregation argument doesn't justify it.
<br>
</blockquote>
<br>
<br>
Not everyone shares Tony and TIPTOP's "IP networks only" notion of
how space networking will play out. Many of us, including experts
from many space agencies, believe that Bundle Protocol (BP) based
networks are intergal parts of a Solar System Internet, just as IP
based surface networks on Earth are and eventually the Moon, Mars,
Europa, etc. will be.
<br>
<br>
What if there were other identifiers which are generally specific
to space applications: BP Node Numbers, Allocator IDs (both in
production), and Region IDs(to be added after proper
standardization). Do discrete blocks for other worlds
(specifically not terrestrial, as defined out to GEO) _and_ BP
based identifiers constitute sufficient reason to entertain
discussion around the notion of a new RIR? <br>
</blockquote>
<p>No problem as well. Still connectivity always comes from Earth
and as such can continue to be organized within the well
established RIR system we have. Any specific/technical details can
be adjusted as necessary without the need to reinvent the wheel or
create a new system to manage this all.</p>
<p>Regards<br>
Fernando</p>
<blockquote type="cite"
cite="mid:8381593d-1e03-ac3b-7d56-88fbe04a9649@solarnetone.org"><br>
Thanks,
<br>
Scott
<br>
<br>
<br>
<blockquote type="cite">
<br>
Keep it simple !
<br>
<br>
Fernando
<br>
<br>
On 5/9/2026 3:41 PM, Tony Li wrote:
<br>
Hi all,
<br>
I tried to attend the session on TIPTOP, but was unable to do
so.
<br>
There were many comments that came up that I’d like to respond
to.
<br>
<br>
1) Space is outside of ARIN’s charter.
<br>
<br>
This is absolutely true. It’s outside of everyone’s
<br>
charter. It was not part of anyone’s thinking when the RIR
<br>
system was first established. This is an oversight that
<br>
needs to be corrected. John mentioned the example of
<br>
Antartica, which I think is apropos. A small demand,
<br>
which ARIN handles for the good of the global community.
<br>
I think space should be handled the same way.
<br>
<br>
It was suggested that space should get its own RIR. While
<br>
that’s possible, that would create an entire organization for a
<br>
handful of constituents with maybe a dozen requests per year and
<br>
lacking the expertise that ARIN has. To my mind, this would be
<br>
as inefficient as an independent RIR for Antartica.
<br>
<br>
Space is outside of ARIN’s current charter. ARIN should broaden
<br>
its reach and include space. Because someone has to and ARIN
<br>
can.
<br>
<br>
2) This doesn’t guarantee aggregation.
<br>
<br>
Absolutely true. This is not regulation. But this is
<br>
enablement. Aggregation cannot happen if allocations are
<br>
not done properly. This is the status quo.
<br>
<br>
This intent of this policy is to enable aggregation. The space
<br>
agencies involved are strongly motivated to keep their overhead
<br>
costs down and keep their routing efficient. We can provide the
<br>
technical expertise to make this happen, but none of that can
<br>
happen if we have dispersed addressing.
<br>
<br>
3) Latency is the driver for the IPv4 portion of the policy.
<br>
<br>
The issue is bandwidth, not latency. Space vehicles are
<br>
very bandwidth limited and communications are mission
<br>
critical, so efficiency is paramount. For this reason,
<br>
missions are being flown with IPv4 today and will likely
<br>
continue to do so. While access to IPv6 prefixes for
<br>
higher bandwidth provides for future missions with higher
<br>
bandwidth, for today’s missions where bandwidth is
<br>
severely constrained, we want to encourage mission
<br>
planners to aggregate within IPv4.
<br>
<br>
<br>
Cheers,
<br>
Tony
<br>
<br>
_______________________________________________
<br>
ARIN-PPML
<br>
You are receiving this message because you are subscribed to
<br>
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
<br>
Unsubscribe or manage your mailing list subscription at:
<br>
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
<br>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
<br>
<br>
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>