You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
It would be great, if
quic
(and maybe other transports as well) had support for theip6zone
protocol, so that it supports multiaddresses like these: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 asocket_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
The text was updated successfully, but these errors were encountered: