Re: ipv6_enable

> Date: Sun, 04 Apr 2010 20:13:40 -0700
> From: Doug Barton <dougb_at_FreeBSD.org>
> 
> On 04/04/10 02:41, Hiroki Sato wrote:
> > "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.
> 
> But that's equally true of how you're using ipv6_prefer. :)  You've
> basically just moved the overloading of 2 of the 3 previous functions of
> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3
> functions into different knobs.
> 
> I also have a lot of sympathy for the idea that there "should" be a
> sysctl or something to "switch off" IPv6 functionality even if INET6 is
> in the kernel. However, doing so is beyond my ability, and even if I
> _could_ do that, I'd _still_ want to toggle it with ipv6_enable. :)
> 
> >  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. 
> 
> I think I can see your perspective on this, however I don't agree with
> you. It also seems to me that the consensus seems to be forming around
> the idea that maintaining the ipv6_enable knob is a good thing.
> 
> >  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".
> 
> I actually agree that this is a problem, which is why I've jiggled the
> order in etc/defaults/rc.conf a bit, and expanded the documentation in
> rc.conf.5. At the end of the day though, I agree that there is a
> learning curve, but I think that given the default of having INET6 in
> GENERIC it's necessary. Also, this issue doesn't change with the way
> you're using ipv6_prefer, it just moves the problem to that knob instead
> of _enable.
> 
> >  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".  
> 
> I agree with your concerns in this area, which is why I moved the
> testing of ipv6_enable into ipv6if(). This way we don't get either of
> the problems you described.
> 
> > 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.
> 
> As I've said previously, I think this is a good goal, of which I am 100%
> supportive. I probably shouldn't have included the aside about IPv4
> stuff in my previous post, sorry for distracting the conversation.
> 
> > 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 this might be an interesting next step, I will have to think
> more about it. At this time however I would really like to get HEAD back
> to something that reasonably resembles the previous status quo for the
> user interface in concept, with your improved features running under the
> hood.
> 
> >  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.
> 
> Thank you for clarifying your goals. Hopefully by now it's clear that I
> generally agree with the direction that you're going, I would just like
> to move a little slower.
> 
> > 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.
> 
> See my response to Kevin on this topic.

Gentlemen,

I think this is converging on a good, functional solution. Making
ipv6_enable="NO" really turn off IPv6 looks like the ideal answer, but I
think it's up to Hiroki to determine if it is feasible. I did my last
kernel programming on VMS about 25 years ago and it was in assembly and
BLISS, not C.

I am just a bit uncomfortable with the use of the DHCP tag in rc.conf
to control the use of SLAAC as SLAAC is so different in function and
capability from DHCPv4, but it's probably the best we can do.

Thanks to both of you for your attention to this. I think IPv6 is
critical and anything that makes the transition easier will bear great
fruit at time goes on.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751