ipv6_enable
Doug Barton
Hash: RIPEMD160
hrs@ has been doing some great work on bringing IPv6 support up to par
with IPv4, and deserves a lot of credit for that work. Included in those
changes were changes to the traditional semantics of how ipv6_enable
works. That variable was previously overloaded to allow general IPv6
configuration support, rtsol autoconfiguration, and preference of IPv6
vs. IPv4. The ipv6_prefer variable was introduced to handle the first
and third functions, and ipv6_enable was deprecated.
In previous discussions on various lists (including this one) there
seems to have been general consensus on the following ideas:
1. There should be an ipv6_enable knob to easily turn IPv6 configuration
on and off when INET6 is in the kernel. I think the value of this kind
of knob is obvious, but I'd be happy to elaborate if that is necessary.
2. ipv6_network_interfaces should be set to AUTO, the same way that it
is for IPv4.
3. Each IPv6 interface (other than lo0) should be configured with rtsol
by default, but manual configuration should still be possible.
The first question is, are the defaults listed above reasonable? I'd
like to see some sort of consensus on this before we proceed with any
changes.
Next, I have a patch that implements the defaults suggested above that I
want to offer for testing and review:
http://people.freebsd.org/~dougb/v6-enable.diff
The patch has several features in addition to changing the defaults. The
network.subr changes in particular are difficult to visualize via the
diff, it's probably easier to apply it in a test tree and review it that
way.
1. Clean up and optimize the following functions:
ifconfig_up (the ipv6 elements)
noafif
ipv6if
ipv6_autoconfif
The general concepts of the cleanups were to move the "easy" tests
earlier in the functions, consolidate duplicate code, and of course to
make things work with the above-listed defaults.
2. Convert noafif() to use is_wired_interface() instead of listing
wireless interfaces explicitly.
3. In rc.d/netoptions, add code for an ipv6_privacy option to use RFC
4193 style privacy addresses (this is what windows does by default, FYI).
4. In /etc/defaults/rc.conf:
Add ipv6_enable back, default to off. If a user has INET6 in the kernel
(which it does by default) no external interfaces will be configured
unless the user enables it. The lo0 interface is always configured if
INET6 is in the kernel.
Set ipv6_network_interfaces to AUTO.
Switch ipv6_prefer to YES. If ipv6_enable is not set this will have no
effect.
5. Document all of this in rc.conf.5.
Enjoy,
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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEAREDAAYFAku3Dh4ACgkQyIakK9Wy8Pur8ACg9du7VjeEy5nxfeP1/Ij6RDQc
nqgAoLfOdoOGY48MzW7OOZMWRsBKMe+g
=S8zx
-----END PGP SIGNATURE-----
Hiroki Sato
in <4BB70E1E...@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.
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.
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. Also, we should not consider
IPv6 as special. Why we have to have $ipv6_enable while we don't
have $ipv4_enable? I am using INET6-only machines for years and the
process removing the IPv4 dependency in the userland was really hard,
but I believe "no line for the protocol in /etc/rc.conf means no
configuration" is a policy which can be implemented and can work fine
even there.
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. The current implementation is
equivalent to always AUTO while the default value is set NONE (see
ipv6if()). The reason I changed it to NONE simply because we need to
extend list_net_interfaces() for per-AF listing first. While I added
some support for SLAAC, it is still not enough and not used yet.
Setting $ipv6_network_interfaces (or $network_interfaces) to non-AUTO
value is for narrowing down the interface list which the rc.d scripts
handle, but I think this should be okay with non-AF-specific one only
for the same reason as not having $ipv6_enable.
Anyway, the current one is incomplete. Changing to "AUTO" is
harmless unless we do not use list_net_interfaces() to list
interfaces for some kind of automatic configuration.
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? 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.
My opinion is: receiving RA must be enabled only when explicitly
specified. If the box is a "host" with only one physical interface
and there is no network configuration it might be good to send RS for
SLAAC as the last resort, but it is still risky. For IPv4 we do not
invoke dhclient by default.
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.
Unconditionally accepting RAs is harmful, but we still have limited
countermeasures. While I recently added DEFROUTE_RTADV flag in my
private branch /user/hrs/ipv6 as another step for that, I believe the
disadvantages outweigh the positives at this moment.
-- Hiroki
Doug Barton
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.
On 04/03/10 04:51, Hiroki Sato wrote:
> Doug Barton <do...@freebsd.org> wrote
> in <4BB70E1E...@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.
> 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." :)
> 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.
> 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.
> 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.
> 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.
> 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.
hth,
Doug
Kevin Oberman
> From: Doug Barton <do...@FreeBSD.org>
> Sender: owner-free...@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.
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: obe...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Hiroki Sato
in <201004040533...@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
sth...@nethelp.no
> enable L3 address autoconfiguration without explicit configuration
> before. This is reasonable and should be kept for IPv6, too.
Agree 100%. Having IPv6 SLAAC as the default is a bad idea.
On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for
the top level IPv6 functionality - even if it doesn't do a 100% job.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Doug Barton
>> 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.
>
> Agree 100%. Having IPv6 SLAAC as the default is a bad idea.
>
> On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for
> the top level IPv6 functionality - even if it doesn't do a 100% job.
Thanks for your response. Do you think the compromise that I suggested
in my response to Kevin, enabling SLAAC for the interface if DHCP is in
use for IPv4 is reasonable?
Doug Barton
especially from those who have actual working knowledge of IPv6. I'm
going to snip the bits where we agree for ease of reading.
On 04/03/10 22:33, Kevin Oberman wrote:
>> Date: Sat, 03 Apr 2010 17:49:40 -0700
>> From: Doug Barton <do...@FreeBSD.org>
>> Sender: owner-free...@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 <do...@freebsd.org> wrote
>>> in <4BB70E1E...@FreeBSD.org>:
>> 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.
Yes, my sentiment is serious, but the practicalities dictated the smiley
at the end. :)
>>> do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol
>>> do> by default, but manual configuration should still be possible.
>
> 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.
I've read the various opinions regarding having RA on by default, and
have reconsidered my position. Therefore I'd like to offer a compromise.
What I'm after is that modulo the need to toggle ipv6_enable if a user
has an interface configured with IPv4 that the same interface should
"just work" with IPv6. Given that RA is the default method of IPv6
deployment, and given that it will almost certainly be necessary, I
thought enabling it by default was a good idea. However I'm nothing if
not reasonable. :)
So I'd like to suggest returning the default in ipv6_autoconfif() to
off, but enabling it if the user has a DHCP option in their IPv4
configuration for that same interface. To that end I've modified my
patch, you can see the new version at
http://people.freebsd.org/~dougb/v6-enable-2.diff. I've also added
support for an RTADV keyword in ifconfig_IF_ipv6 and updated rc.conf.5
to match.
I think this is a reasonable compromise, as those users who are using
DHCP for IPv4 already have the expectation that their interfaces will be
automatically configured. Those who are manually specifying their v4
addresses will have a little more work to get IPv6 up and running, but I
can just send them to Hiroki or Steinar for help. :)
Incidental to the RA default, when working on this new patch I noticed
that noafif() is only ever called by ipv6_autoconfif() so I changed it
to be in line rather than a separate function.
Doug Barton
> "Kevin Oberman" <obe...@es.net> wrote
> in <201004040533...@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.
Kevin Oberman
> From: Doug Barton <do...@FreeBSD.org>
>
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.
Hiroki Sato
in <4BB7E224...@FreeBSD.org>:
do> As we've discussed previously, you and I have a lot of disagreement on
do> some of these principles. I'm going to outline my responses in some
do> detail, however I'm also interested in what others have to say since I'd
do> ultimately like to see some consensus from the community on how this
do> should be configured.
Yes, I agree that it is good to have discussion with more people.
do> I'm just about the biggest rc.d purist there is, and even I don't agree
do> with this. :) I also disagree with your idea that "the original design
do> of rc.d scripts" didn't intend for concepts like this.
Sorry for the noise. This involves my preference and was a different
story. Please ignore this for IPv6 discussion for the moment.
do> > Second, if people need a way to disable IPv6 protocol, they have
do> > already the way; no IPv6 configuration in /etc/rc.conf. If you need
do> > a handy way for on-and-off, separating the IPv6 configuration from
do> > rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into
do> > /etc/rc.conf should be enough, for example.
do>
do> Even if I agreed with this idea (and I don't necessarily have strong
do> DISagreement with it) the knob has existed since the beginning of IPv6
do> support in FreeBSD, and shouldn't be removed lightly. Personally I find
do> it handy to be able to configure things in rc.conf and turn them on and
do> off with one knob without having to comment or uncomment a bunch of stuff.
I didn't removed it *lightly*. My motivation for that is I want to
enable IPv6 by default without making trouble for IPv4-only people.
I also committed several kernel-level measures for people who want
IPv4-only, IPv6-only, and the both to live without the knob at that
time.
Enabling/disabling IPv6 by using rc.d script was quite complex and
the switching will be incomplete with no kernel support. My
conclusion for integration of the network_ipv6->netif changes was
"depend on if adding an GUA or not" and it works fine for
asynchronous invocation of rc.d/netif as well as needs no reboot for
the switch (see another email for the whole story). Some processing
which were in network_ipv6 (calculating $rtsol_interface and so on)
are intentionally removed thanks to this assumption. If you want to
go back to the old days and enable receiving RA by default, we must
look into the whole process carefully again.
If people want to disable IPv6 GUA assignment in per-AF manner, it
should be done by per-AF global knobs for $ifconfig_* because the GUA
assignment involves $ifconfig_* knobs only for the user as explained
in another email.
Let me summarize what I agree and disagree again:
a. I agree that it is useful to have a knob for disabling all of
ifconfig_IF_ipv6 handling. However, I disagree with using the
name "ipv6_enable" just for the purpose. ipv6_enable=NO never
means disabling IPv6 functionality in the kernel, and it will
cause people tend to think IPv6 is disabled completely.
If we want to disable ifconfig_IF_AF lines in a handy manner,
implementing ifconfig_DEFAULT_AF is more consistent and where we
should go. All of AF-specific parameters for an interface are in
$ifconfig_IF_AF, and having a global knob to define the default
for all interfaces are quite reasonable to me. I do not want to
go back to AF-specific handling like ipv6_* wherever possible.
I think this policy is compatible with David Horn's suggestions.
"ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default,
"ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default,
"ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for
example (note that I do not stick to these keywords. "slaac"
would also be a good candidate). No concern for
conflicting/confusing with IPv4; this is orthogonal among AFs. We
can support another new method by just adding a keyword.
Note that SLAAC and DHCPv6 are exclusive. Combinations of
DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the
latter is rather popular). This is one of the reasons I stick to
the per-IF/per-AF solution here.
b. Disagree with disabling IPv6 by default. I think there is no
technical and security reason to go back to the old days.
do> > Also, we should not consider IPv6 as special.
do>
do> I wish that were so, but I disagree. I think we need to make it as easy
do> as possible for users to take advantage of IPv6, but there are a lot of
do> reasons why it is actually special. Primarily because unlike some of our
do> other networking protocols it's "on the cusp" of being something that
do> everyone will need someday, but isn't quite ready for prime time.
IMO, at least for handling in rc.d scripts, it is not necessary to
consider IPv6 as a special AF after I added AF-specific $ifconfig_*
knobs, rc.d/netoptions changes, and so on.
And, well, please let me suggest something for the further discussion
here. Whether we have $ipv6_enable or not, whether we enable
$ipv6_enable by default or not, and whether receiving RA by default
or not, are separated topics from each other. So, I would like
everyone's opinions for the following points separately:
1. Do we need a knob to disable IPv6? If so, which in the following
is expected for that knob?
1-a) Disable ifconfig_IF_ipv6 processing only. This means people
can still do manual configuration for IPv6.
1-b) Disable IPv6 functionlity completely.
2. If we have a knob described in 1, what should be the default
value?
3. Do we go for "accept RAs by default"? We can break down this in
the following way related to 2:
3-a) Enable IPv6 functionality and accept RAs by default.
3-b) Enable IPv6 functionality and not accept RAs by default
3-c) Disable IPv6 functionality by default and accept RAs if one
enables IPv6 in rc.conf.
3-d) Disable IPv6 functionality by default and not accept RAs even
if one enables IPv6 in rc.conf.
My answers for them are:
1. No objection for 1-a, but if so the name $ipv6_enable is wrong to
me. If people needs 1-b, it should be $ipv6_enable. I have no
strong opinion on whether we have one of or both of them. If we
can reach a consensus to have 1-b, I am ready to implement the
necessary changes.
2. I am for "enabled by default" regardless of 1-a or 1-b.
3. I am for 3-b.
-- Hiroki
sth...@nethelp.no
> >> enable L3 address autoconfiguration without explicit configuration
> >> before. This is reasonable and should be kept for IPv6, too.
> >
> > Agree 100%. Having IPv6 SLAAC as the default is a bad idea.
> >
> > On the other hand, I *do* like a single rc.conf knob (ipv6_enable) for
> > the top level IPv6 functionality - even if it doesn't do a 100% job.
>
> Thanks for your response. Do you think the compromise that I suggested
> in my response to Kevin, enabling SLAAC for the interface if DHCP is in
> use for IPv4 is reasonable?
I think this is reasonable. However, I think it would also be worth
while to revisit this point when DHCPv6 has evolved to do a more
complete job (like assign a default gateway).
Doug Barton
Absolutely. That's why I wanted to add the [NO]RTADV knobs, so that you
could combine them with DHCPv6 options.
Hiroki Sato
in <4BB95564...@FreeBSD.org>:
do> On 04/04/10 02:41, Hiroki Sato wrote:
do> > "Kevin Oberman" <obe...@es.net> wrote
do> > in <201004040533...@ptavv.es.net>:
do> >
do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
do> > ob> see no reason not to use them to enable or disable functionality whether
do> > ob> it involves a script in rc.d or not. The idea is to have a clear,
do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's
do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'.
do> >
do> > Another reason I lean to not using xxx_enable is that an rc.d knob
do> > cannot control enabling/disabling the IPv6 functionality actually.
do> > It was true even when we were using the network_ipv6 script.
do>
do> But that's equally true of how you're using ipv6_prefer. :) You've
do> basically just moved the overloading of 2 of the 3 previous functions of
do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3
do> functions into different knobs.
No, the current ipv6_prefer=NO has nothing to do with disabling IPv6.
It is just related to source address selection and a seatbelt for
IPv4-only people. I do not think I just moved the old functions.
Let me explain how these changes happened. As I explained earlier, I
added $ipv6_prefer to *enable IPv6 by default*. IPv6 needs some
configuration even if you do not use IPv4 when the kernel supports
it, and skipping all of IPv6 configuration in the old
rc.d/network_ipv6 script caused another problems. So, I thought it
was possible to enable IPv6 by default and initialize the
functionality with reasonable default parameters. This parameters
included "disable ACCEPT_RTADV by default", which is one of the
topics we are discussing now.
After I moved the initialization outside of the $ipv6_enable, then I
noticed that the rest which should be inside of the $ipv6_enable is
IPv6 GUA address assignments and routing settings only. Here I
stepped further; I changed the disabling feature of $ipv6_enable into
"whether an IPv6 address is assigned or not". That was the whole
story.
The old rc.d/network_ipv6 had a lot more for IPv6 configuration in
the $ipv6_enable conditional clause and ipv6_enable=NO meant to
disable them, too. This is a big difference. The new ipv6_enable in
your patch is not the same in this regard.
Well, I can understand and agree that people want a handy knob to
disable IPv6. I think it is more constructive for this discussion to
be more specific what should be disabled, then. I am still not sure
what you and other people mean by "disable IPv6".
My opinion is "ipv6_enable=NO" should mean disabling IPv6
functionality completely. I do not want to call a knob just to
ignore ifconfig_IF_ipv6 lines as "ipv6_enable" as well as do not want
to disable IPv6 functionality completely by default. So I am
interested in what people want more precisely.
-- Hiroki
John Hay
These questions actually start more questions for me. :-) Maybe we should
also think from the user perspective and list a few use cases and what a
user need to put in rc.conf to make that work?
Your normal desktop/notebook user on a ipv6 radv network, what does he
need to do to have his machine ipv6 usable?
A network server that does not accept radv, what should its ipv6 config
in rc.conf look like?
What about a server that accept radv (so that it can get router info)
and have fixed addresses for it services?
A router kind of box, what should it look like?
Maybe by stating these, and other, use-cases, it will make it easier to
work back to what should happen under the hood? :-) And maybe if we can
document this well in rc.conf(5) for instance, it would make it easier
for people to start with ipv6.
BTW I have been running an ipv6 network for 10+ years, but the SLAAC
acronym is still strange to me. :-)
BTW2 RA on the network has bitten us a few times on the network, but it
always turned out to be innocent mistakes. We have also had rogue DHCP
servers, which also was innocent mistakes, so I doubt if just moving
from RA to DHCP6 will be the answer. :-)
John
--
John Hay -- jh...@meraka.csir.co.za / jh...@FreeBSD.org
Doug Barton
disagreements about how this thing should look. I think that's
unfortunate, since you have a lot of good ideas, I just think some of
them are wrong. :) Seriously though, I hope we can find a way to come to
agreement.
I'm going to repeat myself one more time here, and in response to your
other post, and then step back and let others express their opinions.
I'd really like to come to an agreement on how to proceed in the next
couple days.
I think most of what you've got here is right, and I've tried to
preserve it in my changes. My understanding is that lo0 needs to be
configured if INET6 is in the kernel, but none of the other interfaces
need to be.
> The old rc.d/network_ipv6 had a lot more for IPv6 configuration in
> the $ipv6_enable conditional clause and ipv6_enable=NO meant to
> disable them, too. This is a big difference. The new ipv6_enable in
> your patch is not the same in this regard.
The end result is the same though. If ipv6_enable=no then when
ifconfig_up() calls ipv6if() it'll come back negative, and that
interface won't be configured for IPv6 at all. Specifically, the "inet6
ifdisabled" ifconfig arg will be given.
> Well, I can understand and agree that people want a handy knob to
> disable IPv6. I think it is more constructive for this discussion to
> be more specific what should be disabled, then. I am still not sure
> what you and other people mean by "disable IPv6".
My definition is "not configuring IPv6 on any interface other than lo0."
> My opinion is "ipv6_enable=NO" should mean disabling IPv6
> functionality completely.
If we had a method of "turning off" IPv6 at the kernel level even though
INET6 is in the kernel then I would agree with you. Since we don't have
that, "inet6 ifdisabled" is the next best option.
> I do not want to call a knob just to
> ignore ifconfig_IF_ipv6 lines as "ipv6_enable"
That's not what I'm proposing, have you actually looked at my patch?
> as well as do not want
> to disable IPv6 functionality completely by default.
I don't know exactly what you mean by this. I _think_ you mean that IPv6
functionality should remain available, but that the interfaces should
not be configured unless there is a specific configuration given via
ifconfig_IF_ipv6. Is that right? If so, I agree with you, and my patch
accomplishes this. The difference being that in v2 of the patch RA has
to be enabled in ifconfig_IF_ipv6, OR it will be enabled if there is
IPv4 DHCP configuration for the interface.
Doug Barton
> Doug Barton <do...@FreeBSD.org> wrote
> in <4BB7E224...@FreeBSD.org>:
>
> should be done by per-AF global knobs for $ifconfig_* because the GUA
> assignment involves $ifconfig_* knobs only for the user as explained
> in another email.
To be honest, I think what you're proposing is way too complicated, and
unnecessarily so. I think you've got a very interesting vision for where
we should end up down the road, but as I said in a previous message I
think your proposed UI is much too complex.
> Let me summarize what I agree and disagree again:
>
> a. I agree that it is useful to have a knob for disabling all of
> ifconfig_IF_ipv6 handling.
That's not what I'm actually proposing. Your idea is that the model
should be focused on ifconfig_IF_ipv6. I'd like to make that completely
unnecessary for the common case (RA).
> However, I disagree with using the
> name "ipv6_enable" just for the purpose. ipv6_enable=NO never
> means disabling IPv6 functionality in the kernel, and it will
> cause people tend to think IPv6 is disabled completely.
Throughout this discussion you've been ignoring something very
important. The ipv6_enable knob already existed, and already had well
understood semantics, which you removed. IMO this is a serious POLA
violation.
What I'm suggesting is a return to the same semantics that we had
previously, but with your improvements running under the hood. I think
being able to disable RA particularly and IPv6 generally on a
per-interface basis is a tremendous improvement.
> If we want to disable ifconfig_IF_AF lines in a handy manner,
> implementing ifconfig_DEFAULT_AF is more consistent and where we
> should go. All of AF-specific parameters for an interface are in
> $ifconfig_IF_AF, and having a global knob to define the default
> for all interfaces are quite reasonable to me. I do not want to
> go back to AF-specific handling like ipv6_* wherever possible.
>
> I think this policy is compatible with David Horn's suggestions.
> "ifconfig_DEFAULT_ipv6=DHCP" for DHCPv6 by default,
> "ifconfig_DEFAULT_ipv6=accept_rtadv" for SLAAC by default,
> "ifconfig_fxp0_ipv6=-accept_rtadv" for no-SLAAC for fxp0, for
> example (note that I do not stick to these keywords. "slaac"
> would also be a good candidate). No concern for
> conflicting/confusing with IPv4; this is orthogonal among AFs. We
> can support another new method by just adding a keyword.
Once again, I think what you're proposing is interesting, but way too
complex. I certainly think it's too complex as a first step.
> Note that SLAAC and DHCPv6 are exclusive.
That's not accurate, but it's outside the scope of this issue.
> Combinations of
> DHCPv6-NA + SLAAC, or DHCPv6-PD + SLAAC are not extreme (the
> latter is rather popular). This is one of the reasons I stick to
> the per-IF/per-AF solution here.
Once again, we don't disagree on the principle, that's why I'm adding
support for [NO]RTADV so that down the road we could have something like
ifconfig_IF_ipv6="RTADV DHCPV6-PD", etc.
> b. Disagree with disabling IPv6 by default. I think there is no
> technical and security reason to go back to the old days.
Need to be clear on what this means. Given that INET6 is in GENERIC
(which I think it should be) we have to have a sensible default when it
comes to configuring the external interfaces. IMO the only sensible
default for that is not to. Configuring them by default when the user
doesn't actually have IPv6 connectivity to the outside world would cause
a lot of problems.
> And, well, please let me suggest something for the further discussion
> here. Whether we have $ipv6_enable or not, whether we enable
> $ipv6_enable by default or not, and whether receiving RA by default
> or not, are separated topics from each other. So, I would like
> everyone's opinions for the following points separately:
>
> 1. Do we need a knob to disable IPv6? If so, which in the following
> is expected for that knob?
>
> 1-a) Disable ifconfig_IF_ipv6 processing only. This means people
> can still do manual configuration for IPv6.
My version of the patch does this.
> 1-b) Disable IPv6 functionlity completely.
We don't currently have a way to do this at all if INET6 is in the kernel.
> 2. If we have a knob described in 1, what should be the default
> value?
Off.
> 3. Do we go for "accept RAs by default"? We can break down this in
> the following way related to 2:
>
> 3-a) Enable IPv6 functionality and accept RAs by default.
>
> 3-b) Enable IPv6 functionality and not accept RAs by default
>
> 3-c) Disable IPv6 functionality by default and accept RAs if one
> enables IPv6 in rc.conf.
I think this is the right answer, but others have expressed disagreement
on accepting RAs by default.
> 3-d) Disable IPv6 functionality by default and not accept RAs even
> if one enables IPv6 in rc.conf.
3-e) ipv6_enable=no by default, RAs if DHCP is configured for the
interface, or if the user explicitly configures it.
> My answers for them are:
>
> 1. No objection for 1-a, but if so the name $ipv6_enable is wrong to
> me. If people needs 1-b, it should be $ipv6_enable. I have no
> strong opinion on whether we have one of or both of them. If we
> can reach a consensus to have 1-b, I am ready to implement the
> necessary changes.
I would really appreciate it if you'd take a serious look at my
v6-enable-2.diff patch. I think it does a pretty good job of restoring
the previous UI and still maintaining the best of your improvements.
Hiroki Sato
in <4BB95564...@FreeBSD.org>:
After I moved the initialization outside of the $ipv6_enable, then I
noticed that the rest which should be inside of the $ipv6_enable is
IPv6 GUA address assignments and routing settings only. Here I
stepped further; I changed the disabling feature of $ipv6_enable into
"whether an IPv6 address is assigned or not". That was the whole
story.
The old rc.d/network_ipv6 had a lot more for IPv6 configuration in
the $ipv6_enable conditional clause and ipv6_enable=NO meant to
disable them, too. This is a big difference. The new ipv6_enable in
your patch is not the same in this regard.
Well, I can understand and agree that people want a handy knob to
disable IPv6. I think it is more constructive for this discussion to
be more specific what should be disabled, then. I am still not sure
what you and other people mean by "disable IPv6".
My opinion is "ipv6_enable=NO" should mean disabling IPv6
jhell
>> Date: Sun, 04 Apr 2010 20:13:40 -0700
>> From: Doug Barton <do...@FreeBSD.org>
>>
>> On 04/04/10 02:41, Hiroki Sato wrote:
>>> "Kevin Oberman" <obe...@es.net> wrote
>>> in <201004040533...@ptavv.es.net>:
>
> 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.
Not really seeing the correct thread to reply to with this content I
decided to reply to Kevin and lead off from here.
Seeing a lot of *_enable for interfaces makes sense in the traditional
way of configuring daemons or enabling things like rtsold/rtadvd for
IPv6. Don't get me wrong but the below I am not talking about phasing
those _enables out for the daemons.
Personally I believe that using them for such a behavior as configuring
a protocol for a interface is incorrect usage given the current use of
IPv4 and not needing something like ipv4_enable.
Why not skip the need for ipv?_enable all-in-all and leave those out of
the mix?. Since they do not really disable them or enable anything other
than the ability to use and or check ipv6 related daemons.
How about this? (using ath0 as the example interface) and following what
we already do for DHCP on ipv4 interfaces.
ifconfig_ath0_inet6="dead:beef:ffff:1000::1 RTSOL RTADV DHCP"
While right now without inet6 would obviously be ipv4 configured and
when the time comes to switch to IPv6 by default, chop the inet6 into
just inet or inet4. This eventually should lead into a smoother
transition than ipv4_enable ipv6_enable while relieving some of the
checks that to me just seem useless and can be checked for just by the
existance of the above interface with inet6 attached to the end.
Obviously if the configuration line exists then the user wants ipv6
functionality configured so check that line and mark ipv6 enabled.
Maybe its just me but I really think we are trying to check for way to
much here to make it a usable solution for the end user. No offense
intended.
PS: I would really love to sort(1) a rc.conf and have ipv4 and ipv6
functionality sorted together by interface but this is not my main goal
by writing this. Same would go for static_routes but that is another story.
Regards,
--
jhell
Hiroki Sato
in <2010040508...@zibbi.meraka.csir.co.za>:
jh> These questions actually start more questions for me. :-) Maybe we should
jh> also think from the user perspective and list a few use cases and what a
jh> user need to put in rc.conf to make that work?
jh>
jh> Your normal desktop/notebook user on a ipv6 radv network, what does he
jh> need to do to have his machine ipv6 usable?
Given that it is 9-CURRENT and the box has 1 NIC (fxp0), add the
following line to rc.conf:
ifconfig_fxp0_ipv6="accept_rtadv"
jh> A network server that does not accept radv, what should its ipv6 config
jh> in rc.conf look like?
ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64"
jh> What about a server that accept radv (so that it can get router info)
jh> and have fixed addresses for it services?
ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64 accept_rtadv"
jh> A router kind of box, what should it look like?
Given that the box has 2 NICs (fxp0 and fxp1), add the following lines
to rc.conf:
ipv6_gateway_enable="YES"
ifconfig_fxp0_ipv6="inet6 2001:db8:1::1/64"
ifconfig_fxp1_ipv6="inet6 2001:db8:2::1/64"
And, no ifconfig_IF_ipv6 line means no IPv6 configuration for the IF.
After my changes committed last September, the existence of
ifconfig_IF_ipv6 is used as a flag for whether IPv6 is enable or not
on that interface.
-- Hiroki
Doug Barton
> in <4BB95564...@FreeBSD.org>:
>
> do> On 04/04/10 02:41, Hiroki Sato wrote:
> do> > "Kevin Oberman" <obe...@es.net> wrote
> do> > in <201004040533...@ptavv.es.net>:
> do> >
> do> > ob> The use of FACILITY_enable in rc.conf predates /etc/rc.d scripts and I
> do> > ob> see no reason not to use them to enable or disable functionality whether
> do> > ob> it involves a script in rc.d or not. The idea is to have a clear,
> do> > ob> obvious way to enable or disable functionality. I see nothing in Hiroki's
> do> > ob> proposal that is nearly as clear and to the point as 'ipv6_enable'.
> do> >
> do> > Another reason I lean to not using xxx_enable is that an rc.d knob
> do> > cannot control enabling/disabling the IPv6 functionality actually.
> do> > It was true even when we were using the network_ipv6 script.
> do>
> do> But that's equally true of how you're using ipv6_prefer. :) You've
> do> basically just moved the overloading of 2 of the 3 previous functions of
> do> ipv6_enable to ipv6_prefer. I am suggesting that we split all 3
> do> functions into different knobs.
>
> No, the current ipv6_prefer=NO has nothing to do with disabling IPv6.
if checkyesno ipv6_prefer; then
_ipv6_opts="-ifdisabled"
else
_ipv6_opts="ifdisabled"
fi
In any case, I give up.
Reasonable arguments for not continuing to pursue ipv6_enable:
1. Of those who expressed an opinion, it was roughly evenly divided
between support and opposition.
2. In the months since your original commit, I'm the only one who has
expressed a strong preference for keeping it.
Unreasonable arguments: I am completely out of time and energy to
continue discussing it.
So, I just committed r206408 that has most of my previously posted
changes, but altered to fit both the lack of ipv6_enable, and the
requirement to explicitly configure the interface. I've chosen to take
the complete lack of commentary on any of my previous patches to be
implicit approval of the changes. The one area where we did seem to
reach consensus is that ipv6_network_interfaces=AUTO is a reasonable
intermediate step, so I've included that change as well.
The actual changes and the rationale for them are described in the
commit message. The documentation in rc.conf.5 is greatly expanded as
well, which I think should make things perfectly clear.
With these changes you can now configure RA as simply as adding
ifconfig_<interface>_ipv6=RTADV to rc.conf (assuming of course that
INET6 is in the kernel). The lo0 interface will continue to be
configured by default. If there are no ifconfig_<interface>_ipv6 options
for any of the other interfaces they will not be configured for IPv6 at
all.
Any commentary on the technical merits of the changes is welcome
assuming that the code has been reviewed and understood.
Regards,