Re: IPv6 configuration in rc.d

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