[retronet-core] [retronet] RetroNet globally-routable address allocation policy

[John P. Willis]

On Sat, 1 Sep 2018, Grant Taylor wrote:

> On 09/01/2018 02:45 PM, John P. Willis wrote:
>
> I'd like to back up a moment and clarify something that I'm working with in 
> my head.  Or at least document it for others to benefit from, or correct me.
>
> I've been thinking of these things as "member numbers".  And I'm using said 
> member number for things like ASNs, IP addresses, IPX network numbers, etc.
>
> Functionally we probably end up in the same place.  But I think we could 
> probably safely assume that we can default member numbers when other things 
> are not explicitly specified.  (I don't know if this helps in a DB sense or 
> not.)

I'm currently tying network number assignments to usernames:

Each network is keyed off of first its protocol/class (ASN, IPX, 
APPLETALK, etc.) and then the network number, with a separate index tying 
them to user accounts. Every network number assignment (including ASNs 
themselves) has a parent ASN.

Keeps the code for assigning networks nicely general.

>
>> Autonomous System Numbers:
>> 
>> * Firstly, do we want to support 16-bit ASNs, 32-bit ASNs, or both?
>
> I think we can get away with 16-bit ASNs.  That's 65,534 usable ASNs. (65,535 
> is reserved and shouldn't be used.)
>
> That being said, I see no reason why we can't also support / allow 32-bit 
> ASNs.  I'll defer to someone that has an idea what the problems might be 
> here.
>
> I would design and code things with room to use the 32-bit ASN.  That way it 
> will fit if we want to use it.  16-bit ASNs will easily fit in it too.  ;-)
>

Space isn't an issue unless network numbers exceed 17 digits.

>> * If we want to allow user-requested ASN allocations, I'd like to carve out 
>> a reserved range for this near the top of the 16-bit and/or 32-bit space.
>
> I'm not opposed to having an automatically (sequentially?) assigned section 
> and a separate requested section.
>
> Please help me understand the need for both?

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.

See this scenario:

* User 1 submits the registration form
* Account is created, and gets a member number/ASN of 1
* User 1 is allotted AppleTalk network number 1 and IPX network number 1
* The "next available" counters for ASN, IPX, and AppleTalk is incremented 
by 1

* User 1 requests an additional IPX network number,
* "next available" counter for IPX is now 2
* User 1 now has ASN 1, IPX networks 1 + 2, and AppleTalk network 1.

* User 2 submits the registration form
* User 2 account is created, and gets a member number/ASN of 2
* User 2 is alloted AppleTalk network number 2 and IPX network number 3
* User 2 now has ASN 2, IPX network 3, and AppleTalk network 2

At this point, IPX network numbers no longer match a given user's 
ASN/member number.

[nerdy_programming_note]

FWIW, the code for allocating network numbers is, of necessity, reentrant:

It locks a critical section to avoid race conditions that would happen if 
two users attempt to increment the counters concurrently.

[/nerdy_programming_note]

>
> Can we not assume that all of the space is user requested and just default to 
> the next available if nothing is specifically requested?
>
>> * My initial approach will be to allocate a single ASN to any registrant, 
>> pending further discussion. The database is architected in such a way that 
>> adding the ability to support requests for additional ASN allocations will 
>> be trivial.
>
> That seems reasonable.
>
> I don't foresee any reason that members will need multiple ASNs. Especially 
> considering my suggestion for BGP Confederations.
>

SGTM

>
> Given my (limited) understanding of IPX and how network numbers work, I'd 
> propose that the higher two bytes / four hexadecimal digits be the encoded 
> form of the member number.  That will give each member the lower two bytes / 
> four hexadecimal digits of the IPX network number to use for additional IPX 
> networks.
>
> I think this is somewhat important because NetWare uses a network number for 
> each IPX network, which includes one for each frame type used.  I think 
> NetWare also likes to assign an IPX network number to the loopback of a 
> server so that it can be accessed independently of the physical network and 
> associated Network Number.
>
> So, 0x0000|xxxx - 0xFFFF|xxxx (left side of the pipe) would allow members to 
> stick to one high network number range while choosing their own lower range.
>
> What do you think?

It could be done, with non-trivial (but not extensive)  rearchitecting of 
the network allocation code.

As I understand it, the IPX "internal network" number is for the purpose 
of simplifying routing when a NetWare box has more than one physical 
network interface.

AFAIK, we're only assigning external networks. I don't know what the 
ramifications would be of assigning an external network number that 
happens to coincide with the [usually] randomly-generated internal network 
number of some machine on the member's network. I would hope nothing, as 
it seems that Novell would have been in trouble with their customers for 
such potentially-damaging nondeterministic behavior.


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

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

The downside is complexity of implementation from my side ;-)

I'm sure I could figure it out, though.

>> * We need to come up with some guesses as to how many participants we may 
>> attract. This way, we can reserve a range of IPX network numbers above the 
>> automatically allocatable range for users who request additional IPX 
>> networks.
>
> I'd be surprised if we have more than 65,000 members.  As such, I think 
> 16-bit numbers will probably be okay.
>
> I'd actually like it if we need to worry about this in the future.
>

[aol]
Me too!
[/aol]

>> AppleTalk:
>> 
>> * AppleTalk network numbers are--like the original definition of ASNs--a 
>> 16-bit quantity. If there are more than 64k participants in RetroNet, I'll 
>> be quite surprised. However, like ASNs (in the case that we settle on using 
>> 16-bit ASNs only), I think we should be judicious about handing out huge 
>> numbers of AppleTalk networks without a good reason.
>
> My understanding of AppleTalk addresses is that they are four byte or 32-bit. 
> But those 32-bits are divided into 16-bits for the network number, 8-bits for 
> the node number, and 8-bits for the socket (service) number.
>
> So, as I see it, we can have 16-bits for network numbers.
>
> 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).

>> * I'll allocate one by default, again corresponding to the primary ASN of 
>> the registrant.
>
> Yep, "member number".
>
>> X.25:
>> 
>> * Are we looking at mostly VCs or PVCs? If VCs, then we have a DCC from (I 
>> believe) 000-999, plus a network ID of 0-9.
>> 
>> * I have no experience with X.25, so I'll be leaning on others for input on 
>> this. However, at present, I'm thinking about not doing an automatic X.25 
>> address assignment, but allowing a participant to request a single (and 
>> only one) DCC, and they'd be able to use all 10 network IDs within it.
>
> I'll have to do some more reading on X.25 and get back to you.
>

I'm going to try to play with X.25-over-IP stuff in IOS in the lab this 
week.

>> IP:
>> 
>> * I believe we have tentatively settled on using RFC 6598 addresses, in the 
>> range 100.64.0.0/10.
>> 
>> * How much address space should we allocate by default? Perhaps a /24 to 
>> each subscriber?
>
> I'm inclined to re-use the member number as the 3rd octet and allow members 
> to have the /24 and assign the 4th octet as they see fit.
>

SGTM

> Granted, that's only 14-bits of address space to assign.  So 16-bits of 
> member numbers won't fit.  But I will be shocked if we have 16k members.
>
> I am somewhat inclined to do similar for IPv6.
>
> Note:  I'm allocating a /48 to each member so that they can divide it into 
> many /64s.
>
> 100:64:3::123/48
>
> 0100:0064:0003:0000:0000:0000:0000:0123/48
>
> I could take the following and sub-divide it however I want to.
>
> 0100:0064:0003:xxxx:xxxx:xxxx:xxxx:xxxx
>

A /48 would be the smallest block I'd want to dish out as well.

>> SNA:
>> 
>> * I have no idea how SNA addressing works, so I'm leaving this out for the 
>> moment.
>
> Likewise.
>
>> DECnet:
>> 
>> * Area numbers (in Phase IV and Phase V) are 6-bit, from 0-63. This is a 
>> VERY limited resource.
>> 
>> * Leaving out for now.
>
> I think I'd default to the bottom 6-bits of the member number unless there is 
> a conflict.  We can address conflicts if / when they come up.
>
> Note:  I would not allocate DECnet addresses until the member actively wants 
> to use them.

Ditto.

>
>> I welcome any feedback, input, etc. on this.
>
> Perhaps we should apply the "actively wants to use them" mentality to other 
> protocols & addresses.  Default to the member number unless there is a 
> conflict when the member is ready to use it.
>
> What do you think?
>

Perhaps we should only auto-allocate ASN and IPv4/IPv6 space, and make the 
other stuff entirely on user request?

How married are we to having network numbers in all protocols line up with 
member numbers?

>
>
> -- 
> Grant. . . .
> unix || die
>
>

----------------------------------------------------------------------------------
JP Willis jpw at chivanet.org                     Voice 575/520-9542 Fax 575/449-4122
ChivaNet Internet Services, 425 S. Telshor Blvd., Ste. C202, Las Cruces, NM  88011
Hardware, n.:  The parts of a computer system that can be kicked.       (Borrowed)
----------------------------------------------------------------------------------