Its lots more complicated than ZeroTier would have you believe, especially for Enterprise clients. That can add wrinkles due to VPNs, firewall filtering, non-symmetric packet forwarding. And there's the case of two clients inside the same subnet - to go P2P using the described algorithm requires something called Router Hairpinning which has spotty support.
There are ways around all that, and Sococo supports them all. (Caveat: I work at Sococo).
Sure; but again assumes a simple subnet configuration. Lots of enterprise customers have multiple subnets with gateways, internal routers etc. They probably won't respect/forward LAN locator beacons. We (Sococo) gave up on that approach, particularly since Enterprise IT guys like to get excited about broadcast UDP wandering around their subnet.
A straightforward approach is, when talking with the 'rendezvous' server, to include in the message your discovered local subnet address(es). Then the server can inform your peer of the entire set of candidate IP addresses you might be available at (NATted address + subnet addresses). P2P connection pinging then works the same way, with the additional constraint that the 1st P2P message must include a unique id to identify the peer. Because non-routable subnet addresses can be re-used (10.x.x.x or 192.168.x.x style). You don't want to try to connect to Alice and discover that XRay has the same subnet address, XRay is available on your subnet, and XRay is also running the same P2P app.
Anyway like I mentioned, its complicated and full of wrinkles.
I guess they dismissed it too soon. None of our enterprise customers have a problem with it. And some demand it - the alternative is to have their P2P traffic travel outside the firewall and back in again, 'hairpinned' through the public router. Talk about a security risk!
What can that possibly mean? Of course I read it; they addressed a small fraction of the cases involved in P2P link negotiation.
Ok, I re-read it, missed that sentence the 1st time. The guy does dismiss 'private' IP sharing as mentioned elsewhere in this thread. This has not been an issue with any enterprise client in our network. In fact, its a little weird to be consider sharing IP addresses a problem in a protocol designed to share IP addresses. Especially unroutable ones that can be guessed anyway (there are only 65535 192.168.x.x addresses).
And NOT doing this makes some attempts fail, have worse latency, or worse yet NOW you're sharing your private traffic (voip? video? company IP?) over the PUBLIC internet. In fact several of our more careful customers explicitly demand that we route P2P traffic exclusively inside their firewall, and this is the feature that makes it work for them.
There are ways around all that, and Sococo supports them all. (Caveat: I work at Sococo).