-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NAT Autodetection #4993
Comments
At the expense of network reach unfortunately :( The NAT autodetection concept is very useful regardless - and it would work best with relay infrastructure in place. It is arguable whether we want to announce any other addresses by default when NATed, but I think we shouldn't unless the user plans to test and interconnect with other local network nodes; at which point he probably knows what he is doing at a deeper level than most and can configure his node accordingly. Also. mdns discovery should connect nodes in the LAN without the need to announce internal addresses. |
This state of being dialable can change dramatically within minutes - home routers restart, crash, or forget NAT mappings all the time. A simpler version of this would be "do I have a publicly routable IP address". |
@lgierth Do you have a simple heuristic for 'publicly routable' ? |
I think we can just test dial from a background host (or different process). |
Basically anything that's not included in the list of ranges we block in the On another note, whois lookups for non-public address blocks seem to to return empty, but I've only tested that for |
@lgierth is right, let's just filter everything that's not IANA routable. |
Unless I am missing something the removal of non-routable addresses will prevent the use of IPFS on an internal network. The easiest way to resolve this is to add a config option for the removal of non-routable addresses. |
I would be careful with that. I also feel that we are treating symptoms and not the underlying cause. From my experience go-ipfs' NAT traversal has a lot yet to learn. Using only "I have a socket open on publicly routable IP" for DHT will significantly hurt offline and overlay network scenarios. |
Agreed; there should certainly be options for node operators to configure as they see fit for their environment.
We are also looking forward to integrating with the browser world.
Yes, of course! It's a long term project to achieve reliable NAT penetration at the transport layer. |
Ah yes, I wouldn't want to generally run in In local-ish and offline scenarios we want to have all the peer-to-peer firepower we can get. A node can be in the globally-connected and local-ish/offline scenarios at the same time though. So maybe what we'd want is for some protocols to be aware of certain layers of locality (?). I want to have the full DHT dance with my local peers, but maybe don't want to part in the global DHT because my internet connection is bad. |
So I think what we want here is an option to turn on/off this 'automatic adaptive NAT mode'. Like it or not, the default behavior for the main network should be to run as dhtclient if you have a bad NAT. Users who want can circumvent this by setting the option, but the average user shouldnt have to be aware of this to not make the network worse |
👍 It'd still be great to not make things worse for offline/local use cases though -- requiring flipping an option to make things work locally is meh. I think this whole situation smells like a leaky abstraction. We treat all peers equally, but they really aren't equal. (In a similar sense as how Coral has latency-bounded rings.) |
This is different than what was being proposed here of going dhtclient if you don't have a public IP. I think simple test "am I dialable" with bootstrap peer could be the best way forward. I think it could remove about 90-odd% of undialable peers. |
Hrm... care to elaborate on where the right abstraction might be?
read my original issue though |
Maybe the same |
As in: if we're connected to the peer via their public IP, then they're probably a "global" peer. |
@lgierth I like that, want to open an issue somewhere in libp2p to suggest that? |
And it'd help with pushing the DHT towards a Coral-like model. But we'd probably want something more flexible/future-proof than a simple global/local binary. Will file that issue when I'm back in a bit. |
I fear this would be like throwing out the baby with the bath water, if we blanket do that. |
@vyzo hrm... youre right. Assuming we get connectivity with relays to be high, then the more the merrier. |
Ambient NAT autodiscovery in libp2p/go-libp2p-autonat#1 |
Hmm... this might hurt the browsers badly. Relay is not only for NAT, its also to bridge the gap across different transports/runtimes - we need Relay to be able to dial browser nodes or any nodes that run on weird/incompatible transports (bluetooth, etc...) |
An update:
The plan is to run the NAT service in the bootstrappers. |
Didn't this issue get closed in the 0.5.0 release? |
I'm thinking about having nodes, on startup, check if they are publicly dialable via some libp2p 'can you dial me?' service, and if they find that they are not dialable, running with DHTclient mode (and maybe some other options set, like only announcing relay addresses for themselves).
If this were deployed widely, it would essentially 'solve' the dht connectivity problem.
cc @vyzo @Stebalien @Kubuxu @mgoelzer
The text was updated successfully, but these errors were encountered: