Un-obsolete'ing ipv6_enable

[David Horn]

On Mon, Mar 8, 2010 at 5:27 PM, Hiroki Sato <hrs at freebsd.org> wrote:
> Doug Barton <dougb at freebsd.org> wrote
>  in <4B945AA7.6070000 at FreeBSD.org>:
>
> do> As we've previously discussed, I would like to un-obsolete ipv6_enable,
> do> and return it to the status of being the knob that actually controls
> do> whether or not we configure IPv6. My understanding is that the consensus
> do> is in agreement with this change, however I'm posting my proposed patch
> do> (minus the rc.conf(5) change) just in case. If you have any objection,
> do> please speak up sooner rather than later.
>
>  I do not think we reached the consensus on reverting the change.  In
>  my understanding there are people who want $ipv6_enable but the
>  reason why is they just feel they need a way to disable the
>  functionality.
>
>  The current implementation is based on a concept of "to enable IPv6
>  all you need is simply adding an IPv6 GUA to the interface", which is
>  the same as what we have for IPv4 configuration, and it has an
>  additional seatbelt to prevent unexpected IPv6 communication when
>  ipv6_prefer=NO (default).
>
>  The $ipv6_enable does not disable the functionality actually contrary
>  to people's expectation, and another problem is that what will be
>  done by such per-protocol *_enable knobs are not intuitive.  After
>  changing $ipv6_enable=YES (or NO), what rc.d script should be invoked
>  to reflect the change, for example?  What to be done is nothing but
>  configuring NICs, routes, and network options in the same way as for
>  IPv4.  Because we have IPv6-enabled kernel as the GENERIC, some basic
>  initialization is needed even if the sysadmin do not want to use IPv6
>  at all.  I think we do not need to have $ipv6_enable since we do not
>  have $ipv4_enable.

The question is what is the desired end-state for the rc.conf
configuration of ipv6 ?

Do we want to have a per-interface setting required to enable ipv6 SLAAC ?
Do we want to have a global setting for ipv6 SLAAC ?
Or do we want to choose sane defaults and allow the user to over-ride
on both a global default, and a per-interface basis ?

So, in the 8.0-RELEASE code (and previous TTBOMK), both IPv4 DHCP and
IPv6 SLAAC required manual enabling, although it was inconsistent in
that one was global (IPV6 accept_rtadv), and one was per-interface
(IPv4 DHCP).  Some of this has already started to change in -current.

Question 1)  Based upon history, sane defaults would be do nothing (NO
DHCPv4, NO IPv6 accept_rtadv).  Do you agree with this as the
continued defaults ?

Question 2) Assuming that people do desire consistency with allowing
for both a global, and a per-interface setting, do you agree with
having a global default for DHCPv4 (dhcpv4_default_enable), and for
IPv6 slaac/accept_rtadv  (ipv6-slaac_default_enable), and the
per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
meta configuration variable.

Note, it is trivial to allow the meta configuration variable to be
allowed on EITHER ifconfig_IF0, or ifconfig_IF0_ipv6, etc, so that is
not really germain to the discussion at this point.

Do people understand what I am proposing here, or do you want me to
put together a diff with an implementation to properly review ?

The disable side of the over-rides would be something like:  NOAUTO,
NODHCP, NOSLAAC meta configuration variables for the per-interface
configuration.

Do people understand what I am proposing here, or do you want me to
put together a diff with an implementation to properly review ?   I
already have some of it working in a separate experiment for adding
DHCPv6 configurations.

---Dave  Horn