<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/12/2026 1:16 PM, scott wrote:<br>
</div>
<blockquote type="cite"
cite="mid:746e5e77-80a0-26a6-8d71-60444c79c61e@solarnetone.org">
<blockquote type="cite"> Not everyone shares Tony and
TIPTOP's "IP networks only" notion
<br>
of how space networking will play out. Many of us,
including
<br>
experts from many space agencies, believe that Bundle
Protocol
<br>
(BP) based networks are intergal parts of a Solar System
<br>
Internet, just as IP based surface networks on Earth are
and
<br>
eventually the Moon, Mars, Europa, etc. will be. <br>
</blockquote>
</blockquote>
Honestly, what is the demand of it in terms of devices, networks
right now and for the next few years ?<br>
Taking aggregation out of the equation, what would be the issue of
using IP space allocated by the RIRs to space agencies with
supposedly pretty low demand.
<blockquote type="cite"
cite="mid:746e5e77-80a0-26a6-8d71-60444c79c61e@solarnetone.org">
<blockquote type="cite"> </blockquote>
Do you believe the present system, as is, has competency for
management of BP related resources by the RIR system. We accept
the management of IP resources by the RIRs because RIR
participants generally know IP networking very well. I will wager
that the level of BP related knowledge is not as strong among this
group, yet resources from both will be required to participate in
the LunaNet. It might be preferable for a participant to get
these resources from one source. There are ways to accomplish
this without new RIRs, but it does involve the existing RIRs to
build the relevant competence and infrastructure to support
management of these resources. <br>
</blockquote>
Yes I do. It is well established and can accommodate as necessary.
It has the basis to adapt to whatever necessary and acquire the
necessary technical competence. Furthermore RIRs represent the
interest of each regional internet community worldwide.<br>
<p>Really don't understand by some wish to bypass the RIR system and
create something new and unknown for something that doesn't have
justified demand.</p>
<p>Regards<br>
Fernando</p>
<blockquote type="cite"
cite="mid:746e5e77-80a0-26a6-8d71-60444c79c61e@solarnetone.org"><br>
<br>
<br>
<blockquote type="cite">
<br>
Regards
<br>
Fernando
<br>
<br>
<br>
Thanks,
<br>
Scott
<br>
<br>
<br>
<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
<br>
unable to do so.
<br>
There were many comments that came up that I’d like
<br>
to respond to.
<br>
<br>
1) Space is outside of ARIN’s charter.
<br>
<br>
This is absolutely true. It’s outside of
<br>
everyone’s
<br>
charter. It was not part of anyone’s thinking
<br>
when the RIR
<br>
system was first established. This is an
<br>
oversight that
<br>
needs to be corrected. John mentioned the
<br>
example of
<br>
Antartica, which I think is apropos. A small
<br>
demand,
<br>
which ARIN handles for the good of the global
<br>
community.
<br>
I think space should be handled the same way.
<br>
<br>
It was suggested that space should get its own RIR.
<br>
While
<br>
that’s possible, that would create an entire
<br>
organization for a
<br>
handful of constituents with maybe a dozen requests
<br>
per year and
<br>
lacking the expertise that ARIN has. To my mind,
<br>
this would be
<br>
as inefficient as an independent RIR for Antartica.
<br>
<br>
Space is outside of ARIN’s current charter. ARIN
<br>
should broaden
<br>
its reach and include space. Because someone has to
<br>
and ARIN
<br>
can.
<br>
<br>
2) This doesn’t guarantee aggregation.
<br>
<br>
Absolutely true. This is not regulation. But
<br>
this is
<br>
enablement. Aggregation cannot happen if
<br>
allocations are
<br>
not done properly. This is the status quo.
<br>
<br>
This intent of this policy is to enable aggregation.
<br>
The space
<br>
agencies involved are strongly motivated to keep
<br>
their overhead
<br>
costs down and keep their routing efficient. We can
<br>
provide the
<br>
technical expertise to make this happen, but none of
<br>
that can
<br>
happen if we have dispersed addressing.
<br>
<br>
3) Latency is the driver for the IPv4 portion of the
<br>
policy.
<br>
<br>
The issue is bandwidth, not latency. Space
<br>
vehicles are
<br>
very bandwidth limited and communications are
<br>
mission
<br>
critical, so efficiency is paramount. For this
<br>
reason,
<br>
missions are being flown with IPv4 today and
<br>
will likely
<br>
continue to do so. While access to IPv6
<br>
prefixes for
<br>
higher bandwidth provides for future missions
<br>
with higher
<br>
bandwidth, for today’s missions where
<br>
bandwidth is
<br>
severely constrained, we want to encourage
<br>
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
<br>
subscribed to
<br>
the ARIN Public Policy Mailing List
<br>
(<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
<br>
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
<br>
issues.
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</blockquote>
</body>
</html>