On 28 Jul 2021, at 13:48, Rob PE1CHL via 44Net 44net@mailman.ampr.org wrote: On 7/28/21 1:35 PM, Janko Mivšek via 44Net wrote:
Rob PE1CHL via 44Net je 28. 07. 21 ob 13:18 napisal:
I really think that "we should accomodate static routes" is a very weak reason for the proposed changes. We should move away from static routes, if anything.
Yet having a 'static route only' as a least common denominator is not a bad idea either. Certainly comparing in complexity to IPIP mesh or BGP. Next common denominator should be a VPN to POPs.
BGP is something we need to avoid for end users. It has a illusion of a simple setup, but to understand and manage BGP, this is certainly out of reach for most of radio amateurs.
Yes. If I was not clear: my proposal is to make a new backbone of PoPs instead of the current IPIP mesh (as was discussed end of last year) where a user can choose to:
First of all, let me say that we would like to see IPIP Mesh go away too some day, but we definitely need a robust Global PoP infrastructure first. I think we have many years until we can completely shut down IPIP mesh (at least the official ARDC one, anyone could set up their own). But this can happen gradually. As more and more users are available via the PoPs, then it will be easier to look into the future of IPIP Mesh. We have not discussed anything related to it so far.
- make a simple VPN connection with a local subnet and everything else is at the other end of the VPN. users can decide themselves if they want the local side of that VPN to be an isolated network of radio stuff and set a default route to the VPN, i.e. everything else than local is routed to the PoP and the router there decides how to further route that (to another PoP, to another user, to internet). user has to do no routing at all. everything static. is even possible in a Fritzbox and some other routers which can setup a IPsec VPN (or OpenVPN or Wireguard in some other routers).
This comes with the following issue: how do I know as a sender that you are making this available to the Internet? I will be able to send you packets, but your systems would just send the responses back over the Internet, and I would never get them, as I am Intranet-only. This can also lead to very difficult troubleshooting scenarios.
second alternative is an "intranet only" version of that where the user only routes 44.0.0.0/9 and 44.128.0.0/10 to the PoP and routes all the remainder to their own ISP. That is the variant that is like what is done in Germany. User can use NAT in their router if they want to access AMPRnet from their RFC1918 network.
third option is to run BGP over the VPN and receive and advertise AMPRnet subnet routes over that. this allows advanced users to become a gateway for others, or to setup multiple VPNs to different PoPs and have redundancy. extra VPNs to fellow amateurs for direct routes withoud dependency on the backbone are possible as well. Standard routers like MikroTik can do this, ISP routers of course cannot.
This all can work with some technical solutions and trying to think about a little bit more. As I said many times today, finding a technical solution to connect all users by the same means is easy. We don’t want that. That’s not the problem we try to solve. The problem we try to solve is to allow you, that want to use the ARDC PoPs, to talk to me, that I want to set up my own PoP concept globally, and connect users to my PoPs instead of ARDC’s. And of course we also want us to be able to talk to a radio-only network in the Bermudas that is connected via BGP.
We do not want to force anyone to use the PoPs. Yes, they will make it easier to connect, but only for the people that want a production-grade connection. Not for the ones that want to learn BGP or like to set up antennae, etc. It’s not just one category of people that want the same thing in this network. It’s many, and we should serve them all.
This is what was discussed and we got entangled in implementation decisions (like "are those PoPs to be hardware routers supplied by ARDC or is it better to use VPSes in the cloud") and at some time the discussion was taken offline by the TAC, never to be heard about again. In this solution, there is no reason at all to artifically split the network in intranet and internet sections because the decision how to route can be delegated to the PoP, which obviously runs software capable of dynamic- and policy routing.
Yes, in the network you describe, if you add a few rules and a few additional technical solutions, you could solve “a” / “your” problem. But not everyone else’s. The ARDCs PoPs don’t solve for how I want to connect to this network. So if we just go ahead and force a single way, a single technical solution for a social problem, then I personally believe that we will fail. We’re going to leave many more users either completely excluded or unhappy.
And that’s something that the TAC and ARDC probably do not want to do. This is a resource for all of us, and we should support all the use cases. Not just the ones we want to use, or consider useful, or important.
That’s the main argument here.
I hope that helps, Antonis