27 May
2022
27 May
'22
12:36 a.m.
I like the regional pops idea and add the ability to have redundant
connectivity for an end user (individual or entity). So I connect to a
west coast and a central or east coast pop in the US. Europe and others
can do something similar. If I wanted, maybe I can connect to as many
pops as I think I need to. Could also be admin limited to keep things
from getting too crazy. POPs are a full mesh between regions.
End user setup is MUCH more simple at that point as well. No scripts to
install hundreds of tunnels into a MikroTik router.
I like the idea that a POP can support multiple tunnel methods. I mean
why not right? :D
Are there any programs or ham friendly datacenters that could help with
regional bandwidth and transport between hops? When I think regional, I
think of things like AWS, Azure and Google Cloud with their multi-region
setups. Maybe a bit overkill but something to consider I guess?
Charlie/K7AKT
On 2022-05-23 00:50, Rob PE1CHL via 44net wrote:
A big advantage of POPs over the current IPIP mesh is
that you do not
need to have everyone
use the same tunneling protocol. POPs can offer multiple tunneling
protocols and can experiment
with new ones, without impact on all the other users of the network.
So there is no need to have a broad discussion about "do we use
OpenVPN OR wireguard", we can
offer both of them, and when a new protocol comes around next year we
can just add it, first
to one or a couple of POPs to try and test it, and then to all of them.
With the IPIP mesh we are stuck with using the same protocol
everywhere, and when some user
cannot use it due to limitations of their internet connection, they
simply cannot join.
Also, having POPs as an intermediate makes the network scale much
better, as each user only
has a tunnel to one or a couple of POPs, instead of having a full mesh
to everyone else.
The number of POPs can increase with demand and they can be located
where demand is highest.
Rob
On 5/22/22 20:43, David Andrzejewski via 44net wrote:
I might suggest WireGuard instead of OpenVPN. I
know it's newer but
it's also a bit easier to use and set up.
That said, I fully agree with your point about the learning aspect of
routing. I think there's a balance to be struck - ham radio is about
learning, but there shouldn't be a high barrier to entry.
Dave/ad8g
-----Original Message-----
From: Steve L via 44net <44net(a)mailman.ampr.org>
Sent: Sunday, May 22, 2022 14:25
To: Rosy Schechter - KJ7RYV <rosy(a)ardc.net>
Cc: Amprnet 44 Net <44net(a)mailman.ampr.org>
Subject: [44net] Re: 44Net Assessment Kickoff - Survey!
Good survey
I just completed it and I have some other comments.
The IPIP mesh is not plug and play, which for folks like me who are
interested in learning routing has been an invaluable learning
exercise. I hope something like this can always continue.
However there are other use cases that are more plug and play. One
being supporting internet connected infrastructure (ie. IRLP, Allstar,
DMR, D-Star etc). All of which mostly require a public IPV4 address
and the ability to port forward. Such is not the case with cellular
providers and will only become more of an issue as the global pool
IPv4 addresses shrinks. A system of geographic POP’s should be
deployed. The POP’s might want to use OpenVPN as it's well supported
and issues automated keys or the ARRL LoTW method. It would be wise
to limit the bandwidth to something modest and employ a DPI technique
to drop bittorrent fingerprints to ease overall administration.
Short of ARDC supporting POP’s, then you’re looking at outside groups
making this happen. But these will likely be service specific. Ex, I
believe IRLP has done so with some assigned address space.
Current geographic portal allocations are based on CIDR style routing.
Which makes sense if you intend to interact with existing (legacy) RF
networks. Perhaps a portal question should exist to point them to
their geographic allocation or not. If the intent is non RF or mesh,
then a different allocation methodology should be employed (next chunk
in sequence)
I’ll stress again knowing who is doing what is always good so one can
privately coordinate forwarding partners, etc, and just folks to
experiment with.
Steve, KB9MWR
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an
email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org