[retronet] RetroNet globally-routable address allocation policy

[Grant Taylor]

On 09/02/2018 11:53 AM, Michael Kjörling wrote:
> Let's hope even a 32-bit integer can be packed into 17 decimal digits. 
> If not, we need some new math.

;-)

> 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?

I like that.

> (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.)

Fair.

I don't think I had anticipated that we would also allocate other 
protocols when allocating a second IPX network.  But I know that I 
didn't articulate that.

Thank you for bringing that up Michael.

> 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).

True.

> 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.

I like the 0x04d2xxxx better.  At least in my head, member 1234's IPX 
networks all start with (0x)04D2.

> 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.

I agree that not supporting requested numbers is simpler.  I'd like to 
be able to do it as a creature feature, but it is decidedly NOT required.

> /48 gives plenty of room for subnetting,

That's why I suggested it.

> is there an appropriate IPv6 block to carve them out of?

I'll have to do some looking.

I don't think IPv6 (still) has similar concepts of private address space.

There were some ranges that were subnet local, site local, and 
enterprise local.  I might suggest misusing / abusing them.  —  I'd 
prefer to use this {subnet,site,enterprise} local address space if 
possible.  (I can't remember if, much less how, this failed the last 
time I tried to use it.)

Other than that, I think we'd need to abuse unallocated IPv6 address 
space.  —  It will technically function, but I don't like it.

> It doesn't _really_ matter as long as nobody cares about global routing 
> on the same host,

I'd like to dig a trench in the sand.  Everything in RetroNet is LOCAL 
to RetroNet and will most decidedly NOT be globally routed.

That being said, I believe that Michael meant to imply routed inside of 
RetroNet.

I'd like to support routing from ""public RetroNet addresses.  Then it's 
up to each individual member if the want to use such or not.  I want 
RetroNet to be capable of doing this.

> but could potentially complicate routing for multihomed hosts 
> unnecessarily. Or are we willing to rule out use on multihomed systems?

I had not thought about multihomed hosts.

I don't see a /need/ for multihomed hosts.  But I can certainly see the 
educational value in supporting such.  There may also be some advantage 
of it if / when we expand to multiple cores.

[M1]    [M2]
  |        |
  |        |
  |        |
[C1]----[C2]     Here's hoping ASCII survives the Mailing list.
   \      /
    \    /
     \  /
     [M3]

M3 can benefit from routing knowledge to choose the best path to M1 and M2.

> 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.

I'm going to need to re{read,skim} RFC 4193 to be able to comment.  But 
I suspect we are in the same ballpark.

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

I'd like to avoid special cases.

Maybe 1337:<ipv4>:<ipv4>::/48.  ;-)  At least it's an IPv6 bogon.  ():-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.chivanet.org/pipermail/retronet/attachments/20180902/5df18adc/attachment.bin>