12 Mar
2013
12 Mar
'13
3:37 p.m.
Bill, WA7NWP,
I'm not sure this is best suggestion for many reasons:
- There was a discussion a few weeks back where it was determined that
all stations do not necessarily run telnet (while having others test
connectivity to my station, some were attempting to telnet to me). For
example, my station is not a TNOS/JNOS based router, and therefore does
not provide Converse (the telnet-based service we're referring to) by
default. Under that guideline, my allocation would be purged.
- We also determined that, while all stations should make their IP
addresses ping-able, that was not necessarily the case (either by intent
or error).
- For various reasons, AMPRNet allocations may not necessarily be online
or available through AMPR
- A Station does not necessarily have to download the encap to have a
working allocation (one could manually add static routes from the portal
list or use RIP44, for example)
- It would be impossible to use the download guideline for those using
the RIP44 routing protocol, as it is multicast; and doesn't know what
stations are receiving it or using it
We have to be mindful that all stations may not be identically
configured, use the same Operating Systems, routing protocols nor system
configurations to accomplish connectivity to AMPRNet.
73,
Lynwood
KB3VWG
On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote:
Automate it for now and the future... If a client
doesn't
ping/poke/telnet/download or whatever within 30days/3months/whatever -
purge the entry. You know - just like DHCP but at a higher level..
:)
Bill, WA7NWP
13 Mar
13 Mar
4:25 a.m.
New subject: Portal registrations
lleachii(a)aol.com wrote:
...
We have to be mindful that all stations may not be identically
configured, use the same Operating Systems, routing protocols nor
system
configurations to accomplish connectivity to AMPRNet.
On 03/12/2013 03:00 PM, 44net-request(a)hamradio.ucsd.edu
wrote:
> Automate it for now and the future... If a client doesn't
> ping/poke/telnet/download or whatever within 30days/3months/whatever
> purge the entry. You know - just like DHCP but at a higher level..
> :)
>
> Bill, WA7NWP
My belief is that systems connected to the Internet should respond to ICMP Echo Requests,
it is/was in the Host Requirements RFC I think. It's also so useful in an experimental
network that I would not want to turn it off.
On the other hand, I strongly believe that allocation of static IP addresses should not
*automatically* depend on whether a system is switched on 24/7, nor on whether the system
responds to a ping. Static addresses need to be managed manually.
If address space is scarce, allocate it dynamically. That's what DHCP is for.
Best wishes and thanks to all who keep AMPRnet alive!
G4WSZ
--
Steve Platt
1:06 p.m.
New subject: Portal registrations
Steve,
I agree with you about echo requests, to a point. But the host requirements
were written back when a username and password were sufficient for security.
(I remember the good-ol' days of the NSFnet in the early 80's). In those
days, a "firewall" was something made from approved flame-retardant
materials.
Today, IT managers routinely spend more time fighting spam and hackers than
doing anything else. I know the time I've spent on iptables and postfix
rules never fails to remind me of how sad it is that I have to spend any
time at all on them. So in the corporate world, it is common for key
servers to NOT respond to pings.
I did a test with my gateway when I first put it up. I had it running for a
month or so without accepting pings from the Internet. As soon as I allowed
pings, a variety of attacks began, all within a day or so. Luckily, none
were successful.
My solution was to allow pings from within AMPRnet, but not from external
"commercial" Internet machines. That makes it helpful for experimentation
and testing within our ham community, but reduces visibility to the outside.
The problem with that approach is that it requires a bit more care and
configuration knowledge in iptables or whatever firewall solution someone
has in place. For many, that's either something that is too much to deal
with or something they try to do but aren't quite able to get the
configuration right.
Bottom line, I think it would be a mistake to rely on ICMP echo
requests/response for proof that a gateway is there or not. Our local
repeater coordinating body requires coordination holders to update their
record once every two years (or maybe it's three years). It's as simple as
logging in and clicking a button indicating that their information is
current. The database sends automated reminder emails when the update is
due. It has worked well for many years and is not onerous for the
administrative/system staff or the repeater owners. Something similar seems
like the way to go.
Michael
N6MEF
-----Original Message-----
From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu
[mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Steve
Platt
Sent: Wednesday, March 13, 2013 2:25 AM
To: AMPRNet working group
Subject: Re: [44net] Portal registrations
My belief is that systems connected to the Internet should respond to ICMP
Echo Requests, it is/was in the Host Requirements RFC I think. It's also so
useful in an experimental network that I would not want to turn it off.
On the other hand, I strongly believe that allocation of static IP addresses
should not *automatically* depend on whether a system is switched on 24/7,
nor on whether the system responds to a ping. Static addresses need to be
managed manually.
If address space is scarce, allocate it dynamically. That's what DHCP is
for.
Best wishes and thanks to all who keep AMPRnet alive!
G4WSZ
--
Steve Platt
1:10 p.m.
New subject: Portal registrations
Bottom line, I think it would be a mistake to rely on
ICMP echo
requests/response for proof that a gateway is there or not. Our local
repeater coordinating body requires coordination holders to update their
record once every two years (or maybe it's three years). It's as simple as
logging in and clicking a button indicating that their information is
current. The database sends automated reminder emails when the update is
due. It has worked well for many years and is not onerous for the
administrative/system staff or the repeater owners. Something similar seems
like the way to go.
This is indeed how the portal currently works.
Chris
1:08 p.m.
New subject: Portal registrations
On Wed, Mar 13, 2013 at 2:25 AM, Steve Platt <steve.platt(a)ntlworld.com>wrote;wrote:
If address space is scarce, allocate it dynamically. That's what DHCP is
for.
Another use case for DHCP is mobile operation. As a station moves from
gateway to gateway DHCP (with Dynamic DNS) makes routing much simpler.
Also remember, not all Net-44 traffic will be travelling via AX.25. For
example D-STAR DD sends encapsulated Ethernet packets over the air
interface so DHCP works quite simply. (At least using ircDDBGateway
implementation.)
------------------------------
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:03 p.m.
New subject: Portal registrations
Steve,
I agree with your suggestion, I was simply making note that all hosts
are not TNOS/JNOS based (therefore Telnet is not the best option), and
that there is no simple way to determine if an allocated IP is not in
use, or happened to simply be offline to the Public Internet or AMPR.
DHCP would not work for one major reason, it is a Layer 2 (Ethernet)
implementation. IP-in-IP is a Layer 3 (IP) connection, therefore, at
least one host would have to established the tunnel with a static IP and
act as a DHCP relay, defeating the purpose of a Master DHCP Server. It
also assumes all devices have a compiled and installed DHCP Client, and
requires each station to have a DHCP Server.
Each station is independently capable of allocating their address space
as is most convenient (either static or dynamic). From Brian's
perspective and that of other stations, we simply need to know the valid
route to the subnet.
The AMPR Terms of Service reads:
"The duration of this license is five (5) years,
renewable upon Your request and consent to these Terms and Agreement
and subject to the discretion of ARDC."
Therefore, under the current rules, there is already an expiration of
allocations after a period of time, so the suggestions that each Station
should be responsible for maintaining their own Portal account seems to
work best
- Lynwood
On 03/12/2013 04:37 PM, lleachii(a)aol.com wrote:
44net-request(a)hamradio.ucsd.edu wrote:
My belief is that systems connected to the Internet should respond to
ICMP Echo Requests, it is/was in the Host Requirements RFC I think.
It's also so useful in an experimental network that I would not want
to turn it off.
On the other hand, I strongly believe that allocation of static IP
addresses should not *automatically* depend on whether a system is
switched on 24/7, nor on whether the system responds to a ping.
Static addresses need to be managed manually.
If address space is scarce, allocate it dynamically. That's what DHCP
is for.
Best wishes and thanks to all who keep AMPRnet alive!
G4WSZ
--
Steve Platt
4273
days inactive
4274
days old
5 comments
5 participants
participants (5)
-
Chris Smith -
K7VE - John -
lleachii＠aol.com -
Michael Fox - N6MEF -
Steve Platt