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@mailman.ampr.org Sent: Sunday, May 22, 2022 14:25 To: Rosy Schechter - KJ7RYV rosy@ardc.net Cc: Amprnet 44 Net 44net@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@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org