Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ip6zone protocol in quic transport #634

Open
Zollerboy1 opened this issue Sep 23, 2024 · 1 comment
Open

Add support for ip6zone protocol in quic transport #634

Zollerboy1 opened this issue Sep 23, 2024 · 1 comment

Comments

@Zollerboy1
Copy link

It would be great, if quic (and maybe other transports as well) had support for the ip6zone protocol, so that it supports multiaddresses like these:

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

This would enable usage of libp2p on local networks without any IP address assignment by utilizing the inherent 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.

Ideally, quic would support interface indices and on Unix systems additionally network interface names as the value of ip6zone.

I have a working prototype of this over at the rust implementation: libp2p/rust-libp2p#5609

@umgefahren
Copy link

The biggest questions will resolve around how these addresses should be handled when they are transferred to other peers.

Listening

When listening on an address like this, we should just listen on the specified ip6zone.

This seems trivial 👍

Interaction with protocols

Kademlia

Since addresses known to Kademlia are shared with peers in potential different network configurations these addresses are not useful. How should that be handled? Should we just strip the address of the ip6zone?

I would consider this the biggest question ❓

Identify

Different to Kademlia, it might be good to care about ip6zone in identify. If we have observed an address of a peer while listening on a specified ip6zone we know that this peer is routable through this zone. Especially in configurations that contain IPv6 ULA it might be the only way to dial ULA addresses that we learnt organically.

From where I stand, this seems pretty clear, but there might be pitfalls. ☑️

AutoNAT (v2)

These questions are kind of adjacent to the Kademlia ones. How should servers and clients handle these addresses?
ip6zone might be the ones a peer observes (from the listener itself or others) and it also might be the only routable address, but we don't know anything about the servers network configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Triage
Development

No branches or pull requests

2 participants