30 Dec
2020
30 Dec
'20
6:22 p.m.
On 30.12.2020 10:56, Toussaint OTTAVI via 44Net wrote:
VoIP, digital modes, SDR and other applications using computers are
enjoyed by many people, particularly the young ones. The most recent
commercial transceivers are SDR (ie, a computer), have Ethernet ports,
and use IP. On the other hand, we own a dedicated IP range. My opinion
is that every HAM application using IP should use AMPR addressing, or
should be able to use it easily. If we have a good routing policy,
this would allow to isolate what is pure ham radio (for ex, remote rig
control) from what is general purpose Internet. AMPRNet should work as
a corporate network, allowing members to communicate with each other,
and with the ability to limit / control gateways to wild Internet
(required by some regulations in some countries; this would help us
achieve this goal)
Yes, this is exactly the kind of use that brings out the advantage of
having a dedicated IP subnet available: there is a certain degree of
trust between those hosts.
Now regarding that voip use and the masquerade, from my point of view as
a non-US user...
Most of the people using DMR/D-Star/C4FM and whatever other digital
modes are NOT in the 44net and don't want to be. They just want a simple
solution for their hotspots and repeaters that needs to run over regular
internet connections with a dynamic IP and not bother with other network
stuff. In this case, a reflector running on a public IP or on a BGP
announced 44net will provide the same job, with the same latency and the
same availability, being functional equivalent.
But if that reflector sits on a meshed/tunneled host, that is no longer
the case. It will need to run via the amprgw, which is not desired, so
this is out of the question, especially for users and hotspots outside
the US, since it will add 2 hops over the pond, which take time. For
such cases, running the reflector on a public IP makes sense.
From the users point of view, the issue is similar. Running the client
on a 44net address in the current meshed gateway system will send them
directly to the reflector if the reflector sits on a 44net address AND
provides mesh access, but usually will take them via amprgw if the
reflector is only on a BGP announced subnet without tunnel endpoints
(and this is the usual case as BGP announced subnets are chosen for the
exact reason of not doing the mesh part).
For a reflector located on a public IP, when using 44net in a meshed GW,
depending on the setup, this will either masquerade the outgoing
connection to the GW's public IP loosing the 44net source address (and I
think this is the proper way to do it), or it will go via amprgw, again
crossing the pond once or twice, depending on the reflector's location.
So, while there is no big difference in hosting a voip reflector on a
public or BGP-announced IP for a regular internet user (most of the
hams), it makes no sense to host it solely on a 44net meshed host
(unless access via the public IP is also provided). And in this case,
that reflector needs to appear under 2 different names with different
IPs, so that the end user may select the one appropriate for his setup,
since there is no way to provide IP information for a dual hosted
reflector to the current client hotspot/repeater softwares. It is only a
single name with a single IPv4 address.
And it makes also no sense for a client to try to access reflectors on
the public internet using meshed 44net addresses: masquerading to the
users public GW address will yield better results providing direct
connections without passing through the amprgw, which will happen if
access from a 44net meshed IP to a public IP is requested.
Maybe now I made my self clear...
Marius, YO2LOJ