Subject: Re: [44net] question regarding amprgw.sysnet.ucsd.edu From: Brian Kantor Brian@UCSD.Edu Date: 08/01/2013 03:25 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
On Wed, Jul 31, 2013 at 06:16:32PM -0700, Blaine Forbort wrote:
My DNS request is still waiting for coordinator approval. I guess I'll be waiting for that until I can finish off this first step of my experiment.
Does that mean that you submitted it via the portal.ampr.org DNS function? I'm sorry, that function isn't working yet. I've asked for it to be taken off the portal menu until it*is* working as it confuses people.
It also needs to be discussed what functionality is required here for both the users and the coordinator. Sometimes I get requests for approval, and I just looked in the portal.ampr.org again, but it does not really cover the requirements.
What we need is a request from a user to get one or more addresses allocated, accompanied by information like region where they live. The coordinator then must be able to look into the already assigned list of addresses and find an available address in the correct region (subnet), assign it, and return the address to the requester. As it is now, I get requests for 44.137.0.0/16 which makes little sense. Until now I have a hosts file and I make the assignment by browsing through it in the editor, and copy/pasting a line. Then I send the corresponding update to the ampraddr robot. How can we do this in the portal when we abandon the hosts files?
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/08/2013 22:00, Rob Janssen wrote:
What we need is a request from a user to get one or more addresses allocated, accompanied by information like region where they live. The coordinator then must be able to look into the already assigned list of addresses and find an available address in the correct region (subnet), assign it, and return the address to the requester.
The question is should allocation be part of a regional sub allocation which itself is part of a sub allocation from 44.0.0.0/8?
The most efficient way is probably the way the RIRs have been handling out allocation in the last couple of years. It's probably just easier to determinate the network size and assign the first available network of that size. Eventually you could temporarily reserve the adjacent network of the same size so that the network could be extended to that size if necessary. An example:
44.a.0.0/27 for user A 44.a.0.32/27 reserved for user A extension or until exhaustion of the 44.a.0.0/16 block 44.a.0.64/27 for user B 44.a.0.92/27 reserved for user B or until exhaustion 44.a.0.128/26 for user C 44.a.0.192/26 reserved for user C etc etc
Once you have filled all of 44.a.0.0/16 you can start allocating the reserved blocks. However if in the meantime user B needs more addresses, you can extend his allocation from 44.a.0.64/27 to 44.a.0.64/26. The renumbering is pretty easy in that case, a change if netmask is all that is required (in this example). OTOH there is no link between a physical LAN and the addressing, a physical LAN might be using 2 or more subnets (44.a.0.64/26 and 44.a.0.192/26) for addressing.
Dividing the network into sub-areas will cause issues in case some areas have more needs for addresses while other sub-area networks remain almost empty/unallocated.
The encap file and the RIP44d deliver a full routing table for the AMPRnet with absolutely no route aggregation, so the routing table will always be the same size (e.g. their is no gain in routing table size).
CIDR has been introduced in 1993, we shouldn't make the AMPRnet "classfull" by sticking to multiple levels of sub-allocation.
But those are just my thoughts.
73 de Marc, LX1DUC
On 2.8.2013 0:46, Marc, LX1DUC wrote:
The most efficient way is probably the way the RIRs have been handling out allocation in the last couple of years. It's probably just easier to determinate the network size and assign the first available network of that size. Eventually you could temporarily reserve the adjacent network of the same size so that the network could be extended to that size if necessary. An example:
44.a.0.0/27 for user A 44.a.0.32/27 reserved for user A extension or until exhaustion of the 44.a.0.0/16 block 44.a.0.64/27 for user B 44.a.0.92/27 reserved for user B or until exhaustion 44.a.0.128/26 for user C 44.a.0.192/26 reserved for user C etc etc
Once you have filled all of 44.a.0.0/16 you can start allocating the reserved blocks. However if in the meantime user B needs more addresses, you can extend his allocation from 44.a.0.64/27 to 44.a.0.64/26. The renumbering is pretty easy in that case, a change if netmask is all that is required (in this example). OTOH there is no link between a physical LAN and the addressing, a physical LAN might be using 2 or more subnets (44.a.0.64/26 and 44.a.0.192/26) for addressing.
I noticed that in AMPR this is the way IP allocation is handled and I totally support it. I do it the same way in other network.
I think this is the best approach when you are dealing with subnetting and you do not know how usage will expand.
Pedja YT9TP
Why re-invent the wheel? I know it doesn't solve the DNS issue, but..
http://sourceforge.net/projects/teemip/
-Neil
As for the DNS issue:
http://www.debianadmin.com/bind-dns-server-web-interfacefrontend-or-gui-tool...
-Neil
On Fri, Aug 2, 2013 at 1:35 PM, Neil Johnson neil.johnson@erudicon.comwrote:
Why re-invent the wheel? I know it doesn't solve the DNS issue, but..
http://sourceforge.net/projects/teemip/
-Neil
-- Neil Johnson -N0SFH http://erudicon.com
TeemIP
Me like!!!!
Might grab this for use at work.
Mark
On Fri, Aug 2, 2013 at 2:35 PM, Neil Johnson neil.johnson@erudicon.comwrote:
(Please trim inclusions from previous messages) _______________________________________________ Why re-invent the wheel? I know it doesn't solve the DNS issue, but..
http://sourceforge.net/projects/teemip/
-Neil
-- Neil Johnson -N0SFH http://erudicon.com
-
Brian Kantor -
Marc, LX1DUC -
Mark Phillips -
Neil Johnson -
Rob Janssen -
YT9TP Pedja