I'm trying to follow up on Ubuntu Launchpad bug #369008, in which mDNS IPv6 look-ups don't get the scope ID. There is a patch for nss-mdns which makes it work by implementing _nss_gethostbyname4_r(), which is the only way to pass through the IPv6 scope ID. However, while it works for lookups with family AF_UNSPEC, it doesn't work for family AF_INET6. It turns out that getaddrinfo() is calling _nss_gethostbyname4_r() only for lookups with family AF_UNSPEC. But for family AF_INET6, it is calling _nss_gethostbyname2_r() instead. It really should always call _nss_gethostbyname4_r() for any IPv6 look-ups, in order to get the IPv6 scope ID. It used to work, however, I've traced the problem to glibc git commit 8479f23aa1. http://repo.or.cz/w/glibc.git/commit/8479f23aa1d5e5477a37f46823856bdafaedfa46 In that commit, it was changed to only use _nss_gethostbyname4_r() for AF_UNSPEC, and not AF_INET6. That breaks IPv6 scope ID retrieval. Can we revert that change?
By the way, Ubuntu Launchpad bug #369008 "mdns lookups fail over ipv6" affects look-ups of Zeroconf ".local" names through mDNS. Zeroconf is "zero configuration networking" and that's the application in which IPv6 scope ID is most important--where you want to plug things together and have it "just work". On a network without assigned IPv6 addresses, IPv6 Unique Local Addresses (ULA) are used, and it's necessary to have scope ID look-ups working to be able to communicate to the IPv6 ULA. With nss-mdns working (patched from the above Ubuntu Launchpad bug), it's possible to do: telnet mycomputername.local (it uses a family AF_UNSPEC look-up, which works) But due to this bug, on a network without assigned IPv6 addresses (ULA only) it's not possible to do: telnet -6 mycomputername.local ping6 mycomputername.local (it uses a family AF_INET6 look-up, which doesn't work with IPv6 ULA because scope ID is missing)
Are there any plans to address this issue? Is there any information missing that blocks fixing this (5 year old) issue?
Any updates on this?
(In reply to Craig McQueen from comment #3) > Any updates on this? For most core library issues it isn't that information is missing, but that a motivated developer needs to step up to help with the work. There is no one working on this issue that I know of (note the issue is not yet assigned). Someone would have to look at bug 14505 and reconcile why the change was made. Simply reverting the change is insufficient since it would regress bug 14505. After an analysis of both bugs is made a subsequent fix needs to be decided and posted to libc-alpha following the contribution checklist: https://sourceware.org/glibc/wiki/Contribution%20checklist
is the nss API documented anywhere ? do we have a callback that'd provide IPv6-only resolution ? or do we need to add one ?
(In reply to Mike Frysinger from comment #5) > is the nss API documented anywhere ? There is a section in the manual. > do we have a callback that'd provide > IPv6-only resolution ? or do we need to add one ? struct gaih_addrtuple (which is used by the version 4 name lookup API) contains a scope ID. I have not checked if it is properly propagated up to the application. nss_files does not used it; we could fix that as a first step.
(In reply to Mike Frysinger from comment #5) > do we have a callback that'd provide IPv6-only resolution ? The API <4 can do IPv6-only but it doesn't support returning scope IDs. The API 4 supports that but doesn't support IPv6-only resolution. > or do we need to add one ? Bug #14413 requested that.