Re: ipv6_enable

On 04/04/10 22:42, Hiroki Sato wrote:
> Doug Barton <dougb_at_FreeBSD.org> wrote
>   in <4BB7E224.6020508_at_FreeBSD.org>:
> 
>  If people want to disable IPv6 GUA assignment in per-AF manner, it
>  should be done by per-AF global knobs for $ifconfig_* because the GUA
>  assignment involves $ifconfig_* knobs only for the user as explained
>  in another email.

To be honest, I think what you're proposing is way too complicated, and
unnecessarily so. I think you've got a very interesting vision for where
we should end up down the road, but as I said in a previous message I
think your proposed UI is much too complex.

>  Let me summarize what I agree and disagree again:
> 
>  a. I agree that it is useful to have a knob for disabling all of
>     ifconfig_IF_ipv6 handling.

That's not what I'm actually proposing. Your idea is that the model
should be focused on ifconfig_IF_ipv6. I'd like to make that completely
unnecessary for the common case (RA).

>     However, I disagree with using the
>     name "ipv6_enable" just for the purpose.  ipv6_enable=NO never
>     means disabling IPv6 functionality in the kernel, and it will
>     cause people tend to think IPv6 is disabled completely.

Throughout this discussion you've been ignoring something very
important. The ipv6_enable knob already existed, and already had well
understood semantics, which you removed. IMO this is a serious POLA
violation.

What I'm suggesting is a return to the same semantics that we had
previously, but with your improvements running under the hood. I think
being able to disable RA particularly and IPv6 generally on a
per-interface basis is a tremendous improvement.

>     If we want to disable ifconfig_IF_AF lines in a handy manner,
>     implementing ifconfig_DEFAULT_AF is more consistent and where we
>     should go.  All of AF-specific parameters for an interface are in
>     $ifconfig_IF_AF, and having a global knob to define the default
>     for all interfaces are quite reasonable to me.  I do not want to
>     go back to AF-specific handling like ipv6_* wherever possible.
> 
>     I think this policy is compatible with David Horn's suggestions.
>     "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default,
>     "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default,
>     "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for
>     example (note that I do not stick to these keywords.  "slaac"
>     would also be a good candidate).  No concern for
>     conflicting/confusing with IPv4; this is orthogonal among AFs.  We
>     can support another new method by just adding a keyword.

Once again, I think what you're proposing is interesting, but way too
complex. I certainly think it's too complex as a first step.

>     Note that SLAAC and DHCPv6 are exclusive.

That's not accurate, but it's outside the scope of this issue.

>     Combinations of
>     DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the
>     latter is rather popular).  This is one of the reasons I stick to
>     the per-IF/per-AF solution here.

Once again, we don't disagree on the principle, that's why I'm adding
support for [NO]RTADV so that down the road we could have something like
ifconfig_IF_ipv6="RTADV DHCPV6-PD", etc.

>  b. Disagree with disabling IPv6 by default.  I think there is no
>     technical and security reason to go back to the old days.

Need to be clear on what this means. Given that INET6 is in GENERIC
(which I think it should be) we have to have a sensible default when it
comes to configuring the external interfaces. IMO the only sensible
default for that is not to. Configuring them by default when the user
doesn't actually have IPv6 connectivity to the outside world would cause
a lot of problems.

>  And, well, please let me suggest something for the further discussion
>  here.  Whether we have $ipv6_enable or not, whether we enable
>  $ipv6_enable by default or not, and whether receiving RA by default
>  or not, are separated topics from each other.  So, I would like
>  everyone's opinions for the following points separately:
> 
>  1. Do we need a knob to disable IPv6?  If so, which in the following
>     is expected for that knob?
> 
>     1-a) Disable ifconfig_IF_ipv6 processing only.  This means people
>          can still do manual configuration for IPv6.

My version of the patch does this.

>     1-b) Disable IPv6 functionlity completely.

We don't currently have a way to do this at all if INET6 is in the kernel.

>  2. If we have a knob described in 1, what should be the default
>     value?

Off.

>  3. Do we go for "accept RAs by default"?  We can break down this in
>     the following way related to 2:
> 
>     3-a) Enable IPv6 functionality and accept RAs by default.
> 
>     3-b) Enable IPv6 functionality and not accept RAs by default
> 
>     3-c) Disable IPv6 functionality by default and accept RAs if one
>          enables IPv6 in rc.conf.

I think this is the right answer, but others have expressed disagreement
on accepting RAs by default.

>     3-d) Disable IPv6 functionality by default and not accept RAs even
>          if one enables IPv6 in rc.conf.

3-e) ipv6_enable=no by default, RAs if DHCP is configured for the
interface, or if the user explicitly configures it.

>  My answers for them are:
> 
>  1. No objection for 1-a, but if so the name $ipv6_enable is wrong to
>     me.  If people needs 1-b, it should be $ipv6_enable.  I have no
>     strong opinion on whether we have one of or both of them.  If we
>     can reach a consensus to have 1-b, I am ready to implement the
>     necessary changes.

I would really appreciate it if you'd take a serious look at my
v6-enable-2.diff patch. I think it does a pretty good job of restoring
the previous UI and still maintaining the best of your improvements.


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/