[retronet] RetroNet globally-routable address allocation policy

[Michael Kjörling]

On 2 Sep 2018 10:21 -0600, from jpw at chivanet.org (John P. Willis):
> Space isn't an issue unless network numbers exceed 17 digits.

Let's hope even a 32-bit integer can be packed into 17 decimal digits.
If not, we need some new math.


> If we want the user's ASN (or member number) and network numbers in other
> types of networks to match (at least for the first allotment to any user),
> the incrementing of next-available numbers would need to be in lock-step.

How about making the initial network number assignment be the member
number, which could increase monotonically from 1, and any additional
network number assignments start at the maximum and decrease
monotonically, per protocol? (So member 123 gets IPv4 and IPX network
number 123, and when they request another IPX network, they might get
65529, but there's no reason why they'd also get IPv4 network number
65529 when requesting a second IPv4 assignment.)

Sure, this way a single member's network numbers won't be contiguous,
but there's no reason to expect them to be contiguous anyway unless
the member requests the extra network numbers immediately (or at the
very least all at the same time, for the case of requesting multiple
extra assignments), which seems unlikely. And contiguous allocations
are only _really_ useful when they align on CIDR bit boundaries, which
won't happen except by accident (or design).


>>> * I would begin by allocating one IPX network number to each
>>> registrant, that number being the same as the registrant's ASN.
>> 
>> Yep, re-using the "member number".
>> 
>> Thus I would be 0x0003xxxx, RetroNet would be 0x0001xxxx, and DataShed
>> would be 0x0002xxxx.
> 
> This seems to indicate that we're allocating in hex. I've been doing
> everything decimal.

Well, any 16-bit number can be represented equally well as up to five
decimal digits and up to four hexadecimal digits, so I see no
particular reason why member number 1234 (decimal) can't get
0x04d2xxxx or 0xxxxx04d2. Otherwise you're limiting to 10K members,
rather than 64Ki.


> What I like about the approach is that it would keep any members' own
> networks contiguous, and would mean that we would not really need to support
> user requests for more IPX networks (they get what they get).


>> I think we should re-use the "member number" for the first AppleTalk
>> network number.  If / when a member needs an additional AppleTalk
>> network number, they can request something specific, or they can default
>> to the next one from the top down.
>> 
>> I'm suggesting top down to avoid potential conflicts with defaulting
>> member numbers from the next one from the bottom up.
> 
> This top-down approach for user-requested allocations, with bottom-up for
> automatic allocations would certainly make the code easier to reason about
> and implement (other than some possible bit-twiddling if we go with your
> idea for dividing up the IPX address space).

Top down for additional allocations seems reasonable; I'd actually
suggest against allowing people to make specific requests. It's not
like it makes a great difference if one gets network number 65529 or
42424, and it seems likely to complicate things rather substantially.


>> Note:  I'm allocating a /48 to each member so that they can divide it
>> into many /64s.
> 
> A /48 would be the smallest block I'd want to dish out as well.

/48 gives plenty of room for subnetting, but is there an appropriate
IPv6 block to carve them out of? It doesn't _really_ matter as long as
nobody cares about global routing on the same host, but could
potentially complicate routing for multihomed hosts unnecessarily. Or
are we willing to rule out use on multihomed systems?

There's the old, deprecated site-local space, which would provide
sufficient room. Properly done RFC 4193 space doesn't; that gives only
a single /64.

Or ffff:<ipv4>:<ipv4>::/48? But I think that's special-cased by a lot
of software...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)