IPv6 configuration in rc.d (Was: Re: svn commit: r206408 ...)

Doug Barton dougb at FreeBSD.org
Sat Apr 17 21:42:49 UTC 2010

To add a little history to the discussion:

In June of last year you posted a patch to the -rc list to update our
treatment of IPv6 configuration in rc.d and bring it on par with how we
configure IPv4. At the time I did not give your patch adequate review,
and subsequent to it being committed a number of problems were
discovered, and some things about your changes that I did not agree with
became apparent to me. Some of the problems were easily fixed, others
were more fundamental and required a lot more time and attention. OTOH,
the majority of the work you did was really great, long overdue, and as
I've said in the past you should be commended for it. I would like to be
clear that for the most part where you and I disagree is not in the
"under the hood" aspects of the scripting but rather in the user
interface design.

For a variety of reasons I was unable to give the more in-depth issues
the time and attention they deserved until recently. Frankly I did not
place a high priority on this because for the most part the IPv6
configuration worked, and since the changes are not going to be MFC'ed I
devoted my attention to other things. (FWIW my life for over a year now
has been devoted to trying to find a job, and doing what little contract
work I've been able to find, including the work on portmaster that has
been supported by the FreeBSD community.)

For the last several weeks I have tried to engage you, and other
interested parties in discussion about how IPv6 configuration in rc.d
should look. For better or worse you have a very clear, well-defined
vision of what you think things should look like, and have (IMO) been
quite intractable. Others in the community have spoken up and expressed
their opinions on how they would like to see the configuration look as

I continue to disagree rather strongly with some of your perspectives,
most notably the demise of the ipv6_enable knob. However as I expressed
in my post to -current after I committed my most recent changes I judged
the opinions expressed by the community as roughly evenly divided, so I
regarded the fact that I was the only one complaining about it as the
tie-breaking vote and agreed to let it stay dead. On other aspects of
the UI design I listened to what you and our users had to say and tried
to come up with what I believe is a good compromise that is clean, easy
to understand, and consistent.

Regarding some of the other aspects of your concept of the UI I have
tried to be diplomatic and express my opinions in the context of what I
believe the good points are in the changes I made. However given your
continued insistence on the issues you expressed below I think I need to
be more direct. While a lot of what you did was great work, several
aspects of the UI that you had/have in mind are quite simply bad ideas.
While to some extent I understand the goals of what you seem to be
trying to achieve the ideas you have are in many cases overly complex,
and more importantly inconsistent with general rc.d UI concepts and more
specifically inconsistent with how we configure IPv4.

I will respond more particularly to the points you make below, however
as I said previously I've already spent way too much time on what (IMO)
should have been some simple changes to make things easier and more
consistent for our users. If after reading this message you still don't
agree with my perspective I would like to suggest that you use the
available dispute resolution mechanism and then we can take it from there.

On 04/17/10 07:39, Hiroki Sato wrote:
> 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'm sorry, but what you're suggesting makes no sense at all. One area
that you and I agreed on was that the previous ipv6_enable knob was
overloaded in the sense of controlling 3 different things that should
have had separate configuration options (overall IPv6 config, accepting
RAs, and preferring IPv6). Your idea to split these functions into
separate configuration elements is a major step forward. However, adding
a new knob for ipv6_prefer and then also overloading it to control
link-local addresses is a big step backwards. The ipv6_prefer knob
should control one thing, and one thing only, whether or not IPv6
transport is preferred vs. IPv4 transport. This is what I mean by "clean
and simple UI design."

>  I explained again and again, the ifdisabled flag is *not for*
>  disabling IPv6 on an interface as opposed to the name. 

The description of the flag in ifconfig(8) seems to disagree with you:
     Set a flag to disable all of IPv6 network communications on the
     specified interface.

I think it's also worth pointing out that regardless of how you think it
should be used, setting 'ifdisabled' on the interface does actually do
what the man page describes, and therefore if there is no
ifconfig_IF_ipv6 for the interface (other than lo0) then it gets set,
and no IPv6 configuration is done for it. Voila!

>  In rc.d
>  scripts this is used for controlling link-local address assignment.

In the current code if the user has any sort of ifconfig_IF_ipv6 then
the ifdisabled flag is cleared, and the link-local address will be
configured in addition to any global addresses (either from manual
configuration or RA). If the user wants to configure ONLY a link-local
address they can do that as well. In fact I just committed examples to
etc/defaults/rc.conf and rc.conf.5 to demonstrate how to do this.

(Meanwhile, I have a non-trivial amount of experience with IPv6, follow
the discussion on numerous IETF and IPv6 operations lists, and I can't
think of a reason why someone would actually WANT to do this, but if
someone wants to they can.)

>  Your change removed the logic in no $ifconfig_IF_ipv6 case,

If what you mean here is, "With your changes no link-local address will
be created if there is no ifconfig_IF_ipv6 variable for that interface"
then yes, that is correct. You (and others) said over and over again in
the previous discussions that this is how it should be, so that's what I
did. What you're proposing (automatic config of link-local) violates the
exact principle that you espoused quite forcefully, and which (in a
spirit of compromise) I have adopted.

>  and it is not a consensus.

I never saw _any_ discussion about "If there is no ifconfig_ line for an
interface it should still get a link-local address." If I had, I would
have stated my strong objection to this as a principle. There was also
no discussion about overloading ipv6_prefer with this capability either.
And even if there had been, I feel compelled to point out once again
that doing either of those things would be a bad idea.

>  I strongly disagree with this because some IPv6
>  applications depend on link-local address automatically added on
>  cloned interfaces

Can you please give a configuration example that would create the
scenario you are describing with the current code? And assuming that you
actually have a valid use case for having a "link-local but no global"
interface, can you please explain why configuring that with an
ifconfig_IF_ipv6 line is not a good solution? If there is such a use
case, and the current code does not allow for it, I will gladly work
with you to find a solution.

>  and at the same time IPv4 people do not like the link-local address.

I would restate this as, "If there is no explicit IPv6 configuration for
an interface (other than lo0) the user has the reasonable expectation
that there will not be a link-local address assigned to it."

>  We need a knob to control that, and the default
>  should be "no link-local when no ifconfig_IF_ipv6",

On this we agree (in the sense that I accepted this as a compromise
position based on your insistence and other feedback from the community).

>  and "all
>  interfaces have a link-local address when $ipv6_prefer=YES".

And as I said above, this makes no sense. Clean, consistent UI design
mandates that each knob have a specific, well defined function. As an
example of why what you're suggesting is a bad idea, how would a user
specify that they want link-local addresses on an interface, but they do
NOT want the other effect of ipv6_prefer (the ip6addctrl settings)?

(It's also worth pointing out that in addition to link-local
configuration, in your code it was not possible to do any IPv6
configuration at all unless ipv6_prefer was yes.)

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

Two reasons, in roughly equal importance. First, it has always been true
that if IPv6 configuration is enabled IPv6 transport is preferred.
Changing that now would be a POLA violation. Second, (as I stated
previously) if the user takes the proactive step to configure IPv6 it is
entirely reasonable to assume that they also want it to be tried first.
However (as I said to bz in my previous post) because it is possible
that this is not true, and because we now have a knob to control the
behavior, I moved the ipv6_prefer knob up to the number 2 spot in the
IPv6 configuration section of defaults/rc.conf so that anyone who wants
to change this can do so easily.

FWIW, I've been using IPv6 on FreeBSD for about 6 years now, and other
than the very occasional glitch on the content-provider side it's been
smooth sailing. Given that the default has been the equivalent of
"ipv6_prefer=yes" all that time, I don't see any problem with leaving it
that way, and as I said above I think defaulting it to off would be the
wrong decision. It's probably also worth pointing out that in the case
of ipv6_prefer=yes and no IPv6 configured on an external interface, the
_prefer knob is moot.

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

Because (as you and others pointed out, and I agree with) we want IPv6
configuration to have parity with IPv4 configuration. It also makes no
sense to have a design in mind for "later" but not use it now. It's much
better from a user experience standpoint to introduce the new UI now so
that people have a chance to get used to it, exercise the code, shake
out the bugs, etc. Using RTADV is also consistent with how we do things
with IPv4 ala [NO]DHCP and WPA. The fact that those 2 IPv4 knobs _also_
start external processes is a red herring. Users don't care how things
work under the hood, they just want a simple, easy to understand UI.

FWIW, I also want to mention here that accepting the need to configure
anything explicitly to get RA behavior is a compromise on my part. I
STILL think that RA should "just work," which is how the protocol is
designed to work in the first place.

>  At this moment, having two keywords makes nothing easy.

We don't have "two keywords." We have one keyword (RTADV) that users can
use just like they use DHCP for IPv4. I also maintained backwards
compatibility for [-]accept_rtadv in ifconfig_IF_ipv6 because that's the
right thing to do. However, that method is not documented, and no one
who reads the examples in defaults/rc.conf or rc.conf.5 could possibly
be confused.

>  Invoking rtsold (and/or dhclient) when receiving RAs are not so
>  simple.  Did you really try that?

This part of the conversation is a little off-topic to the overall rc.d
discussion, but in any case, yes. I've been using the rtsold option ever
since it was committed.

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

I agree with you on that, which is why I haven't made any changes in
this area. :)  However, given that we know that at some point in the
future we will want a DHCPV6 knob, and given that we are likely to  also
want to do things other than just 'ifconfig accept_rtadv' for RA in the
future, it makes sense to introduce RTADV now.

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

I'm sorry to hear you say that, as I was hoping that it was simply an
honest mistake on your part. To be clear, ipv6_prefer should control
one, and only one thing, the behavior of rc.d/ip6addctrl. Overloading it
in any way, and more importantly overloading it to require that it be on
for any IPv6 configuration to occur at all is not acceptable. There
_must_ be a way for users to configure IPv6 for their external
interfaces and also have it not be preferred.

Regardless of how you intended it at the time, adding an ipv6_prefer
knob to control the behavior of rc.d/ip6addctrl is a good idea, and a
valuable addition to FreeBSD. Overloading it to perform other functions
is not acceptable.



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

More information about the freebsd-current mailing list