Add something explaining NAT traversal and what we do

This question comes up frequently. My canned response is...

We have three nat-traversal solutions at the moment.

UPnP/NATPortMap

When NAT traversal is enabled (in go-libp2p, pass the NATPortMap() option to the libp2p constructor), libp2p will use UPnP and NATPortMap to ask the NAT's router to open and forward a port for libp2p. If your router supports either UPnP or NATPortMap, this is by far the best option.

STUN/hole-punching

LibP2P has it's own version of the "STUN" protocol using peer-routing, external address discovery, and reuseport. LibP2P:

1. Uses the same source port for both dialing and listening (reuseport).
2. Receives observed address information from all connected peers (external address discovery).
3. Publishes these addresses to the network (peer routing).

• On some NATs, the first feature allows us to accept new inbound connections on the source port used by the router (the "mapped" source port).
• The second feature allows us to discover this mapped source port and our external address.
• The third feature allows us to tell the network about this external address.

TURN-like protocol

Finally, we have a TURN like protocol called p2p-circuit. This protocol allows libp2p nodes to "proxy" through other p2p nodes. Unfortunately, neither go-libp2p nor js-libp2p announce p2p-circuit addresses at the moment (by default). This means that it doesn't just automagically bypass NATs (yet).

The next steps here are to:

1. Have all nodes behind NATs connect to "hub" nodes that volunteer to act as p2p-circuit relays.
2. Announce to the network that we're accepting relay connections from these nodes.

Corporate Firewalls

While technically a different issue, this still falls under the category of working around meddlesome middle boxes.

Currently, we don't have any good ways to work around corporate firewalls. However, we have an issue (https://github.com/ipfs/go-ipfs/issues/5251) to enable the websocket listener by default on go-ipfs which will help significantly because this transport supports HTTP proxies out of the box. Note: This won't be fully solved until p2p-circuit becomes fully automatic as proxy support only allows us to dial, not listen.

Start with the issue body and the libp2p docs-old site to find the appropriate documentation location. Adapt the supplied NAT traversal and corporate firewall explanation for that location, and consider the work done when the new explanation is published and covers the listed approaches and limitations.