IPNS defaults will break in LANs with proposed NAT-detecting DHT

[aschmahmann]

Current Proposal

The changes proposed by #4993 and libp2p/go-libp2p-kad-dht#349, which have been implemented in a feature branch courtesy of libp2p/go-libp2p-kad-dht#350 will break IPNS (default) behavior in LANs.

The gist of the linked proposals is that peers should detect when they are behind a NAT/likely undialable by most of the internet, and if they are then they should not advertise themselves as dht servers (although they may continue to send queries as dht clients). This should help IPFS and IPNS publishing and resolving speed dramatically.

Problems

A side effect of this is that the DHT will no longer work by default in offline environments since all of the peers will notice that they are undialable and therefore not become dht servers. IPFS can be protected from this if the network supports MDNS, since MDNS will ensure that local peers all connect to each other and then Bitswap will broadcast requests directly to those peers. However, IPNS (by default) can only publish and resolve records using the DHT so it will not work. The groups hurt by this change are broadly people with broken defaults, and people with broken use cases.

• Broken Defaults: If they set their ipfs config to use dht-server (or whatever we call this mode) instead of the regular auto dht then everything works again. This effects:

  • private swarms
  • LANs with many nodes and/or MDNS disabled (Note: this is also a problem for IPFS)
  • people who just don't like/block autonat, but have publicly dialable network addresses

• Broken Use Cases: Even setting the config to dht-server is insufficient. This effects:

  • nodes that move between the public network to a LAN with many nodes. If we tell them to turn on server mode then it hurts the public network, if we tell them to leave it on auto/client then their LAN setup might not function.

I suspect that the number of people with broken use cases is very small (although I could certainly be wrong here), but the number of people with broken defaults might actually be significant.

Options/Mitigations

Below are a number of potential options that could help:

• Communication
  • Let people know what breaks might be coming. We might be lucky with most private swarms and large LANs probably having a script that does their default configurations, but some might have less automated setups.
• Enable IPNS-over-PubSub by default
  • This will help with private swarms and people who block autonat. However, it won't help with large LANs and/or MDNS disabled networks
  • Has gotten much better, but has not been part of a release since the main blocker on Road to being a real feature was dealt with IPNS over PubSub as an independent transport #6447
• Create a second DHT that is targeted at non-public nodes
  • Will likely have some design challenges, but should help with all of the listed issues
  • This would be useful in certain situations even without the proposed DHT changes

There are potentially other mitigations and solutions available and if you have suggestions, please comment!

@kpp I recall you are working with a large private network, although you might not be using IPNS. Do these changes affect you and do you have any thoughts on the proposed mitigations?

^ @Stebalien @alanshaw

[kpp]

Hi. We use IPNS + MDNS and our nodes move between the public network to a LAN with many nodes (up to 3-5 in avg and ~30 in the worst cases) one of them can be a relay to the public network. Moving from public to LAN is uncontrollable so it's we can't turn off the node and reload it with new config options (probably we can, but it seems unsufficient).

[aschmahmann]

@kpp Thanks, that's good to know. As we get closer to a release would you be willing to try out the improved IPNS-over-PubSub? That should allow IPNS to work even if you left the configurations on default.

For now it's behind an experimental flag. While we could potentially change that, it'd be nice to have a release to gather feedback if we could.

[kpp]

I am willing to try new features and develop them =) I already contacted @Stebalien about libp2p/go-libp2p-core#64. Please add me to your dev chats.

[aschmahmann]

For go-ipfs v0.5.0 we ended up resolving this with option 3: Create a second DHT that is targeted at non-public nodes. See libp2p/go-libp2p#803 and #7127