libp2p / libp2p/go-libp2p

Segregate routable and non-routable networks

Open
#436 46 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/enhancement P1
Dominant language
Go
Stars
6.9k
Forks
1.3k
Avg merge
13d 21h
Merged PRs (30d)
1

Description

Currently, we announce *all* IP addresses we're listening, even private ones, and will *dial* any address we find for a peer, even private ones. We do this intentionally so we can connect to nodes on our local network. Unfortunately, this causes issues like https://github.com/ipfs/go-ipfs/issues/5511 and really pisses off users (for obvious reasons).

One reasonable solution (IMO) is to segregate routable and non-routable networks. That is:

1. If we learn about a non-routable IP address from a routable network, discard it.
2. If we know a non-routable IP for a peer, only distribute it to peers with non-routable addresses.

We'll still be able to discover and dial nodes on non-routable networks through local discovery (mDNS). Additionally, if we're running IPFS on a VPN and *all* peers have non-routable addresses, everything should "just work".

This will mostly require changes to the DHT and the Identify protocol.

Future work:

* https://github.com/libp2p/notes/issues/3
* Separate DHTs? We could have a private one and a public one.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the DHT and Identify protocol implementations, tracing how peer addresses are learned, advertised, and dialed. Done means non-routable addresses learned from routable networks are discarded or restricted to peers with non-routable addresses, while local discovery and all-non-routable VPN scenarios continue to work.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
distributed-systems, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.