Re: svn commit: r206408 - in head: etc etc/defaults etc/rc.d share/man/man5

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>
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