Bug 279618
| Summary: | getnameinfo - IPv6 problem | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Bjoern A. Zeeb <bz> |
| Component: | bin | Assignee: | Bjoern A. Zeeb <bz> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | bz, emaste, hrs, ume |
| Priority: | --- | Keywords: | ipv6 |
| Version: | CURRENT | Flags: | bz:
mfc-stable14?
bz: mfc-stable13? |
| Hardware: | Any | ||
| OS: | Any | ||
I have a potential patch at https://reviews.freebsd.org/D45547 A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c179937b986ec3959d89bfeb8eed0a6f58a28649 commit c179937b986ec3959d89bfeb8eed0a6f58a28649 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2024-06-10 11:34:25 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-07-26 11:03:56 +0000 libc/getnameinfo: stop adding NI_NUMERICHOST where inappropriate Checking the first nibble of the IPv6 address to be 0 and then excluding two well known cases (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 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 Reviewed by: hrs Differential Revision: https://reviews.freebsd.org/D45547 lib/libc/net/getnameinfo.c | 54 +++++++++++++++++++++++++++++++--------------- 1 file changed, 37 insertions(+), 17 deletions(-) A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ff26fd77ee44de1b2a4c0a527deb6eb44c2fa238 commit ff26fd77ee44de1b2a4c0a527deb6eb44c2fa238 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2024-06-10 11:34:25 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-09-28 10:35:11 +0000 libc/getnameinfo: stop adding NI_NUMERICHOST where inappropriate Checking the first nibble of the IPv6 address to be 0 and then excluding two well known cases (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 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 Reviewed by: hrs Differential Revision: https://reviews.freebsd.org/D45547 (cherry picked from commit c179937b986ec3959d89bfeb8eed0a6f58a28649) lib/libc/net/getnameinfo.c | 54 +++++++++++++++++++++++++++++++--------------- 1 file changed, 37 insertions(+), 17 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e131c310c697aea2106728a7619cd0d41ba0d9ff commit e131c310c697aea2106728a7619cd0d41ba0d9ff Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2024-06-10 11:34:25 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-09-28 11:07:44 +0000 libc/getnameinfo: stop adding NI_NUMERICHOST where inappropriate Checking the first nibble of the IPv6 address to be 0 and then excluding two well known cases (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 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 Reviewed by: hrs Differential Revision: https://reviews.freebsd.org/D45547 (cherry picked from commit c179937b986ec3959d89bfeb8eed0a6f58a28649) lib/libc/net/getnameinfo.c | 54 +++++++++++++++++++++++++++++++--------------- 1 file changed, 37 insertions(+), 17 deletions(-) MFCed to all stable branches; next I can go and see to push the pref64 changes into review. |
6cb9418289f90 introduced a special check on the first nibble of an in6_addr: + switch (sin6->sin6_addr.s6_addr[0]) { + case 0x00: If it doesn't fall into any of the two categories it will not attempt to do name resolution and lookup the PTR because it sets NI_NUMERICHOST. I cannot see why this "else" case was ever added (and someone should dig into the KAME archives to understand). Also someone should check if POSIX says anything beyond the RFC and fully understand what is supposed to go on. Addresses with the IPv6 DNS64 default prefix 64:ff9b::/96 such as 64:ff9b::4007:8d09 (zoo) will not be resolved and that does indeed break software (e.g. postfix in an ipv6-only setup behind a NAT64). Manually calling hp = getipnodebyaddr(&sin6.sin6_addr, sizeof(struct in6_addr), AF_INET6, &h_error); will result in the correct answer from an accordingly setup resolver.