22 Feb
2012
22 Feb
'12
4:33 p.m.
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
22 Feb
22 Feb
4:59 p.m.
On 2/22/2012 2: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
It's my error, soon to be fixed.
Also, just got an email from the coordinator saying the 44.9.0 addresses
were in error, so the whole entry will go away and come back different.
73 de David WA6NMF
73 de Marius, YO2LOJ
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
5:19 p.m.
On 2/22/2012 3:08 PM, Brian Kantor wrote:
On Thu, Feb 23, 2012 at 12:33:32AM +0200, Marius
Petrescu wrote:
Dan K6DLC says his
assignment of these addresses to me was in error, new
addresses are in 44.4.9, new gateway entry in the works.
I am puzzled that we want to assign 44-net addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
73 de David WA6NMF
Should be either 44.9.0.1/255.255.255.255 or
44.9.0.0/255.255.255.252
44.9 is an invalid subnet. 
8:47 p.m.
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson WA6NMF
<wa6nmf(a)josephson.com> wrote:
I am puzzled that we want to assign 44-net addresses
one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
I think the reason we started it that way was the sparse population of
addresses and the fact we coordinators didn't initially know any
better coupled with the geographical/topological distribution of IP
nodes where we couldn't really count on a node being in any specific
location within the net. Nodes had to determine their neighbors by
discovery and they were routed manually.
I didn't start subnetting until users wanted blocks of IP addresses
for specific purposes, like UHF vs VHF gateways, digipeaters, or
ARES/RACES. I wrote a paper on it but I don't know how widely it was
distributed or how well it was received.
--
Geoff Joy - ke6qh -
AmprNet IP Address Coordinator for San Bernardino & Riverside Counties.
geoff(a)windomeister.com
8:54 p.m.
Geoff,
Would you mind sending a copy of your paper to the group?
K6DLC
On 2/22/2012 6:47 PM, Geoff Joy wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson
WA6NMF
<wa6nmf(a)josephson.com> wrote:
I am puzzled that we want to assign 44-net
addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
I
think the reason we started it that way was the sparse population of
addresses and the fact we coordinators didn't initially know any
better coupled with the geographical/topological distribution of IP
nodes where we couldn't really count on a node being in any specific
location within the net. Nodes had to determine their neighbors by
discovery and they were routed manually.
I didn't start subnetting until users wanted blocks of IP addresses
for specific purposes, like UHF vs VHF gateways, digipeaters, or
ARES/RACES. I wrote a paper on it but I don't know how widely it was
distributed or how well it was received. 
9:04 p.m.
Hi Geoff,
I am in the process of revamping and reassigning ampr addresses in the Greater
Los Angeles area (Orange, Los Angeles, Ventura and Santa Barbara
counties) and would love to look over your paper.
Thanks
Don WB5EKU
On Wed, Feb 22, 2012 at 6:54 PM, Daniel Curry <daniel(a)danielcurry.net> wrote:
Geoff,
Would you mind sending a copy of your paper to the group?
K6DLC
On 2/22/2012 6:47 PM, Geoff Joy wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David
Josephson WA6NMF
<wa6nmf(a)josephson.com> wrote:
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net I am puzzled that we want to assign 44-net
addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
I
think the reason we started it that way was the sparse population of
addresses and the fact we coordinators didn't initially know any
better coupled with the geographical/topological distribution of IP
nodes where we couldn't really count on a node being in any specific
location within the net. Nodes had to determine their neighbors by
discovery and they were routed manually.
I didn't start subnetting until users wanted blocks of IP addresses
for specific purposes, like UHF vs VHF gateways, digipeaters, or
ARES/RACES. I wrote a paper on it but I don't know how widely it was
distributed or how well it was received.
9:19 p.m.
I would be interested too. The project at the moment is to set up
essentially an on-demand WISP for disaster response on 3.5 GHz to serve
the Monterey Bay area. We will be colocating with one of the significant
ISPs here that has a high level site (I do microwave consulting for
them, they give me rack space and bandwidth.) We will eventually want a
fairly large DHCP pool for use in emergencies. The radios are readily
available. I specifically don't want to use NAT'ted private address
space because it should be clear that the network is only for traffic
that can be handled under the amateur radio rules. There will probably
be a trickle of everyday traffic too, remote receivers, linking, etc.
Perhaps we can designate some of the unused /24s for subnetted nodes and
leave the existing ones for individual IPs.
WA6NMF
On 2/22/12 6:54 PM, Daniel Curry wrote:
Geoff,
Would you mind sending a copy of your paper to the group?
K6DLC
On 2/22/2012 6:47 PM, Geoff Joy wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David
Josephson WA6NMF
<wa6nmf(a)josephson.com> wrote:
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net I am puzzled that we want to assign 44-net
addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
I
think the reason we started it that way was the sparse population of
addresses and the fact we coordinators didn't initially know any
better coupled with the geographical/topological distribution of IP
nodes where we couldn't really count on a node being in any specific
location within the net. Nodes had to determine their neighbors by
discovery and they were routed manually.
I didn't start subnetting until users wanted blocks of IP addresses
for specific purposes, like UHF vs VHF gateways, digipeaters, or
ARES/RACES. I wrote a paper on it but I don't know how widely it was
distributed or how well it was received. 
9:54 p.m.
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson WA6NMF <wa6nmf(a)josephson.com>
wrote:
I am puzzled that we want to assign 44-net addresses
one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
Subnetting is reasonable to do but we still have to assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
The division of the AMPRNet space into the existing blocks of addresses
was primarily for administrative convenience, not as a mandated subnetting
scheme.
Subnets should probably track routers/gateways; that is, each
router/gateway should have a small subnet associated with it. That would
help to keep the routing table at a reasonable size. Since routers often
serve a specific geographical area, having regional subnets could be a fairly
good way to assign addresses.
The hard question is what size region and what size subnet?
The implication is that there will be a router for each region, which is
what we've been doing in many places anyway. Perhaps major cities is a
reasonable way to divide an area into subnets. But there are also flat
networks which need only one router even though they span multiple cities.
Ideas?
- Brian
11:12 p.m.
On Wed, Feb 22, 2012 at 19:54, Brian Kantor <Brian(a)ucsd.edu> wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson
WA6NMF <
wa6nmf(a)josephson.com> wrote:
>I am puzzled that we want to assign 44-net addresses one by one as shown
>in amprhosts rather than as subnets. Perhaps there is a historical
>reason for that. The routing table could get to be very large (we can
hope!)
Subnetting is reasonable to do but we still have to assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
The division of the AMPRNet space into the existing blocks of addresses
was primarily for administrative convenience, not as a mandated subnetting
scheme.
Subnets should probably track routers/gateways; that is, each
router/gateway should have a small subnet associated with it. That would
help to keep the routing table at a reasonable size. Since routers often
serve a specific geographical area, having regional subnets could be a
fairly
good way to assign addresses.
The hard question is what size region and what size subnet?
The implication is that there will be a router for each region, which is
what we've been doing in many places anyway. Perhaps major cities is a
reasonable way to divide an area into subnets. But there are also flat
networks which need only one router even though they span multiple cities.
Ideas?
- Brian
Dynamic DNS to update amprgw's filter.
We only need the filter for ingress to Net44, we could use "Established"
and "Related" IPTABLES for egress.
DHCP for mobile users (those moving between access points).
We already have "region" subnets, e.g. 44.x.0.0/17 blocks already allocated
to coordinators. That means the inter region routing tables can be
relatively small. Within the region subnetting and even sub-subnet can
performed based on local need.
I wrote this in late January and you see more comments in the thread
starting at http://groups.yahoo.com/group/STARnetDigital/message/209
One of the uses I foresee for STARnet Digital is for it to support "VPNs"
for D-STAR Digital Data. Currently, the D-STAR frame addresses one and
only one destination. The UR is either set to the gateway for NATing out
to the Internet, or it is set to the call of a remote system.
If the UR were to be set to STARnet Digital group, then each frame could be
relayed back out to each terminal in the VPN/Group. This still needs to be
tested and probably refined.
I think the Net-44 address space could be the unifying point for IP based
amateur communications. The NxN
text tables being distributed now to IPIP tunnel pockets of activity
doesn't scale well and uses a format designed around a specific
application. I have been thinking, instead we should build a network
around regional routers that each support one 44.x.x.x/16 address
space (44.0-255.x.x)
-- these could exist in a VPN (maybe LT2P) creating tunnels either to each
other or through 1 or more continental/country routers.
In turn, these 256 POP routers, would support up to 256+ local
networks (44.x.x.x/24),
which in turn could distribute out to progressively smaller and smaller
CIDR address spaces.
When AMPRNET was created, the available hardware was either severely
limited or financially unreachable for a hobby pursuit. Now a US$40 router
(http://routerboard.com/RB750 IPV4, IPV6, VPN, Tunnels, MPLS) can be
pressed into service to provide these services (
http://wiki.mikrotik.com/wiki/Manual:License#License_Levels) for any local
jump off point to RF (even to a mesh or PTP high speed microwave link). The
core routers can be had in the US$350 range (http://routerboard.com/RB1200).
There are a number of hams that own or have access to high bandwidth
enabled data centers to house core and regional routers.
Additionally, with a little creativity we could build a special DHCP that
would examine the D-STAR, AX.25, or ??? frames to assign a Dynamic DNS
address to each station (assuming amateur-relay.net as the domain, could be
ampr.org):
- In AX.25, if the source address was WF7R and the SSID was 2 then
Dynamic DNS records would be created:
- wf7r-2 IN A 44.24.73.2 ; Using wf7r-2.amateur-relay.net domain
name set IP to 44.24.73.2
- 2.73.24.44.in-addr.arpa. PTR wf7r-2.amateur-relay.net. ; Shows
wf7r-2.amateur-relay.net on hostname lookup of IP 44.24.73.2
- On D-STAR, if the mycall address was K7VE and the 8th character
(terminal ID) was C, then Dynamic DNS records would be created:
- k7ve-c IN A 44.24.88.230
- 230.88.24.44.in-addr.arpa PTR k7ve-c.amateur-relay.net.
Fixed stations and servers likely would have static IPs, but mobile
stations, say D-STAR DD units moving from repeater/access point to
repeater/access point could release and renew LAN IP addresses using DHCP.
A STARnet Digital server could be modified to include a DHCP lease block
for stations in the group/VPN, so mobile D-STAR stations would retain the
same DNS entries moving from one repeater/access point to another.
As the owner of the STARnetDigital Yahoo! forum, I invite anyone interested
in this topic to reply to the thread there.
------------------------------
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>
23 Feb
23 Feb
12:23 a.m.
Greetings,
Here in Michigan we once had (1990's) a significant number of mobile
Hams (truckers and salesman, etc.) that used the RSPF "Radio Shortest Path
First" protocol that is included in the JNOS software.
#undef RSPF 1 /* Include Radio Shortest Path First Protocol */
It worked much like what you describe below, except that each mobile
was assigned a fixed IP address (from a very specific subnet 44.102.0/24 -
the ZERO or MOBILE subnet for Michigan). Each JNOS node in the network
'knew' how to route this subnet for any mobile users as they passed from
node to node to node as they drove along. The nodes would 'hand off' a
mobile units connection as s/he drove from cell to cell.
Don't ask me the specifics, as I never used this myself nor did I have
anything to do with the necessary JNOS configurations to support it. But
it worked REALLY well. I know one truck driver with a laptop stayed
connected as he drove from Port Huron to Toledo without ever losing his
connection (cringes at the thought of texting while driving an 18
wheeler - at night!).
Might be worth investigating rather than re-inventing the wheel...
--- Jay Nugent WB8TKL
o Chair, ARRL Michigan Section "Digital Radio Group" (DRG)
[www.MI-DRG.org]
On Wed, 22 Feb 2012, K7VE - John wrote:
On Wed, Feb 22, 2012 at 19:54, Brian Kantor
<Brian(a)ucsd.edu> wrote:
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 22 Feb 2012 15:19:31 -0800, David
Josephson WA6NMF <
wa6nmf(a)josephson.com> wrote:
> I am puzzled that we want to assign 44-net addresses one by one as shown
> in amprhosts rather than as subnets. Perhaps there is a historical
> reason for that. The routing table could get to be very large (we can
hope!)
Subnetting is reasonable to do but we still have to assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
The division of the AMPRNet space into the existing blocks of addresses
was primarily for administrative convenience, not as a mandated subnetting
scheme.
Subnets should probably track routers/gateways; that is, each
router/gateway should have a small subnet associated with it. That would
help to keep the routing table at a reasonable size. Since routers often
serve a specific geographical area, having regional subnets could be a
fairly
good way to assign addresses.
The hard question is what size region and what size subnet?
The implication is that there will be a router for each region, which is
what we've been doing in many places anyway. Perhaps major cities is a
reasonable way to divide an area into subnets. But there are also flat
networks which need only one router even though they span multiple cities.
Ideas?
- Brian
Dynamic DNS to update amprgw's filter.
We only need the filter for ingress to Net44, we could use "Established"
and "Related" IPTABLES for egress.
DHCP for mobile users (those moving between access points).
We already have "region" subnets, e.g. 44.x.0.0/17 blocks already allocated
to coordinators. That means the inter region routing tables can be
relatively small. Within the region subnetting and even sub-subnet can
performed based on local need.
I wrote this in late January and you see more comments in the thread
starting at http://groups.yahoo.com/group/STARnetDigital/message/209
One of the uses I foresee for STARnet Digital is for it to support "VPNs"
for D-STAR Digital Data. Currently, the D-STAR frame addresses one and
only one destination. The UR is either set to the gateway for NATing out
to the Internet, or it is set to the call of a remote system.
If the UR were to be set to STARnet Digital group, then each frame could be
relayed back out to each terminal in the VPN/Group. This still needs to be
tested and probably refined.
I think the Net-44 address space could be the unifying point for IP based
amateur communications. The NxN
text tables being distributed now to IPIP tunnel pockets of activity
doesn't scale well and uses a format designed around a specific
application. I have been thinking, instead we should build a network
around regional routers that each support one 44.x.x.x/16 address
space (44.0-255.x.x)
-- these could exist in a VPN (maybe LT2P) creating tunnels either to each
other or through 1 or more continental/country routers.
In turn, these 256 POP routers, would support up to 256+ local
networks (44.x.x.x/24),
which in turn could distribute out to progressively smaller and smaller
CIDR address spaces.
When AMPRNET was created, the available hardware was either severely
limited or financially unreachable for a hobby pursuit. Now a US$40 router
(http://routerboard.com/RB750 IPV4, IPV6, VPN, Tunnels, MPLS) can be
pressed into service to provide these services (
http://wiki.mikrotik.com/wiki/Manual:License#License_Levels) for any local
jump off point to RF (even to a mesh or PTP high speed microwave link). The
core routers can be had in the US$350 range (http://routerboard.com/RB1200).
There are a number of hams that own or have access to high bandwidth
enabled data centers to house core and regional routers.
Additionally, with a little creativity we could build a special DHCP that
would examine the D-STAR, AX.25, or ??? frames to assign a Dynamic DNS
address to each station (assuming amateur-relay.net as the domain, could be
ampr.org):
- In AX.25, if the source address was WF7R and the SSID was 2 then
Dynamic DNS records would be created:
- wf7r-2 IN A 44.24.73.2 ; Using wf7r-2.amateur-relay.net domain
name set IP to 44.24.73.2
- 2.73.24.44.in-addr.arpa. PTR wf7r-2.amateur-relay.net. ; Shows
wf7r-2.amateur-relay.net on hostname lookup of IP 44.24.73.2
- On D-STAR, if the mycall address was K7VE and the 8th character
(terminal ID) was C, then Dynamic DNS records would be created:
- k7ve-c IN A 44.24.88.230
- 230.88.24.44.in-addr.arpa PTR k7ve-c.amateur-relay.net.
Fixed stations and servers likely would have static IPs, but mobile
stations, say D-STAR DD units moving from repeater/access point to
repeater/access point could release and renew LAN IP addresses using DHCP.
A STARnet Digital server could be modified to include a DHCP lease block
for stations in the group/VPN, so mobile D-STAR stations would retain the
same DNS entries moving from one repeater/access point to another.
As the owner of the STARnetDigital Yahoo! forum, I invite anyone interested
in this topic to reply to the thread there.
------------------------------
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>
1:23 a.m.
It is my belief that fixed IP addresses are only needed by services (e.g. a
web server, irc server, etc.), pretty much all mobile and most base
stations do not need fixed addresses.
Being able to address k7ve.ampr.org whether that mobile station is on LAN 1
or LAN 2 is much better than needing to know 44.24.1.10 and having all of
the individual routers keeping separate entries for routing to some sort of
proxy.
If the demarcation is that anything in 44.0.0.0/8 can address anything else
in the 44.0.0.0/8 address space, then sub-netting is a great solution and
DNS entries become optional. However, fixed "services" being accessed from
outside of 44.0.0.0/8 would still pass through the router (or routers) and
they can do a lookup to make sure there is a DNS entry, whether fixed or
dynamic.
On Wed, Feb 22, 2012 at 22:23, Jay Nugent <jjn(a)nuge.com> wrote:
Greetings,
Here in Michigan we once had (1990's) a significant number of mobile
Hams (truckers and salesman, etc.) that used the RSPF "Radio Shortest Path
First" protocol that is included in the JNOS software.
#undef RSPF 1 /* Include Radio Shortest Path First Protocol */
It worked much like what you describe below, except that each mobile was
assigned a fixed IP address (from a very specific subnet 44.102.0/24 - the
ZERO or MOBILE subnet for Michigan). Each JNOS node in the network 'knew'
how to route this subnet for any mobile users as they passed from node to
node to node as they drove along. The nodes would 'hand off' a mobile
units connection as s/he drove from cell to cell.
Don't ask me the specifics, as I never used this myself nor did I have
anything to do with the necessary JNOS configurations to support it. But
it worked REALLY well. I know one truck driver with a laptop stayed
connected as he drove from Port Huron to Toledo without ever losing his
connection (cringes at the thought of texting while driving an 18 wheeler -
at night!).
Might be worth investigating rather than re-inventing the wheel...
--- Jay Nugent WB8TKL
o Chair, ARRL Michigan Section "Digital Radio Group" (DRG)
[www.MI-DRG.org]
On Wed, 22 Feb 2012, K7VE - John wrote:
On Wed, Feb 22, 2012 at 19:54, Brian Kantor <Brian(a)ucsd.edu> wrote:
<http://www.facebook.com/john.**d.hays<http://www.facebook.com/john.d.hays>
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, 22 Feb 2012 15:19:31 -0800, David
Josephson WA6NMF <
wa6nmf(a)josephson.com> wrote:
I am puzzled that we want to assign 44-net addresses one by one as shown
in amprhosts rather than as subnets. Perhaps
there is a historical
reason for that. The routing table could get to be very large (we can
hope!)
Subnetting is reasonable to do but we still have to assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
The division of the AMPRNet space into the existing blocks of addresses
was primarily for administrative convenience, not as a mandated
subnetting
scheme.
Subnets should probably track routers/gateways; that is, each
router/gateway should have a small subnet associated with it. That would
help to keep the routing table at a reasonable size. Since routers often
serve a specific geographical area, having regional subnets could be a
fairly
good way to assign addresses.
The hard question is what size region and what size subnet?
The implication is that there will be a router for each region, which is
what we've been doing in many places anyway. Perhaps major cities is a
reasonable way to divide an area into subnets. But there are also flat
networks which need only one router even though they span multiple
cities.
Ideas?
- Brian
Dynamic DNS to update amprgw's filter.
We only need the filter for ingress to Net44, we could use "Established"
and "Related" IPTABLES for egress.
DHCP for mobile users (those moving between access points).
We already have "region" subnets, e.g. 44.x.0.0/17 blocks already
allocated
to coordinators. That means the inter region routing tables can be
relatively small. Within the region subnetting and even sub-subnet can
performed based on local need.
I wrote this in late January and you see more comments in the thread
starting at
http://groups.yahoo.com/group/**STARnetDigital/message/209<http://groups…
One of the uses I foresee for STARnet Digital is for it to support "VPNs"
for D-STAR Digital Data. Currently, the D-STAR frame addresses one and
only one destination. The UR is either set to the gateway for NATing out
to the Internet, or it is set to the call of a remote system.
If the UR were to be set to STARnet Digital group, then each frame could
be
relayed back out to each terminal in the VPN/Group. This still needs to
be
tested and probably refined.
I think the Net-44 address space could be the unifying point for IP based
amateur communications. The NxN
text tables being distributed now to IPIP tunnel pockets of activity
doesn't scale well and uses a format designed around a specific
application. I have been thinking, instead we should build a network
around regional routers that each support one 44.x.x.x/16 address
space (44.0-255.x.x)
-- these could exist in a VPN (maybe LT2P) creating tunnels either to each
other or through 1 or more continental/country routers.
In turn, these 256 POP routers, would support up to 256+ local
networks (44.x.x.x/24),
which in turn could distribute out to progressively smaller and smaller
CIDR address spaces.
When AMPRNET was created, the available hardware was either severely
limited or financially unreachable for a hobby pursuit. Now a US$40
router
(http://routerboard.com/RB750 IPV4, IPV6, VPN, Tunnels, MPLS) can be
pressed into service to provide these services (
http://wiki.mikrotik.com/wiki/**Manual:License#License_Levels<http://wik…)
for any local
jump off point to RF (even to a mesh or PTP high speed microwave link).
The
core routers can be had in the US$350 range (
http://routerboard.com/RB1200**).
There are a number of hams that own or have access to high bandwidth
enabled data centers to house core and regional routers.
Additionally, with a little creativity we could build a special DHCP that
would examine the D-STAR, AX.25, or ??? frames to assign a Dynamic DNS
address to each station (assuming amateur-relay.net as the domain, could
be
ampr.org):
- In AX.25, if the source address was WF7R and the SSID was 2 then
Dynamic DNS records would be created:
- wf7r-2 IN A 44.24.73.2 ; Using wf7r-2.amateur-relay.net domain
name set IP to 44.24.73.2
- 2.73.24.44.in-addr.arpa. PTR wf7r-2.amateur-relay.net. ; Shows
wf7r-2.amateur-relay.net on hostname lookup of IP 44.24.73.2
- On D-STAR, if the mycall address was K7VE and the 8th character
(terminal ID) was C, then Dynamic DNS records would be created:
- k7ve-c IN A 44.24.88.230
- 230.88.24.44.in-addr.arpa PTR k7ve-c.amateur-relay.net.
Fixed stations and servers likely would have static IPs, but mobile
stations, say D-STAR DD units moving from repeater/access point to
repeater/access point could release and renew LAN IP addresses using DHCP.
A STARnet Digital server could be modified to include a DHCP lease block
for stations in the group/VPN, so mobile D-STAR stations would retain the
same DNS entries moving from one repeater/access point to another.
As the owner of the STARnetDigital Yahoo! forum, I invite anyone
interested
in this topic to reply to the thread there.
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog>
<http://twitter.com/#!/john_**hays<http://twitter.com/#!/john_hays>
22 Feb
22 Feb
11:45 p.m.
Greetings,
On Wed, 22 Feb 2012, Brian Kantor wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson
WA6NMF <wa6nmf(a)josephson.com> wrote:
Michigan was assigned 44.102/16 and shortly after that we had a group
of interested parties get together and define a state "plan". It went
something like this...
Michigan has 83 counties, however the Upper Penninsula had already been
claimed by Wisconsin as part of their coordination region. We then
determined how many licensed Hams there were in each county - this gave us
some idea just how much or little AMPRnet activity to expect in each
county. We then assigned anywhere from TWO to EIGHT /24 subnets to each
county based on their Ham populations.
For example: Wayne county (LOTS of Hams!) received 8 subnets
44.102.48/24 through 44.102.55/24
Mason county (very few Hams) recieved 2 subnets
44.102.146/24 and 44.102.147/24
This assured a better "distribution" of the IP address space.
Jeff King WB8WKA was the Michigan IP Address coordinator at that time.
Later I took over (Jay Nugent WB8TKL) the reines when Jeff moved on to
other interests.
The following is a JPG image of the map I wrote up back in 1992. The
numbers listed on each county defines the range of the 3rd octets for that
county's subnets:
http://www.mi-drg.org/AMPR-subnets-by-county.jpg
This plan continues to work to this day! We have had situations where
one Gateway/Hamgate supported routes for multiple counties. And we have
had multiple Gateways/Hamgates within one county with each agreeing to
route one or more subnets - but never do BOTH Hamgates route the SAME
subnet. Users could get an IP address for EACH gateway and choose which
would be their default route.
We have assigned entire subnets and or blocks/ranges of addresses to
groups or individuals for their own experimentation.
We also promote that each county operate on their own frequency to
avoid the "Hidden Transmitter" problems. We also reccommend that subnets
exist on their own frequencies as well.
There are currently 277 route entires in todays ENCAP.TXT route table.
With 49 of those being Michigan /24 (a couple are /23 or /22) subnets used
in our counties. We make up about 17% of the total ENCAP route table.
Perhaps that is a sign as to our level of activity? I can only hope...
Enjoy!
--- Jay Nugent WB8TKL
o Chair, ARRL Michigan Section "Digital Radio Group" (DRG)
[ www.MI-DRG.org ]
o Michigan AMPRnet IP Address Coordinator
[ http://www.mi-drg.org/ip-addr-form.html ]
() 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|
+------------------------------------------------------------------------+
23:01:01 up 171 days, 5:39, 3 users, load average: 0.00, 0.02, 0.00
I am puzzled that we want to assign 44-net
addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
Subnetting is reasonable to do but we still have to assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
The division of the AMPRNet space into the existing blocks of addresses
was primarily for administrative convenience, not as a mandated subnetting
scheme.
Subnets should probably track routers/gateways; that is, each
router/gateway should have a small subnet associated with it. That would
help to keep the routing table at a reasonable size. Since routers often
serve a specific geographical area, having regional subnets could be a fairly
good way to assign addresses.
The hard question is what size region and what size subnet?
The implication is that there will be a router for each region, which is
what we've been doing in many places anyway. Perhaps major cities is a
reasonable way to divide an area into subnets. But there are also flat
networks which need only one router even though they span multiple cities.
Ideas? 
23 Feb
23 Feb
12:12 a.m.
On 2/22/12 7:54 PM, Brian Kantor wrote:
Subnetting is reasonable to do but we still have to
assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
I understand the intent ... but as Jay WB8TKL pointed out there are lots
of assignments that have no DNS (or listing in amprhosts).
The division of the AMPRNet space into the existing
blocks of addresses
was primarily for administrative convenience, not as a mandated subnetting
scheme.
Subnets should probably track routers/gateways; that is, each
router/gateway should have a small subnet associated with it. That would
help to keep the routing table at a reasonable size. Since routers often
serve a specific geographical area, having regional subnets could be a fairly
good way to assign addresses.
The hard question is what size region and what size subnet?
At present (at least per Daniel Curry, new coordinator for my region)
coordinators seem to have been instructed to assign individual
addresses, not subnets, in order to capture per-host domain information.
This causes a problem in that when one goes to register a gateway, the
range of addresses doesn't necessarily fall into a normal power of 2 as
would be expected for a subnet. I don't think there is a lot of
contention for this address space, so you could throw a dart and say
that anyone running a gateway should be assigned a /24 or /26 or such.
But then, there's the challenge of how to get data for DNS and ingress
filtering as you mention.
Perhaps the gateway robot can be modified to expect entries for subnets
and hosts within that subnet, including the desired DNS entry for each
host. Then the operator of the gateway could be responsible for
assigning local addresses, maintaining the DNS entries for each, and
sending those updates via the robot.
73 de WA6NMF
6:45 a.m.
On 23 Feb 2012, at 03:54, Brian Kantor wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson
WA6NMF <wa6nmf(a)josephson.com> wrote:
1.
That is indeed a hard question. And I don't think one size will fit all no matter how
much effort goes into it. My own preference is logical areas with 'room to grow'.
However as usage of IP has died a death here.
2.
I'd be interested in seeing the paper as well
and
3. Going back to startup scripts.
With a lot of reading old posts and figuring things out. I ended up with the following
(Ubuntu 10.04 LTS)
root@mini-itx:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
200 44
/etc/network/interfaces
..
auto
iface tunl1 inet static
address 44.155.6.12
netmask 255.255.255.0
network 44.155.6.0
broadcast 44.155.6.255
pre-up /sbin/ip tunnel add tunl1 mode ipip remote 169.228.66.251 local
10.100.12.254
post-down /sbin/ip tunnel del tunl1
pre-down /sbin/ip route del default via 169.228.66.251 onlink table 44
pre-down /sbin/ip route del 169.228.66.251 dev eth0 table 44
pre-down /sbin/ip rule del to 44.0.0.0/8 table 44
pre-down /sbin/ip rule del from 44.0.0.0/8 table 44
pre-down /sbin/ip rule del to 44.155.6.12/24 table main
up /sbin/ip rule add to 44.155.6.12/24 table main priority 1
up /sbin/ip rule add from 44.0.0.0/8 table 44 priority 44
up /sbin/ip rule add to 44.0.0.0/8 table 44 priority 45
up /sbin/ip route add 169.228.66.251 dev eth0 table 44
up /sbin/ip route add default dev tunl1 via 169.228.66.251 onlink table 44
I'm using the most excellent rip44d
I found (by trial, error, and confusion) that if I had another interface with the
44.155.6.12 IP. rip44d wouldn't work. I'm using 44.155.6.12 as its one of the
only 2 IPs that I have that is already in the DNS.
Cheers
John
EI7IG
I am puzzled that we want to assign 44-net
addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
Subnetting is reasonable to do but we still have to assign addresses in
those subnets one at a time in order to get DNS entries for them and to
enable them in the Internet ingress filter.
The division of the AMPRNet space into the existing blocks of addresses
was primarily for administrative convenience, not as a mandated subnetting
scheme.
The hard question is what size region and what size subnet? 
11:22 a.m.
The first few requests I received for 44 net addresses came
from MSYS BBS operators wanting an IP address. In every
case, it was a very short time before they asked for another
address or two. Eventually, when I got requests regardless
from who or why, I just assigned a block of 4 addresses, then 8.
The addresses naturally fell on boundaries that could be segregated
by a netmask. They became de facto subnets. I made it clear
that was not the purpose but merely convenient for both of us.
The node operators of Netrom nodes were continually installing
TheNET X1J and instituting subnets for IP routing. Basically, the
hardware or software was driving the implementation of the
network. Not the other way around.
As I understand it, the intent was to develop a network with
enough sophistication that mobile stations (IP addresses) could
remain connected because the network would dynamically
discover and track/route without having the operator consciously
change IP address or any other identifier. RSPF is one effort
toward that goal.
__Reid, WB7CJO__
Reid Fletcher
Chief Engineer, KUWR
Wyoming Public Radio - University of Wyoming
On 2/22/2012 7:47 PM, Geoff Joy wrote:
On Wed, 22 Feb 2012 15:19:31 -0800, David Josephson
WA6NMF
<wa6nmf(a)josephson.com> wrote:
I am puzzled that we want to assign 44-net
addresses one by one as shown
in amprhosts rather than as subnets. Perhaps there is a historical
reason for that. The routing table could get to be very large (we can hope!)
I
think the reason we started it that way was the sparse population of
addresses and the fact we coordinators didn't initially know any
better coupled with the geographical/topological distribution of IP
nodes where we couldn't really count on a node being in any specific
location within the net. Nodes had to determine their neighbors by
discovery and they were routed manually.
I didn't start subnetting until users wanted blocks of IP addresses
for specific purposes, like UHF vs VHF gateways, digipeaters, or
ARES/RACES. I wrote a paper on it but I don't know how widely it was
distributed or how well it was received.
4658
days inactive
4659
days old
15 comments
12 participants
participants (12)
-
Brian Kantor -
Daniel Curry -
David Josephson -
David Josephson WA6NMF
-
Donald Jacob -
Geoff Joy -
Jay Nugent -
John Ronan -
K7VE - John -
Marius Petrescu -
Reid Fletcher -
WA6NMF