STUN/ICE NAT traversal

john1deer 2019-01-14 11:48:33 UTC #1

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 2019-01-15 03:21:46 UTC #2

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 2019-01-15 08:14:46 UTC #3

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 2019-01-16 02:19:56 UTC #4

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 2019-01-21 11:59:55 UTC #5

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 2019-01-21 12:27:46 UTC #6

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 2019-01-21 14:28:02 UTC #7

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 2019-01-21 15:02:37 UTC #8

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 2019-01-21 22:03:26 UTC #9

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).