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.
libp2p uses an “ICE-like protocol”. Here are the relevant specs.
https://github.com/libp2p/specs/blob/master/3-requirements.md#34-nat-traversal
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.
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.
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.
1 Like
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.
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…
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.
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).