Now we're getting somewhere. :) On 04/18/10 12:04, Hiroki Sato wrote: > Doug Barton <dougb_at_FreeBSD.org> wrote > in <4BCA2B55.9000609_at_FreeBSD.org>: > > do> > I strongly disagree with this because some IPv6 > do> > applications depend on link-local address automatically added on > do> > cloned interfaces > do> > do> Can you please give a configuration example that would create the > do> scenario you are describing with the current code? And assuming that you > > We now have no control for whether a link-local address is > automatically added or not when simply doing the following: > > # ifconfig gif0 create > # ifconfig gif0 up Your statement is literally true, in this case the network.subr stuff "has no control" because it isn't run. That was the same for the old code as it is for the new code. Meanwhile, have you actually tested setting up a tunnel by hand? The gif man page says this: Note that IPv6 link-local addresses (those that start with fe80::) will be automatically configured whenever possible. You may need to remove IPv6 link-local addresses manually using ifconfig(8) ... So it seems to me that the link-local addresses will be created regardless. However I just tried the two commands you pasted and A) the code in network.subr was not run for gif0, and B) I had to manually do -ifdisabled on gif0 to get it to create a link-local address. So it's not at all clear to me that the new code in network.subr is relevant in this situation at all. > IPv4 people hates that gif0 has an IPv6 link-local (and IPv6 > communication itself), People who don't want v6 at all compile it out of the kernel, and the whole problem goes away. The project made a decision a long time ago to ship with v6 in GENERIC, so this is not a new issue. > and IPv6 people hates that it needs an > additional step to enable it (ifconfig inet6 -ifdisabled in this > case). gif (and other cloned interfaces) can be created by a program > (a ppp script, for example), so we cannot prepare $ifconfig line in > rc.conf in advance. Why not? There is no reason you can't have ifconfig_* lines for interfaces that are not always configured, I do it all the time. > In short, if we have no knob to control this and > put ifdisabled onto interfaces with no $ifconfig_IF_ipv6 line by > default, people always needs "ifconfig inet6 -ifdisabled" for such > dynamically created interfaces. Even if that's true (and it's not clear to me that it is), I don't see a problem. The vast majority of network configuration is done at boot time via rc.conf. IF someone has to add one or two lines to the conf file to make something work, that's a one-time issue, and has the benefit of being consistent. > This was the reason why $ipv6_prefer=YES did "ifconfig inet6 > -ifdisabled" on interfaces with no $ifconfig_IF_ipv6 line and > ipv6_prefer was NO by default. There are third party programs that > use the above example to establish IPv6-over-IPv4 tunnel. The > requirement of "-ifdisabled" will be very frustrating for IPv6 > people. Are you theorizing here, or do you have actual examples? If you can find actual examples of "here is something that used to work, but now it does not" then we can work on a solution. I am not necessarily opposed to the idea of automatically creating link-local addresses for cloned interfaces, but it's impossible for me to code against something I don't have in front of me. :) > I admit "two meanings (src addr selection and -ifdisabled) in one > $ipv6_prefer variable" is suboptimal, but at that time I thought > factoring out them was rather troublesome. While my goal was to > eliminate/factor such a opaque flag completely, this is the one > unresolved. I still have no solution about this. > > do> And as I said above, this makes no sense. Clean, consistent UI design > do> mandates that each knob have a specific, well defined function. As an > do> example of why what you're suggesting is a bad idea, how would a user > do> specify that they want link-local addresses on an interface, but they do > do> NOT want the other effect of ipv6_prefer (the ip6addctrl settings)? > > I think that is a reasonable question. It was a loose end of the > changes last year; I did not want to add additional knob to solve the > problem explained above, so I decided to keep it coupled with the > link-local thing until we get a solution. IMO, the src addr > selection is supposed to be controlled by $ip6addrctl_* prefixed > variables, and $ipv6_prefer should be removed in the long-term. Two things here, first, I think ipv6_prefer is a good name for the knob, and is clearer (and shorter) than ip6addrctl_ so I really think it should stay. Second, there are 2 very important rules of UI design that apply here. Don't introduce an interface that you intend to take away later, and don't change the semantics of an interface. Either thing frustrates users. Obviously there are times with both rules need to be broken, but only under extreme circumstances. > do> > Also, source address selection has to be IPv4-preferred by default. > do> > Why did you change this? I disagree with this. I want "IPv6 enabled > do> > by default", but we are not ready for "IPv6 is preferred when the > do> > both are available" for various reasons. > do> > do> Two reasons, in roughly equal importance. First, it has always been true > do> that if IPv6 configuration is enabled IPv6 transport is preferred. > do> Changing that now would be a POLA violation. Second, (as I stated > do> previously) if the user takes the proactive step to configure IPv6 it is > do> entirely reasonable to assume that they also want it to be tried first. > > In the default configuration (no rc.conf), there is no > ifconfig_IF_ipv6 line. If we take this as no configuration for IPv6, > should IPv6-preferred be disabled in this case? > > do> FWIW, I've been using IPv6 on FreeBSD for about 6 years now, and other > do> than the very occasional glitch on the content-provider side it's been > do> smooth sailing. Given that the default has been the equivalent of > do> "ipv6_prefer=yes" all that time, I don't see any problem with leaving it > do> that way, and as I said above I think defaulting it to off would be the > do> wrong decision. It's probably also worth pointing out that in the case > do> of ipv6_prefer=yes and no IPv6 configured on an external interface, the > do> _prefer knob is moot. > > For IPv4 people, performance regression will be noticeable. > IPv6-preferred src addr selection means ::1 is always used for > localhost. On my box, IPv6 loopback is 25-30% slower than IPv4 > counterpart. Whether this is critical or not depends on the > application, but forcing IPv4-only people to use IPv6 loopback does > not look a smart choice to me until we solve this problem though I > love to see IPv6-preferred by default. Simple solution to that problem, fix IPv6 loopback to be of equal or better performance than IPv4. :) Seriously though, there are not that many things that have loopback as their performance-critical issue, and once again, people for whom having any IPv6 at all is an issue already compile it out of the kernel. Meanwhile I am thinking that one way to make this a little easier for the users is if ipv6_network_interfaces=NONE that we override ipv6_prefer in rc.d/ip6addctrl. Does that sound reasonable? > do> > That behavior was intentional. > do> > do> I'm sorry to hear you say that, as I was hoping that it was simply an > do> honest mistake on your part. To be clear, ipv6_prefer should control > do> one, and only one thing, the behavior of rc.d/ip6addctrl. Overloading it > do> in any way, and more importantly overloading it to require that it be on > do> for any IPv6 configuration to occur at all is not acceptable. There > do> _must_ be a way for users to configure IPv6 for their external > do> interfaces and also have it not be preferred. > do> > do> Regardless of how you intended it at the time, adding an ipv6_prefer > do> knob to control the behavior of rc.d/ip6addctrl is a good idea, and a > do> valuable addition to FreeBSD. Overloading it to perform other functions > do> is not acceptable. > > The reason I left two things in one variable is as explained earlier. > I agree that they should be separated from each other, but please > consider why I did so and solution to the problems *before* > committing your change. I have continued to write lengthy emails > because I am responsible to explain what I did that are mostly > undocumented. I do not think my implementation is the best, so > please do not take my opinion as a simple disagreement against your > idea. I am interested in other people's view for the issues I showed > and before further changes I want to discuss the direction we take > even if it involves lengthy email exchanges. I agree with you completely that thorough understanding of the problems and finding the best solutions are excellent goals. :) 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 Sun Apr 18 2010 - 18:22:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC