STUN/ICE NAT traversal

john1deer · January 14, 2019, 11:48am

Does IPFS support NAT traversal protocols such as STUN and ICE?

From a few limited tests it seems IPFS has issues with transferring files between 2 nodes both behind a NAT.

leerspace · January 15, 2019, 3:21am

libp2p uses an “ICE-like protocol”. Here are the relevant specs.

libp2p/specs/blob/master/3-requirements.md#34-nat-traversal

3 Requirements and considerations
=================================

## 3.1 Transport agnostic

`libp2p` is transport agnostic, so it can run over any transport protocol. It does not even depend on IP; it may run on top of NDN, XIA, and other new Internet architectures.

In order to reason about possible transports, `libp2p` uses [multiaddr](https://github.com/multiformats/multiaddr), a self-describing addressing format. This makes it possible for `libp2p` to treat addresses opaquely everywhere in the system, and have support for various transport protocols in the network layer. The actual format of addresses in `libp2p` is `ipfs-addr`, a multiaddr that ends with an IPFS node id. For example, these are all valid `ipfs-addrs`:

```
# IPFS over TCP over IPv6 (typical TCP)
/ip6/fe80::8823:6dff:fee7:f172/tcp/4001/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over uTP over UDP over IPv4 (UDP-shimmed transport)
/ip4/162.246.145.218/udp/4001/utp/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over IPv6 (unreliable)
/ip6/fe80::8823:6dff:fee7:f172/ipfs/QmYJyUMAcXEw1b5bFfbBbzYu5wyyjLMRHXGUkCXpag74Fu

# IPFS over TCP over IPv4 over TCP over IPv4 (proxy)

This file has been truncated. show original

john1deer · January 15, 2019, 8:14am

Is ICE (like) implemented, though?

I don’t think I ever saw a uTP address, and files do not seem to be accessible when both machines are behind a NAT.

leerspace · January 16, 2019, 2:19am

That would be because uTP isn’t supported.

I haven’t looked into it much, so I’ll leave it to someone else to comment on the current implementation details of NAT traversal for go-ipfs.

Relays are implemented which would help situations where both nodes are behind a NAT, but automatic relay node discovery isn’t yet.

john1deer · January 21, 2019, 11:59am

Thanks.
Seems QUIC is preferred over uTP, which is fine. It’s a UDP-based protocol and in principle all the hole-punching and other NAT traversal methods should be supported.

Unfortunately, seems QUIC is “experimental” and doesn’t seem to support NAT traversal (automatic gateway discovery is only available on the “dev” branch, for example).

NAT traversal seems like a basic requirement for a P2P decentralized protocol.

leerspace · January 21, 2019, 12:27pm

I don’t think you’ll find many (any?) who disagree with this. However, go-ipfs is currently beta software so it’s not surprising that not everything is implemented yet.

john1deer · January 21, 2019, 2:28pm

Work in Progress

Another related question: it seems like IPFS requires each node to connect directly (up to a relay) to the peer with the required block. But, if my node requires a block - why can’t it ask one of its current peers to retrieve that block on its behalf (it will be “paid” via BitSwap for the service)? As long as a route to the block exist, it will be accessible. As a bonus, peers can cache the block (this again can make sense - next time the block is requested, there’s no need to “pay” for it via BitSwap).

I think that 1970s email store & forward worked in a similar fashion…

leerspace · January 21, 2019, 3:02pm

It’s also open source though so if someone who knows what they’re doing wants to implement/enhance it I’m sure that would be welcome if they coordinate with the core devs .

I think this is almost the same as the original idea for how IPFS would work. However, if there is a node requesting illegal or immoral content, it shouldn’t be allowed to indirectly make other nodes also request that same content on its behalf. Nodes should be allowed to choose what they’re storing and providing.

john1deer · January 21, 2019, 10:03pm

I can understand the rationale behind this. However, this hurts the network as a whole. A node could refuse to cache some or all content if it likes (it could be penalized - i.e. via BitSwap - but this is an acceptable tradeoff).