Hi Nenad,
On Fri, Apr 11, 2014 at 05:24:02PM +0200, Nenad Merdanovic wrote:
> >>> connect(4, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
> >>> "2a03:2880:f010:900:face:b00c:0:1", &sin6_addr), sin6_flowinfo=0,
> >>> sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
> >>> connect(4, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"},
> >>> 16) = 0
> >>> connect(4, {sa_family=AF_INET, sin_port=htons(0),
> >>> sin_addr=inet_addr("31.13.81.144")}, 16) = 0
>
> These are happening at startup only and are a direct consequence of
> using getaddrinfo().
Ah indeed I didn't notice the destination port is zero, so they're just
used to check whether the protocols are supported or not! Thanks for
enlighting me on this! So this is not a problem in practice, as we don't
care about the number of calls during the startup.
> >>> Also we need to be aware that browsers do a lot of tricks to fix IPv6
> >>> blackholes (RFC6555), while we don't.
> >>>
> >>>
> >>> By using this approach we switch from default IPv4 to default IPv6.
> >>>
>
> I do agree with Willy's approach to make best default choices, but this
> is documented in RFC 3484 (getaddrinfo() will return IPv6 first with the
> default configuration)
Yes but at the same time we definitely want *not* to break existing setups.
So we need to be very very careful on this.
> > I'm OK with using an explicit config prefix to say "I want to use
> > getaddrinfo"
> > but not to make all users suddenly get into trouble because of random
> > resolving issues leading to sometimes using IPv4, sometimes IPv6 depending
> > on the weather.
> >
>
> This might be the correct way, although I dislike doing this because for
> me it is counter-intuitive. If I said I want to use getaddrinfo() by
> setting the build flag then I should know all the implications of doing
> that (most important one being preferring IPv6).
Here, the problem is that it's not *you* who said you want to use gai(),
but it's the distro packager who set the flag for you. Don't get me wrong,
most people on this list do build themselves, but most users simply run
the package provided by their distro. I do care about them, not the skilled
people here on the list who will have no problem knowing what to do with
that.
> If you really want to work with IPv4 only in your dual-stack
> environment, you are still OK with using ipv4@ on the server line, so
> even that case is covered.
Yes but that syntax is new and still does not appear in any legacy config.
> Still, I understand what you are saying, although I find the
> getaddrinfo() to be deterministic and following RFC 3484 (in this regard).
Well, it's still possible to do something. gai() was not supported in 1.4.
So people who will notice a difference are those who would upgrade from
1.4 to 1.5 or simply from 1.5-devX to 1.5. In both cases these are not
migrations that can be done without double-checking. And if someone is
fool enough to upgrade from a major version to another one without at
least ensuring that all servers are up, he's definitely trying to get
harmed. So we could decide to use gai() by default.
But there are all the other cases. People who run code on servers they
don't manage, where gai() does not work properly or is not configured
in a way to return the same thing as ghbn(). These ones need an option
to disable use of gai(), or to force ghbn() first as we do today.
So we could have a global option to disable use of gai() even when it's
supported so that they get the original behaviour again. The common
example is ghbn() using /etc/hosts while gai() uses the DNS. For a
number of users, this might not be an acceptable change.
The reason for having this option to disable it instead of the opposite
is that it will progressively fade away and we won't have to support
such an interim option forever.
What do you think about this ?
Willy
