hrs at FreeBSD.org
Sat Apr 3 11:52:40 UTC 2010
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100403/58373690/attachment.pgp
More information about the freebsd-current