16 Jan
2016
16 Jan
'16
2:08 p.m.
Subject:
Re: [44net] Verifying the identities of IP coordinators
From:
K7VE - John <k7ve(a)k7ve.org>
Date:
01/15/2016 10:05 PM
To:
AMPRNet working group <44net(a)hamradio.ucsd.edu>
I beg to differ. I agree with the NAT position, but there are definitely
cases for the use of dynamically allocated addresses.
Here is one: D-STAR data protocol encapsulates Ethernet frames inside of
D-STAR frames, in turn those can contain IP frames. If I am in a mobile,
driving down a highway and using a series of access points, then receiving
a new 44.x.x.x address via DHCP from those access points keeps me connected
for services I am using.
I would implement that using a dynamic routing of a fixed address rather than assignment
of a dynamic address (and having to cope with a changing address).
Rob
16 Jan
16 Jan
10:33 p.m.
New subject: dynamic addresses
Coping with a changing address is trivial with dynamic DNS, and prevents
the need to send packets on (possibly) inferior routes, with (possibly)
poor latency to get to the destination - why is this worse than dealing
with IP address changes?
The impact of IP address changes does depend upon the underlying
protocols. However, lots of protocols survive IP address changes with
little or no impact. If you don't want IP address change you can tunnel
to the origin - nothing that is being suggested here precludes that, but
totally barring address changes can preclude using protocols that aren't
impacted - and can have a serious impact on performance.
Do it all - allow dynamic routing for protocols that are IP address
sensitive, and dynamic IPs for protocols that are not IP address
sensitive. We really can 'have it all'.
Don't say 'no' where we can say 'yes'. It doesn't mean that every
individual station has to allow dynamic IP addresses (every individual
station gets to choose!), but don't prevent the ones that can handle
using dynamic addresses from doing it.
This really is Burger King - "you can have it your way".
- Richard, VE7CVS
On 1/16/16 12:08 PM, Rob Janssen wrote:
I would implement that using a dynamic routing of a fixed address
rather than assignment
of a dynamic address (and having to cope with a changing address).
Rob
17 Jan
17 Jan
2:22 p.m.
New subject: dynamic addresses
The problem of dynamic address is that in order to pass the 44 Net Router you need too
have a DNS name
and the AMPR.ORG dns have no system of DHCP update or any kind of "quick"
update
so the whole business is irrelevant until such a system will be implemented
Rone - 4Z4ZQ
http://www.ronen.org
________________________________________
9:19 p.m.
New subject: dynamic addresses
So, until Dynamic DNS (or similar) is implemented, the dynamic address
could have a fixed (but not personally identifiable) DNS name. It could
be related to the station that is offering up the dynamic address. (The
DHCP addresses in my home network work this way.)
This is another reason that more automation is needed, not just for
simplifying registration, but for enabling more advanced technology -
ham radio isn't about 'standing still'.
A maxim at my $WORK is that "Those who dislike change are *really* going
to detest irrelevancy."
To say that change is hard, therefore we shouldn't do it - I have to
say: change is necessary, therefore we *must* do it - or be replaced.
For the mesh network being developed for the NW Digital radios, we're
moving to IPv6 - the 44 net becomes awkward to interface with - unless
it modernises. It would be useful to use 44 net addresses for IPv4 for
interconnect, but that's only going to be practical if the current
system is willing to adapt.
BTW - I wrote the front end code for the world's first TNC - I'm not
adverse to new technology or change. ;-)
- Richard, VE7CVS
On 1/17/16 12:22 PM, R P wrote:
_______________________________________________
The problem of dynamic address is that in order to pass the 44 Net Router you need too
have a DNS name
and the AMPR.ORG dns have no system of DHCP update or any kind of "quick"
update
so the whole business is irrelevant until such a system will be implemented
Rone - 4Z4ZQ
http://www.ronen.org
3232
days inactive
3234
days old
3 comments
3 participants
participants (3)
-
R P -
Richard Chycoski -
Rob Janssen