Date: Sat, 17 Apr 2010 23:39:57 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: dougb@FreeBSD.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 Message-ID: <20100417.233957.145060369.hrs@allbsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Apr_17_23_39_57_2010_726)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton <dougb@freebsd.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100417.233957.145060369.hrs>