Quoth Hajimu UMEMOTO <u...@freebsd.org>: > Hi, > > >>>>> On Wed, 9 Jan 2013 16:29:00 +0000 > >>>>> Ben Morrow <b...@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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
