Re: ipv6_enable

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.

-- Hiroki