From owner-freebsd-current@FreeBSD.ORG Sat Apr 17 15:01:14 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 149FE106564A; Sat, 17 Apr 2010 15:01:14 +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 99B6D8FC1D; Sat, 17 Apr 2010 15:01:13 +0000 (UTC) Received: from delta.allbsd.org (p4178-ipbf1907funabasi.chiba.ocn.ne.jp [114.146.127.178]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o3HF0nxf046609; Sun, 18 Apr 2010 00:01:00 +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 o3HF0ii5000362; Sun, 18 Apr 2010 00:00:49 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 17 Apr 2010 23:39:57 +0900 (JST) Message-Id: <20100417.233957.145060369.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BC8EE88.6000700@FreeBSD.org> <201004090135.o391Z9q2092650@svn.freebsd.org> References: <201004090135.o391Z9q2092650@svn.freebsd.org> <20100416214823.Q40281@maildrop.int.zabbadoz.net> <4BC8EE88.6000700@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(Sat_Apr_17_23_39_57_2010_726)--" 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]); Sun, 18 Apr 2010 00:01:06 +0900 (JST) X-Spam-Status: No, score=2.2 required=13.0 tests=CONTENT_TYPE_PRESENT, FORGED_RCVD_IP,RCVD_IN_PBL,SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, bz@FreeBSD.org Subject: Re: svn commit: r206408 - in head: etc etc/defaults etc/rc.d share/man/man5 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: Sat, 17 Apr 2010 15:01:14 -0000 ----Security_Multipart(Sat_Apr_17_23_39_57_2010_726)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BC8EE88.6000700@FreeBSD.org>: do> > or if the do> > commit hadn't happed in the middle of a discussion that died with do> > this. do> do> I took from the discussion the few things that we had achieved some form do> of consensus on, and chose to drop the rest of the topics that I had do> severe disagreements about. I also followed up to the list regarding do> this, and my reasons for dropping out. No, you changed the meaning of $ipv6_prefer, which does not agree with one of the results of discussion. When ipv6_prefer=YES, ifdisabled flag must be cleared on all interfaces. The reason is to enable automatic link-local address assignment without manual configuration. I explained again and again, the ifdisabled flag is *not for* disabling IPv6 on an interface as opposed to the name. In rc.d scripts this is used for controlling link-local address assignment. Your change removed the logic in no $ifconfig_IF_ipv6 case, and it is not a consensus. I strongly disagree with this because some IPv6 applications depend on link-local address automatically added on cloned interfaces and at the same time IPv4 people do not like the link-local address. We need a knob to control that, and the default should be "no link-local when no ifconfig_IF_ipv6", and "all interfaces have a link-local address when $ipv6_prefer=YES". For all scenarios I can think of this is the least-worst. Also, source address selection has to be IPv4-preferred by default. Why did you change this? I disagree with this. I want "IPv6 enabled by default", but we are not ready for "IPv6 is preferred when the both are available" for various reasons. do> > So usually we seem to use the upper case pseudo arguments like DHCP, do> > SYNCDHCP, WPA, .. in combination with an actual command to start apart do> > from ifconfig. Now RTADV does not do that but it passes accept_rtadv or do> > -accept_rtadv to ifconfig. So if you need a command alias for that it do> > should probably be in ifconfig and discussed separately. do> do> I understand your argument, but I don't agree with it. The one thing do> that there was actually strong consensus on was that the IPv6 do> configuration should have feature-parity with IPv4. Given that we have do> easy to use knobs to enable things like DHCP and WPA that users are do> already familiar with it made sense to me to introduce the same types of do> knobs for RA. This is in anticipation of also adding support for DHCPV6 do> at some point in the future. From a user interface standpoint it does do> not make sense to have one form of IPv6 configuration to require an do> ifconfig statement, and another to have a knob. do> do> Furthermore: do> 1. I explicitly included support for the existence of [-]accept_rtadv in do> ifconfig_IF_ipv6 so if you or anyone else prefers that method of do> configuration it's available to you. do> 2. Just because RTADV doesn't start something "apart from ifconfig" now do> doesn't mean it won't or can't in the future. Specifically I'd like to do> see this knob turn on rtsold as well. (Even if I thought your argument do> above was valid, which I do not.) So please add that after you implement it and RTADV is not equivalent to accept_rtadv. I cannot understand why we need to add it now. At this moment, having two keywords makes nothing easy. Invoking rtsold (and/or dhclient) when receiving RAs are not so simple. Did you really try that? I personally lean to having a userland daemon to handle RA options including RDNSS and O-flag. If you want direction for extending rc.d scripts to handle them, please show the concrete implementation first as David Horn did. I think this is not a simple one like just adding a keyword and careful consideration is needed before implementing it. do> It did not. Previous to the introduction (and overloading) of the do> ipv6_prefer knob if you enabled IPv6 support with ipv6_enable it was do> preferred. With the code just prior to my change in order to configure do> IPv6 for an interface at all it was necessary to set ipv6_prefer to on, do> which meant that there was no way to have IPv6 configured but not have do> it be preferred. That behavior was intentional. Please keep it disabled by default. I disagree with decoupling seatbelt for link-local addr assignment from IPv6-preferred source address selection. The IPv6-preferred source address selection is troublesome for IPv4-only people, and for IPv6-people the seatbelt for link-local addr is troublesome. I designed $ipv6_prefer as a knob for this trade-off. -- Hiroki ----Security_Multipart(Sat_Apr_17_23_39_57_2010_726)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkvJyD0ACgkQTyzT2CeTzy1e6QCcDoZ1RSceEkD6fna+LNkIiHq2 /B4AnA5jWJYf/RyzZTP6i7oTaGSr7XHC =+kag -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Apr_17_23_39_57_2010_726)----