[retronet] RetroNet globally-routable address allocation policy

[Michael Kjörling]

On 2 Sep 2018 12:39 -0600, from gtaylor at tnetconsulting.net (Grant Taylor):
> 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.

I think it makes sense to allow for allocation of address space in
different protocols. If we agree on that, then the only issue is the
allocation strategy. If there is no strong reason that all allocations
must use an identical network number, which they can't anyway (cough
decnet cough), then they probably don't need to be allocated all
together, or identically.


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

I'm not too familiar with IPX network addressing, and couldn't quite
wrap my head around it based on the little recent discussion here, so
I figured I'd cover all the bases. :)


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

Looking again at RFC 4193, it seems I misremembered slightly; it has 8
bits of IPv6 prefix, followed by a 40 bit "global ID", followed by a
16 bit "subnet ID", followed by the 64 bits interface ID. By picking
one or two 40 bit global IDs for RetroNet according to the method
described in that RFC, each 16-bit member number can map to one /64 by
default. That doesn't allow for subnetting that allocation further,
but additional allocations can be requested as with other protocols.
One global ID could be for "subnet ID is member number", the other
could be for extra assignments.

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

There's link local, but that's really _link_ local, akin to 169.254/16
in IPv4, as opposed to RFC 1918 which can be routed. Routing of
link-local traffic "to other links" is expressly forbidden.


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

Yeah, I'd really rather avoid appropriating some random
currently-unused portion of the address space.


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

Actually, yes and no.

I'm not arguing that RetroNet traffic should be routed outside of
RetroNet. So I firmly believe that we're in agreement there. If
RetroNet is to serve as a safe playground or experimentation network,
then it should be contained.

However, I don't think it would be fair to assume that no RetroNet
host will ever benefit from being able to _also_ route traffic to and
from the Internet, if for no other reason then to tunnel traffic to
other RetroNet hosts for RetroNet routing purposes.

So it's not so much hosts multihomed on RetroNet (those could be
covered by having multiple assignments within RetroNet space), as it
is about hosts that have connectivity to both RetroNet _and_ the
Internet.

If we're willing to rule out the possibility of RetroNet hosts also
having Internet connectivity, then all of the address space in each
protocol is available for assignment, and there is no need to limit
to, for example, only 100.64/10 in IPv4.

So, I guess this boils down to: Is the idea for RetroNet hosts to be
able to participate on the Internet, or should any host that exists on
RetroNet be completely isolated from the Internet? If the latter, how
to route traffic between RetroNet hosts?


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

Site local was described in RFC 3513, and later deprecated by RFC
3879. It used a 10-bit fixed prefix of fec0::/10 plus a 54-bit locally
assigned "subnet ID". Link-local is similar, except it uses fe80::/10
with all subnet ID bits set to zero, hence the oft-seen
fe80::mmmm:nnnn:oooo:pppp/64. The big problem, from my understanding,
is that nobody ever defined what constituted a "site".

RFC 4193 is fc00::/7 with a grand total of 48 bits global ID
(including the 8 bits of IPv6 prefix) and another 16 bits subnet ID,
as discussed above.

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