sendmail vs ipv6 broken after upgrade to 9.1

[Ben Morrow]

Quoth Hajimu UMEMOTO <ume at FreeBSD.org>:
> Hi,
> 
> >>>>> On Wed, 9 Jan 2013 16:29:00 +0000
> >>>>> Ben Morrow <ben at morrow.me.uk> said:
> 
> ben> Where does it say that? All I can find (but I might be being stupid) is
> ben> the bit in the description of AI_ALL where it says 'A query is first
> ben> made for AAAA records and if successful, the IPv6 addresses are
> ben> returned. Another query is then made for A records and any found are
> ben> returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant
> ben> to indicate the AAAA results are returned first in the list, just that
> ben> both sets of results are included.
> 
> It is the sentence you mentioned.  It was not thought those days that
> a query order and an order of the value to return were another.  So, I
> think that it implies the order of the value to return.

OK. Since this is a legacy API, the real question is 'what do existing
applications calling it expect?'. You may be right that they will expect
to see IPv6 addresses first if there are any.

> ben> Also, RFC 6724 (which is more recent), says 'we intend that
> ben> implementations of APIs such as getaddrinfo() will use the destination
> ben> address selection algorithm specified here to sort the list of IPv6 and
> ben> IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()'
> ben> is supposed to include getipnodebyname and gethostbyname2, and the whole
> ben> list of v4 and v6 addresses is supposed to be sorted by those rules.
> 
> I thought so at the time when I implemented it.  However,
> getipnodebyname has IPv4-mapped addresses issue as compared with
> getaddrinfo.
> Since gethostbyname2 doesn't treat multiple families at once, it is
> out of scope, IMHO.  gethostbyname2 in FreeBSD doesn't obey
> ip6addrctl.

ip6addrctl does more than just order v4 vs v6: it also sorts the v6
addresses, in a way which can be quite important. IMHO both the v6
addresses returned from getipnodebyname and the addresses returned from
gethostbyname2(AF_INET6) ought to be sorted according to ip6addrctl,
even if getipnodebyname special-cases the v4-mapped addresses to appear
last.

> ben> However, given that FreeBSD disables the use of v4-mapped addresses on
> ben> AF_INET6 sockets by default, it might be sensible to change the rules a
> ben> little. An application making an AF_INET6 query is probably going to use
> ben> the result with an AF_INET6 socket, so a v4-mapped address is going to
> ben> be mostly useless.
> 
> There is IPV6_V6ONLY socket option.  Still, an application has two
> choices:
> - convert IPv4-mapped address to IPv4 address, or
> - issue IPV6_V6ONLY socket option.
> In anyway, I think it is important that an application conscious of
> using the IPv4-mapped address.

Yeah; I agree that the v4-mapped option is pretty useless (even when
using a stack which supports it). I suspect the IETF people were trying
too hard to account for the case of a v6-only stack talking to the v4
Internet, when AFAIK there aren't any v6-only stacks yet, nor are there
likely to be for the forseeable future. That's why I think Sendmail
ought to be changed to pass 0 flags, so it doesn't see v4-mapped
addresses at all: after all, there's little point binding separate v4
and v6 sockets if the v6 socket is just going to end up bound to a
v4-mapped address.

> > I've just committed to disable it:
> > 
> > http://svnweb.freebsd.org/base?view=revision&revision=245225
> 
> ben> I don't think that's the right answer. Even if the code should be
> ben> changed to always return addresses from A records last, the IPv6
> ben> addresses from AAAA records should still be sorted according to
> ben> ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix
> ben> and a global prefix) won't be able to control their use properly.
> 
> getipnodebyname was deprecated by RFC 3493 and appropriate time has
> passed since then.  So, it is low-priority, IMHO.

Well, if important applications like Sendmail are still using it it's
probably important it works consistently with the rest of the system's
IPv6 support. I'd rather see it removed, or reimplemented as a wrapper
around getaddrinfo, than left in a broken state.

Ben