@marten-seemann

As an example, an IoT node before IP is set can use it to communicate via p2p.
IPv6 link-local address can be used even if a static IP is not set.
In this case, you can communicate by searching for each other using mdns, etc. within the local network.

Since link-local address cannot be used on the Internet, it was intentionally excluded from announce.

What do you mean by „before the IP address is set“? Are you referring to DHCP?

How would and ip6zone address passed to the TCP transport look like?

@marten-seemann
To be exact, it is an environment without DHCP. In an environment with DHCP, there is no need to use link-local address.
e.g. /ip6zone/eth0/ip6/fe80::3811:2aff:fe94:adbe/tcp/1234

Can you just advertise /ip6/fe80::3811:2aff:fe94:adbe/tcp/1234? For the peer, it’s irrelevant that it’s on your eth0 interface, right?

@marten-seemann Currently, link-local addresses are intentionally excluded from basic_host.
Is there a reason to announce it? A link-local address is only useful if the receiving party can determine the listening interface, such as mdns.
I thought it would be a good idea not to advertise unnecessary addresses. Still, is it better to advertise?

A link-local address is only useful if the receiving party can determine the listening interface, such as mdns.

I don't understand how this would work. What is configured to be eth0 is only relevant to me, not to the remote node. Therefore, we should never advertise it.

Please don't reply here. Let's move discussion of this back to the issue: #2659.

I'm adding the blocked label here, since there's little point in moving this PR forward until we've resolved libp2p/zeroconf#35.

Once that has been done, we still need to decide if support IPv6 link-local is something we want to do, see #2659 (comment).