<html aria-label="message body">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<br>
<div>
<blockquote type="cite">
<div>On Mar 2, 2026, at 1:53 AM, Tony Li <tony.li@tony.li> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Mohibul,
<div><br>
</div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><span class="gmail-rnc2Gd" style="color:rgb(31,31,31);font-family:"Google Sans",Roboto,Arial,sans-serif;font-size:16px;font-variant-ligatures:no-contextual">I'm focused on the debate between the two main ideas: grouping IP space by celestial body (like
giving Mars one prefix) versus the more traditional approach of allocating space based on the space agency/provider.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Just one clarification: the proposal in the draft is to allocate one prefix per body and also allocate per provider within that prefix.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>
<div>Perfectly sensible – and similar to what space agencies would are likely do if they were to receive their own allocation: allocating one prefix per body internally to allow per-body aggregation, and issuing space to projects based on the most expected
celestial body of operation. </div>
</div>
</div>
<div><br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><span class="gmail-rnc2Gd" style="color:rgb(31,31,31);font-family:"Google Sans",Roboto,Arial,sans-serif;font-size:16px;font-variant-ligatures:no-contextual">While the 'celestial body' aggregation seems clean, I'm concerned about the administrative work
and policy issues it might create, especially in the early stages of deep space networking.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Please say more. How is this different than what is done today?</div>
<br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><span class="gmail-rnc2Gd" style="color:rgb(31,31,31);font-family:"Google Sans",Roboto,Arial,sans-serif;font-size:16px;font-variant-ligatures:no-contextual">Could the supporters of the celestial body model explain how it's genuinely simpler for routing
and less burdensome than a model where each space agency gets its own aggregate block for all its missions, no matter where they are in space?
</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Again, the natural barriers between bodies create natural cut sets in the topology, making for convenient boundaries for abstraction and aggregation. For example, for the portion of network that is distant from Mars, it should be possible to carry a single
prefix for all of Mars.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
Acknowledged – if attempting to do that with deep space network providers having their own allocation for their entire network, the you’d end up with having to route that providers specific celestial body prefix in order to carry their traffic for Mars. </div>
<div><br>
</div>
<div>But of course that also means that if providers instead received their own aggregate blocks for all all activities – regardless of celestial location – then under normal circumstances each provider would advertise a single covering aggregate across the
deep space Internet. Aggregation would follow provider infrastructure, similar to terrestrial ISP models.</div>
<div><br>
</div>
<div>It does seem like the actual operational aggegation and net routing load would be quite sensitive to number of celestial-body interconnects that end up in routine operation – and that celestial-body-based allocation would in normal circumstances require
each provider to carry N routes (N being number of celestial body-assigned allocations it received) on its own network both internally and to shared with others to maintain full connectivity. </div>
<div><br>
<blockquote type="cite">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><span class="gmail-rnc2Gd" style="color:rgb(31,31,31);font-family:"Google Sans",Roboto,Arial,sans-serif;font-size:16px;font-variant-ligatures:no-contextual">Also, I'd like to hear more about how this model would handle the necessary coordination between
all the different agencies and countries that will be operating off-world.</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Providers would obtain prefixes from the RIR for the specific body. They would then coordinate with other agencies/providers for reachability. At appropriate points in the network, providers would aggregate and propagate prefixes for the body, making
off-body routing more efficient.</div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div><span class="gmail-rnc2Gd" style="color:rgb(31,31,31);font-family:"Google Sans",Roboto,Arial,sans-serif;font-size:16px;font-variant-ligatures:no-contextual">In my view, starting with the path that involves the least amount of administrative friction might
be a more practical way to begin, and we can adjust the policy as the space community grows.</span></div>
</div>
</div>
</blockquote>
<br>
</div>
<div><br>
</div>
<div>The challenge with that is that we end up doing effectively random allocation and completely lose out on the ability to aggregate. The primary purpose of all addressing is to make routing efficient, and it seems like we would be well served to take this
opportunity to not repeat previous inefficiencies.</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>
<div>You suggest that a model where each space agency gets its own aggregate block for all its missions is effectively random allocation?? Could you elaborate on that? </div>
<div><br>
</div>
<div>Provider-based allocation allows naturally for aggregation across infrastructure – as you are aware, the IPv4 “swamp" referenced in the draft is a result of provider-independent (PI) assignments for terminus networks – many being made pre-CIDR era, and
others due to provider-independent allocation policies at the RIRs since… I guess the question is whether we expect a lot of requests for IP address space that not affiliated with any deep space network - do you have an estimate?</div>
<div><br>
</div>
<div>Thanks!</div>
<div>/John</div>
<div><br>
</div>
<div>
<div>John Curran</div>
<div>President and CEO</div>
<div>American Registry for Internet Numbers</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</body>
</html>