On Feb 21, 2026, at 5:47 PM, Tony Li <[email protected]> wrote: Hi John,
Actually, there are zero external routes for the agency network operating along its own interplanetary links, and only additional routes for the specific missions of other agencies currently being transit to meet joint mission requirements - i.e. additional routes, but controlled and temporary in nature to reflect scope and mission duration. That doesn’t match my understanding. NASA’s DSN is shared across multiple missions, so should be considered independent of any celestial body. The missions that we’re talking about are currently temporary, but over time will certainly attempt to become permanent, thus, any unaggregated routes will effectively be permanent. By doing allocation along celestial bodies, each agency will be able to get a prefix for their network from the common block for that specific body. These can then be aggregated when they hit interplanetary links, resulting in minimal overhead. Aggregated by whom? Is there a presumption that an agency network will step up and serve as the default transport provider for each given celestial body? There are certainly going to be per-body relays that interact with the DSN. That would be an ideal place to aggregate. These could be operated by various agencies. Note that aggregation with celestial body allocations if and only if – a) all the entities in that deep-space region have rich connectivity between themselves and b) one of those entities announces a covering prefix for the entire body address space, and then c) all traffic traffic goes via that single connection and no agency network announces their more specifics for their their own network. Those aren’t real requirements. Those would be necessary if the goal was perfect aggregation, which its not (and never is). If aggregation is not perfect, there will be additional routes. But that’s actually not relevant to the discussion because you would still be better off than having zero aggregation. It’s actually not better off - provider-based allocation is always the optimum case, since addressing follows actual network topology and aggregation is inherent. You are the one proposing a scheme to try and achieve similar aggregation via addressing that’s not topologically aligned with agency network connectivity, and so it will be worse unless you achieve the above conditions and have a significant set of celestial-body relays operational. There is zero aggregation with your proposed architecture unless there’s agreement up front to have designated service providers for each deep space body/region, and further than agency networks do not interconnect or route individual components with one other except thru the default service providers for that the deep space region/body - i.e. the party announcing the covering route via its communications links. That’s utter nonsense. The architecture provide per-body aggregation and ample opportunity for the agencies to aggregate through the shared nework. There does not need to be a single network provider. Multiple providers can interconnect and aggregate. Hmm.. Rather than dealing in abstractions, perhaps we can work with actual data? Is there a network design or operating model for this celestial "shared network”? I ask because ARIN is capable of dealing with ISP IPv6 allocation requests that are quite sizable and unusual in nature, but we do require some fairly concrete plans to support any such allocation request. Individual space agency networks are likely to qualify today with sufficiently detailed requests (just as we’ve handled various satellite network requests), but I suspect your Deep Space IPv6 requirements really are really of a nature that need to be handled as a new RIR region – that will allow for allocations to be more expansively sized and for handling the implied operational/policy development requirements. Thanks, /John John Curran President and CEO American Registry for Internet Numbers
_______________________________________________ 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.
