1

I want to connect to a link-local IPv6 service represented by an NsdServiceInfo. The service is announced in the LAN via zeroconf. Therefore I need the scope ID in addition to the IP (i.e. to create "<IPv6>%<scope ID>"). However, I could not find a way to retrieve the scope ID (i.e. the network interface through which the service was discovered) out of the NsdServiceInfo. For now, as an ugly workaround, I iterate over all network interfaces and check reachability of the server IP using NsdServiceInfo#getHost()#isReachable().

BTW NsdServiceInfo#getHost()#getScopeId() and NsdServiceInfo#getHost()#getScopedInterface() do always return 0 and null respectively.

Am I missing something here or is there actually no straight forward solution to this?

Wave
  • 61
  • 6
  • The Scope ID is only used for Link-Local addressing. RFC 6874 explains: "_To limit this risk, implementations MUST NOT allow use of this format except for well-defined usages, such as sending to link-local addresses under prefix fe80::/10. At the time of writing, this is the only well-defined usage known._" – Ron Maupin Sep 17 '21 at 17:16
  • @RonMaupin As far as I understand link-local addressing should be the usual case for zeroconf networks? – Wave Sep 17 '21 at 17:51
  • Traffic sent to a link-local address cannot be routed off the link to a different network. It is only useful to communicate with devices on the same LAN. – Ron Maupin Sep 17 '21 at 17:53
  • RFC 4291 explains link-local addressing: "_Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present. Routers must not forward any packets with Link-Local source or destination addresses to other links._" – Ron Maupin Sep 17 '21 at 17:56
  • So communicating on the same LAN is exactly my goal. I have a service which is announced in the LAN via zeroconf. Now my client discovers this service and wants to connect to the corresponding server. However, NsdManager does service discovery on all network interfaces at the same time and (to my knowlegde) does not provide the information on which interface it discovered a specific service. This is why I have to check every interface if it is the one where the link-local service is available. – Wave Sep 17 '21 at 18:06
  • Just use multicast. IPv6 has a great multicast environment and makes heavy use of it (having eliminated broadcast). Multicast works great for service discovery. Send announcements to a specific multicast group (there are multicast scopes, including link-local) and the clients can listen for the multicast announcements on the multicast group you have defined for the service. There really is no other way to make announcements since there is no broadcast, and you do not need to worry about the Scope (really called Zone) ID. – Ron Maupin Sep 17 '21 at 19:21
  • I am using the dns_sd.h compatibility header of Avahi to announce the service on the server, which actually uses multicast. However, I cannot specify the multicast scope with it, so it implicitly uses link-local i guess. In NsdManager I cannot specify the multicast group either. Regarding multicast, the following is stated in NsdManager's documentation: "The API currently supports DNS based service discovery and discovery is currently limited to a local network over Multicast DNS." – Wave Sep 17 '21 at 21:38
  • Using multicast, even link-local multicast does not use a Zone ID. The Zone ID is for link-local unicast (`fe80::/10`). Link-local multicast is in the `ffX2::/112` range. – Ron Maupin Sep 20 '21 at 01:47

0 Answers0