28 Jul
2021
28 Jul
'21
6:48 p.m.
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:
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
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.