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.
On Thu, Feb 23, 2012 at 05:56:42PM -0800, Geoff Joy wrote:
[...] 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.
Yes, that was a time when we seemed to be growing subnets faster than expected and it looked like the original scheme I inherited was going to run out of space.
Nowadays I think we'll not need those two extra bits any time soon.
In retrospect I probably should have come up with a more equitable scheme for non-USA countries, but we have had enough space to allocate additional blocks when it became desireable to accomodate larger subnetting schemes.
Conversely, there are some allocations which are larger than the entire ham population of some countries. It's largely been a "seat of the pants" approach and is notably suboptimal in several cases. For that I apologize. - Brian
It took me some time to re-invent the program to calculate the subnet pattern but here is a table of the subnets indexed in intended order of assignment. The goal is to postpone the collision of host assignments with subnet assignments.
Looking at the bit patterns it becomes clear that the first 32 subnets are the primaries and the secondaries are the overflow nets supporting added hosts in the primaries.
If this were implemented across eight bits instead of six the number of subnets quadruples.
Subnet Index Subnet Hex Binary 0 0 0x00 000000 1 32 0x20 100000 2 16 0x10 010000 3 48 0x30 110000 4 8 0x08 001000 5 40 0x28 101000 6 24 0x18 011000 7 56 0x38 111000 8 4 0x04 000100 9 36 0x24 100100 10 20 0x14 010100 11 52 0x34 110100 12 12 0x0c 001100 13 44 0x2c 101100 14 28 0x1c 011100 15 60 0x3c 111100 16 2 0x02 000010 17 34 0x22 100010 18 18 0x12 010010 19 50 0x32 110010 20 10 0x0a 001010 21 42 0x2a 101010 22 26 0x1a 011010 23 58 0x3a 111010 24 6 0x06 000110 25 38 0x26 100110 26 22 0x16 010110 27 54 0x36 110110 28 14 0x0e 001110 29 46 0x2e 101110 30 30 0x1e 011110 31 62 0x3e 111110 32 1 0x01 000001 33 33 0x21 100001 34 17 0x11 010001 35 49 0x31 110001 36 9 0x09 001001 37 41 0x29 101001 38 25 0x19 011001 39 57 0x39 111001 40 5 0x05 000101 41 37 0x25 100101 42 21 0x15 010101 43 53 0x35 110101 44 13 0x0d 001101 45 45 0x2d 101101 46 29 0x1d 011101 47 61 0x3d 111101 48 3 0x03 000011 49 35 0x23 100011 50 19 0x13 010011 51 51 0x33 110011 52 11 0x0b 001011 53 43 0x2b 101011 54 27 0x1b 011011 55 59 0x3b 111011 56 7 0x07 000111 57 39 0x27 100111 58 23 0x17 010111 59 55 0x37 110111 60 15 0x0f 001111 61 47 0x2f 101111 62 31 0x1f 011111 63 63 0x3f 111111
On Fri, Feb 24, 2012 at 10:12:14PM -0800, Geoff Joy wrote:
If this were implemented across eight bits instead of six the number of subnets quadruples.
Good scheme!
I think we can take it as read that the /16s really are /16s as the table says, not /18s as I once thought they'd have to be, so you do have all 8 bits of the third octet to use.
I wonder if it might be wise to reserve the zero'th subnet?
- Brian
On Sat, 25 Feb 2012 00:30:05 -0800, Brian Kantor Brian@ucsd.edu wrote:
On Fri, Feb 24, 2012 at 10:12:14PM -0800, Geoff Joy wrote:
If this were implemented across eight bits instead of six the number of subnets quadruples.
Good scheme!
I think we can take it as read that the /16s really are /16s as the table says, not /18s as I once thought they'd have to be, so you do have all 8 bits of the third octet to use.
I wonder if it might be wise to reserve the zero'th subnet?
I didn't think reserving it was necessary, CIDR allows it as a proper subnet so I grandfathered the zero'th subnet as "mobile" or non-specific use since those routes already existed but whenever anyone had a specific location, use, or frequency or they wanted a block of IP's I allocated them one of the subnets.
You do have to reserve host 0 and host 255 as broadcast addresses. If you follow what seems to be the de facto standard host 1 also becomes the gateway for that subnet with 2, 4, 6 being DNS. Although, if you take BBN's (now Level3) original usage as an example, their DNS is on 4.2.2.1, 4.2.2.2 through 6.
CIDR _is_ classless, so I would expect modern routers that take the CIDR mask would be able to handle broadcasts across joined subnets on a 44.x.x.x/23 mask, but I have not experimented with it. In that case if you need to expand the hosts bit to /23 the first address in that subnet becomes the broadcast address as in 44.x.1.255, 44.x.129.255, etc.
If you want to allocate 9 or 10 bits to the hosts and use the /23 or /22 netmask then you are back to the first 128 or 64 indexes respectively.
Using all eight bits the scheme looks like this and the 6-bit scheme fits interstitially with the 8-bit scheme.
Subnet assignment order by index
Index Subnet Hex Binary 0 0 0x00 00000000 1 128 0x80 10000000 2 64 0x40 01000000 3 192 0xc0 11000000 4 32 0x20 00100000 5 160 0xa0 10100000 6 96 0x60 01100000 7 224 0xe0 11100000 8 16 0x10 00010000 9 144 0x90 10010000 10 80 0x50 01010000 11 208 0xd0 11010000 12 48 0x30 00110000 13 176 0xb0 10110000 14 112 0x70 01110000 15 240 0xf0 11110000 16 8 0x08 00001000 17 136 0x88 10001000 18 72 0x48 01001000 19 200 0xc8 11001000 20 40 0x28 00101000 21 168 0xa8 10101000 22 104 0x68 01101000 23 232 0xe8 11101000 24 24 0x18 00011000 25 152 0x98 10011000 26 88 0x58 01011000 27 216 0xd8 11011000 28 56 0x38 00111000 29 184 0xb8 10111000 30 120 0x78 01111000 31 248 0xf8 11111000 32 4 0x04 00000100 33 132 0x84 10000100 34 68 0x44 01000100 35 196 0xc4 11000100 36 36 0x24 00100100 37 164 0xa4 10100100 38 100 0x64 01100100 39 228 0xe4 11100100 40 20 0x14 00010100 41 148 0x94 10010100 42 84 0x54 01010100 43 212 0xd4 11010100 44 52 0x34 00110100 45 180 0xb4 10110100 46 116 0x74 01110100 47 244 0xf4 11110100 48 12 0x0c 00001100 49 140 0x8c 10001100 50 76 0x4c 01001100 51 204 0xcc 11001100 52 44 0x2c 00101100 53 172 0xac 10101100 54 108 0x6c 01101100 55 236 0xec 11101100 56 28 0x1c 00011100 57 156 0x9c 10011100 58 92 0x5c 01011100 59 220 0xdc 11011100 60 60 0x3c 00111100 61 188 0xbc 10111100 62 124 0x7c 01111100 63 252 0xfc 11111100 64 2 0x02 00000010 65 130 0x82 10000010 66 66 0x42 01000010 67 194 0xc2 11000010 68 34 0x22 00100010 69 162 0xa2 10100010 70 98 0x62 01100010 71 226 0xe2 11100010 72 18 0x12 00010010 73 146 0x92 10010010 74 82 0x52 01010010 75 210 0xd2 11010010 76 50 0x32 00110010 77 178 0xb2 10110010 78 114 0x72 01110010 79 242 0xf2 11110010 80 10 0x0a 00001010 81 138 0x8a 10001010 82 74 0x4a 01001010 83 202 0xca 11001010 84 42 0x2a 00101010 85 170 0xaa 10101010 86 106 0x6a 01101010 87 234 0xea 11101010 88 26 0x1a 00011010 89 154 0x9a 10011010 90 90 0x5a 01011010 91 218 0xda 11011010 92 58 0x3a 00111010 93 186 0xba 10111010 94 122 0x7a 01111010 95 250 0xfa 11111010 96 6 0x06 00000110 97 134 0x86 10000110 98 70 0x46 01000110 99 198 0xc6 11000110 100 38 0x26 00100110 101 166 0xa6 10100110 102 102 0x66 01100110 103 230 0xe6 11100110 104 22 0x16 00010110 105 150 0x96 10010110 106 86 0x56 01010110 107 214 0xd6 11010110 108 54 0x36 00110110 109 182 0xb6 10110110 110 118 0x76 01110110 111 246 0xf6 11110110 112 14 0x0e 00001110 113 142 0x8e 10001110 114 78 0x4e 01001110 115 206 0xce 11001110 116 46 0x2e 00101110 117 174 0xae 10101110 118 110 0x6e 01101110 119 238 0xee 11101110 120 30 0x1e 00011110 121 158 0x9e 10011110 122 94 0x5e 01011110 123 222 0xde 11011110 124 62 0x3e 00111110 125 190 0xbe 10111110 126 126 0x7e 01111110 127 254 0xfe 11111110 128 1 0x01 00000001 129 129 0x81 10000001 130 65 0x41 01000001 131 193 0xc1 11000001 132 33 0x21 00100001 133 161 0xa1 10100001 134 97 0x61 01100001 135 225 0xe1 11100001 136 17 0x11 00010001 137 145 0x91 10010001 138 81 0x51 01010001 139 209 0xd1 11010001 140 49 0x31 00110001 141 177 0xb1 10110001 142 113 0x71 01110001 143 241 0xf1 11110001 144 9 0x09 00001001 145 137 0x89 10001001 146 73 0x49 01001001 147 201 0xc9 11001001 148 41 0x29 00101001 149 169 0xa9 10101001 150 105 0x69 01101001 151 233 0xe9 11101001 152 25 0x19 00011001 153 153 0x99 10011001 154 89 0x59 01011001 155 217 0xd9 11011001 156 57 0x39 00111001 157 185 0xb9 10111001 158 121 0x79 01111001 159 249 0xf9 11111001 160 5 0x05 00000101 161 133 0x85 10000101 162 69 0x45 01000101 163 197 0xc5 11000101 164 37 0x25 00100101 165 165 0xa5 10100101 166 101 0x65 01100101 167 229 0xe5 11100101 168 21 0x15 00010101 169 149 0x95 10010101 170 85 0x55 01010101 171 213 0xd5 11010101 172 53 0x35 00110101 173 181 0xb5 10110101 174 117 0x75 01110101 175 245 0xf5 11110101 176 13 0x0d 00001101 177 141 0x8d 10001101 178 77 0x4d 01001101 179 205 0xcd 11001101 180 45 0x2d 00101101 181 173 0xad 10101101 182 109 0x6d 01101101 183 237 0xed 11101101 184 29 0x1d 00011101 185 157 0x9d 10011101 186 93 0x5d 01011101 187 221 0xdd 11011101 188 61 0x3d 00111101 189 189 0xbd 10111101 190 125 0x7d 01111101 191 253 0xfd 11111101 192 3 0x03 00000011 193 131 0x83 10000011 194 67 0x43 01000011 195 195 0xc3 11000011 196 35 0x23 00100011 197 163 0xa3 10100011 198 99 0x63 01100011 199 227 0xe3 11100011 200 19 0x13 00010011 201 147 0x93 10010011 202 83 0x53 01010011 203 211 0xd3 11010011 204 51 0x33 00110011 205 179 0xb3 10110011 206 115 0x73 01110011 207 243 0xf3 11110011 208 11 0x0b 00001011 209 139 0x8b 10001011 210 75 0x4b 01001011 211 203 0xcb 11001011 212 43 0x2b 00101011 213 171 0xab 10101011 214 107 0x6b 01101011 215 235 0xeb 11101011 216 27 0x1b 00011011 217 155 0x9b 10011011 218 91 0x5b 01011011 219 219 0xdb 11011011 220 59 0x3b 00111011 221 187 0xbb 10111011 222 123 0x7b 01111011 223 251 0xfb 11111011 224 7 0x07 00000111 225 135 0x87 10000111 226 71 0x47 01000111 227 199 0xc7 11000111 228 39 0x27 00100111 229 167 0xa7 10100111 230 103 0x67 01100111 231 231 0xe7 11100111 232 23 0x17 00010111 233 151 0x97 10010111 234 87 0x57 01010111 235 215 0xd7 11010111 236 55 0x37 00110111 237 183 0xb7 10110111 238 119 0x77 01110111 239 247 0xf7 11110111 240 15 0x0f 00001111 241 143 0x8f 10001111 242 79 0x4f 01001111 243 207 0xcf 11001111 244 47 0x2f 00101111 245 175 0xaf 10101111 246 111 0x6f 01101111 247 239 0xef 11101111 248 31 0x1f 00011111 249 159 0x9f 10011111 250 95 0x5f 01011111 251 223 0xdf 11011111 252 63 0x3f 00111111 253 191 0xbf 10111111 254 127 0x7f 01111111 255 255 0xff 11111111
So it seems to me that we have two classes of people requesting address allocations from their local coordinators:
1. those who are planning to operate a regional router (radio- or tunnel-based gateway)
2. those who are planning to use an existing router.
How should we handle these?
It's apparent that some scheme like Geoff's for allocating a subnet block to the first group is wise. It's probably not necessary to actually register the network (0'th) address nor the broadcast (all-ones) in the DNS but they're still part of the allocation. Still, the entire block (a /24 in Geoff's scheme) should be reserved by the coordinator for that router operator.
Do we (for a /24) enter 254 addresses into the DNS every time we register a router block? I don't think that's necessary, although we've done it for a select few blocks.
At our current level of usage, perhaps it's enough to register only the first 4 or 8 or 16 addresses in the block so that experiments can begin, and register more as activity grows.
In effect, this makes each router/gateway operator a delegated coordinator for his subnet block, as all further allocation from his block has to be coordinated with him.
Is this getting too complicated?
Ideas? - Brian
On 2/25/12 10:13 AM, Brian Kantor wrote:
At our current level of usage, perhaps it's enough to register only the first 4 or 8 or 16 addresses in the block so that experiments can begin, and register more as activity grows.
I think that makes sense. The flag for this might be to register the 0th address, which would indicate that the gateway operator intends subnetting.
In effect, this makes each router/gateway operator a delegated coordinator for his subnet block, as all further allocation from his block has to be coordinated with him.
Is this getting too complicated?
I don't think so. Every gateway operator has different ideas about how to run the gateway. This will also reduce the newbie load on the coordinators as the gateway op would be able to counsel individual users on choices of domain name etc. which would then be passed along to the coordinator. It can also be a simpler exchange because the gateway op already knows the range of IPs from which to assign new hosts.
-- David Josephson
On Thu, 23 Feb 2012 17:56:42 -0800, Geoff Joy geoff@windowmeister.com wrote:
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
Correction:
Subnet 16 rolls over into subnet 17. 2 00101100.00010010.00010000.11111111 44.18.16.0/24 34 00101100.00010010.00010001.00000000 44.18.17.0/24
Hello,
It is one thing I don't really get about this rollover...
A subnet is supposed to be a broadcast domain, so every subnet, don't matter how small needs a network and a broadcast address to work properly. In the classic routing schemes that means that by subnetting e.g. a /24 subnet into 4 /22 subnets you loose theoretically 2 subnets, and can use only x.x.x.64/22 and x.x.x./128/22. And this means also that only subnetting in steps of 2 is possible (and also /31 is not a valid subnetting scheme). Classless approaches eliminate this and allow the use of all subnets created by subnetting (and I think all modern routers and OSes support this). But you still have to reserve (IP & Mask) for the network address and (IP | (~mask)) for the broadcast address (e.g. 44.x.x.0 and 44.x.x.255 on a /24 subnet). This means that the roll over on the subnet boundary would have to be e.g. 44.x.x.254 -> 44.x.x+1.1 or the routers on the subnet gateway may go havoc.
Correct me if I'm wrong...
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Geoff Joy Sent: Saturday, February 25, 2012 08:29 To: AMPRNet working group Subject: Re: [44net] On the Issue of Subnets
On Thu, 23 Feb 2012 17:56:42 -0800, Geoff Joy geoff@windowmeister.com wrote:
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
Correction:
Subnet 16 rolls over into subnet 17. 2 00101100.00010010.00010000.11111111 44.18.16.0/24 34 00101100.00010010.00010001.00000000 44.18.17.0/24
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Marius,
Am 25. Feb 2012, um 11:10:56 schrieb Marius Petrescu:
Hello,
It is one thing I don't really get about this rollover...
A subnet is supposed to be a broadcast domain, so every subnet, don't matter how small needs a network and a broadcast address to work properly.
That depends on if your network is a broadcast network (like Ethernet). Thats when you need the broadcast address.
Please note that the broadcast address is generally used only locally; directed-broadcast ("ping 192.168.100.255") whith said network being remote has been mostly disabled on the internet, because it was used as an attack tool. /31 is a valid netmask for Point-to-Point links where no broadcast is necessary (see RFC 3021)
Classless approaches eliminate this and allow the use of all subnets created by subnetting (and I think all modern routers and OSes support this).
You can assume classless by default. Its been used for ages that way. Any end-node supporting explicit netmask specification supports classless, making this only an issue if you are concerned about dynamic routing protocols, and there, only very archaic ones (RIP-1) dont deal with classless networks.
This means that the roll over on the subnet boundary would have to be e.g. 44.x.x.254 -> 44.x.x+1.1 or the routers on the subnet gateway may go havoc.
That depends: If you can change the netmask of the subnet in question to a /23, then the routers would be fine. If you dont do that, then you really run two separate IP networks (/24's in this case) on the same physical wire, so yes, you will have to spend the all-zeroes host, the all-ones-host and an additional IP for the gateway in this segment.
Best regards,
Mario
Hello Mario,
In fact I wanted just to point out some possible points to think about them. If they are non-issues, that's fine :-)
It is clear that broadcasts are used locally.
That depends on if your network is a broadcast network (like Ethernet). Thats when you need the broadcast address.
But if we don't take in account the fact that an subnet is further subneted, than there's a chance that one tries to send a packet to a network or broadcast address. I think the allocation scheme should be aware of that.
That depends: If you can change the netmask of the subnet in question to a
/23, then the routers would be fine.
In that case the discussion doesn't apply since it is just a regular /23 subnet. But you can not just define such a joined subnet without special care , because in that case the broadcast IP of the first and the network IP of the second subnet will become routable IP addresses.
Just my 2 cents...
73! Marius, YO2LOJ
A small correction to my previous post... (Tnx Thomas, DL9SAU for pointing it out).
The subnets are /26 not /22.
In the classic routing schemes that means that by subnetting e.g. a /24 subnet into 4 /22 subnets you loose theoretically 2 subnets, and can use only x.x.x.64/22 and x.x.x./128/22.
Marius
On Sat, 25 Feb 2012 11:10:56 +0200, "Marius Petrescu" marius@yo2loj.ro wrote:
Hello,
It is one thing I don't really get about this rollover...
A subnet is supposed to be a broadcast domain, so every subnet, don't matter how small needs a network and a broadcast address to work properly. In the classic routing schemes that means that by subnetting e.g. a /24 subnet into 4 /22 subnets you loose theoretically 2 subnets, and can use only x.x.x.64/22 and x.x.x./128/22. And this means also that only subnetting in steps of 2 is possible (and also /31 is not a valid subnetting scheme). Classless approaches eliminate this and allow the use of all subnets created by subnetting (and I think all modern routers and OSes support this). But you still have to reserve (IP & Mask) for the network address and (IP | (~mask)) for the broadcast address (e.g. 44.x.x.0 and 44.x.x.255 on a /24 subnet). This means that the roll over on the subnet boundary would have to be e.g. 44.x.x.254 -> 44.x.x+1.1 or the routers on the subnet gateway may go havoc.
Correct me if I'm wrong...
Marius, YO2LOJ
You are correct. The broadcast addresses are 0 and 255 in each /24 and x.x.s+1.255 in each /23 where s is subnet 2,4,6 etc. The point of the scheme is to allocate subnets such that the LSB of the subnets are allocated later, if at all, only when you run out of the upper bits.
Yes, the rollover actually occurs when you have assigned 44.x.x.254.
See my reply to Brian listing the /24 scheme.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Geoff Joy Sent: Saturday, February 25, 2012 08:29 To: AMPRNet working group Subject: Re: [44net] On the Issue of Subnets
On Thu, 23 Feb 2012 17:56:42 -0800, Geoff Joy geoff@windowmeister.com wrote:
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
Correction:
Subnet 16 rolls over into subnet 17. 2 00101100.00010010.00010000.11111111 44.18.16.0/24 34 00101100.00010010.00010001.00000000 44.18.17.0/24
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I think we have several factors at play here. They are related, but need to be addressed separately.
*History*
Network 44 was conceived back in the days of network classes, e.g. A, B, C, ... with a fairly strict notion of network vs host addressing space. We thought of Network 44 as a Class "A" network, which contained 256 Class "B" networks, which could each could support 256 Class "C" networks, and so forth.
Also in that time we were using DOS and some early Linux systems to provide all of the network resources for routing, services, etc. -- homegrown programs were created to manage the peculiarities of the time and to provide a "bridge" between traditional AX.25 packet and the Internet enabled abilities that Network 44 allowed. This meant mostly messaging/email, NNTP, and bulletin boards that were now IP connected. The network was also sparse so route management was included as well as tunneling via IPIP. Transports were generally very slow, so minimizing "hops" was of high priority.
16 million addresses are too many for one person to manage and it was decided that we needed regional coordinators to manage the "Class B" networks (actually 1/2 Class B) and Brian undertook allocating a series of these "Class B" networks and finding coordinators who understood local needs and would manage the assignment of individual addresses to individual users. The email robot was created to create, read, update, and delete those addresses and the coordinators manage that process. Many coordinators also tried to bring some network management and order to the address space they manage, often creating LANs, etc.
There was a vanity associated with having your very own route-able IP address.
*Move forward nearly a quarter century and things have changed*.
The larger Internet has moved on to Classless Inter-Domain Routing (CIDR)http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing so the whole idea of "subnets" takes on a different meaning and is much more flexible and adaptable. Wouldn't it make more sense to have regional coordinators using these newer tools to take their regional networks and organize them as makes sense for their area? For some things, like a single radio link maybe a PointToPoint mapping makes sense with a CIDR of /31 or /32, for a full duplex repeater maybe a LAN with a CIDR of /28 with some addresses DHCP and others fixed? Or an EOC might have a LAN with a CIDR of /29? Having a coordinator/network manager doing this sort of planning is adding a much higher value.
Off the shelf hardware for routing and infrastructure between subnets has become pervasive and cheap, including some high power routers that can be purchased and run for what may be less money than is used to keep that old recycled PC powered for a year. For about US$40 one can purchase a physically small, 5 port 10/100 Ethernet router, and for about US$80 can purchase a 10/100/1000 Ethernet router with a 1W MIMO 2.4 Wifi capability - each with multiple tunnel capability, sophisticated firewalls, and address management protocols. Microwave Point-to-Point links going 10s of KM can be had for less than $200 (both ends with antennas). Does it really make sense to not use this commercial, off the shelf, modern, and inexpensive equipment for infrastructure?
*DNS and Routing*
The only "stations" in Network 44 that benefit from fixed IP addresses are those which are used to provide services (e.g. Websites, Mailserver, NNTP host, Chat Server, VOIP conferencing, etc.) and control/managment/infrastructure. The average user just needs an IP address, and possibly a DNS PTR record for management / identification of users. Mobile stations should definitely be using DHCP as they move from access point to access point, especially when they are mostly clients to services. Modern systems can easily use DNS delegation combined with DHCP and Dynamic DNS to keep up to date DNS A and PTR records.
*The Last Kilometer*
There are only a handful of transports/topologies we have to concern ourselves with in Network 44:
*Fixed assets that are tied directly to Internet / Ethernet* -- these can be supported by a "tunneled" CIDR subnet, using one of the inexpensive routers mentioned above. (I use a pair of them to bring my personal Class C network from a datacenter to my home through an L2TP tunnel. I have Fiber Optic to the house and get virtually the same symmetrical bandwidth over the tunnel as I do through my ISP. One end, my house, has a Dynamic IP4 address and the tunnel keeps my fixed addresses on the Class C up.) These could peer to one (or more) regional routers.
*IP over AX.25* -- this is still a beast, as IP must be encapsulated in an AX.25 frame. Often these run on simplex frequencies using UNPROTO packets, which works to create a small LAN if all stations can hear each other. One station (or more) could receive a properly sized CIDR subnet and both fixed and DHCP addresses could be allocated. This "gateway" to the LAN might run current IP over AX.25 software and "tunnel" to one (or more) regional routers. (Right now mostly 1200/9600 bps in US, some higher in Europe, some projects to give more speed options underway.)
*Part 95 (or 15) WiFi* -- HSMM, Emcomm deployment, etc. Fits nicely with drop in an inexpensive off the shelf router with Mesh or upstream / downstream microwave links. Inexpensive Point-To-Point and Multipoint/Mesh off the shelf devices give higher bandwidth over varying distances.
*IP over D-STAR* -- D-STAR has a "Digital Data" mode that encapsulates Ethernet Frames in D-STAR Frames. Off the shelf radios for 23cm provide a 128K bit rate. Current implementation of gateways, use D-STAR addresses (callsigns) for "Point-to-Point" radio links and look like an Ethernet connection at the endpoints. There are some projects underway that can make this more flexible (e.g. repeaters for on air LANs and bridges between access points for larger "VPNs"), but in general this is just another way to distribute "Network 44 LANs" over radio where an off the shelf router could be plugged in to tie local LANs back into Network 44. (There is also a very slow, e.g. less than 1200 bps, data stream in the D-STAR voice protocol that has carried TCP/IP as well - see D-RATS.)
*Closing Thoughts*
All of this means we can and should be working toward a unified amateur radio Internet Protocol network, it can live inside Network 44 with stations initiating connections out to the rest of the Internet and with heavy filtering of traffic coming back into the network (like we have now, except it could limit inbound traffic only to specific services that are designated). We can also solve some problems for services that like having known IP addresses and ports, that NAT just doesn't satisfy, like some of the VOIP protocols.
I think if we take this approach and standardize infrastructure on inexpensive "off the shelf" router devices (I like the MikroTik routerboards -- bang for the buck, and we might even be able to build an AX.25 module for them), I can see how we can offer standard configurations and a tool for coordinators to add specifics for LANs, that LAN operators could "load and go!"
One last thought, we might want to re-brand. (ampr.net is cool, but it has an image of slow AX.25 packet) -- ham-44.net or similar might work?
------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
-
Brian Kantor -
David Josephson -
Geoff Joy -
K7VE - John -
Mario Lorenz -
Marius Petrescu