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:
- 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).
- 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 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.
Rob