The IPIP mesh may be non-standard, but it is distributed, without any single point of failure. To get between two points, the two gateways have to have IP connectivity to each other. That's it. The two end-points can troubleshoot directly.
But every proposal I've seen on this list involves adding at least two other ham points of failure. For example, I would presumably connect to some other ham's BGP node and the other end of the connection would do the same. Why?
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
The IPIP mesh may be non-standard, but it is distributed, without any
single point of failure.
To get between two points, the two gateways have to have IP connectivity
to each other.
That's it. The two end-points can troubleshoot directly.
But every proposal I've seen on this list involves adding at least two
other ham points
of failure. For example, I would presumably connect to some other ham's
BGP node and
the other end of the connection would do the same. Why?
Mainly because it makes it an "outgoing" connection for most people.
... clipped ...
By putting VPN servers in datacenters and having the users connect to them,
you avoid those problems.
Yes. But you keep ignoring the problems it creates. You're simply trading one set of problems for another.
Also, there is no requirement that there only be a single connection! You
can setup crosslinks
to wherever you like.
But you also say "There is no need for a portal that registers the subnets, they only need to be configured in the gateway routers."
I haven't seen a technical write-up of what you propose. But the statement above tells me that those who aren't interested in the putting up with the new problems the overlay hubs would create have lost the simplicity we have now.
It's easy enough to say things like "you can set up crosslinks to wherever you like". But without the central registry, we lose the simplicity we have today. Today, we download a file and run a script. Done. Direct connections to everyone else. No middle men. No added latency. No added complexity. No added troubleshooting difficulty. No added dependence on some volunteer at the hub who may or may not be available when needed.
Now if your proposal included the following, it would truly be solving a problem for some people with causing a problem for others:
1) For folks who can't support direct connections, let them use a VPN connection to a hub of their choosing (as you appear to be proposing)
2) *** BUT *** leave the central registry in place, and augment it so that when you sign up for a hub, your subnets are still published to all other gateways as reachable through the hub.
3) Therefore, those who can support direct connects but are not a hub can still see a full registry and automatically create direct links/tunnels to all other gateways (whether they are individual gateways or hub gateways) and routes to all subnets behind all other gateways.
Michael, N6MEF