Open Zollerboy1 opened 1 month ago
The biggest questions will resolve around how these addresses should be handled when they are transferred to other peers.
When listening on an address like this, we should just listen on the specified ip6zone
.
This seems trivial 👍
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 ❓
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. ☑️
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: https://github.com/libp2p/rust-libp2p/pull/5609