On 14/6/24 6:17 am, Dan Cross via 44net wrote:
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).
That was my understanding as well, to make it easier for the average end user to connect to the IPIP (or its replacement) infrastructure. I did similar for myself, putting my IPIP endpoint in the cloud and then using a ZeroTier bridge to make my subnet accessible here, allowing ZeroTier to do the work of getting through local NAT. The VPS where the IPIP terminates is relatively close to me, so performance is good.
When ARDC replace the IPIP mesh, I'd like to put my VPS on the backbone, so I can use my existing link without the overhead of an additional VPN tunnel, since I already have equivalent functionality in place.
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).
The way the routing works is one thing I like about the IPIP mesh that VPNs by themselves can't easily reproduce, but I believe there's more modern methods out there to replace the IPIP functionality with, with the last hop to the end user being done using Wireguard, unless they choose to participate in the backbone.