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.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
