[Bug network/30604] New: Inconsistent getaddrinfo zone-index handling

[Bug network/30604] New: Inconsistent getaddrinfo zone-index handling

[mirai at makinata dot eu]

https://sourceware.org/bugzilla/show_bug.cgi?id=30604

            Bug ID: 30604
           Summary: Inconsistent getaddrinfo zone-index handling
           Product: glibc
           Version: 2.37
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: mirai at makinata dot eu
  Target Milestone: ---

Created attachment 14951
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14951&action=edit
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)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/30604] Inconsistent getaddrinfo zone-index handling

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30604

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=20611,
                   |                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=21657
                 CC|                            |fweimer at redhat dot com

--- Comment #1 from Florian Weimer <fweimer at redhat dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.