IPv6 configuration in rc.d
Hiroki Sato
hrs at FreeBSD.org
Sun Apr 18 19:09:02 UTC 2010
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100418/1007686f/attachment.pgp
More information about the freebsd-current
mailing list