Created attachment 14951 [details] Reproducer code While writing a procedure that validates IP addresses by using getaddrinfo I noticed the following inconsistencies when it comes to addresses with a zone index: An existing interface … … as a numeric value: 2001:db8::1%2: getaddrinfo: OK fe80::1%2: getaddrinfo: OK … as an interface name: 2001:db8::1%enp4s0: getaddrinfo: Name or service not known fe80::1%enp4s0: getaddrinfo: OK An absent interface… … as a numeric value: 2001:db8::1%9999: getaddrinfo: OK fe80::1%9999: getaddrinfo: OK … as an interface name: 2001:db8::1%foobar: getaddrinfo: Name or service not known fe80::1%foobar: getaddrinfo: Name or service not known I've included a small reproducer example below. (regarding the absent interface cases, I've no opinion on what behavior to expect here.) It strikes me as odd that the "2001:db8::1%enp4s0" case is treated differently on the basis of its prefix (compared to "fe80:…"). Although at the moment only link-local and multicast scopes have defined meaning [RFC4007], within the Introduction of the same RFC it states: … the IPv6 working group decided to … and is now investigating other forms of local IPv6 addressing. If I understood correctly this means that zone indexes should not be preferentially handled on basis of prefix since other scopes might be introduced later. In any case, I think that getaddrinfo should handle "2001:db8::1%enp4s0" in the same way it handles "2001:db8::1%2". Allowing %2 but not %enp4s0 is just massive hair-splitting. (especially when %2 happens to match %enp4s0)
This restriction in __inet6_scopeid_pton was carried over from the previous code in the fix for bug 20611 (commit 80d8cb91dee8bdcc4e430b3e2620d95f89b1ee0b) and enhanced to cover more addresses in bug 21657 (commit f768b450204f54b080ea5dc5c2071940604b424c). The original restriction goes back to the initial change circa 2000, citing the “to follow latest RFC draft”. We can probably drop that restriction.