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

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_<interface>_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/