Doug Barton <do...@freebsd.org> wrote in <4bca2b55.9000...@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 IPv4 people hates that gif0 has an IPv6 link-local (and IPv6 communication itself), 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. 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. 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. 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. 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. 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. -- Hiroki
pgp10xLh16Ogi.pgp
Description: PGP signature
