svn commit: r206408 - in head: etc etc/defaults etc/rc.d
hrs at FreeBSD.org
Sat Apr 17 15:01:14 UTC 2010
Doug Barton <dougb at freebsd.org> wrote
in <4BC8EE88.6000700 at FreeBSD.org>:
do> > or if the
do> > commit hadn't happed in the middle of a discussion that died with
do> > this.
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
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> 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> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100417/a37df7da/attachment.pgp
More information about the freebsd-current