libc/getnameinfo: stop adding NI_NUMERICHOST where inappropriate

[bz]

Summary

Checking the first nibble of the IPv6 address to be 0 and then
excluding two wellknown (v4-mapped, loopback) leaves us with more
cases where the first nibble could be 0, e.g., the RFC 6052, 2.1
Well-Known Prefix 64:ff9b::/96.
It is not practical to track them all and it is not clear what lead
to this special casing originally, so remove them.

While here handle the IN6_IS_ADDR_UNSPECIFIED() directly and
also remove the IN6_IS_ADDR_LINKLOCAL() + NI_NUMERICHOST case as
link-local address resolution does exist.

We do leave the IN6_IS_ADDR_MULTICAST() case for now as I could
not find any references to any official reverse lookups for these.

Adding comments for more case (and some historic behaviour) in order
to make it easier to follow the logic.

PR: 279618
Fixes: 6cb9418289f90
MFC after: 6 weeks

[bz]

lib/libc/net/getnameinfo.c

256

@emaste : I found that OpenSSH (sshd) on boot fails (likely on this):

sshd[1881]: error: getnameinfo failed: Name does not resolve

It would still listen on IPv4 if we'd support that address family:
root sshd 1881 3 tcp4 *:22 *:*

So I assume it's the call in crypto/openssh/sshd.c::listen_on_addrs()

I wonder if the "but not return an appropriate error" bit was intentional or early days and "POSIX" later changed it or if I am misreading this altogether or if this a bug in opeensh?

[bz]

Add Ed for the OpenSSH dependency (problem).

lib/libc/net/getnameinfo.c

253

insoert .... "does " not return

[bz]

lib/libc/net/getnameinfo.c

236

Turns out their frames got me to the 2004 version at some point; the behaviour has changed in the 2017 version of course; that explains the problems now seen.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/getnameinfo.html

[bz]

Update based on 'The Open Group Base Specifications Issue 7, 2018 edition'
as per updated link in the description.

[hrs]

Removing the NI_NUMERICHOST flag except for multicast addresses looks good to me.

I have been using a similar patch locally in order to use reverse mapping of fe80::/16 for a long time, but I have not experienced any regression. While "::1" will generate a lookup of /etc/hosts (or DNS if "::1" was not defined in the file) after this patch, the overhead is trivial and this behavior is more aligned with IPv4.