[44net] On the Issue of Subnets

I wrote a paper back in the 1995-1999 time frame when packet was fairly active in my area regarding when and why to subnet. I received about an equal number of complaints from the linear-allocation advocates versus the subnetting advocates with good reasons on both sides for doing one or the other. I have searched my old hard drives for my original document but I can't seem to find it so I will outline the basic scheme again. My first plan was to dedicate bits in the address plan for geography/frequency and other factors but Brian talked me out of making any plan more complex than it already was. He also informed me of his reservation of the first 2 bits in the third octet for his use in future, something I was unaware of when I assumed the post. This made the CIDR mask 44.18.0.0/18 instead of the expected /16. This gave me effectively only 6 bits in the third octet to play with. Next came the question of how big to make the subnets. I don't have multiple counties to play with and I don't coordinate a whole state so topologically my region is pretty flat, being two counties, but still geographically very large, San Bernardino being the largest county in the U.S. but sparsely populated. Considering the population of hams in the region and the number of hosts addresses within 44.18/16 I didn't expect to have a problem running out of addresses no matter what scheme we chose. I was pretty much stuck with subnet 0, being the linear assignment scheme I inherited from the previous coordinator and we simply followed the pattern initiated in Los Angeles County where the ham population was more active and dense. My research into the RFCs and the nature of subnets and CIDR masks led me to a proposal to mask the subnet bits downward and the host bits upward, I don't recall the source of the document at this time but it might have been an RFC. Thus, the zeroeth subnet could stay in place as two-meter and mobile nodes and the _first_ subnet would be 32, not 1 as you might expect in a linear scheme. The bits map as follows: 44.18.0.0/18 The S.B. & Riverside Co. Group 6 bits reserved for CIDR subnets within the group. c = CIDR, x = hosts 00101100.00010010.00cccccc.xxxxxxxx The CIDR mask for the subnets becomes 44.18.0.0/24 and the total number of subnets is 64. The CIDR bits are allocated in sequence from MSB to LSB, thus: Subnet Bitmap 0 00101100.00010010.00000000.xxxxxxxx 44.18.0.x/24 1 00101100.00010010.00100000.xxxxxxxx 44.18.32.x/24 2 00101100.00010010.00010000.xxxxxxxx 44.18.16.x/24 3 00101100.00010010.00110000.xxxxxxxx 44.18.48.x/24 4 00101100.00010010.00001000.xxxxxxxx 44.18.8.x/24 5 00101100.00010010.00101000.xxxxxxxx 44.18.40.x/24 ... 63 00101100.00010010.00111111.xxxxxxxx 44.18.63.x/24 By growing the subnets downward and the hosts upward linearly, if a subnet were to become overpopulated with hosts, it can expand upward into another subnet: 2 00101100.00010010.00010000.11111111 44.18.16.0/24 rolls over into x 00101100.00010010.00010001.00000000 44.18.33.0/24 I then becomes possible to allocate entire subnets to a single group, (e.g., ARES, RACES) and a single band (6 meters) without regard to the number of hosts needed in that subnet. Connectivity and routing in Southern California can be sparse and geographically large, for instance, a 2 meter and 6 meter digipeater on Big Bear covering San Bernardino and Ontario California and reaching into Arizona and Nevada but seeing less than two dozen active nodes. The implications for static routing are straight forward. To get to any subnet one merely needs to route to the nearest host in 44.18/18 and the most any host needs is 63 routes. This was my solution, your mileage may vary. I never received any feedback regarding this solution until I googled this: http://www.snarked.org/~scdcc/tcpip-18.html I'll be interested in reading the comments from the list.