From owner-freebsd-current@FreeBSD.ORG Fri Apr 16 23:11:08 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 2A7F71065670 for ; Fri, 16 Apr 2010 23:11:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id CB0EC8FC12 for ; Fri, 16 Apr 2010 23:11:07 +0000 (UTC) Received: (qmail 5810 invoked by uid 399); 16 Apr 2010 23:11:06 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Apr 2010 23:11:06 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BC8EE88.6000700@FreeBSD.org> Date: Fri, 16 Apr 2010 16:11:04 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <201004090135.o391Z9q2092650@svn.freebsd.org> <20100416214823.Q40281@maildrop.int.zabbadoz.net> In-Reply-To: <20100416214823.Q40281@maildrop.int.zabbadoz.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@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: Fri, 16 Apr 2010 23:11:08 -0000 On 4/16/2010 3:27 PM, Bjoern A. Zeeb wrote: > On Fri, 9 Apr 2010, Doug Barton wrote: > > Hi, > > first off all it would have been easier to figure a few things out, if > the several different things had been individual commits I considered that but given that the changes had to happen at the same time because they were interrelated, this seemed impractical. Of course if there are any questions about the changes that I can answer for you, I will be happy to do so. Given that the various functions in network.subr are highly interrelated I found that the easiest way to review it was to have several windows open at the same time so that I could trace the interactions. It took me quite some time to unravel it all. The diff itself is nearly unintelligible, I suggest that you review the actual code in its current form. > or if the > commit hadn't happed in the middle of a discussion that died with > this. I took from the discussion the few things that we had achieved some form of consensus on, and chose to drop the rest of the topics that I had severe disagreements about. I also followed up to the list regarding this, and my reasons for dropping out. > The comments below are on the first four things I could figure > out easily. > >> Author: dougb >> Date: Fri Apr 9 01:35:09 2010 >> New Revision: 206408 >> URL: http://svn.freebsd.org/changeset/base/206408 >> >> Log: > ... >> 6. Add support for the [NO]RTADV options in ifconfig_getargs() and >> ipv6_autoconfif(). In the latter, include support for the explicit >> addition of [-]accept_rtadv in ifconfig__ipv6 as is done >> in the current code. > > So usually we seem to use the upper case pseudo arguments like DHCP, > SYNCDHCP, WPA, .. in combination with an actual command to start apart > from ifconfig. Now RTADV does not do that but it passes accept_rtadv or > -accept_rtadv to ifconfig. So if you need a command alias for that it > should probably be in ifconfig and discussed separately. I understand your argument, but I don't agree with it. The one thing that there was actually strong consensus on was that the IPv6 configuration should have feature-parity with IPv4. Given that we have easy to use knobs to enable things like DHCP and WPA that users are already familiar with it made sense to me to introduce the same types of knobs for RA. This is in anticipation of also adding support for DHCPV6 at some point in the future. From a user interface standpoint it does not make sense to have one form of IPv6 configuration to require an ifconfig statement, and another to have a knob. Furthermore: 1. I explicitly included support for the existence of [-]accept_rtadv in ifconfig_IF_ipv6 so if you or anyone else prefers that method of configuration it's available to you. 2. Just because RTADV doesn't start something "apart from ifconfig" now doesn't mean it won't or can't in the future. Specifically I'd like to see this knob turn on rtsold as well. (Even if I thought your argument above was valid, which I do not.) > Please revert this part. As I not only do not believe that you've proved your case but I also strongly disagree with your perspective on what I believe to be valid grounds, I must politely decline your request. OTOH, I would be supportive of any efforts you wanted to make in regards to documenting the ability to specify [-]accept_rtadv with ifconfig in rc.conf.5 and/or etc/defaults/rc.conf if you so desire. >> Switch ipv6_prefer to YES. If ipv6_enable is not set this will have >> no effect. > > This changed the default. It did not. Previous to the introduction (and overloading) of the ipv6_prefer knob if you enabled IPv6 support with ipv6_enable it was preferred. With the code just prior to my change in order to configure IPv6 for an interface at all it was necessary to set ipv6_prefer to on, which meant that there was no way to have IPv6 configured but not have it be preferred. With my changes to the user interface I've completely decoupled the 3 features that were previously overloaded into ipv6_enable: ability to configure IPv6, acceptance of RA, and preference of v6 over v4. Furthermore, one could easily deduce from the act of configuring IPv6 that the user would wish it to be preferred. However just in case that isn't true I purposely moved the ipv6_prefer knob up to just after ipv6_network_interfaces in defaults/rc.conf and up the list in rc.conf.5 as well to be sure that the user had a chance to see it and change it if necessary. > I have no idea where in the commit message it was but I must have > missed it. Anyway, with this change the link-local addresses are > there by default If INET6 is in the kernel, the loopback and link-local addresses for lo0 are always configured. My understanding is that this is a requirement, and Bad Things will happen if it's not done. However, in the absence of an ifconfig_IF_ipv6 line of some sort for an interface other than lo0 no IPv6 configuration should be happening for it at all, including link-local. If you're seeing that it's a bug, and I will gladly address it. >> 5. In rc.d/netoptions, add code for an ipv6_privacy option to use >> RFC 4193 style pseudo-random addresses > .. >> Add a default for ipv6_privacy (NO). > > I think this is the only option I can say I feel ok with so far. Thanks. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/