dougb at FreeBSD.org
Mon Apr 5 03:13:44 UTC 2010
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
> 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
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> 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> 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
> 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> 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.
... and that's just a little bit of history repeating.
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
More information about the freebsd-current