IPv6 link local addresses of a resolved service are not usable without a scope id

[hrzlgnm]

trafficstars

I've been experimenting with adding an "Open" button for services like _http._tcp in my mDNS browsing app. While doing so, I ran into a problem when resolving services that only advertise an IPv6 link-local address.

The issue is that if multiple network interfaces are present, the resolved IPv6 link-local address is essentially unusable without a scope ID. Normally, the scope ID can be inferred from the receiving interface, but I'm not entirely confident this can be done reliably in all cases.

For comparison, Avahi includes the scope (as an interface index) when resolving records, which seems necessary to make use of link-local addresses in multi-interface environments.

Would it be possible to include the scope/interface information in the resolved record?

[keepsimple1]

Interesting and a valid point. I'm not actively using IPv6 so didn't realize that.

Would it be possible to include the scope/interface information in the resolved record?

I think it's possible. If I understand this issue, that means we probably change the addresses in ResolvedService into a set of some struct that includes both IP address and also interface index.

https://github.com/keepsimple1/mdns-sd/blob/4192b1a9bdfa8cc003e2971b3a0abead481e2deb/src/service_info.rs#L1154-L1155

which also means changes in ServiceInfo to support that. I can take a look, or do you want to work on that?

[hrzlgnm]

I can look into it and start implementing it, it's not that urgent, I'll create a Pull Request when ready. The addition would also introduce a breaking change I guess. I don't know how to handle that, except bumping the version minor.

[hrzlgnm]

@keepsimple1: One point where I would need some feedback before starting: I'm not sure yet whether to use interface index or interface name to identify the scope id would be more feasible. From a non technical user perspective interface name would make more sense. But as far as I know, on windows one cannot use the interface name as a scope id (90% confident). So perhaps we could make a compromise and add both, interface name and interface index. What do you think about it?

Perhaps just reusing Interface from if_addrs would make the most sense. As it has all the interesting fields already.

[keepsimple1]

I can look into it and start implementing it, it's not that urgent, I'll create a Pull Request when ready.

Thanks for willing to look into it! Of course.

The addition would also introduce a breaking change I guess.

Most likely. But I think it's manageable in this case. Particularly for ServiceInfo we might be able to keep backward compatible. And even for ResolvedService, it's non_exhaustive so we might be able to add new field(s) first to keep backward compatible and later deprecate addresses (if desired).

Perhaps just reusing Interface from if_addrs would make the most sense. As it has all the interesting fields already.

It's an option. Upside is obvious. The downside I can see two things:

1. Currently Interface in if_addrs is per address. I.e. if an interface has 2 addresses configured, there will be two interfaces even though it's really just one interface in the host.

2. Like any dependency, we will have a long term dependency on if_addrs. What if we want to migrate to a different crate for IP address, or if their Interface has breaking changes? I know currently we have flume channel as a long term dependency, but I hope to avoid adding more.

In this case, maybe we can make our own that mimics Interface from if_addrs , and change it so that one interface struct supports multiple addresses?

[hrzlgnm]

@keepsimple1 I've started implementing it and sort of finished it in one sitting. Comments are welcome in #342

[keepsimple1]

Thanks for your PR with quick response! I'll probably take a couple of days to review, but will do.