[v6ops] getaddrinfo glitch (Re: An Update to Happy Eyeballs)

[神明達哉 <[e-mail]>]

(I suspect it's now off topic for the HE thread).

At Thu, 23 Mar 2017 11:22:15 +1300,
Brian E Carpenter <[e-mail]> wrote:

> > Perhaps of interest to this group:
> >
> > https://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/
>
> What a bizarre idea to use getaddrinfo() for format conversion, when
> inet_pton() and inet_ntop() exist.
>
> My sympathy is limited.

+1, but (as the blog itself notes) there's at least one thing that
(some implementations of) getaddrinf() can do but inet_pton() can't:
handle the extended scoped-address format as defined in RFC4007 and
set the corresponding zone index to sockaddr_in6.sin6_scope_id.

My sympathy is still limited since the blog post seems to suggest
another instance of commonly observed trap: overreaction on glitches
of one particular implementation (often that's Linux or glibc in my
biased experiences).  I suspect "talking to the kernel, and
enumerating all local IP addresses (!)" is to sort converted addresses
per RFC 6724.  Obviously it's not necessary if the purpose of the
getaddrinfo() call is to just convert textual numeric IPv6 address
into a binary form (like the case mentioned in the blog), and, as far
as I remember, BSDs implementation of getaddrinfo() doesn't do such
an obvious waste.

At the very least the blog should point to a specific poor
implementation, and, say that even if it's not an inherent defect of
getaddrinfo() itself but due to one bad implementation they should
give up using it to be portable.

--
JINMEI, Tatuya

p.s. I have no opinion about whether getaddrinfo() is a good choice
for HE.  This message is not to defend it in that context.