On "DialMe", NAT traversal, Relay, line switching, packet switching (libp2p protocols)

[jbenet]

• libp2p will have a bunch of NAT traversal facilities, like hole punching, relay, and "ask others to dial me". whether these will be part of one big NAT traversal protocol, or several little ones is still unclear.
• so far, @jbenet made go-libp2p have a host.RoutedHost abstraction that uses a "Peer Routing" protocol to establish addresses of peers in order to dial.
• @jbenet also implemented a "line switching" relay protocol in go-libp2p, that is currently disabled. this could be made to opt in / turn on with a config var. (difficult questions re traffic there)
• @diasdavid and i discussed replacing this in libp2p by just a libp2p.Node, with just a RoutedTransport (or some other, more suitable name) that understands how to use a libp2p.PeerRouting protocol to resolve more abstract addresses (eg (/ipfs/<id>) into more specific addresses (eg /ip4/1.2.3.4/tcp/1234/ipfs/<id>), and use those to establish a connection.
• @diasdavid @lgierth @whyrusleeping and @jbenet are all very interested in getting a packet-switching based thing working. (building on other things, like dht routing table. @lgierth is working on fc00)
• despite "packet switching" being better, I think "line switching" transports will still exist, so our NAT protocols should be able to work over both. (most NAT traversal protocols are all about "line switching" anyway, and "packet switching" circumvents NAT at the expense of direct connections + routers/relays)
• Let's take the concrete case of a "DialMe" request protocol, which is fwded to peers. this can be achieved with either the "line switching" or "packet switching" relays. so should be able to layer above cleanly.
• A "Relay Finder" (Routing) protocol can leverage PeerRouting protocols (like a DHT) to find suitable "line switching" relays (directly connected one-hops, or just finding a whole route). ((concretely: "use dht routing table to find peers directly connected, recursively").
• Given a relayed connection (line or packet switched), our DialMe protocol can send a message asking to be dialed at a particular address. if the connection is successful the swarm can just pick up the (better) connection.
• down the road, latency + bandwidth estimators can be used to select between connection streams, independent of whether line switching or packet switching is going on underneath.

Synthesis

• a RelayRouter protocol can use a PeerRouter to find suitable relays.
• a Relay protocol can setup relayed connections
• a DialMe protocol can use any connection (relayed or not) to ask for a "dial back" (may not need to know about Relays at all)
• for now, the libp2p.Node (today RoutedHost) could bring it all together, i.e. when dialing is not working, attempt a relayed connection. (it already handles resolving addresses, and NAT traversal)
• in the long run, estimators will help decide between connections.
• deciding which connection to use should still be up to the Swarm (can close the Relayed connection for now, until we have proper estimators).
• in the long run, fc00 swarm would take ownership of all the relay part, and DialMe would just work to setup a new connection.

What to do now?

I recommend:

• enabling the Relay service ("i offer to relay for others") as an config based opt-in service to run. (it has serious policy implications, so it must be opt-in (at least for now))
• finding a good way to insert the DialMe abstractions into go-libp2p's RoutedHost without needing to change much just yet, but roughly in accord with the long term view. it could even serve the RelayRouter part.
• use DialMe to avoid using relayed connections. maybe only use relayed connections for DialMe requests for now.

cc @noffle too

In an HN comment, someone brought up pwnat: http://samy.pl/pwnat/#HOW

It's based on Autonomous NAT Traversal by Grothoff, Evans, Mueller, Kamkar: http://samy.pl/pwnat/pwnat.pdf

The proposed method for autonomous NAT traversal uses fake ICMP messages to initially contact the NATed peer.

[whyrusleeping]

I remember seeing pwnat before, its an absurd hack, and requires root to work IIRC.

[Kubuxu]

Yes it would requite root to work as it sends raw ICMP but it could be skipped in case of IPFS as we know addresses of peers now behind NAT and can connect to them so they can tell us our address.

Then we could use 3rd party to do DialAtTheSameTime over UDP to careate connections.

Problem is that it would only work over full-clone NAT which is becoming rare this days.

[jbenet]

pwnat is epically awesome. i tried getting it to work once, but couldn't in 30min.