[arin-ppml] TIPTOP

Preston Ursini preston at thefirehorn.com
Wed May 20 12:25:51 EDT 2026


I agree with many of the points raised and I believe any address allocation that revolves (orbits?) around celestial body aggregation will be difficult and would merit input from a body such as the IAU, Planetary Society, government space agencies, commercial operators, and many others with cross domain knowledge. A multi-stakeholder working group is likely a good idea.

In our own solar system we go from planet to moon and then we have dwarf planets, asteroids, and many other classifications of celestial objects.

One thing we run into is celestial objects are constantly being discovered that could need address space.

A simple hierarchy from Planet -> Moon won’t work, especially with thousands of trans neptunian objects alone, and millions of other categorized objects as well.

This is only our own solar system, interstellar probes could also potentially need to be addressable.

I believe a prefix for each planet may be a good idea, but which planets, of what size, and what classification of planet (dwarf / gas giant with many moons / etc) is just barely scratching the surface of what is needed here.

If we really were thinking of the far future, I believe that the solar system and objects only exiting the solar system such as the voyager probes should be separately allocated from interstellar objects that may need to one be addressed.

On a very high level I’d propose:
 - Earth orbit and Near Earth Objects (LEO / GEO / Lagrangian Points / etc)
 - Solar system bodies and spacecraft (Moon / Mars / Jupiter / Asteroids)
 - Interstellar probes or future non-solar system networks (Anything destined to leave the solar system)

Each of these class of objects have different needs with latency / connectivity / etc, and I believe is a good start based on density of use and future planning.  Moon/Mars Colony can then be addressed different than an LEO satellite, and Voyager type spacecraft would be in a different range from everyone else.

There will obviously need to be major discussions as to what ranges each body / orbit / etc gets.  I also believe it is worthwhile to not include IPv4 in any of these plans as we’re at exhaustion and the v4 space is not nearly vast enough to accommodate these needs.  I believe most of these space based implementations will require unique networking to the point where IPv6-only will be the least technical challenge here, especially with this and so much of it being so future-focused.


Preston Louis Ursini 
  
  
 

> On May 20, 2026, at 9:57 AM, arin-ppml-request at arin.net wrote:
> 
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
> 
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: TIPTOP (David Farmer)
>   2. Re: TIPTOP (Martin Hannigan)
>   3. Re: TIPTOP (Tony Li)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 20 May 2026 09:20:06 -0500
> From: David Farmer <farmer at umn.edu>
> To: Alison Wood <Alison.WOOD at das.oregon.gov>
> Cc: Martin Hannigan <hannigan at gmail.com>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] TIPTOP
> Message-ID:
> <CAN-Dau1DvzTwcS+wXM91G0Eef2C1CzKWLpTp4dV7CAJLqrt01Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> First, compliance, regulation, and enforcement are stronger terms than I
> intended. I'm thinking more along the lines of mutual understanding, shared
> intent, and consensus.
> 
> Early in this discussion, others and I asked for more details about what is
> meant by "celestial body aggregation". I believe this means that relatively
> large address pools will be reserved for use on and around other celestial
> bodies. Allocations will then be made from these reserved pools to ETNs and
> their operators. I think this much is generally agreed upon. However,
> which celestial bodies receive which size reserved pools is a detail that
> needs to be resolved before ARIN or anyone else can begin allocating to ETN
> operators on such a basis.
> 
> Furthermore, to be effective and to avoid future renumbering or address
> block fragmentation around celestial bodies, it seems likely that very
> large reserve pools will be necessary and will be of interest to the
> Internet Registry System as a whole, the IETF, space agencies, other space
> and Internet operators. What processes will be used to reach consensus
> regarding these parameters? Ideas like "slow start" seem out of place;
> conservation and other goals will likely have new balance points within a
> celestial-body aggregation-allocation regime, compared to the
> provider-based aggregation-allocation regime we have today.
> 
> I'm doubtful these issues can be effectively resolved within IPv4, given
> that IPv4 allocations have been exhausted. The only possible solutions I
> see for IPv4 are either to allocate Class-E (240.0.0.0/4) for ETN use or to
> have NASA or another government agency provide an IPv4 block for ETN use.
> 
> For IPv6, I envision asking the IETF to allocate a block outside 2000::/3
> for ETN use, and then using sparse allocation within that block,
> probably starting with allocations for the Moon and Mars, then
> other celestial bodies as necessary.
> 
> Finally, I think an ETN advisory group should be created that includes
> representatives from space agencies, other space operators, and the
> Internet number resource community as a whole.
> 
> However, nothing in the current proposal addresses how these many issues
> will be resolved.
> 
> 
> On Tue, May 19, 2026 at 11:48?PM Alison Wood <Alison.WOOD at das.oregon.gov>
> wrote:
> 
>> Thank you for the suggestion!
>> 
>> One intended goal of the policy was aggregation, but compliance was not
>> defined.  I would appreciate any suggestions that you have on compliance
>> and enforcing the aggregation per celestial body.
>> ------------------------------
>> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of David Farmer
>> via ARIN-PPML <arin-ppml at arin.net>
>> *Sent:* Tuesday, May 19, 2026 11:48 AM
>> *To:* Martin Hannigan <hannigan at gmail.com>
>> *Cc:* arin-ppml at arin.net <arin-ppml at arin.net>
>> *Subject:* Re: [arin-ppml] TIPTOP
>> 
>> 
>> On Thu, May 14, 2026 at 5:12?PM Martin Hannigan <hannigan at gmail.com>
>> wrote:
>> 
>> 
>> On Thu, May 14, 2026 at 13:07 Tony Li <tony1athome at gmail.com> wrote:
>> 
>> 
>> Hi Fernando,
>> 
>>> Honestly, what is the demand of it in terms of devices, networks right
>> now and for the next few years ?
>> 
>> In 2025, there were about a dozen space missions of note. I would expect
>> the same with a slow linear increase for the foreseeable future.
>> 
>> 
>> +1 to find a policy solution to support this need.
>> 
>> Demand doesn't matter. A need presented by a community does. They(network
>> and other engineers building these networks) already have demand using the
>> resources.
>> 
>> There's no good reason to argue if aggregation benefits are important both
>> policy or technical. ICP2 and the NRPM say so. The high level resource
>> engineering discussed  is a ?duh? moment. Physics.
>> 
>> 
>> I also support a policy to allocate resources for use in deep space and to
>> aggregate them around celestial bodies. However, the current policy doesn't
>> seem to include any kind of commitment from the entities receiving the
>> resources to use them in accordance with the proposed aggregation. Without
>> even a theoretical commitment by the resource holders to implement the
>> intended aggregation, how will it ever be achieved? Obviously, there will
>> be limits to what ARIN can contractually enforce; nevertheless, it seems
>> prudent that resources received under this policy have some minimal
>> exceptions to implement the intended aggregation. Without at least a
>> minimal commitment to fulfill the intended aggregation, creating a new
>> policy regime seems unwise.
>> 
>> --
>> Thank you / Ho Pidamayado / Miigwech
>> ===============================================
>> David Farmer               Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2829 University Ave SE    Phone: 612-626-0815
>> Minneapolis, MN 55414   Cell: 612-812-9952
>> ===============================================
>> 
> 
> 
> -- 
> Thank you / Ho Pidamayado / Miigwech
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2829 University Ave SE    Phone: 612-626-0815
> Minneapolis, MN 55414   Cell: 612-812-9952
> ===============================================
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260520/2a022390/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 20 May 2026 10:37:05 -0400
> From: Martin Hannigan <hannigan at gmail.com>
> To: David Farmer <farmer at umn.edu>
> Cc: Alison Wood <Alison.WOOD at das.oregon.gov>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] TIPTOP
> Message-ID:
> <CAMDXq5OC2nSi-=RQrWzvdbeEUdVAk5FN9QM1LJt_o+bmMxK06g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> On Wed, May 20, 2026 at 10:20 David Farmer <farmer at umn.edu> wrote:
> 
> [ clip ]
> 
>> 
> 
>> I'm doubtful these issues can be effectively resolved within IPv4, given
>> that IPv4 allocations have been exhausted. The only possible solutions I
>> see for IPv4 are either to allocate Class-E (240.0.0.0/4) for ETN use or
>> to have NASA or another government agency provide an IPv4 block for ETN use.
>> 
> 
> Clearly a parody(?), but oddly aligning:
> 
> https://desnic.net
> 
> YMMV,
> 
> -M<
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260520/17910cbc/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 20 May 2026 07:57:32 -0700
> From: Tony Li <tony.li at tony.li>
> To: David Farmer <farmer at umn.edu>
> Cc: Alison Wood <Alison.WOOD at das.oregon.gov>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] TIPTOP
> Message-ID: <13E8D435-0FEC-4E8E-9437-8C5A493DF0AA at tony.li>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> Hi David,
> 
> 
>> On May 20, 2026, at 7:20?AM, David Farmer via ARIN-PPML <arin-ppml at arin.net> wrote:
>> 
>> First, compliance, regulation, and enforcement are stronger terms than I intended. I'm thinking more along the lines of mutual understanding, shared intent, and consensus.
> 
> 
> Agreed.  Envisioning ?enforcement? against large government organizations that play around with tons of liquid oxygen is a challenging proposition.
> 
> 
>> Early in this discussion, others and I asked for more details about what is meant by "celestial body aggregation". I believe this means that relatively large address pools will be reserved for use on and around other celestial bodies.
> 
> 
> It need not be large, but otherwise yes.
> 
> 
>> Allocations will then be made from these reserved pools to ETNs and their operators. I think this much is generally agreed upon. However, which celestial bodies receive which size reserved pools is a detail that needs to be resolved before ARIN or anyone else can begin allocating to ETN operators on such a basis.
> 
> 
> Can we defer this to the managing RIR?
> 
> 
>> Furthermore, to be effective and to avoid future renumbering or address block fragmentation around celestial bodies, it seems likely that very large reserve pools will be necessary and will be of interest to the Internet Registry System as a whole, the IETF, space agencies, other space and Internet operators. What processes will be used to reach consensus regarding these parameters? Ideas like "slow start" seem out of place; conservation and other goals will likely have new balance points within a celestial-body aggregation-allocation regime, compared to the provider-based aggregation-allocation regime we have today.
> 
> 
> This also seems like it could be deferred to the managing RIR.
> 
> 
>> I'm doubtful these issues can be effectively resolved within IPv4, given that IPv4 allocations have been exhausted. The only possible solutions I see for IPv4 are either to allocate Class-E (240.0.0.0/4 <http://240.0.0.0/4>) for ETN use or to have NASA or another government agency provide an IPv4 block for ETN use.
> 
> 
> I?ve suggested that a reclaimed /16 or other reclaimed prefixes might suffice.
> 
> 
>> For IPv6, I envision asking the IETF to allocate a block outside 2000::/3 for ETN use, and then using sparse allocation within that block, probably starting with allocations for the Moon and Mars, then other celestial bodies as necessary.
> 
> 
> Seems reasonable.
> 
> 
>> Finally, I think an ETN advisory group should be created that includes representatives from space agencies, other space operators, and the Internet number resource community as a whole.
> 
> 
> This seems like this is the purview of the managing RIR.
> 
> 
>> However, nothing in the current proposal addresses how these many issues will be resolved.
> 
> 
> Please propose text?
> 
> Cheers,
> Tony
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260520/747ae3c1/attachment.htm>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> https://lists.arin.net/mailman/listinfo/arin-ppml
> 
> 
> ------------------------------
> 
> End of ARIN-PPML Digest, Vol 251, Issue 15
> ******************************************



More information about the ARIN-PPML mailing list