[arin-ppml] Addressing for other planets

[Tony Li]

Hi Mohibul,

> 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.


Just one clarification: the proposal in the draft is to allocate one prefix per body and also allocate per provider within that prefix.


> 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.


Please say more. How is this different than what is done today?


> 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?


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.


> 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.


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.


> 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.


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.

Tony


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260301/c06972df/attachment-0001.htm>