From owner-freebsd-rc@FreeBSD.ORG Tue Mar 9 04:37:48 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0AA0106566C; Tue, 9 Mar 2010 04:37:48 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id C08D88FC13; Tue, 9 Mar 2010 04:37:46 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so2057369fge.13 for ; Mon, 08 Mar 2010 20:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P7S9Xl2FwyTFbpZpnLNiGY2+L4cHLrwzGCTKZKV1Jd8=; b=e1mH3zDRQxj4cVRg8Un7k2U7dCLTEKov+4yKNm5V4QhX6g/RoW1uzwHNSXojax04IJ 4eFaPCOU4v8yVQaaKvvUnkX6Sr4vxPKF15Vy2wBF2g0heTkY/RuAZ06PVeJzLhPppgyM FehrYAT9w6E9rgWbL/NbefQGIhgnF6hBaX+40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QS/8mJzMr4TRChbRBkVQBnFfGhScwSeTvVIgDZ8USN7pLJaKOryz2k7V/gNwlPYBzT upMPuF2ymE0BlzsQg6ZgVJ1GobrImi6swIacjUA4FDz6Dk6vFbRHVBo2ZamFMfLS0w7u dZ2DVKroSS/iolmdTsqYMQbHwu2bjr8f3+G3o= MIME-Version: 1.0 Received: by 10.239.186.1 with SMTP id e1mr27257hbh.162.1268109464811; Mon, 08 Mar 2010 20:37:44 -0800 (PST) In-Reply-To: <20100309.072719.200228546.hrs@allbsd.org> References: <4B945AA7.6070000@FreeBSD.org> <20100309.072719.200228546.hrs@allbsd.org> Date: Mon, 8 Mar 2010 23:37:44 -0500 Message-ID: <25ff90d61003082037v3519995bx7e119e9d14143db4@mail.gmail.com> From: David Horn To: Hiroki Sato Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, dougb@freebsd.org, freebsd-rc@freebsd.org Subject: Re: Un-obsolete'ing ipv6_enable X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 04:37:48 -0000 On Mon, Mar 8, 2010 at 5:27 PM, Hiroki Sato wrote: > Doug Barton 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