Hiroki Sato <h...@freebsd.org> wrote in <20120803.124305.1981901625663633450....@allbsd.org>:
hr> Maksim Yevmenkin <e...@freebsd.org> wrote hr> in <CAFPOs6pM8qrR72kOtZzO90wYembNrtzw7=ig-nsfudjza7b...@mail.gmail.com>: hr> hr> em> of course :) we have ipv4 systems in production that make use of hr> em> getaddrinfo(3) api. when a particular dns name is resolved, and, hr> em> multiple A records are returned, the results get sorted according to hr> em> the "default" address selection policy. rfc3484 has a set of rules hr> em> according to which results should be sorted. all of the rules do not hr> em> apply in our case, except one - the rule #9. the idea is that ipv4 hr> em> addresses are "converted" to ipv6 addresses and then longest prefix hr> em> match sorting is applied. in other words, if your system ip address hr> em> happens to share high bits with the ip address from the A record, the hr> em> IP address from the A record will always be preferred. of course, hr> em> longest prefix match is performed without any extra information such hr> em> as netmask and/or cidr. it really is just matching high bits of the hr> em> address. hr> em> hr> em> so, what we found out, is that some systems tend to favor a particular hr> em> ip address (from a bunch of ip addresses returned by name resolution) hr> em> because 4 high bits were the same. basically, round-robin dns was hr> em> completely shot. hr> hr> Is that issue solved by applying the attached patch and setting hr> net.inet6.ip6.longestmatch_mapped=0? hr> hr> I do not think it is a good idea to use the empty rule to solve it hr> because if the system has to support IPv6 as well the empty rule has hr> negative effect. Adding flag to the IPv4 address line in the policy hr> or adding a sysctl sounds a reasonable solution to me. Gr, I got a wrong idea about the issue. What you want is to disable longest match in the dest addr selection. It needs a change in comp_dst() in getaddrinfo.c. -- Hiroki
pgpM52YBIlDkS.pgp
Description: PGP signature
