NAT Flow

[dryajov]

Here is an outline of the overall plan for NAT traversal. This implies both port mapping/punching as well as using other techniques such as circuit relaying and dialme flows:

• Have a nat module to take care of all things NAT
• Circuit relays work like TURN servers
  • circuit relays and NAT port mapping/punching provides pretty good connectivity for peers
  • relaying traffic can be slow, plus it will be demanding for the relay peers
• The upcoming dialme protocol can be used to upgrade relayed connections to direct ones when possible, thus increasing the chances of direct connections and alleviating load on the relay nodes

Here is the overall flow I'm thinking about

Booting libp2p

assuming nat manager and circuit dialing are both enabled

• On boot
  • detect the current network topology
    • if we have a public ip do nothing and ignore NAT altogether
    • if we've detected NAT then proceed to set up NAT traversal
      • try to set up a port mapping for each of the (applicable) swarm addrs
      • announce the public addresses (along side the private ones?)

Dialing Peers

(assuming we have NATed ports and circuit is enabled)

• Dialing a peer
  • Peer A dials to Peer B over circuit (because B is behind a NAT or its a browser, etc...)
    • on success, see if Peer A has a public address or NAT port mappings setup
      • if either are true
        • use the dialme protocol to ask the other end (Peer B) to dial us on our public address
          • if success, drop the circuit connection and use the newly acquired direct connection
          • if failure, continue using the circuited connection
      • if neither are true
        • continue using the circuited connection

[sequoiar]

+1 traverse FW/NAT

[VishalWaman]

+1

[achingbrain]

Closing due to staleness. The current approach is to use a combination of uPNP NAT traversal, if available, and if not to use autonat + socket timing - see https://blog.ipfs.tech/2022-01-20-libp2p-hole-punching/