I think I have already addressed all your points below, no need to
rehash endlessly. I'll let others chime in.
I'm still very interested in any real-world problems this might have caused.
Simon
Le 2014-05-02 11:35, Jérémie Courrèges-Anglas a écrit :
> Simon Perreault <si...@per.reau.lt> writes:
>
>> Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit :
>>> Let's say you have a machine with no IPv6 address configured (or rather,
>>> only link-local addresses configured and ::1 on lo0). With the
>>> AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
>>> passes no hints structure):
>>>
>>> - getaddrinfo("fe80::...%em0") fails with "no address associated with name"
>>> - getaddrinfo("::1") fails similarly
>>> - more generally, getaddrinfo("numeric IPv6 address") fails with "no
>>> address associated with that name"
>>> - getaddrinfo("localhost") now requires IPv4/v6 connectivity on non-lo
>>> interfaces. oops.
>>>
>>> All those are IMHO poor behavior (lies), especially since getaddrinfo is
>>> supposed to handle pretty much anything you're throwing at it.
>>
>> I think you need to change your expectations.
>
> I don't think that any of the failing examples given above can qualify
> as "reasonable expectation".
>
>> If you're running on a host without IPv6, why would you want
>> getaddrinfo() to return any IPv6 results? What good would it do to you?
>
> What's a regular OpenBSD host with no IPv6? I'd assume that it is
> a host that can perform IPv6 connections to ::1 / localhost and reach
> its neighbors through link-local addresses. It is certainly not a host
> that has been butchered by removing option INET6 or removing all
> automatically configured IPv6 address (link-local / lo0).
>
> If you pass a raw IPv6 address to getaddrinfo, is "no address associated
> with name" a reasonable result?
>
>> AI_ADDRCONFIG is all about what it *returns*. The fact that it allows
>> skipping DNS AAAA requests is a nice side-effect.
>
> Yet people use it for this side-effect, else why would you propose to
> make the base programs use it (explicitely) as a way to mitigate the
> impact of switching to "family inet6 inet4" by default?
>
>> If your program needs to resolve addresses for the sake of resolving
>> addresses, and you want accuracy,
>
> I think that I've clearly explained that it is more than mere accuracy.
>
>> you need to explicitly unset
>> AI_ADDRCONFIG. You're writing something special. In the general case,
>> where you will just connect() or bind() on the returned addresses,
>> AI_ADDRCONFIG makes sense as is.
>>
>> Has this caused any real-world problems?
>
> All the examples I've listed above are cases where programs that used no
> hints will now fail. I think they're valid, real-world cases.
>
