libp2p / libp2p/rust-libp2p

Add support for the `ip6zone` protocol

Open
#5,608 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
5.6k
Forks
1.3k
Avg merge
8h 47m
Merged PRs (30d)
19

Description

Description

libp2p should support Multiaddrs with the ip6zone protocol. For example, a Multiaddr like this should be supported:

/ip6/fe80::9700:803e:ca65:66e8:c21/ip6zone/wlan0/udp/12345/quic-v1
Motivation

This would enable usage of libp2p on local networks without any IP address assignment by utilizing the link-local addresses of the peers. Currently, this isn't possible, because the unix socket API requires the scope_id of a socket_addr to be set to the index of the network interface which should be used to talk to link-local IP addresses, but no libp2p transport supports this.

Requirements

Each transport that connects to unix sockets using an IPv6 address that it got from a Multiaddr (this includes at least the quic, tcp, and webrtc transports), should additionally check, if this Multiaddr also defines a zone name using the ip6zone protocol, and – if it does – should use this zone name to populate the scope_id of the socket_addr before connecting.

Open questions

No response

Are you planning to do it yourself in a pull request ?

Yes

Contributor guide

Open the contributing guide

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

Trace how the Multiaddr is converted into a socket_addr in the quic, tcp, and webrtc transports, focusing on IPv6 connection paths. Verify how an ip6zone value can populate scope_id, then test that each affected transport connects using the zone from the example Multiaddr.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
networking
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.