Use https://crates.io/crates/p2p for NAT traversal?

[TheWaWaR]

Current rust-libp2p implementation has very simple NAT traversal support. As I know, just remap the port the a public IP address.

How about use p2p as to support more powerful NAT traversal techniques? Like TCP and UDP hole punching (even port number prediction), looks great to me.

A TCP hold punching example:

• https://github.com/ustulation/p2p/blob/master/examples/tcp_rendezvous_server.rs
• https://github.com/ustulation/p2p/blob/master/examples/tcp_rendezvous_connect.rs

Example steps

1. Start the relay sever (require public IP address)

   socat TCP-LISTEN:45666 TCP-LISTEN:45667

2. Start the rendezvous(traversal) server (require public IP address)

   cargo run --example tcp_rendezvous_server
   # listening on public socket address <rendezvous-server>:45000
   # our public key is: {"sign":[...],"encrypt":[...]}

3. Start NAT peers (Better locate in different NAT)

   # Start first peer
   RUST_LOG=p2p=trace cargo run --example tcp_rendezvous_connect -- --relay=<relay-server-ip>:45666 --traversal-server=<rendezvous-server>:45000 --traversal-server-key='{"sign":[...],"encrypt":[...]}' this-is-45666
   
   # Start second peer
   RUST_LOG=p2p=trace cargo run --example tcp_rendezvous_connect -- --relay=<relay-server-ip>:45667 --traversal-server=<rendezvous-server>:45000 --traversal-server-key='{"sign":[...],"encrypt":[...]}' this-is-45667

[tomaka]

I took a look at the crate a long time ago, but quickly dismissed it because some of its dependencies are under GPL. That would need to solved first before considering it.

The libp2p protocol itself also has a relay protocol that is equivalent to a STUN or rendez-vous server. The only thing we're missing are "router-level" capabilities like UPnP or port prediction.

[TheWaWaR]

They changed their license to MIT/BSD3 29 days ago.

But a quick cargo lichking check report is not good.

$ cargo lichking check
warning: IANAL: This is not legal advice and is not guaranteed to be correct.
error: p2p cannot include package sha1, license BSD-3-Clause is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package future-utils, license GPL-2.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package tokio-shared-udp-socket, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package config_file_handler, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package fuchsia-zircon-sys, license BSD-3-Clause is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package unwrap, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package netsim, license GPL-2.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package fuchsia-zircon, license BSD-3-Clause is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package net-literals-impl, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package future-utils, license GPL-2.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package net-literals, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package future-utils, license GPL-2.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package get_if_addrs, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package capabilities, license MPL-2.0 is incompatible with Any(MIT, BSD-3-Clause)
error: p2p cannot include package maidsafe_utilities, license GPL-3.0-only is incompatible with Any(MIT, BSD-3-Clause)
error: Incompatible license

I'll create an issue about it.

[romanb]

What rust-libp2p can do in terms of NAT traversal is somewhat limited by the design of some libp2p protocols. In particular, sophisticated TCP hole punching is not really possible in a general manner, due to the need for role separation between endpoints in core protocols, e.g. a TCP simultaneous connect does not currently work well with libp2p as both endpoints of the connection assume the role of "dialer". See also libp2p/specs#196. Nevertheless, some foundations for that direction have been laid in #1887 via opt-in TCP port reuse, which I think is enabled by default in most other libp2p implementations. Other than hole punching techniques, and as was already mentioned before, there is a relay protocol in libp2p and a recent PR for its implementation in rust-libp2p at #1838.

I hope that clarifies the status quo. Feel free to re-open or create new issues for further suggestions under consideration of this information.