jhay at meraka.org.za
Mon Apr 5 08:31:04 UTC 2010
On Mon, Apr 05, 2010 at 02:42:52PM +0900, Hiroki Sato wrote:
> Doug Barton <dougb at FreeBSD.org> wrote
> in <4BB7E224.6020508 at FreeBSD.org>:
> do> As we've discussed previously, you and I have a lot of disagreement on
> do> some of these principles. I'm going to outline my responses in some
> do> detail, however I'm also interested in what others have to say since I'd
> do> ultimately like to see some consensus from the community on how this
> do> should be configured.
> Yes, I agree that it is good to have discussion with more people.
> do> I'm just about the biggest rc.d purist there is, and even I don't agree
> do> with this. :) I also disagree with your idea that "the original design
> do> of rc.d scripts" didn't intend for concepts like this.
> Sorry for the noise. This involves my preference and was a different
> story. Please ignore this for IPv6 discussion for the moment.
> do> > Second, if people need a way to disable IPv6 protocol, they have
> do> > already the way; no IPv6 configuration in /etc/rc.conf. If you need
> do> > a handy way for on-and-off, separating the IPv6 configuration from
> do> > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into
> do> > /etc/rc.conf should be enough, for example.
> do> Even if I agreed with this idea (and I don't necessarily have strong
> do> DISagreement with it) the knob has existed since the beginning of IPv6
> do> support in FreeBSD, and shouldn't be removed lightly. Personally I find
> do> it handy to be able to configure things in rc.conf and turn them on and
> do> off with one knob without having to comment or uncomment a bunch of stuff.
> I didn't removed it *lightly*. My motivation for that is I want to
> enable IPv6 by default without making trouble for IPv4-only people.
> I also committed several kernel-level measures for people who want
> IPv4-only, IPv6-only, and the both to live without the knob at that
> Enabling/disabling IPv6 by using rc.d script was quite complex and
> the switching will be incomplete with no kernel support. My
> conclusion for integration of the network_ipv6->netif changes was
> "depend on if adding an GUA or not" and it works fine for
> asynchronous invocation of rc.d/netif as well as needs no reboot for
> the switch (see another email for the whole story). Some processing
> which were in network_ipv6 (calculating $rtsol_interface and so on)
> are intentionally removed thanks to this assumption. If you want to
> go back to the old days and enable receiving RA by default, we must
> look into the whole process carefully again.
> 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.
> 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. 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.
> 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.
> Note that SLAAC and DHCPv6 are exclusive. 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.
> b. Disagree with disabling IPv6 by default. I think there is no
> technical and security reason to go back to the old days.
> do> > Also, we should not consider IPv6 as special.
> do> I wish that were so, but I disagree. I think we need to make it as easy
> do> as possible for users to take advantage of IPv6, but there are a lot of
> do> reasons why it is actually special. Primarily because unlike some of our
> do> other networking protocols it's "on the cusp" of being something that
> do> everyone will need someday, but isn't quite ready for prime time.
> IMO, at least for handling in rc.d scripts, it is not necessary to
> consider IPv6 as a special AF after I added AF-specific $ifconfig_*
> knobs, rc.d/netoptions changes, and so on.
> 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.
> 1-b) Disable IPv6 functionlity completely.
> 2. If we have a knob described in 1, what should be the default
> 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.
> 3-d) Disable IPv6 functionality by default and not accept RAs even
> if one enables IPv6 in rc.conf.
> 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.
> 2. I am for "enabled by default" regardless of 1-a or 1-b.
> 3. I am for 3-b.
These questions actually start more questions for me. :-) Maybe we should
also think from the user perspective and list a few use cases and what a
user need to put in rc.conf to make that work?
Your normal desktop/notebook user on a ipv6 radv network, what does he
need to do to have his machine ipv6 usable?
A network server that does not accept radv, what should its ipv6 config
in rc.conf look like?
What about a server that accept radv (so that it can get router info)
and have fixed addresses for it services?
A router kind of box, what should it look like?
Maybe by stating these, and other, use-cases, it will make it easier to
work back to what should happen under the hood? :-) And maybe if we can
document this well in rc.conf(5) for instance, it would make it easier
for people to start with ipv6.
BTW I have been running an ipv6 network for 10+ years, but the SLAAC
acronym is still strange to me. :-)
BTW2 RA on the network has bitten us a few times on the network, but it
always turned out to be innocent mistakes. We have also had rogue DHCP
servers, which also was innocent mistakes, so I doubt if just moving
from RA to DHCP6 will be the answer. :-)
John Hay -- jhay at meraka.csir.co.za / jhay at FreeBSD.org
More information about the freebsd-current