[arin-ppml] Addressing for other planets

[Tony Li]

Hi Bill,

> Are you the same Tony Li I worked with in the IRTF Routing Research
> Group (RRG) years ago?


As co-chair, yes.


> I watched the TIPTOP presentation at APRICOT a couple weeks ago. It
> sounded like the idea is to hew as closely as practical to the
> existing protocol standards and practices that we have now, rather
> than invent an interplanetary-specific network stack. Relax the timers
> and change the buffering expectations. Is that about right?


Yes, that’s about right.

As you well know, the Internet and IP are enormously flexible and powerful. Space agencies would gain many advantages from using as much of our technology as possible rather than re-inventing everything from the ground up (literally :-).


> I guess my main question is: what's different about interplanetary
> network links that would allow geographic address aggregation to align
> with the routing? I thought we pretty clearly established in the RRG
> that geographic routing in terrestrial interdomain networks was a
> non-starter.


No, what we established was that what people were proposing was a non-starter. While they called it geographic addressing, it would be more correctly called metro addressing.  It made one pretty big assumption: all providers in a metro area would be regulated into connecting into a single metro interconnect. From there, only the aggregate would ever be advertised out of the metro.  This was the primary aggregation and abstraction mechanism.  The ultimate goal was to achieve provider independent addressing, but that would have meant per-site or per-host prefixes in the metro routing, which pretty clearly doesn’t scale adequately.

Doing nested abstraction on a geographic basis has never been adequately considered. It’s been around for a long time (see RFC 1518, section 5.7), but the pain/reward tradeoff has never been high enough for us to expore it in depth.

Using geographically based aggregation at a higher level has the advantage that it allows us to capture ’noise’ that exists within the routing system at obvious boundaries. Geography is indirectly the driver because geography induces cut sets in the topology that are easier to manage.  In the case of Mars and deep space, for example, we have a cut set of a single link, NASA’s DSN.

This still allows provider/agency aggregation within the geographic abstraction and it allows links out of the abstraction that don’t advertise the full aggregate.  In short, it operates exactly as our usual provider-based addressing would, except that it can eliminate many adjacent prefixes that all have the same next hop.

This scalability advantage is a major win the deep space case because we are unlikely to be able to use our conventional routing protocols over the intermittent deep space links and will instead have to have some other mechanism to update our forwarding tables. Avoiding an O(n) factor in these updates would be welcome.


> Folks running expensive long haul links like to be paid. They choose
> protocols which restrict the introduction of data packets to addresses
> operated by networks who have directly or indirectly compensated them.


True, but how is this relevant?


> We know with the transatlantic and other oceanic routes that this
> selection does not follow large geographic boundaries closely enough
> to benefit from geographic address aggregation. Why would it follow
> large spatial ones?


I’m sorry, I don’t understand your question.  We’re not talking about transoceanic links here. We’re talking about deep space. You can take it as a given that this protected by sufficient firewalls and application gateways that no unauthorized packets will ever make it to Mars.  [Which is kind of a pity, as I really want to ping Mars. :-) ]

In space, we have a small number of agencies who are already agreeing to cooperate on link sharing for cost-savings.


> Taking my Bill Herrin hat off and putting my Advisory Council hat on:
> 
> If you want to achieve something like this at ARIN, at some point you
> would write and submit a number policy proposal which does three
> things:
> 
> 1. Establishes criteria in the ARIN NRPM where IP addresses deployed
> in outer space are considered in use for the purpose of ARIN
> determining an organization's use and qualification.
> 
> 2. Establishes pools of IPv4 addresses reserved for each of the
> specific celestial bodies, and the quantity reserved for each.
> 
> 3. Establishes pools of IPv6 addresses reserved for each of the
> specific celestial bodies, and the quantity reserved for each.
> 
> Finally, you'd specify that implementation would pend a request from
> IANA pursuant to publication of the relevant TIPTOP RFC.


Ok, I have no idea how to do those things, but I’ll look into it.  Right now, I’m showing you the RFC that will be coming out of TIPTOP.  If you need specific things in that RFC, now would be a good time.

I’ll forgo the IPv4 part for now.  Let’s get the IPv6 parts in place.


> Once the policy proposal is submitted, it goes through a bunch of
> steps, for which the main one is presenting it to the community and
> gathering their consent. That means discussing it here on the PPML and
> at ARIN in-person meetings and gathering feedback.
> 
> I think I would consider splitting it into three proposals since
> you're really asking the community for three related but different
> things: permission for ARIN to act as a registrar for outer space,
> permission to reserve blocks of IPv4 addresses which then cannot be
> used for another purpose and permission to reserve blocks of IPv6
> addresses which then cannot be used for other purposes. That way you
> could get some separation of fate between whether the ARIN community
> is willing to have its fees support space allocations and whether
> they're willing to tie up IP addresses for it ahead of those
> addresses' use.
> 
> And I would definitely suggest more informal discussion like this one
> to help develop such a proposal before formally submitting it.
> 
> You can find the template here:
> https://www.arin.net/participate/policy/pdp/appendix_b/


On it.

Regards,
Tony