dougb at FreeBSD.org
Sun Apr 4 00:49:44 UTC 2010
As we've discussed previously, you and I have a lot of disagreement on
some of these principles. I'm going to outline my responses in some
detail, however I'm also interested in what others have to say since I'd
ultimately like to see some consensus from the community on how this
should be configured.
On 04/03/10 04:51, Hiroki Sato wrote:
> 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
I'm just about the biggest rc.d purist there is, and even I don't agree
with this. :) I also disagree with your idea that "the original design
of rc.d scripts" didn't intend for concepts like this.
> 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.
Even if I agreed with this idea (and I don't necessarily have strong
DISagreement with it) the knob has existed since the beginning of IPv6
support in FreeBSD, and shouldn't be removed lightly. Personally I find
it handy to be able to configure things in rc.conf and turn them on and
off with one knob without having to comment or uncomment a bunch of stuff.
> 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.
The standard way for users to configure stuff like this is rc.conf.
That's a feature. :) Yes, more detailed knobs exist, but should the
user have to learn about them?
> Also, we should not consider IPv6 as special.
I wish that were so, but I disagree. I think we need to make it as easy
as possible for users to take advantage of IPv6, but there are a lot of
reasons why it is actually special. Primarily because unlike some of our
other networking protocols it's "on the cusp" of being something that
everyone will need someday, but isn't quite ready for prime time.
> Why we have to have $ipv6_enable while we don't have $ipv4_enable?
I actually look forward to the day when we have an ipv4_enable, and look
forward even more to the day when it defaults to "off." :)
> I am using INET6-only machines for years and the
> process removing the IPv4 dependency in the userland was really hard,
Have you ported any of those changes to FreeBSD? There is a lot of talk
currently about a near-term future when internal networks are v6-only,
and all communication with v4 networks happen over some kind of
translation layer. I'm not sure whether I like those ideas or not, but I
think it would be great for FreeBSD to be in a leadership role here.
> 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.
I think it's useful because people may want to configure some interfaces
for v6 and not others.
> 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?
Because (like it or not) that's how the protocol works for the vast
majority of IPv6 networks. I think users should have the reasonable
expectation that if they enable IPv6 it should "just work."
That said, I added the NORTADV knob precisely because I look forward to
the day when we have other viable options like DHCPv6. When the default
for IPv6 configuration is no longer RA this should be revisited.
> 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.
I actually agree with these concerns. I personally don't like RA, I
think it has all the security concerns you describe and more. But it IS
the way that the world works at the moment. DHCPv6 is in its infancy,
which means that the only viable configuration options right now are RA
and direct configuration via ifconfig_IF_v6. In the latter case my patch
disables RA entirely for that interface.
> For IPv4 we do not invoke dhclient by default.
I think this is an apples and oranges comparison. IPv6 has a lot of
similarities to IPv4, but they have a lot of differences as well. As I
said above (for better or worse) RA is fundamental to the design and
implementation of IPv6, and for almost all users it will be necessary in
order to get IPv6 connectivity up.
> 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.
First, I am not proposing flipping the kernel sysctl by default, however
the end result of my change is effectively the same; with the defaults
I'm proposing any new interface that comes up would be configured with
RA. However I think what you're describing is an extreme edge case.
Users who add new interfaces to a system that has working IPv6 would
generally expect that the new interfaces would also work, by default.
... and that's just a little bit of history repeating.
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
More information about the freebsd-current