From owner-freebsd-current@FreeBSD.ORG Mon Apr 5 07:05:10 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48106106566C for ; Mon, 5 Apr 2010 07:05:10 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 98B5F8FC13 for ; Mon, 5 Apr 2010 07:05:09 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o3574hIT019117 for ; Mon, 5 Apr 2010 16:04:55 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o3574c9x009821 for ; Mon, 5 Apr 2010 16:04:40 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 05 Apr 2010 16:04:16 +0900 (JST) Message-Id: <20100405.160416.107652240.hrs@allbsd.org> To: freebsd-current@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BB95564.1070604@FreeBSD.org> References: <20100404053352.E6F751CC13@ptavv.es.net> <20100404.184141.03733377.hrs@allbsd.org> <4BB95564.1070604@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr__5_16_04_16_2010_540)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 05 Apr 2010 16:05:02 +0900 (JST) X-Spam-Status: No, score=0.4 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 07:05:10 -0000 ----Security_Multipart(Mon_Apr__5_16_04_16_2010_540)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BB95564.1070604@FreeBSD.org>: do> On 04/04/10 02:41, Hiroki Sato wrote: do> > "Kevin Oberman" wrote do> > in <20100404053352.E6F751CC13@ptavv.es.net>: do> > do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I do> > ob> see no reason not to use them to enable or disable functionality whether do> > ob> it involves a script in rc.d or not. The idea is to have a clear, do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'. do> > do> > Another reason I lean to not using xxx_enable is that an rc.d knob do> > cannot control enabling/disabling the IPv6 functionality actually. do> > It was true even when we were using the network_ipv6 script. do> do> But that's equally true of how you're using ipv6_prefer. :) You've do> basically just moved the overloading of 2 of the 3 previous functions of do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3 do> functions into different knobs. No, the current ipv6_prefer=NO has nothing to do with disabling IPv6. It is just related to source address selection and a seatbelt for IPv4-only people. I do not think I just moved the old functions. Let me explain how these changes happened. As I explained earlier, I added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some configuration even if you do not use IPv4 when the kernel supports it, and skipping all of IPv6 configuration in the old rc.d/network_ipv6 script caused another problems. So, I thought it was possible to enable IPv6 by default and initialize the functionality with reasonable default parameters. This parameters included "disable ACCEPT_RTADV by default", which is one of the topics we are discussing now. After I moved the initialization outside of the $ipv6_enable, then I noticed that the rest which should be inside of the $ipv6_enable is IPv6 GUA address assignments and routing settings only. Here I stepped further; I changed the disabling feature of $ipv6_enable into "whether an IPv6 address is assigned or not". That was the whole story. The old rc.d/network_ipv6 had a lot more for IPv6 configuration in the $ipv6_enable conditional clause and ipv6_enable=NO meant to disable them, too. This is a big difference. The new ipv6_enable in your patch is not the same in this regard. Well, I can understand and agree that people want a handy knob to disable IPv6. I think it is more constructive for this discussion to be more specific what should be disabled, then. I am still not sure what you and other people mean by "disable IPv6". My opinion is "ipv6_enable=NO" should mean disabling IPv6 functionality completely. I do not want to call a knob just to ignore ifconfig_IF_ipv6 lines as "ipv6_enable" as well as do not want to disable IPv6 functionality completely by default. So I am interested in what people want more precisely. -- Hiroki ----Security_Multipart(Mon_Apr__5_16_04_16_2010_540)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku5i3AACgkQTyzT2CeTzy3ZpACfbA+xpauXCH9nTfHuZcS45JRZ UhMAnjcH2Ql0uKRF4qy4sfiNGHRrMw6U =s7gB -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr__5_16_04_16_2010_540)----