Un-obsolete'ing ipv6_enable

Doug Barton dougb at FreeBSD.org
Sat Apr 3 07:42:13 UTC 2010


Sorry it's taken me so long to get back to this, had a lot of other
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.


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/



More information about the freebsd-rc mailing list