Re: ipv6_enable

> Date: Sat, 03 Apr 2010 17:49:40 -0700
> From: Doug Barton <dougb_at_FreeBSD.org>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> As we've discussed previously, you and I have a lot of disagreement on
> some of these principles. I'm going to outline my responses in some
> detail, however I'm also interested in what others have to say since I'd
> ultimately like to see some consensus from the community on how this
> should be configured.

I guess it's time to put in my $.02. I do have some experience with
IPv6. I have the first system to run a production IPv6 address in that
ARIN region sitting under my desk in Berkeley.

I agree with one of Doug's points and one of Hiroki's.
> 
> On 04/03/10 04:51, Hiroki Sato wrote:
> > Doug Barton <dougb_at_freebsd.org> wrote
> >   in <4BB70E1E.3090102_at_FreeBSD.org>:
> > 
> > do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration
> > do> on and off when INET6 is in the kernel. I think the value of this kind
> > do> of knob is obvious, but I'd be happy to elaborate if that is necessary.
> > 
> >  There were reasons related to technical difficulty and inconsistency
> >  (and a bit my preference) to drop $ipv6_enable.
> > 
> >  First, we are overly abusing $xxx_enable knob even when no
> >  corresponding rc.d/xxx file.  I think $xxx_enable knob should be used
> >  only for rc.d/xxx whenever possible.  It is intuitive, and what the
> >  original design of rc.d scripts intended.  Although this would be
> >  another topic, it was one of the motivation for me to remove the
> >  knob.
> 
> I'm just about the biggest rc.d purist there is, and even I don't agree
> with this. :)  I also disagree with your idea that "the original design
> of rc.d scripts" didn't intend for concepts like this.
> 
> >  Second, if people need a way to disable IPv6 protocol, they have
> >  already the way; no IPv6 configuration in /etc/rc.conf.  If you need
> >  a handy way for on-and-off, separating the IPv6 configuration from
> >  rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into
> >  /etc/rc.conf should be enough, for example.
> 
> Even if I agreed with this idea (and I don't necessarily have strong
> DISagreement with it) the knob has existed since the beginning of IPv6
> support in FreeBSD, and shouldn't be removed lightly. Personally I find
> it handy to be able to configure things in rc.conf and turn them on and
> off with one knob without having to comment or uncomment a bunch of stuff.
> 

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

> > After all, protocols cannot be disabled only by using rc.d scripts.
> > If we really need the way to do that, we have to have kernel-level
> > knobs like sysctl or ifconfig flag.
> 
> The standard way for users to configure stuff like this is rc.conf.
> That's a feature. :)  Yes, more detailed knobs exist, but should the
> user have to learn about them?
> 
> >  Also, we should not consider IPv6 as special.
> 
> I wish that were so, but I disagree. I think we need to make it as easy
> as possible for users to take advantage of IPv6, but there are a lot of
> reasons why it is actually special. Primarily because unlike some of our
> other networking protocols it's "on the cusp" of being something that
> everyone will need someday, but isn't quite ready for prime time.
> 
> >  Why we have to have $ipv6_enable while we don't have $ipv4_enable?
> 
> I actually look forward to the day when we have an ipv4_enable, and look
> forward even more to the day when it defaults to "off." :)

It's possible that the time will come this decade when IPv4 is really
not needed by the typical user, but I don't expect utilization to drop
low enough that it would be appropriate to make the default "no"
(certainly not "off"). POLA and general conservatism will prevent this
for a long time.

> >  I am using INET6-only machines for years and the
> >  process removing the IPv4 dependency in the userland was really hard,
> 
> Have you ported any of those changes to FreeBSD? There is a lot of talk
> currently about a near-term future when internal networks are v6-only,
> and all communication with v4 networks happen over some kind of
> translation layer. I'm not sure whether I like those ideas or not, but I
> think it would be great for FreeBSD to be in a leadership role here.

I hate the idea. I want a end-to-end network that can be trivially
subordinated to the control of any entity and allows for the innovation
that an end-to-end network allows. I also fear the stability of massive
carrier grade NAT systems. There is a huge amount of state required for
CGN and if something goes wrong, it goes VERY wrong.

> > do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it
> > do> is for IPv4.
> > 
> >  I agree with this change, but I am still not sure if we should have
> >  $ipv6_network_interfaces itself. 
> 
> I think it's useful because people may want to configure some interfaces
> for v6 and not others.

I agree with Doug, here, though I think its use will be very limited.
(But maybe I will be wrong.)

> > do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol
> > do> by default, but manual configuration should still be possible.
> > 
> >  Why accepting RA and sending RS by default?
> 
> Because (like it or not) that's how the protocol works for the vast
> majority of IPv6 networks. I think users should have the reasonable
> expectation that if they enable IPv6 it should "just work."
> 
> That said, I added the NORTADV knob precisely because I look forward to
> the day when we have other viable options like DHCPv6. When the default
> for IPv6 configuration is no longer RA this should be revisited.
> 
> >  I object this because it
> >  is too problematic.  The KAME implementation does not care about
> >  receiving RAs from multiple networks and we cannot control the
> >  accept-or-not.  My patch for per-IF ACCEPT_RTADV handling was the
> >  first step, but still I can imagine cases which cause surprising
> >  results for sysadmins.
> 
> I actually agree with these concerns. I personally don't like RA, I
> think it has all the security concerns you describe and more. But it IS
> the way that the world works at the moment. DHCPv6 is in its infancy,
> which means that the only viable configuration options right now are RA
> and direct configuration via ifconfig_IF_v6. In the latter case my patch
> disables RA entirely for that interface.

I would agree with Doug EXCEPT for experiences I have had. I have been
at a conference where a rogue RA totally clobbered the IPv6
network. Yes, not that many of us were running over IPv6, but I was (see
the headers on this message) and it was very annoying. (It was also
totally inadvertent.)

I also know that a large federal research lab discovered that they had
hundreds of systems running IPv6 on their network without knowing
it. Almost all UNIX systems turn it on by default and some systems were
configured for RTADV. It was causing all sorts of problems that were very
hard to track down.

Neither of these cases involved any intent to cause harm, but they
demonstrate that it would not be hard for a miscreant to take advantage
of this.

ATM there is no alternative to running RTADV, and I am hopeful that IETF
finishes and that vendors quickly implement RA-Guard, as well as mods
to DHCPv6 to allow it to operate without needing a system running RTADV
on the wire.

> >  For IPv4 we do not invoke dhclient by default.
> 
> I think this is an apples and oranges comparison. IPv6 has a lot of
> similarities to IPv4, but they have a lot of differences as well. As I
> said above (for better or worse) RA is fundamental to the design and
> implementation of IPv6, and for almost all users it will be necessary in
> order to get IPv6 connectivity up.

I agree with Doug. This is one of the few areas where IPv4 and IPv6 are
really different. While I don't agree that accepting RTADV should be the
default, the IPv4 comparison is really not relevant.
> 
> >  This is not so simple.  A network interface can appears by cloning or
> >  adding a new NIC into the system, and then devd(8) invokes rc.d/netif
> >  via /etc/pccard_ether asynchronously.  If the kernel accepts RAs by
> >  default, these dynamically-added ones will also become RA-receiving
> >  interfaces.  Pseudo ifconfig flags like NORTADV don't work for them.
> 
> First, I am not proposing flipping the kernel sysctl by default, however
> the end result of my change is effectively the same; with the defaults
> I'm proposing any new interface that comes up would be configured with
> RA. However I think what you're describing is an extreme edge case.
> Users who add new interfaces to a system that has working IPv6 would
> generally expect that the new interfaces would also work, by default.

Why? They do not accept the same for IPv4. Why should they for IPv6?

RTADV and automatic configuration seemed like a really good idea. But,
as happens far too often, security issues were not properly
considered. IPv6 is riddled with security issues (not the same as
vulnerabilities) that make me very nervous. I think RTADV is a huge
opportunity for DOS. Not an issue yeat and almost no one is dependent on
IPv6, but that is likely to change.

Just my opinions and I'd like to hear what others think, at least those
who actually use IPv6 and understand the issues. Otherwise this thread
turns into a bikeshed.
-- 
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