Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Aug 2012 06:23:01 +0200
From:      John Hay <jhay@meraka.org.za>
To:        Hiroki Sato <hrs@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, dougb@FreeBSD.org, emax@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r238622 - head/etc/rc.d
Message-ID:  <20120803042301.GA78461@zibbi.meraka.csir.co.za>
In-Reply-To: <20120803.124305.1981901625663633450.hrs@allbsd.org>
References:  <CAFPOs6rHmMPca7Xzhng82b17RPZObCCP64x%2BHPEBvf7%2BwK3pnQ@mail.gmail.com> <501AF66A.8020804@FreeBSD.org> <CAFPOs6pM8qrR72kOtZzO90wYembNrtzw7=ig-NSfudJZA7bp6Q@mail.gmail.com> <20120803.124305.1981901625663633450.hrs@allbsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

While you guys are here, may I add a request that we go back to prefering
IPv6 when IPv6 addresses are enabled. That is the way it was from FBSD-4
up to FBSD-8. 9 is a big POLA here. The world is past World IPv6 Launch
and I think people expect that if they configure IPv6 addresses, that
would be prefered. If you configure IPv6 addresses and do not want them
prefered, you are the odd one out and should have to do something.

Otherwise when in the future are we going to change it?

my 2cents

John
-- 
John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org

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








Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120803042301.GA78461>