From owner-svn-src-all@FreeBSD.ORG Thu Aug 2 22:22:36 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 7FC7F1065670; Thu, 2 Aug 2012 22:22:36 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D289E8FC0A; Thu, 2 Aug 2012 22:22:35 +0000 (UTC) Received: by qcsg15 with SMTP id g15so28816qcs.13 for ; Thu, 02 Aug 2012 15:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UyTPVOGV9UoS9BfsRteKmNfukSJqUGxHGVXIPwT7kcY=; b=aemCLGfFPaXWw1qzQuypELqZVSN5yPoaVcIGlbFmSOVo7QIyGvZjQiy4mbfYwG+TtY Sjqg/yJzNmRAgFp/cphmu+GpmLcqUm1A1clemx+mUfj4aMAsVy4zSApw34wjrWi5tPSS iQCGWlQrxojNz/Xm/rr9uMmuTs2CFmCqzstFDvBQ8nBmd2FCnqxGSKWcpbUdgm4mDUjS 4eMwenDpu7YMBmVhvorhuWoRbVdRuaxcRPRnxLCQlX7xbTAmIT0BWkom6+d24037EeHi ah+WOv/4X2ZP3/I0bsNayUbA6vm2dhSsbgEOMOzgkr8l5VDe3eejxfNTE0U19WBDSvZZ 18mA== MIME-Version: 1.0 Received: by 10.224.194.1 with SMTP id dw1mr44951960qab.27.1343946155029; Thu, 02 Aug 2012 15:22:35 -0700 (PDT) Sender: maksim.yevmenkin@gmail.com Received: by 10.224.216.72 with HTTP; Thu, 2 Aug 2012 15:22:34 -0700 (PDT) In-Reply-To: <501AF66A.8020804@FreeBSD.org> References: <201207191536.q6JFabOR094467@svn.freebsd.org> <20120803.055554.1380323232583218022.hrs@allbsd.org> <501AF66A.8020804@FreeBSD.org> Date: Thu, 2 Aug 2012 15:22:34 -0700 X-Google-Sender-Auth: kXX_qhn8HdTAdMruGmAtSRG2Cg8 Message-ID: From: Maksim Yevmenkin To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Hiroki Sato , 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: Thu, 02 Aug 2012 22:22:36 -0000 On Thu, Aug 2, 2012 at 2:51 PM, Doug Barton wrote: > On 8/2/2012 2:25 PM, Maksim Yevmenkin wrote: >> On Thu, Aug 2, 2012 at 1:55 PM, Hiroki Sato wrote: >> >>> Just curious, why ip6addrctl_enable=NO is not enough here? > > Because the behavior of the script for =NO is to prefer v4. > >>> I would >>> like to eliminate yes/no/none keywords in $ip6addrctl_policy because >>> such keywords are vague. If we need the empty rule for some reason, >>> "empty" would be a better name for the policy, I think. > > Personally I think that the established meanings of "yes" and "no" are > well understood, but I wouldn't object to emitting a warning for them to > help the user make a more explicit selection. > > While we're at it, the way that the current script replicates the test > for checkyesno in case is bogus, and should be changed. I had fixed this > in the change set that you(hrs) backed out. To stick with the structure > of the current script, something like this would work: > > http://people.freebsd.org/~dougb/ip6addrctl.diff > > That also brings in the warning described above. > >> i just wanted to make sure that there is a way to absolutely make sure >> that there is no default address selection policy installed. the wide >> know rule 9 of rfc 3484 is really messing things up for dns-style load >> balancing. even when ipv6 is not used. > > Maksim, can you say more about this? Or point me to a reference that has > the discussion? of course :) we have ipv4 systems in production that make use of getaddrinfo(3) api. when a particular dns name is resolved, and, multiple A records are returned, the results get sorted according to the "default" address selection policy. rfc3484 has a set of rules according to which results should be sorted. all of the rules do not apply in our case, except one - the rule #9. the idea is that ipv4 addresses are "converted" to ipv6 addresses and then longest prefix match sorting is applied. in other words, if your system ip address happens to share high bits with the ip address from the A record, the IP address from the A record will always be preferred. of course, longest prefix match is performed without any extra information such as netmask and/or cidr. it really is just matching high bits of the address. so, what we found out, is that some systems tend to favor a particular ip address (from a bunch of ip addresses returned by name resolution) because 4 high bits were the same. basically, round-robin dns was completely shot. >> personally, i don't think that >> "none" is unreasonable word for "ip6addrctl_policy", but i don't feel >> particularly strongly about it. any name will do as long as original >> functionality is preserved. > > I agree that "none" is reasonable, and is in line with other rc.d knobs. > I would not object to "empty" being added as a synonym though. > > One request however, is this new knob documented in rc.conf.5? If not, > can you do that please? :) sure. i will try to do it later this week or early next week. thank you for pointing it out. thanks, max