Date: Mon, 8 Mar 2010 23:37:44 -0500 From: David Horn <dhorn2000@gmail.com> To: Hiroki Sato <hrs@freebsd.org> Cc: freebsd-net@freebsd.org, dougb@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Un-obsolete'ing ipv6_enable Message-ID: <25ff90d61003082037v3519995bx7e119e9d14143db4@mail.gmail.com> In-Reply-To: <20100309.072719.200228546.hrs@allbsd.org> References: <4B945AA7.6070000@FreeBSD.org> <20100309.072719.200228546.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 8, 2010 at 5:27 PM, Hiroki Sato <hrs@freebsd.org> wrote: > Doug Barton <dougb@freebsd.org> wrote > =A0in <4B945AA7.6070000@FreeBSD.org>: > > do> As we've previously discussed, I would like to un-obsolete ipv6_enabl= e, > 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 consen= sus > do> is in agreement with this change, however I'm posting my proposed pat= ch > do> (minus the rc.conf(5) change) just in case. If you have any objection= , > do> please speak up sooner rather than later. > > =A0I do not think we reached the consensus on reverting the change. =A0In > =A0my understanding there are people who want $ipv6_enable but the > =A0reason why is they just feel they need a way to disable the > =A0functionality. > > =A0The current implementation is based on a concept of "to enable IPv6 > =A0all you need is simply adding an IPv6 GUA to the interface", which is > =A0the same as what we have for IPv4 configuration, and it has an > =A0additional seatbelt to prevent unexpected IPv6 communication when > =A0ipv6_prefer=3DNO (default). > > =A0The $ipv6_enable does not disable the functionality actually contrary > =A0to people's expectation, and another problem is that what will be > =A0done by such per-protocol *_enable knobs are not intuitive. =A0After > =A0changing $ipv6_enable=3DYES (or NO), what rc.d script should be invoke= d > =A0to reflect the change, for example? =A0What to be done is nothing but > =A0configuring NICs, routes, and network options in the same way as for > =A0IPv4. =A0Because we have IPv6-enabled kernel as the GENERIC, some basi= c > =A0initialization is needed even if the sysadmin do not want to use IPv6 > =A0at all. =A0I think we do not need to have $ipv6_enable since we do not > =A0have $ipv4_enable. 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=3D"dhcp") aka a meta configuration variable, and a per-interface IPv6 slaac (ifconfig_IF0=3D"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25ff90d61003082037v3519995bx7e119e9d14143db4>