From owner-svn-src-all@FreeBSD.ORG Fri Aug 3 04:18:24 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20E15106566C; Fri, 3 Aug 2012 04:18:24 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 5C87E8FC0C; Fri, 3 Aug 2012 04:18:23 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q734I6Ax047814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 13:18:17 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q734I6wb071548; Fri, 3 Aug 2012 13:18:06 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 03 Aug 2012 13:17:46 +0900 (JST) Message-Id: <20120803.131746.1643150967050340012.hrs@allbsd.org> To: emax@FreeBSD.org From: Hiroki Sato In-Reply-To: <20120803.124305.1981901625663633450.hrs@allbsd.org> References: <501AF66A.8020804@FreeBSD.org> <20120803.124305.1981901625663633450.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Aug__3_13_17_46_2012_949)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 03 Aug 2012 13:18:17 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, dougb@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r238622 - head/etc/rc.d X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 04:18:24 -0000 ----Security_Multipart(Fri_Aug__3_13_17_46_2012_949)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20120803.124305.1981901625663633450.hrs@allbsd.org>: hr> Maksim Yevmenkin wrote hr> in : 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 ----Security_Multipart(Fri_Aug__3_13_17_46_2012_949)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlAbUOoACgkQTyzT2CeTzy0ECwCg3PSWvaFc6W9mSklO6dt/D1x4 rQ4AoKoVIpTnKPrEInLKTaTgf0LeVdxq =GBkx -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Aug__3_13_17_46_2012_949)----