Re: [44net] My view to 44net's future

I'm a relative newcomer to using 44Net for ham things (last 2-ish years) but we've made extensive use of it in our Megalink project for Northeast Ohio. I think that something that is more turnkey for the ham community is sorely needed. Most hams are not network engineers. Much good work has been done over the years to make AMPNet what it is. However in 2020, most basic infrastructure is largely turnkey (e.g. AWS, Azure, cloud hosting, VPS, etc.). Infrastructure and network engineering is, sadly, a diminishing field because the need just isn't there anymore outside of the big providers. To support ham connectivity into the future, AMPR needs to offer something comparable. The one caveat I would offer is that endpoints connecting to such a new service core should be one of a limited number of supported hardware + software configurations at the end. Experimentation can be free beyond the connection's edge device but the edge devices themselves need to be fairly uniform for supportability. I also firmly believe that any new service should be dual-stack v4 and v6. We should be encouraging the use of IPv6 as a primary goal. We could get a /32 or so from one of the RIRs as AMPRNet v6. The other thing is that having lots of transit at major providers is $$$++ (relatively speaking) and we're probably want run the core on some serious networking hardware. Would ARDC fund these? I'd be willing to help run one or several, but the expense of doing so is far beyond my budget. Jason N8EI -----Original Message----- From: 44Net <44net-bounces+jason=mfamily.org(a)mailman.ampr.org> On Behalf Of Rob Janssen via 44Net Sent: Saturday, July 11, 2020 4:52 PM To: 44net(a)mailman.ampr.org Cc: Rob Janssen <pe1chl(a)amsat.org> Subject: Re: [44net] My view to 44net's future It is about a year ago that I tried to discuss such a proposal. My view was like this: let's establish routers at datacenters around the world, in addition to the existing UCSD router and some others that already handle /16 networks on internet.   I was thinking about around 10 routers globally. They interconnect using BGP on private AS numbers (the 32-bit AS numbering scheme we already use) over a mesh of tunnels between them, to exchange routing information for 44Net subnets, but on internet the announcing remains as it is (i.e. the whole network is announced at UCSD, and regional subnets are, but do not need to be, announced at those global routers). The "users" connect to those routers using a (small) variety of tunnel protocols to match the restrictions they face from their internet providers, e.g. forcibly being behind a NAT router, having a dynamic IP address, maybe having some enforced firewalling, etc. I was thinking of standard tunneling protocols like GRE, GRE/IPsec, L2TP/IPsec, etc. The tunnels would be operated in a point-to-point fashion by default (/30 or /31 subnets on the tunnel), and the users would use BGP to announce their own routable subnet over that. They can setup redundant tunnels to multiple global routers when they desire to do so. They can also setup tunnels directly to other users when desired, and run a BGP session with them.  And of course, radio links can be incorporated in the scheme. Users could use the widely available inexpensive routers available today that can use these standard protocols without special tinkering with scripting, locally compiled executables, etc.   E.g. the inexpensive models available from MikroTik, Ubiquiti, etc. More technically inclined users could install software on their own Linux system or -board. I see this as a solution for the following problems: - more and more users struggle with getting IPIP routed on their internet connection, due to them being behind ISP-managed routers, CGNAT, having dynamic addresses, etc. - non-technical users struggle to get our special IPIP mesh operational on their routers, where using industry-standard protocols would be much easier as their router config interface already knows about those. - some users requested to have redundant IPIP tunnels (multiple internet routers serving the same 44Net subnet(s) in a redundant way, which the IPIP mesh cannot do. - the IPIP mesh does not really allow to check the status of the configured gateway routers, so routers that have not been operational for a long time just remain in the tables. I expected enthousiasm from the users, but unfortunately I was met with a lot of resistance to change, e.g. from people who believed that such a system would rob them from their direct tunnel to their buddies on the other side of the world and force them to go via established and centrally managed hubs (incorrect, of course).  As I see this as a hobby and not as a struggle to be right and convince those that do not want to be convinced, I did not pursue it further. I don't know if the attitude an scepticism has gone away now.  We would have to see in a new discussion.  Maybe some of the opponents have realized by now that it would be better to have a more flexible mechanism like this instead of going on with the IPIP mesh forever.  Maybe not. I don's see the need of routing the entire 44Net from internet to all those routers.  When everyone routes only their own regional subnet(s), it remains more manageble and we do not face the raised issues.  Furthermore, some of us have our ISP announce the relevant regional subnet on their redundant border routers under their AS, and then route it to our "gateway" router.  That relieves us from being responsible for that announcement, and we use the ISP NOC services.  But of course it also means we are less integrated with the internet routing, e.g. we cannot allow that subnets from our announcement are routed to others. Of course everyone can decide if they want to announce their subnet on internet directly or via an ISP, but I would suggest that the internet side of things be kept separate from our internal routing (2 BGP instances, the 44Net one using a private AS number) W.r.t. the .ham TLD: I don't see what advantage that would bring, we already have the .ampr.org domain and we run the DNS for it.  It should offer the same capabilities as a dedicated TLD, I think, at a much lower cost. Rob _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net