ipv6_enable

[Doug Barton]

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.


Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/