Alternative towards mDNS

[philsbln]

Hi,

in cases where mDNS is not available, e.g. constrained router bootstrap, an alternative input method would be useful.
I see no reason why this could not be done within the hosts' resolver stack.
By using a pseudo-domain, e.g. ll-ip6.arpa and composing the name by concatenating address in rfc5952 format with dashes prepended by the local interface name.
So fe80::23:42 on en5 becomes en5.fe80--23-42.ll-ip6.arpa.

The advantage of this representation is that it does not need any change to the client application (assuming it uses the OS's resolver and the scope id in sockaddr_in6 is not bleached) and plays well with the same-origin policy.

From a web app/server perspective, it is the same as answering to all names of a wildcard DNS record.

Interest for a PR proposing that?

[DavidSchinazi]

Hi Philipp, can you elaborate on your use case? As far as I know, any constrained device that implements HTTP has sufficient resources to also implement responding to mDNS resolution requests.

[philsbln]

I have seen several corporate and event networks where mDNS was explicitly filtered and debugging of IoT equipment via a built-in web interface was necessary.

[DavidSchinazi]

Generally this kind of managed network uses DHCPv6 to centrally assign a routable address to each device. Additionally, these managed networks are generally large - the whole reason to manage the network is because it is large enough to span multiple broadcast domains - so link-local addresses probably won't work between your browser and the IoT device. What am I missing?

[philsbln]

You are missing the contractor flied engineer of the AV company fixing the conference system or smart doorplate, who has been given L2-access to the network, but has no access to the whole management architecture and has no leverage.
Link-Local addressing will be this last resort, e.g., to enable DHCPv6.

[DavidSchinazi]

I'm assuming that by "to enable DHCPv6" you mean "to enable the DHCPv6 client on the conference system". In this scenario, how does the contractor know what link-local address to use to connect to the conference system?

[philsbln]

Most probably "printed on the backside of the system" or "displayed on the system itself"

[DavidSchinazi]

Do you have examples of such a device? I was under the impression that we'd moved away from EUI-64 in favor or randomly-generated link-local addresses

[philsbln]

As this does notation does not exist yet, there are none.
Today, these kind of embedded devices are often still IPv4 only and use hardcoded fallback addresses if DHCPv4 fails. If they are modern, they may have implemented EUI-64 LL and do SLAAC.
I don't argue that this is better than mDNS, just that there is a small use case for accessing web-interfaces of devices with link-local addresses from a browser – especially when people filter or turn off mDNS.

I have indeed recovered some routers and switches by creative use of link-local addresses (in all cases using EUI-64 addresses) – luckily I did not need a web browser but could use SSH.

[DavidSchinazi]

Thanks for the details. I think you're right that this use case exists, even if it's incredibly rare. Given the rarity, I don't think it makes sense to put machinery in DNS resolver stacks to handle it. It would be aspirational in the same way that RFC 6874 was, and most likely won't get implemented.