On Thu, Jun 13, 2024 at 3:55 PM Cara Salter via 44net
<44net@mailman.ampr.org> wrote:
> On 6/13/24 14:49, lleachii--- via 44net wrote:
> > Dave,
> >
> >
> > I appreciate your response. But again, I still choose not to change the
> > topic.
> >
> > I think you also forgot about my infrastructure and that of my sponsor
> > (i.e. radio towers I mentioned for actual amateur use and access).
> >
> > It does indeed seem ARDC doesn't welcome amateur use, aside from these
> > different fanciful descriptions everyone seems to have, just different
> > from mine and others.
> >
> > Nonetheless, just know in our region, regardless of DNS or IP, we'll
> > welcome all those who have a a licence (in the US Technician Class would
> > cover it and the bands used) and have the equipment. Just seems there's
> > another way to connect to 44net (maybe Wireguard).
> >
> > Just recall, that will be blocked here - you cannot obscure the meaning
> > of a packet on licensed bands (I hope this is starting to make sense to
> > some).
>
> I think the idea behind the Wireguard VPN is to allow people to connect
> to AMPRGW or other gateways using a modern protocol on the non-RF links
> of the internet. From what I've understood and heard, the Wireguard
> connection would be terminated before entering 44net space.

Correct. As I understand it, the intent is for a bunch of wireguard
VPNs to replace the existing IPENCAP tunnel mesh. So instead of having
bidirectional tunnels between sites carrying 44net traffic, sites
would instead establish VPN connections to a (hopefully?) nearby POP
that then route traffic normally across the broader Internet. So for
example, if one is in the northeastern US one might VPN into a NE-US
POP and route through it. But the VPN infrastructure would not be used
over the air (again, as I understand it).

In some respects this will be an improvement over the existing tunnel
mesh: sites won't have to maintain all the routes themselves, and
programs like ampr-ripd or my own 44ripd can slowly fade into
obscurity. On the other hand, it will, on average, make connecting
between sites marginally slower: the existing point-to-point tunnels
are, in some way, optimal between sites as presumably the routing of
encapsulated datagrams flows directly between endpoints (or as
directly as anything routed over the Internet ever is, anyway).

A lot of the tension in this conversation seems to come, as far as I
can tell, from miscommunication, and could probably be resolved with a
(probably even relatively short!) video conference.

To a just slightly lesser extent, I suspect some of the issues stem
from a perceived lack of transparency around the "fishbowl" style of
changes implemented on AMPRNet recently. Communication around _what_
is happening is important, but equally -- if not more important -- is
involving the community and communication both the _how_ and the
_why_. This latter could be improved.

        - Dan C.