[deepspace] Re: Understanding the difference in aggregation between a single and multiple RIR model

[Scott Mitchell Johnson <[e-mail]>]

Tony,

On Thu, 27 Aug 2026, Tony Li wrote:

>
> Hi Scott,
>
>
>> The multiply redundant nature of the RIR system is important.  To discard it in favor of unilateral control is unwise, IMHO.
>
> Really?  Is there some failover mechanism in place that I’m unaware of?

Apparently so... the community of network operators comes to mind.

>
> Multiple RIRs exist for reasons of scale.
>

No, not really.  They exist to distribute responsibility across different 
jurisdictions, so that if one fails, such as the recent situation with 
AFRINIC due to lawfare by Lu Heng, et. al., there is not failure of the 
system as a whole.  There used to be only one registry, mind you; his name 
was Jon Postel.

>
>> I was under the impression that the IETF worked via the principle of 
>> "running code and loose concensus."  Where is the running code, please? 
>> Can you show me where any space agency, or any relevant commercial 
>> entity, has signed onto the notion of using QUIC for these use cases 
>> (i.e. loose concensus among the userbase you are targeting)?  What does 
>> the CCSDS have to say on the matter?
>
>
> For the purposes of address, QUIC is irrelevant.

I disagree.  The idea of codepointing network addresses for off-world use, 
in the context of this groups work to date, MUST be predicated on a 
_working, demonstrable_ end-to-end IP solution; one which is viable beyond 
the Moon, at that.

> The point is IP connectivity.  That require addressing.  The running code 
> is the Internet as it exists today.

Sorry, that does not meet the bar, IMHO, as "the Internet as it exists 
today" will break just past the Moon due to latency, notwithstanding 
lack of contiguous path, and that is IF you don't drop a single packet.
The premise here is that TIPTOP has some manner of solution which changes 
that equation, and things will "just work" when surfing websites served on 
Titan, or when sshing into a machine on Ganymede, via an end-to-end IP 
network.  Now, if you had signalling over quantum entanglement, then the 
delay and disruption issues disappear, and sure, go with IP, and things 
will "just work."  Barring that, I am not seeing a solution which requires 
addressing consideration.


> It will grow outwards, sooner or later.  Here’s on example of plans for 
> IP in space, the LunaNet Interoperability
> Specification Document: https://www.nasa.gov/wp-content/uploads/2025/02/lunanet-interoperability-specification-v5-baseline.pdf?emrc=606f95

Note that this is not "IP in space."  This is IP on the Lunar surface. 
There is a real and significant difference.

On your point, however, we are not so much in disagreement.  I am fully 
convinced that there will be IP networks on the surface of other worlds, 
where the conditions are suitable for IP network operation.  Where we 
differ is that I realize that to perfect a Solar System Internet, delay 
tolerant store and forward networks are an absolute necessity for the 
space link components, just as IP components are necessary for surface 
operations, due to its robust, mature application base.  We have a really 
good store and forward mechanism already (BP), which is pretty well 
accepted by those operating space networks, and don't want to reinvent the 
wheel with the wrong tools.  Note the requirement for BPv7 in the LNIS 
document which you linked above.

In the context of this hybrid BP + IP approach to Solar System 
Internetworking, we really don't need aggregation for routing purposes, 
because in this model, neither routes nor packets need to traverse high 
latency space links.  What would work better, under this model, is 
unroutable, "martian" designation for any IP networks NOT deployed on the 
local world.  I do agree that designated blocks should be set aside for 
off-world use, just for different reasons.

What we _do_ need is the structure of the RIR system, which derives it's 
authority from the community, to remain intact, even if that means a new 
RIR for off-world network governance.  The middle ground is chunks of
a block being divvied up to the 5 RIRs, which is in line with current 
operation regarding other network address allocation.

I have seen no serious attention paid to DNS operation in any of the 
discussion here, yet, which leads me to believe that there is not a full 
end-to-end IP solution which requires network address allocation.  This 
mail, however, is being sent via a hybrid BP + IP network.  Go ahead, 
check the headers. Do some digs... only an MX; no A or AAAA for 
luna.sol.int.  You will find that this mail originated from a host which 
is numbered only with a "martian" address(retired 6bone address, to be 
specific), passed through a BP network by means of an SMTP Application 
Layer Gateway, and was delivered by a "terrestrial" MX to the IETF 
mailman.  This is called "running code" and it operates as a demonstration 
of a viable multi-world DNS architecture; one needs an application that 
uses DNS, or DNS sits there and does nothing.  SMTP seems a good 
demonstration of the DNS and ALG architecture, don't you think?
It also justifies the need for addressing in the off-world use case...

This instance runs in a bespoke high capacity R&E network called the 
Bundle-Bone, built for BP network/application 
development/stress-testing/etc., but will work from the lunar surface as 
well.

Thank you for participating in my interoperability testing of the SMTP ALG 
:)  It also could provide, in a form and fashion, the "running code" 
necessary to justify a block of addresses for off-world use.  As I have 
demonstrated, any old "martian" will do, but I do think a dedicated block 
is wise, as is retaining the RIR structure in that blocks distribution.

>
> As you probably know, CCSDS is the primary organization behind BP and 
> seems dead-set against IP.  Their loss.

Seems to me they are the ones with all the satellites, ground-stations, 
and other lower layer components necessary to network with... maybe one 
should listen to their point of view, just a little?  It takes them 
(space community) AND us (Internet community) to solve this correctly, 
Tony.  We can't freeze them out any more than they can freeze us out.
My advice would be to govern yourselves accordingly.

Scott

>
> Cheers,
> Tony
>
> -- 
> deepspace mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]