From owner-svn-src-all@FreeBSD.ORG Wed Sep 16 21:59:50 2009 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 809391065676 for ; Wed, 16 Sep 2009 21:59:50 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 352E68FC1A for ; Wed, 16 Sep 2009 21:59:50 +0000 (UTC) Received: (qmail 21060 invoked by uid 399); 16 Sep 2009 21:59:49 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 16 Sep 2009 21:59:49 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AB15FCE.70505@FreeBSD.org> Date: Wed, 16 Sep 2009 14:59:42 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Hiroki Sato References: <200909122222.n8CMMV3d099311@svn.freebsd.org> In-Reply-To: <200909122222.n8CMMV3d099311@svn.freebsd.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, freebsd-rc@freebsd.org Subject: Re: svn commit: r197145 - in head: etc/defaults share/man/man5 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: Wed, 16 Sep 2009 21:59:50 -0000 [Please direct follow-ups to freebsd-rc@] Hiroki, I realize that you've posted your patches in the past, and I definitely had it in mind to review them in detail and give you feedback on them. However I got focused on my own projects for the pending release, and then since we were so close to the release I did not think you would be committing these changes until after it was done so I let review of these patches slip down my list of priorities. Therefore I ask you to accept my apologies for this "after the fact" review. Before I forget, you keep putting "mfc after 3 days" in your commit messages. You don't actually plan to MFC these changes to RELENG_8 prior to the 8.0-RELEASE do you? I would not be supportive of this given the sweeping nature of the changes and the (unfortunately) small percentage of our userbase that uses and tests IPv6. I think shaking this code out in HEAD for several weeks at least would be a good thing. That said I very much like the idea of integrating IPv6 support into the overall network code, and I am very supportive of that. I do have some small problems with the direction that you've taken in a few areas, which happen to be neatly summarized in this post. Hiroki Sato wrote: > Author: hrs > Date: Sat Sep 12 22:22:31 2009 > New Revision: 197145 > URL: http://svn.freebsd.org/changeset/base/197145 > > Log: > The following changes are added because of > network_ipv6->rc.d/netif integration: > > - $ipv6_enable is now obsolete. Instead, IPv6 is enabled by > default if the kernel supports it, and $ipv6_network_interfaces > is "none" by default. If you want to use IPv6, define > $ipv6_network_interfaces and $ifconfig_xxx_ipv6. In general I have a problem with the idea of drastically changing the semantics of the current code when I can't see any real value in doing so. I object to this change specifically because on my laptop I really like having the ability to easily disable IPv6 when I am not on my home network. My preferred scenario would be something similar to what we have now, which is that if ipv6_enable is set that it takes the same list of interfaces as ipv4 (defaults to AUTO) and that rtadv is enabled by default for each of those interfaces. My feeling is that this not only significantly reduces POLA it will also more precisely fit the way that the vast majority of our users will actually use IPv6. On a "marketing" note I really think it would be valuable to make it as easy as possible for the average user to get IPv6 working. We have IPv4 down to it more or less "just works," I think IPv6 should be the same way. (On a side note, I'd actually like to see DHCP be the default for IPv4 such that if you have DHCP available on a network you wouldn't have to do any configuration at all to get FreeBSD on line, but that's a whole other topic.) > An interface which is in $network_interfaces and not in > $ipv6_network_interfaces will be marked as "inet6 > -auto_linklocal ifdisabled" (see ifconfig(8)). I think that if a user specifies both lists, and that they differ, that this is a very good way to handle it. > - $ipv6_ifconfig_xxx is renamed to ifconfig_xxx_ipv6 for > consistency with other address families. The old variables > still work but can be removed in the future. Note that > ipv6_ifconfig_xxx="..." should be replaced with > ifconfig_xxx_ipv6="inet6 ...". I see that you are giving a warn'ing when the old format is detected, which is good. > - Receiving ICMPv6 Router Advertisement is not automatically > enabled even if there is no manual configuration of IPv6 in > rc.conf. If you want it, define > ifconfig_xxx_ipv6="inet6 ... accept_rtadv". What is the reason for this change? While I am definitely in favor of making it easier to disable rtadv, I still think it should be the default. > - The rc.d/ip6addrctl now chooses address selection policy based > on $ipv6_prefer, not $ipv6_enable. The default is > ipv6_prefer=NO. Once again, what is the reason for this change? My read of the IPv6-using community is that if they have it available they want to use it as a first choice. I know that is certainly my preference. Once again my apologies for the late review, but hopefully this is useful. Doug -- This .signature sanitized for your protection