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 well. 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: ifdisabled 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. 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/Received on Sat Apr 17 2010 - 19:42:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC