Un-obsolete'ing ipv6_enable
Doug Barton
and return it to the status of being the knob that actually controls
whether or not we configure IPv6. My understanding is that the consensus
is in agreement with this change, however I'm posting my proposed patch
(minus the rc.conf(5) change) just in case. If you have any objection,
please speak up sooner rather than later.
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/
Bjoern A. Zeeb
Hi,
> As we've previously discussed, I would like to un-obsolete ipv6_enable,
> and return it to the status of being the knob that actually controls
> whether or not we configure IPv6. My understanding is that the consensus
> is in agreement with this change, however I'm posting my proposed patch
> (minus the rc.conf(5) change) just in case. If you have any objection,
> please speak up sooner rather than later.
I am not sure where the previous discussion happened anymore but I
veto to bring back ipv6_enable this way. It's not going to do what
you promise above.
It will be utterly confusing for people to have
ipv6_enable="NO"
ifconfig_if0_ipv6="inet6 2001:db8::1/64"
and find that IPv6 is still enabled and working on if0.
Further I can no longer find a way to say "accept rtadv messages on the
upstream interface but by default do not on any other of the
interfaces while still having IPv6 enabled" unless I configure an
ifconfig_ifN_ipv6="..." for all of them.
I would immediately vote for removing the backward stuff to cleanup
the code though.
/bz
--
Bjoern A. Zeeb It will not break if you know what you are doing.
Hiroki Sato
in <4B945AA7...@FreeBSD.org>:
do> As we've previously discussed, I would like to un-obsolete ipv6_enable,
do> and return it to the status of being the knob that actually controls
do> whether or not we configure IPv6. My understanding is that the consensus
do> is in agreement with this change, however I'm posting my proposed patch
do> (minus the rc.conf(5) change) just in case. If you have any objection,
do> please speak up sooner rather than later.
I do not think we reached the consensus on reverting the change. In
my understanding there are people who want $ipv6_enable but the
reason why is they just feel they need a way to disable the
functionality.
The current implementation is based on a concept of "to enable IPv6
all you need is simply adding an IPv6 GUA to the interface", which is
the same as what we have for IPv4 configuration, and it has an
additional seatbelt to prevent unexpected IPv6 communication when
ipv6_prefer=NO (default).
The $ipv6_enable does not disable the functionality actually contrary
to people's expectation, and another problem is that what will be
done by such per-protocol *_enable knobs are not intuitive. After
changing $ipv6_enable=YES (or NO), what rc.d script should be invoked
to reflect the change, for example? What to be done is nothing but
configuring NICs, routes, and network options in the same way as for
IPv4. Because we have IPv6-enabled kernel as the GENERIC, some basic
initialization is needed even if the sysadmin do not want to use IPv6
at all. I think we do not need to have $ipv6_enable since we do not
have $ipv4_enable.
-- Hiroki
David Horn
The question is what is the desired end-state for the rc.conf
configuration of ipv6 ?
Do we want to have a per-interface setting required to enable ipv6 SLAAC ?
Do we want to have a global setting for ipv6 SLAAC ?
Or do we want to choose sane defaults and allow the user to over-ride
on both a global default, and a per-interface basis ?
So, in the 8.0-RELEASE code (and previous TTBOMK), both IPv4 DHCP and
IPv6 SLAAC required manual enabling, although it was inconsistent in
that one was global (IPV6 accept_rtadv), and one was per-interface
(IPv4 DHCP). Some of this has already started to change in -current.
Question 1) Based upon history, sane defaults would be do nothing (NO
DHCPv4, NO IPv6 accept_rtadv). Do you agree with this as the
continued defaults ?
Question 2) Assuming that people do desire consistency with allowing
for both a global, and a per-interface setting, do you agree with
having a global default for DHCPv4 (dhcpv4_default_enable), and for
IPv6 slaac/accept_rtadv (ipv6-slaac_default_enable), and the
per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
meta configuration variable.
Note, it is trivial to allow the meta configuration variable to be
allowed on EITHER ifconfig_IF0, or ifconfig_IF0_ipv6, etc, so that is
not really germain to the discussion at this point.
Do people understand what I am proposing here, or do you want me to
put together a diff with an implementation to properly review ?
The disable side of the over-rides would be something like: NOAUTO,
NODHCP, NOSLAAC meta configuration variables for the per-interface
configuration.
Do people understand what I am proposing here, or do you want me to
put together a diff with an implementation to properly review ? I
already have some of it working in a separate experiment for adding
DHCPv6 configurations.
---Dave Horn
Hiroki Sato
in <25ff90d61003082037v351...@mail.gmail.com>:
dh> The question is what is the desired end-state for the rc.conf
dh> configuration of ipv6 ?
dh>
dh> Do we want to have a per-interface setting required to enable ipv6 SLAAC ?
dh> Do we want to have a global setting for ipv6 SLAAC ?
dh> Or do we want to choose sane defaults and allow the user to over-ride
dh> on both a global default, and a per-interface basis ?
dh>
dh> So, in the 8.0-RELEASE code (and previous TTBOMK), both IPv4 DHCP and
dh> IPv6 SLAAC required manual enabling, although it was inconsistent in
dh> that one was global (IPV6 accept_rtadv), and one was per-interface
dh> (IPv4 DHCP). Some of this has already started to change in -current.
dh>
dh> Question 1) Based upon history, sane defaults would be do nothing (NO
dh> DHCPv4, NO IPv6 accept_rtadv). Do you agree with this as the
dh> continued defaults ?
I am for "no automatic configuration unless one specifies it", but it
should be able to be configured in a per-interface basis as well as
global basis.
dh> Question 2) Assuming that people do desire consistency with allowing
dh> for both a global, and a per-interface setting, do you agree with
dh> having a global default for DHCPv4 (dhcpv4_default_enable), and for
dh> IPv6 slaac/accept_rtadv (ipv6-slaac_default_enable), and the
dh> per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
dh> meta configuration variable.
I think the global configuration can be realized by setting something
like ifconfig_DEFAULT_<proto>="AUTO" instead of adding a new global
knobs.
dh> Do people understand what I am proposing here, or do you want me to
dh> put together a diff with an implementation to properly review ? I
dh> already have some of it working in a separate experiment for adding
dh> DHCPv6 configurations.
Yeah, actually I received your proposal a month ago and I should have
put it to the wiki or so. Sorry about that. I will work on that
soon for the further discussion.
-- Hiroki
David Horn
> David Horn <dhor...@gmail.com> wrote
> in <25ff90d61003082037v351...@mail.gmail.com>:
>
> dh> The question is what is the desired end-state for the rc.conf
> dh> configuration of ipv6 ?
> dh>
> dh> Do we want to have a per-interface setting required to enable ipv6 SLAAC ?
> dh> Do we want to have a global setting for ipv6 SLAAC ?
> dh> Or do we want to choose sane defaults and allow the user to over-ride
> dh> on both a global default, and a per-interface basis ?
> dh>
> dh> So, in the 8.0-RELEASE code (and previous TTBOMK), both IPv4 DHCP and
> dh> IPv6 SLAAC required manual enabling, although it was inconsistent in
> dh> that one was global (IPV6 accept_rtadv), and one was per-interface
> dh> (IPv4 DHCP). Some of this has already started to change in -current.
> dh>
> dh> Question 1) Based upon history, sane defaults would be do nothing (NO
> dh> DHCPv4, NO IPv6 accept_rtadv). Do you agree with this as the
> dh> continued defaults ?
>
> I am for "no automatic configuration unless one specifies it", but it
> should be able to be configured in a per-interface basis as well as
> global basis.
Sorry for the delayed response. I agree with this paradigm.
>
> dh> Question 2) Assuming that people do desire consistency with allowing
> dh> for both a global, and a per-interface setting, do you agree with
> dh> having a global default for DHCPv4 (dhcpv4_default_enable), and for
> dh> IPv6 slaac/accept_rtadv (ipv6-slaac_default_enable), and the
> dh> per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
> dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
> dh> meta configuration variable.
>
> I think the global configuration can be realized by setting something
> like ifconfig_DEFAULT_<proto>="AUTO" instead of adding a new global
> knobs.
Yes, that is certainly one method that can work.
I will put together two review versions of a diff. One with backward
compatible logic included (at least for the ipv6_enable YES/NO cases,
and the ipv6_ifconfig_IF syntax ), and one with the backwards compat
code removed to further this discussion.
Doug Barton
pressing issues. Short version, I think you're taking the wrong approach
here.
Longer version, I'm going to be posting to -current shortly to ask for
opinions on what the defaults should be. My understanding from the last
go-round about this topic was clear, but I'd like to confirm it. I have
a new, more complete patch at
http://people.freebsd.org/~dougb/v6-enable.diff that I'll be writing up
for that post. I'd like to request that we all follow up on that post
when it happens so that the conversation can all happen in the same
location, and with a wider audience.
More details below.
On 03/11/10 20:59, David Horn wrote:
> <snip> for brevity sake
>>> dh> Question 2) Assuming that people do desire consistency with allowing
>>> dh> for both a global, and a per-interface setting, do you agree with
>>> dh> having a global default for DHCPv4 (dhcpv4_default_enable), and for
>>> dh> IPv6 slaac/accept_rtadv (ipv6-slaac_default_enable), and the
>>> dh> per-interface DHCPv4 (ifconfig_IF0="dhcp") aka a meta configuration
>>> dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0="slaac") aka a
>>> dh> meta configuration variable.
I'm not interested in dealing with v4 dhcp as part of this, I want to
focus on getting v6 back to reasonable defaults. You should of course
feel free to pursue your ideas about v4 dhcp separately.
>>> I think the global configuration can be realized by setting something
>>> like ifconfig_DEFAULT_<proto>="AUTO" instead of adding a new global
>>> knobs.
Like I said, I'm hesitant to deal with v4 issues in this context. I'm
even more hesitant to deal with a global autoconf knob. The default v6
configuration is SLAAC, whereas in v4 there is not nearly as much
unanimity.
I actually look forward to a day when DHCPv6 is more common, and then
I'd like to revisit this topic.
> Historically (8.0-RELEASE and prior), there was a global rc.conf knob
> for ipv6 (ipv6_enable, default="NO") that performed several functions:
>
> a) Enabled (or disabled) ipv6 link-local address for every interface
> (auto_linklocal AND -ifdisabled)
> b) Enabled (or disabled) ipv6 SLAAC by default for every interface by
> setting the global net.inet6.ip6.accept_rtadv=1 sysctl
> c) inherently specified utilization of a ipv6 address (AAAA) over an
> ipv4 address (A) when both were available from a dns query when using
> getaddrinfo()
> d) Others I can not think of at the moment ?
>
> As well, there has always been a per-interface variable for IPv4 dhcp
> (The pseudo-variable of "dhcp" on an ifconfig_IF rc.conf line), but no
> global knob.
>
> Now, I propose two new global variables: ipv6_slaac_default_enable,
> ipv4_dhcp_default_enable
> and several new/updated per-interface pseudo variables: auto, noauto,
> accept_rtadv, -accept_rtadv, slaac, noslaac, dhcp, nodhcp
I think (others may disagree) that this is too much complexity. I do
however agree with the idea of decoupling some of the functions that
ipv6_enable did previously. My patch doesn't change the current semantic
of ipv6_prefer, and adds the ability to do specify SLAAC, direct
configuration, and a NORTADV knob on a per-ipv6-interface basis.
> Changelist:
> 4) Misc changes/fixes:
> Changed ifconfig_up() to use ipv6_autoconfif() rather than
> re-checking some values for itself,
I did my own pass on ifconfig_up(), but it ended up looking similar to
yours in some ways. In particular, I agree with this change and have
adopted it.
> and now allow
> ifconfig_em0_ipv6="inet6 2001:db8::1" to work with AND without
> user-specified "inet6", as it used to be implied, and most recently
> was required, and is now optional.
ifconfig_IF for v4 has always required "inet <address>" I don't see any
reason to NOT require inet6 for ifconfig_IF_ipv6. Making things easier
for users is a good thing, but sometimes too many options make things
worse, not better. :)
> Change ipv6_network_interfaces to default to "AUTO" just like
> network_interfaces (consistency is the theme)
This I agree with (on both counts), as I've stated previously.
More to come on -current.