Re: ipv6_enable

"Kevin Oberman" <oberman_at_es.net> wrote
  in <20100404053352.E6F751CC13_at_ptavv.es.net>:

ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
ob> see no reason not to use them to enable or disable functionality whether
ob> it involves a script in rc.d or not. The idea is to have a clear,
ob> obvious way to enable or disable functionality. I see nothing in Hiroki's
ob> proposal that is nearly as clear and to the point as 'ipv6_enable'.

 Another reason I lean to not using xxx_enable is that an rc.d knob
 cannot control enabling/disabling the IPv6 functionality actually.
 It was true even when we were using the network_ipv6 script.

 I agree that the idea to use $xxx_enable is clear, but I think it is
 better not to use it because it cannot make the functionality
 enable/disable completely in this IPv6 case.  "To use IPv6, please
 add an IPv6 GUA to the interface" makes everything simple.  If we
 really need a knob for enable/disable, $ipv6_enable is the best.
 However, if it cannot disable actually, $xxx_enable is just a
 confusing name.  I added $ipv6_prefer and removed $ipv6_enable
 because of this reason.

 I have seen a lot of people who are trying to add an IPv6 address to
 use IPv6 but do not notice they have ipv6_enable="NO".  The trouble
 is that it actually works with some incomplete configurations.  I
 want to get rid of such a possibility.  Especially issues of "an
 interface has an IPv6 GUA and no link-local address" and "sysadmins
 who want IPv4 only do not notice an IPv6 link-local address can do L3
 communication".  The current default settings are not the best, but a
 result of trade-off.

ob> > Have you ported any of those changes to FreeBSD? There is a lot of talk
ob> > currently about a near-term future when internal networks are v6-only,
ob> > and all communication with v4 networks happen over some kind of
ob> > translation layer. I'm not sure whether I like those ideas or not, but I
ob> > think it would be great for FreeBSD to be in a leadership role here.
ob>
ob> I hate the idea. I want a end-to-end network that can be trivially
ob> subordinated to the control of any entity and allows for the innovation
ob> that an end-to-end network allows. I also fear the stability of massive
ob> carrier grade NAT systems. There is a huge amount of state required for
ob> CGN and if something goes wrong, it goes VERY wrong.

 My goal is for eliminating implicit IPv4 dependency and make the
 world AF-neutral wherever possible, not eliminating IPv4.  Something
 like changes to rc.d/netoptions in HEAD is a good example.

ob> > > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it
ob> > > do> is for IPv4.
ob> > >
ob> > >  I agree with this change, but I am still not sure if we should have
ob> > >  $ipv6_network_interfaces itself.
ob> >
ob> > I think it's useful because people may want to configure some interfaces
ob> > for v6 and not others.
ob>
ob> I agree with Doug, here, though I think its use will be very limited.
ob> (But maybe I will be wrong.)

 I agree with the usefulness, but we can implement this functionality
 with no $ipv6_network_interfaces.  For example, $network_interfaces
 is for all IFs and AFs, "ifconfig_DEFAULT_AF=IGNORE" is per-AF, and
 "ifconfig_IF_AF=IGNORE" is per-AF+IF.

 I think it is not necessary to have a global knobs for a specific AF
 because we already have a per-AF knob for each IF as described above.
 The reason why we have ipv6_* knobs equivalent to ones for IPv4 is
 that the "ipv6_"-prefixed knobs were used in KAME to separate the
 IPv6 knobs from the existing IPv4 ones.  As I explained, I want to
 merge the duplicates in AF-neutral manner.  Not want to eliminate the
 existing functionality itself.

ob> > >  For IPv4 we do not invoke dhclient by default.
ob> >
ob> > I think this is an apples and oranges comparison. IPv6 has a lot of
ob> > similarities to IPv4, but they have a lot of differences as well. As I
ob> > said above (for better or worse) RA is fundamental to the design and
ob> > implementation of IPv6, and for almost all users it will be necessary in
ob> > order to get IPv6 connectivity up.
ob>
ob> I agree with Doug. This is one of the few areas where IPv4 and IPv6 are
ob> really different. While I don't agree that accepting RTADV should be the
ob> default, the IPv4 comparison is really not relevant.

 No, my intension is not to compare IPv4 and IPv6 here.  We have never
 enable L3 address autoconfiguration without explicit configuration
 before.  This is reasonable and should be kept for IPv6, too.

-- Hiroki