Re: ipv6_enable

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>
> 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
>  time.
> 
>  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>
> 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
>     value?
> 
>  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
-- 
John Hay -- jhay_at_meraka.csir.co.za / jhay_at_FreeBSD.org