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.
This might be a good time to implement a rwhoisd server for the whole
44/8 network. This way for the people who want to register a block of any size
we can have an easily accessible and viewable whois entries. Also anyone,
anywhere can find out what is assigned to who regardless of it's block size and
regardless if there are DNS entries or not. Then it would fall back to the
regional coordinator if no entries were made for the query being checked, and
then back to the top parent of Brian for 44/8 of no coordinator assigned. This
is a proven method as ARIN has been using this for years on their whois server.
Works very well.
Assuming that if 44.X.X.0 is assigned something in DNS that it's broken
into a /24 I believe is not a good idea as it might actually be a smaller or
larger subnetmask. /24 can be very wasteful if you're not using most of it. I
would say it would be more common to hand out /27's or /26's.
This would also lend it's self nicely into IPv6, since that is
supported as well if we get space.
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
On Sat, 25 Feb 2012, Brian Kantor wrote:
> Date: Sat, 25 Feb 2012 10:13:48 -0800
> From: Brian Kantor <Brian(a)ucsd.edu>
> Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] On the Issue of Subnets
>
> 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
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
>
I've set the 'reply to list' option ON for this list, so
by default your replies to discussions should from now on
be automatically directed to the list rather than to the
original poster.
You'll probably have to take specific action in your mail
client if you want to reply privately only to the person
posting the message.
I think this is more in keeping with the spirit of the list,
and it had been asked for by a few of the subscribers.
If this causes difficulties, please let me know and I can
turn it back OFF.
- Brian
Sorry:
I crossed my outgoing with Brian and Davids incoming.
You're already on it
Bill
--------------------------
Well, for starters, it looks like the address you posted here is:
44.9.0.1, and you state belongs to WA6NMF.
However, I show no such address on the network.
I do show an address for WA6NMF, but it is 44.4.9.1 not 44.9.0.1.
wa6nmf IN A 44.4.9.1
wa6nmf-1 IN A 44.4.9.2
wa6nmf-2 IN A 44.4.9.3
wa6nmf-3 IN A 44.4.9.4
Now, I also show the 44.9.x.x as a discontinued range.
I also DO NOT show any entries at Fullers for either WA6NMF
or for any address starting with 44.9.x.x or any with 44.4.9.x
So, I'm curious as to where your entry came from ??
At 02:49 PM 02/22/12, you wrote:
>No, I never said it belons to me.
>I just got an error regarding that address while checking my routing infos.
>It belongs to wa6nmf and should be corrected because it is wrong.
>
Wm Lewis (KG6BAJ)
AMPR Net IP Address Coordinator - Northern and Central California Regions
(A 100% Volunteer Group)
(530) 263-1595 (Home/Office)
______________________________________________
----------
This message is for the designated recipient only and MAY CONTAIN
PRIVILEGED OR CONFIDENTIAL INFORMATION.
If you have received it in error, please notify the sender immediately and
delete the original. Any other use of this E-mail is prohibited.
Is it just me or we have a error in the gateway routing table?
entry: 44.9.0.1/255.255.255.252 via 207.111.203.194
This gives a invalid subnet/netmak pair and gets ignored by rip44d.
Should be either 44.9.0.1/255.255.255.255 or 44.9.0.0/255.255.255.252
73 de Marius, YO2LOJ
Well, for starters, it looks like the address you posted here is:
44.9.0.1, and you state belongs to WA6NMF.
However, I show no such address on the network.
I do show an address for WA6NMF, but it is 44.4.9.1 not 44.9.0.1.
wa6nmf IN A 44.4.9.1
wa6nmf-1 IN A 44.4.9.2
wa6nmf-2 IN A 44.4.9.3
wa6nmf-3 IN A 44.4.9.4
Now, I also show the 44.9.x.x as a discontinued range.
I also DO NOT show any entries at Fullers for either WA6NMF
or for any address starting with 44.9.x.x or any with 44.4.9.x
So, I'm curious as to where your entry came from ??
At 02:49 PM 02/22/12, you wrote:
>No, I never said it belons to me.
>I just got an error regarding that address while checking my routing infos.
>It belongs to wa6nmf and should be corrected because it is wrong.
>
Wm Lewis (KG6BAJ)
AMPR Net IP Address Coordinator - Northern and Central California Regions
(A 100% Volunteer Group)
(530) 263-1595 (Home/Office)
______________________________________________
----------
This message is for the designated recipient only and MAY CONTAIN
PRIVILEGED OR CONFIDENTIAL INFORMATION.
If you have received it in error, please notify the sender immediately and
delete the original. Any other use of this E-mail is prohibited.
No, I never said it belons to me.
I just got an error regarding that address while checking my routing infos.
It belongs to wa6nmf and should be corrected because it is wrong.
From: Daniel Curry [mailto:daniel@danielcurry.net]
Sent: Thursday, February 23, 2012 00:41
To: Marius Petrescu
Subject: Re: [44net] Gateway ip/netmask pair
I found that you do not have 44.9.0.1 register to you.
ftp://hamradio.ucsd.edu/pub/amprhosts
On 02/22/2012 02:33 PM, Marius Petrescu wrote:
Is it just me or we have a error in the gateway routing table?
entry: 44.9.0.1/255.255.255.252 via 207.111.203.194
This gives a invalid subnet/netmak pair and gets ignored by rip44d.
Should be either 44.9.0.1/255.255.255.255 or 44.9.0.0/255.255.255.252
73 de Marius, YO2LOJ
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
--
Daniel Curry
PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92
At the moment, I receive a continuous stream of packets like this:
Frame 1: 118 bytes on wire (944 bits), 118 bytes captured (944 bits)
Arrival Time: Feb 22, 2012 18:05:47.069526000 CET
Epoch Time: 1329930347.069526000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 118 bytes (944 bits)
Capture Length: 118 bytes (944 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:ip:data]
Ethernet II, Src: ThomsonT_1e:e4:ca (00:14:7f:1e:e4:ca), Dst: AsustekC_b4:b4:6d (00:1d:60:b4:b4:6d)
Destination: AsustekC_b4:b4:6d (00:1d:60:b4:b4:6d)
Address: AsustekC_b4:b4:6d (00:1d:60:b4:b4:6d)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: ThomsonT_1e:e4:ca (00:14:7f:1e:e4:ca)
Address: ThomsonT_1e:e4:ca (00:14:7f:1e:e4:ca)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 169.228.66.251 (169.228.66.251), Dst: 80.101.113.129 (80.101.113.129)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 104
Identification: 0x1924 (6436)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 49
Protocol: IPIP (4)
Header checksum: 0xc1a8 [correct]
[Good: True]
[Bad: False]
Source: 169.228.66.251 (169.228.66.251)
Destination: 80.101.113.129 (80.101.113.129)
Internet Protocol, Src: 76.114.219.34 (76.114.219.34), Dst: 169.228.66.251 (169.228.66.251)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 21504
Identification: 0x0000 (0)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 512
Time to live: 43
Protocol: IPIP (4)
Header checksum: 0x3b1e [incorrect, should be 0x2746]
[Good: False]
[Bad: True]
[Expert Info (Error/Checksum): Bad checksum]
[Message: Bad checksum]
[Severity level: Error]
[Group: Checksum]
Source: 76.114.219.34 (76.114.219.34)
Destination: 169.228.66.251 (169.228.66.251)
Data (64 bytes)
0000 45 00 00 54 00 00 40 00 3e 01 8e 79 2c 3c 2c 0a E..T..@.>..y,<,.
0010 2c 89 29 61 08 00 3d 1d 27 45 41 f6 70 20 45 4f ,.)a..=.'EA.p EO
0020 af 34 02 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 .4..............
0030 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ............ !"#
Data: 45000054000040003e018e792c3c2c0a2c89296108003d1d...
[Length: 64]
It appears to be an IPIP packet from the gateway, which then contains another IPIP packet
sent by 76.114.219.34 to the gateway, which again has another IPIP packet that my trace
tool no longer shows.
I don't understand why the gateway delivers these packets to me.
As it looks like 76.114.219.34 is indeed a valid gateway in the system, I assume a
misconfiguration rather than malice for now.
But probably it would be better when amprgw just rejected all IPIP traffic that includes
another layer of IPIP within it.
Rob
Does anyone have a step-by-step set of instructions for configuring a
Linux host as a tunnel subnet gateway for AMPRNet?
I'd like to have a proven list of all the commands that have to be
entered to set one up.
I think it would be very helpful and I don't have such a document in
my archives.
Thank you!
- Brian
(PS: this is the first message through the new mailing list setup;
if you encounter any difficulties please let me know.)
Greetings Brian,
On Tue, 21 Feb 2012, Brian Kantor wrote:
> Does anyone have a step-by-step set of instructions for configuring a
> Linux host as a tunnel subnet gateway for AMPRNet?
>
> I'd like to have a proven list of all the commands that have to be
> entered to set one up.
>
> I think it would be very helpful and I don't have such a document in
> my archives.
Here is the snippett from the /NOS/AUTOEXEC.NOS where it sets up the TUN0
interface. Below that, I show the output of IFCONFIG and ROUTE on the Linux
box, for your reference.
In this example, 192.168.0.5 is the address of the Linux ethernet card and
192.168.0.44 is the address of the JNOS application running on Linux. BOTH
address "appear" to exist on your LAN as if they were two independent machines.
# --------------------------
# - TUN0 Configuration -
# --------------------------
# NOTE: Remember to turn on IPv4 Forwarding in the kernel !!!!
# echo 1 > /proc/sys/net/ipv4/ip_forward
#
attach tun tun0 1500 0
#
# Whenever any host on your ethernet sends an ARP asking "Who-Has
# 192.168.0.44", the ethernet in the Linux box will respond that it knows how
# to reach this address. This 'feature' negates the need to assign an Alias
# address to the Linux box's Eth0 interface (eth0:44), nor the need to put
# anything special in the Linux route table :)
#
ifconfig tun0 ipaddress 192.168.0.44
ifconfig tun0 netmask 255.255.255.0
ifconfig tun0 mtu 1500
ifconfig tun0 description "TUN0 to Ethernet"
#
shell ifconfig tun0 192.168.0.5 pointopoint 192.168.0.44 mtu 1500 up
#
# Shouldn't be any need to ARP on a Point-to-Point link
# so this has been commented out.
# Note: The MAC addr would be that of the Linux eth card
##shell arp -s 192.168.0.44 00:11:43:c4:b3:48 pub
#
echo ***** TUN0 Configuration Complete *****
pause 2
#
#
All done!
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:43:c4:b3:48
inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::211:43ff:fec4:b348/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14669 (14.3 KB) TX bytes:7099 (6.9 KB)
Interrupt:16
tun0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:192.168.0.5 P-t-P:192.168.0.44 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:392 (392.0 B) TX bytes:526 (526.0 B)
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.6 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 eth0
On your gateway router remember to port forward (to 192.168.0.44) Telnet,
Finger, and any other 'services' you want to reach on your JNOS application
from the Internet. I do *not* recomend forwarding SMTP unless you have a solid
way to prevent spam from the public Internet getting out onto your RF network.
If your JNOS application is running the ENCAP.TXT route table and uses
the 'encap' interface, DO NOT PORT FORWARD ANYTHING! Instead, define the
192.168.0.44 ip address of the JNOS application as your "DMZ Host" so that
ALL protocols (TCP, IPIP Protocol-4, and others) will be automatically
routed to the JNOS application where JNOS'es 'ip access' and 'tcp access'
firewall rules will decide what gets through for processing/routing.
Hope this helps!
--- Jay Nugent WB8TKL
o Chair, ARRL Michigan Section "Digital Radio Group" (DRG)
[www.MI-DRG.org]
() ascii ribbon campaign in
/\ support of plain text e-mail
+------------------------------------------------------------------------+
| Jay Nugent jjn(a)nuge.com (734)484-5105 (734)649-0850/Cell |
| Nugent Telecommunications [www.nuge.com] |
| Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring |
| Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
+------------------------------------------------------------------------+
02:01:01 up 170 days, 8:39, 3 users, load average: 0.07, 0.14, 0.06
