IPv6 lookup adds scope ID for global scope addresses

[kc2zgu]

IPv6 addresses returned always have an scope ID set, even for global scope addresses that should not have one. This is benign in some cases, but breaks mount.nfs due to the way it passes the address string to the kernel.

[kc2zgu]

Possible fix (unset scope ID for addresses that don't start with fe80): kc2zgu@660b877

[lathiat]

While not strictly necessary, I don't believe this is invalid and it's entirely possible to have two interfaces with the same subnet and to therefor want this functionality. I think probably the interface using this should be improved to handle this. Ideally the kernel would handle the syntax or worst case the user-space part would strip it if for some reason the kernel can't be fixed. For example without this functionality you couldn't mount NFS from a link local IP - so there's clearly a feature gap.

I'm happy to reconsider if you have good evidence that either this is not supposed to happen this way or other wide spread breakage. But I think fixing the applications would be better.

I have noticed that generally speaking hostname%index isn't working everywhere such as gethostbyname and I'd like to fix that system wide. Can you give me a few more details on the error you get and the exact software versions you are using. I'm happy to look at assisting to fix the kernel/NFS side instead.

[kc2zgu]

My assumption was that the scope/interface ID is only used on link-local addresses since you don't generally have multiple interfaces going to the same subnet (unless there's some use for that with IPv6 - every time I've seen two copies of the same network in the routing table it's some kind of configuration error). I'm not sure if it's more correct to have gethostbyname omit the scope for global addresses or for applications to accept it in all cases. Most seem to accept it.

The error I get from the NFS client is "NFS: bad IP address specified: addr=2604::[redacted]::62eb%2" when trying to mount a path like "my-nfs-server.local:/share" when nss_mdns is used for the lookup. The "%2" is the problem.

In my patch I added a check for link-local addresses so the scope ID would be included in that case. I wasn't able to test this though since I don't have a network handy with mdns hosts and no global IPv6 addresses. I don't know all the details though of how this is supposed to work with the sockets API so it's possible I'm barking up a completely wrong tree.

I get the same behavior on a Gentoo system with nfs-utils-2.4.2 and a 4.14 kernel as well as Fedora with 2.4.1 and 5.3. mount.nfs probably behaves a little differently from most pure userland applications since it passes the returned address in the mountaddr option to the kernel as a string instead of feeding it to one of the socket functions.

[chrysn]

If an address is globally unique, no zone identifier should be present. As mentioned, this is mostly benign, but causes confusion all around (the mentioned NFS topic; and SSH prints a line like Warning: Permanently added the ECDSA host key for IP address '2a02:...%189' to the list of known hosts. every time your interface identifier changes).

I don't fully understand the underlying IPv6 Scoped Address Architecture, but the literature on it suggests that ZoneIDs on non-link-local addresses are to be avoided ("Note that the behaviour of an IPv6 stack, if it is passed a non-null zone index for an address other than link-local, is undefined.")

[Neustradamus]

Have you progressed on this ticket?