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