On 12/8/21 5:02 pm, Rob PE1CHL via 44Net wrote:
On 8/12/21 2:53 AM, Tony Langdon via 44Net wrote:
All nice, but the backbone would need to have _multiple_ links to the Internet. For example, currently (by default), to get from my IPIP connected subnet to my BGP connected one, I have to do a very long trip of 2000+km via San Diego to communicate over 150km! Obviously, an exit point onto the Internet geographically closer would be needed if I was going to trust the backbone to route my traffic correctly.
Yes, of course! My idea was to announce (mostly) /16 networks from the backbone routers, each of them in the backbone router(s) closest to the area where that /16 is used. Others proposed to announce the full space at some places in the backbone router network. Essential is that traffic between you and internet crosses over at a router physically close to you. There should be at least one such connection in Australia, probably 2 or 3. You would not have to go via San Diego. As I see it, San Diego could become one of the backbone router sites, nothing special anymore. Note that in the Netherlands, our BGP connected subnet and our IPIP connected subnet is the same. We have fast roundtrip to internet and still have IPIP connections to those on the mesh. That is functionaly the same as I see it in the backbone network: it would be a network of routers interconnected by a tunnel mesh, and also announcing networks to internet.
Mostly OK so far. :)
Note that in the proposed structure, anything with a net-44 source address and an internet destination address can be routed to the backbone network and it will go to internet without NAT. No need for separate subnets to achieve that. And because the path via the backbone is efficient, there is no need to add band-aids like routing internet traffic via a local NAT router. That is what whe need to get rid of, because that is what is causing the issues that motivated the creation of the separate 44.190 network. That solution was apparently not good enough and now we get the proposal of renumbering everything. Which I predict will not solve the problems either. That is why I propose fixing it the right way: by setting up a proper backbone network with good connectivity and easy options to join it (so there is no reason why people would skip it and use the local NAT shortcut).
There is one aspect that might be a potential issue, and that is where the 44net IP is on amateur links. Open access to the Internet could be problematic, from a legal point of view. I know our authorities are very conservative in this area, and in fact, it took a while to get Winlink approved for use here, that was a long running saga. They're fine with using the Internet as a carrier for amateur traffic (e.g. RoIP networks like IRLP, Echolink, etc), or the IPIP tunnels, but not so keen where non amateur traffic could enter the amateur frequencies. This implies there will need to be some fairly straightforward firewall options available. I could easily use iptables, but others might need something more user friendly. I would have 3 classes of IP in my networks:
1. Public, BGP routed (direct connection). Basically my existing 44.190 allocation is a prime example of this. These IPs are to provide Internet facing services.
2. Backbone routed IPs on LAN (or local wifi). These are mainly for intranet use, but not being on air, connection to Internet hosts is tolerated. For example, these addresses would be a good place to run an IRLP or Echolink node.
3. Radio based IPs. Here, I would be very selective what to allow by default - other Intranet addresses, possibly at least some of the public BGP routed 44net space. Individual hosts on radio may even have cause to communicate with specific Internet IP addresses (e.g. the end point for some other amateur link), on a case by case basis. Or I may allow specific ports/protocols only to the general Internet (e.g. Echolink, IRLP, etc).