Re: [44net] Time to restructure the network?

Mainly because it makes it an "outgoing" connection for most people. That means it is not affected by NAT, CGNAT, dynamic addresses, inflexible router firewalls, etc. Getting IPIP to work bidirectionally often requires to setup the internal system as "DMZ" (which in home router speak means that it will receive all incoming traffic not matched by the NAT engine). This can only be done for a single system, and even then it often does not work correctly (e.g. it receives only TCP/UDP and not other protocols). You should not under-estimate the difficulty that IPIP is causing for more and more people. As an example, I am currently trying to migrate my physical colocation server to a VM. The service offered by the hosting company uses Apache Cloudstack. While the VM itself works fine and can load the ipip module, it turns out that Cloudstack cannot allow IPIP ingress in its firewall settings. So I will have to look for another hosting option... By putting VPN servers in datacenters and having the users connect to them, you avoid those problems. Also, using the topology I propose, there is no requirement that the entire network runs a single tunneling protocol or a single topology. Only the peers need to support the same protocol. And it can be a symmetric protocol like IPIP or GRE when you like that better. Also, there is no requirement that there only be a single connection! You can setup crosslinks to wherever you like. There will rarely be traffic to all IPIP mesh peers. There are more than 500 gateways in the list, and when I look in our stats I see we have had traffic to only 23 of them in the past day. Most active gateways can probably point out at most 5 peers to which they have regular traffic. You can setup crosslinks to those. And this system is not dependent on a central RIP sender! Every node is active in distributing its own subnets and receiving the others. There is no need for a portal that registers the subnets, they only need to be configured in the gateway routers. A portal could still be useful as a management system for VPN accounts. Especially at the major hubs, the users need to have a VPN account that assigns them a point-to-point address, and the BGP on that router needs to be configured with the AS number on that address. This could be done using some form of portal and a program that configures the router using its API. That is not mandatory. On our gateway the addition of new users still is done manually. I once have added a large number of skeleton BGP peers and VPN accounts, and when a new user requests a connection I find an available one, enter the username (callsign), a random password, and enable it. In the BGP peer I enter the AS number and enbale it. Done. There always will be some dependencies, but they do not need to be single-point and with some money available they do not need to be only relying on volunteers and unclear situations where some company hosts a service only because a worker there has arranged it. I think it has big advantages over the system we have now. Rob