[retronet] RetroNet globally-routable address allocation policy

[Grant Taylor]

On 09/01/2018 02:45 PM, John P. Willis wrote:
> Hello all,

Hi John,

> As I develop the application for managing a RetroNet participant's address 
> space allocations for the various protocols, I have a number of policy 
> proposals that it would behoove us to address sooner rather than later:

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

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

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

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.

Aside:  BGP Confederations allow a group of routers to pretend to be a 
single ASN to the routers outside the confederation.  The routers inside 
of the confederation use internally administered ASNs, completely 
independent of what outsiders see.

> IPX:
> 
> * IPX network numbers are in the range 0x1-0xFFFFFFFE. For our purposes, 
> it seems unlikely that we'll exhaust this resource, especially given 
> the 48-bit nature of IPX node addresses.

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?

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

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

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

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

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

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

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

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



-- 
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/20180901/f91061eb/attachment.bin>