Re: ipv6_enable

Doug Barton <dougb_at_freebsd.org> wrote
  in <4BB70E1E.3090102_at_FreeBSD.org>:

do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration
do> on and off when INET6 is in the kernel. I think the value of this kind
do> of knob is obvious, but I'd be happy to elaborate if that is necessary.

 There were reasons related to technical difficulty and inconsistency
 (and a bit my preference) to drop $ipv6_enable.

 First, we are overly abusing $xxx_enable knob even when no
 corresponding rc.d/xxx file.  I think $xxx_enable knob should be used
 only for rc.d/xxx whenever possible.  It is intuitive, and what the
 original design of rc.d scripts intended.  Although this would be
 another topic, it was one of the motivation for me to remove the
 knob.

 Second, if people need a way to disable IPv6 protocol, they have
 already the way; no IPv6 configuration in /etc/rc.conf.  If you need
 a handy way for on-and-off, separating the IPv6 configuration from
 rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into
 /etc/rc.conf should be enough, for example.

 After all, protocols cannot be disabled only by using rc.d scripts.
 If we really need the way to do that, we have to have kernel-level
 knobs like sysctl or ifconfig flag.  Also, we should not consider
 IPv6 as special.  Why we have to have $ipv6_enable while we don't
 have $ipv4_enable?  I am using INET6-only machines for years and the
 process removing the IPv4 dependency in the userland was really hard,
 but I believe "no line for the protocol in /etc/rc.conf means no
 configuration" is a policy which can be implemented and can work fine
 even there.

do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it
do> is for IPv4.

 I agree with this change, but I am still not sure if we should have
 $ipv6_network_interfaces itself.  The current implementation is
 equivalent to always AUTO while the default value is set NONE (see
 ipv6if()). The reason I changed it to NONE simply because we need to
 extend list_net_interfaces() for per-AF listing first.  While I added
 some support for SLAAC, it is still not enough and not used yet.

 Setting $ipv6_network_interfaces (or $network_interfaces) to non-AUTO
 value is for narrowing down the interface list which the rc.d scripts
 handle, but I think this should be okay with non-AF-specific one only
 for the same reason as not having $ipv6_enable.

 Anyway, the current one is incomplete.  Changing to "AUTO" is
 harmless unless we do not use list_net_interfaces() to list
 interfaces for some kind of automatic configuration.

do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol
do> by default, but manual configuration should still be possible.

 Why accepting RA and sending RS by default?  I object this because it
 is too problematic.  The KAME implementation does not care about
 receiving RAs from multiple networks and we cannot control the
 accept-or-not.  My patch for per-IF ACCEPT_RTADV handling was the
 first step, but still I can imagine cases which cause surprising
 results for sysadmins.

 My opinion is: receiving RA must be enabled only when explicitly
 specified.  If the box is a "host" with only one physical interface
 and there is no network configuration it might be good to send RS for
 SLAAC as the last resort, but it is still risky.  For IPv4 we do not
 invoke dhclient by default.

 This is not so simple.  A network interface can appears by cloning or
 adding a new NIC into the system, and then devd(8) invokes rc.d/netif
 via /etc/pccard_ether asynchronously.  If the kernel accepts RAs by
 default, these dynamically-added ones will also become RA-receiving
 interfaces.  Pseudo ifconfig flags like NORTADV don't work for them.

 Unconditionally accepting RAs is harmful, but we still have limited
 countermeasures.  While I recently added DEFROUTE_RTADV flag in my
 private branch /user/hrs/ipv6 as another step for that, I believe the
 disadvantages outweigh the positives at this moment.

-- Hiroki