From owner-freebsd-rc@FreeBSD.ORG Mon Mar 8 02:02:20 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 DD589106564A for ; Mon, 8 Mar 2010 02:02:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 240258FC16 for ; Mon, 8 Mar 2010 02:02:17 +0000 (UTC) Received: (qmail 697 invoked by uid 399); 8 Mar 2010 02:02:16 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Mar 2010 02:02:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B945AA7.6070000@FreeBSD.org> Date: Sun, 07 Mar 2010 18:02:15 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-rc@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: multipart/mixed; boundary="------------080009000605050204070406" Cc: Subject: Un-obsolete'ing ipv6_enable X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-rc@FreeBSD.org 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: Mon, 08 Mar 2010 02:02:20 -0000 This is a multi-part message in MIME format. --------------080009000605050204070406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. 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/ --------------080009000605050204070406 Content-Type: text/plain; name="v6-prefer-diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="v6-prefer-diff" Index: network.subr =================================================================== --- network.subr (revision 204851) +++ network.subr (working copy) @@ -100,18 +100,12 @@ _ipv6_opts="-accept_rtadv" fi else - if checkyesno ipv6_prefer; then + if checkyesno ipv6_enable; then _ipv6_opts="-ifdisabled" + _ipv6_opts="${_ipv6_opts} accept_rtadv" else _ipv6_opts="ifdisabled" fi - - # backward compatibility: $ipv6_enable - case $ipv6_enable in - [Yy][Ee][Ss]) - _ipv6_opts="${_ipv6_opts} accept_rtadv" - ;; - esac fi if [ -n "${_ipv6_opts}" ]; then Index: rc.d/netif =================================================================== --- rc.d/netif (revision 204851) +++ rc.d/netif (working copy) @@ -41,8 +41,6 @@ extra_commands="cloneup clonedown" cmdifn= -set_rcvar_obsolete ipv6_enable ipv6_prefer - network_start() { # Set the list of interfaces to work on. Index: rc.d/ip6addrctl =================================================================== --- rc.d/ip6addrctl (revision 204851) +++ rc.d/ip6addrctl (working copy) @@ -20,8 +20,6 @@ prefer_ipv6_cmd="ip6addrctl_prefer_ipv6" prefer_ipv4_cmd="ip6addrctl_prefer_ipv4" -set_rcvar_obsolete ipv6_enable ipv6_prefer - ip6addrctl_prefer_ipv6() { afexists inet6 || return 0 Index: defaults/rc.conf =================================================================== --- defaults/rc.conf (revision 204851) +++ defaults/rc.conf (working copy) @@ -439,6 +439,7 @@ icmp_bmcastecho="NO" # respond to broadcast ping packets ### IPv6 options: ### +ipv6_enable="NO" # Set to YES to enable IPv6 configuration. ipv6_network_interfaces="none" # List of IPv6 network interfaces # (or "auto" or "none"). ipv6_defaultrouter="NO" # Set to IPv6 default gateway (or NO). --------------080009000605050204070406-- From owner-freebsd-rc@FreeBSD.ORG Mon Mar 8 11:07:05 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 63D6410656BF for ; Mon, 8 Mar 2010 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4658E8FC1B for ; Mon, 8 Mar 2010 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o28B75VC073800 for ; Mon, 8 Mar 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o28B74GH073798 for freebsd-rc@FreeBSD.org; Mon, 8 Mar 2010 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Mar 2010 11:07:04 GMT Message-Id: <201003081107.o28B74GH073798@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-rc@FreeBSD.org 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: Mon, 08 Mar 2010 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/144400 rc [patch] /etc/rc.d/named - $named_wait_host needs an up o conf/144213 rc [rc.d] [patch] Disappearing zvols on reboot o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances o conf/143084 rc [jail] [patch]: fix rc.d/jail creating stray softlinks o conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141907 rc [rc.d] Bug if mtu (maybe others?) is set as first argu o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/141275 rc [request] dhclient(8) rc script should print something o conf/141258 rc /etc/rc.d/tmp may act incorrectly based on unprivleged o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip o conf/138208 rc [rc] [patch] Making rc.firewall (workstation) IPv6 awa o conf/137629 rc [rc] background_dhclient rc.conf option causing double o conf/137470 rc [PATCH] /etc/rc.d/mdconfig2 : prioritize cli parameter o conf/136875 rc [request] _flags appending o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/135338 rc [rc.d] pf startup order seems broken [regression] o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/134006 rc [patch] Unload console screensaver kernel modules if s o conf/133987 rc [rc.d] defaultroute broken with DHCP in some cases o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/132483 rc rc.subr(8) [patch] setfib(1) support for rc.subr o conf/132476 rc [rc.d] [patch] add support setfib(1) in rc.d/routing o conf/130414 rc [patch] rc services started with onestart are not stop o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/127917 rc [patch] dumpon rejects on start with physmem>swap even o bin/126562 rc rcorder(8) fails to run unrelated startup scripts when o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped p bin/126324 rc [patch] rc.d/tmp: Prevent mounting /tmp in second tim o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug o conf/120431 rc [patch] devfs.rules are not initialized under certain o conf/120406 rc [devd] [patch] Handle newly attached pcm devices (eg. o conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses o conf/118255 rc savecore never finding kernel core dumps (rcorder prob o conf/117935 rc [patch] ppp fails to start at boot because of missing o conf/113915 rc [patch] ndis wireless driver fails to associate when i o conf/109980 rc /etc/rc.d/netif restart doesn't destroy cloned_interfa o conf/109562 rc [rc.d] [patch] [request] Make rc.d/devfs usable from c o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p o conf/105689 rc [ppp] [request] syslogd starts too late at boot o conf/105568 rc [patch] [request] Add more flexibility to rc.conf, to o conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp o conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/99721 rc [patch] /etc/rc.initdiskless problem copy dotfile in s o conf/99444 rc [patch] Enhancement: rc.subr could easily support star o conf/96343 rc [patch] rc.d order change to start inet6 before pf o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d o conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle o conf/89061 rc [patch] IPv6 6to4 auto-configuration enhancement o conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi o conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} o conf/56934 rc [patch] rc.firewall rules for natd expect an interface o conf/45226 rc [patch] Fix for rc.network, ppp-user annoyance o conf/44170 rc [patch] Add ability to run multiple pppoed(8) on start 75 problems total. From owner-freebsd-rc@FreeBSD.ORG Mon Mar 8 19:50:08 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 E1E32106564A; Mon, 8 Mar 2010 19:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 78D968FC18; Mon, 8 Mar 2010 19:50:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0CB8841C759; Mon, 8 Mar 2010 20:50:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id SMKSHRpP9Da6; Mon, 8 Mar 2010 20:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 84B0A41C758; Mon, 8 Mar 2010 20:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 810344448EC; Mon, 8 Mar 2010 19:48:06 +0000 (UTC) Date: Mon, 8 Mar 2010 19:48:06 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-rc@FreeBSD.org In-Reply-To: <4B945AA7.6070000@FreeBSD.org> Message-ID: <20100308193942.W33454@maildrop.int.zabbadoz.net> References: <4B945AA7.6070000@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@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: Mon, 08 Mar 2010 19:50:08 -0000 On Sun, 7 Mar 2010, Doug Barton wrote: 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. From owner-freebsd-rc@FreeBSD.ORG Mon Mar 8 22:44:01 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 CE76D1065700; Mon, 8 Mar 2010 22:44:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (vlsi00.si.noda.tus.ac.jp [133.31.130.32]) by mx1.freebsd.org (Postfix) with ESMTP id 519858FC08; Mon, 8 Mar 2010 22:44:01 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o28MRre5021555; Tue, 9 Mar 2010 07:28:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o28MRmVt084800; Tue, 9 Mar 2010 07:27:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 09 Mar 2010 07:27:19 +0900 (JST) Message-Id: <20100309.072719.200228546.hrs@allbsd.org> To: freebsd-rc@FreeBSD.org, dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4B945AA7.6070000@FreeBSD.org> References: <4B945AA7.6070000@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Mar__9_07_27_19_2010_858)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 09 Mar 2010 07:28:10 +0900 (JST) X-Spam-Status: No, score=0.2 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@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: Mon, 08 Mar 2010 22:44:01 -0000 ----Security_Multipart(Tue_Mar__9_07_27_19_2010_858)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4B945AA7.6070000@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 ----Security_Multipart(Tue_Mar__9_07_27_19_2010_858)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkuVeccACgkQTyzT2CeTzy2W3QCfUOOVn/Qj11m1ohT4lafEGXyF y7cAn2bmUeCQwqiB4ulU1/vKfU/nuYf8 =bvBA -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Mar__9_07_27_19_2010_858)---- 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 From owner-freebsd-rc@FreeBSD.ORG Tue Mar 9 05:01:10 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 AE3F0106566B; Tue, 9 Mar 2010 05:01:10 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (vlsi00.si.noda.tus.ac.jp [133.31.130.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC0A8FC1B; Tue, 9 Mar 2010 05:01:10 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o294xUXY028877; Tue, 9 Mar 2010 13:59:40 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o294xPEZ085092; Tue, 9 Mar 2010 13:59:27 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 09 Mar 2010 13:59:17 +0900 (JST) Message-Id: <20100309.135917.161082188.hrs@allbsd.org> To: dhorn2000@gmail.com From: Hiroki Sato In-Reply-To: <25ff90d61003082037v3519995bx7e119e9d14143db4@mail.gmail.com> References: <4B945AA7.6070000@FreeBSD.org> <20100309.072719.200228546.hrs@allbsd.org> <25ff90d61003082037v3519995bx7e119e9d14143db4@mail.gmail.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Mar__9_13_59_17_2010_019)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Tue, 09 Mar 2010 13:59:47 +0900 (JST) X-Spam-Status: No, score=0.1 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org 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 05:01:10 -0000 ----Security_Multipart(Tue_Mar__9_13_59_17_2010_019)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Horn wrote in <25ff90d61003082037v3519995bx7e119e9d14143db4@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_="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 ----Security_Multipart(Tue_Mar__9_13_59_17_2010_019)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkuV1aUACgkQTyzT2CeTzy0T+ACfSfB0DRdhLNDDKV/Hyx9FCapZ lc4An33sS6Ri6tmKdvUrDmSVYvcq+S/l =fl5R -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Mar__9_13_59_17_2010_019)---- From owner-freebsd-rc@FreeBSD.ORG Thu Mar 11 16:09:22 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 1E0EC106564A; Thu, 11 Mar 2010 16:09:22 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 298568FC17; Thu, 11 Mar 2010 16:09:20 +0000 (UTC) Received: by fxm22 with SMTP id 22so203900fxm.14 for ; Thu, 11 Mar 2010 08:09:20 -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=XCBE7b/FG61qeO6er8yWkcB0QFlWpZ8gvKn3qe2yWwI=; b=n21WvYrO5HF16P7QzIP779pItv2vusUavK3O1eBviP5kIiaLQOK2SvKK5Nshw7j8Gq +pNr0+3CA4AZhHoeDfwF+IYh5iRXmpGffwCKqSbpw0G1222akvaEgLZ4ksWqqIhIgvJ5 p3E5zZX5XqbK33i1IeWX+xVfUiUlKy0P+jJPQ= 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=Qyaq5TqTPo2m2wYZnr6VcKurIpI6Fzucax5XelBUksTUT6qz2D5Vp4hxjnlp4V2f/Y KBrP/OMs+KIZ+Fr4suxuDgODxUfMUaApc+1qz3UtA8cYvHQqqNQI9lJG790KYM/UYDYs Wg3DxrGzIGNuKHklcSzY6HKObj6cn94tZZsNA= MIME-Version: 1.0 Received: by 10.87.44.8 with SMTP id w8mr5327130fgj.16.1268323759972; Thu, 11 Mar 2010 08:09:19 -0800 (PST) In-Reply-To: <20100309.135917.161082188.hrs@allbsd.org> References: <4B945AA7.6070000@FreeBSD.org> <20100309.072719.200228546.hrs@allbsd.org> <25ff90d61003082037v3519995bx7e119e9d14143db4@mail.gmail.com> <20100309.135917.161082188.hrs@allbsd.org> Date: Thu, 11 Mar 2010 11:09:19 -0500 Message-ID: <25ff90d61003110809s4cc775e9r2ff6ebee151be6f6@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: Thu, 11 Mar 2010 16:09:22 -0000 On Mon, Mar 8, 2010 at 11:59 PM, Hiroki Sato wrote: > David Horn wrote > =A0in <25ff90d61003082037v3519995bx7e119e9d14143db4@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 SL= AAC ? > 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). =A0Some of this has already started to change in -curren= t. > dh> > dh> Question 1) =A0Based upon history, sane defaults would be do nothing = (NO > dh> DHCPv4, NO IPv6 accept_rtadv). =A0Do you agree with this as the > dh> continued defaults ? > > =A0I am for "no automatic configuration unless one specifies it", but it > =A0should be able to be configured in a per-interface basis as well as > =A0global 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 =A0(ipv6-slaac_default_enable), and the > dh> per-interface DHCPv4 (ifconfig_IF0=3D"dhcp") aka a meta configuration > dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0=3D"slaac") aka= a > dh> meta configuration variable. > > =A0I think the global configuration can be realized by setting something > =A0like ifconfig_DEFAULT_=3D"AUTO" instead of adding a new global > =A0knobs. 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. > > 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 ? =A0 I > dh> already have some of it working in a separate experiment for adding > dh> DHCPv6 configurations. > > =A0Yeah, actually I received your proposal a month ago and I should have > =A0put it to the wiki or so. =A0Sorry about that. =A0I will work on that > =A0soon for the further discussion. > > -- Hiroki > From owner-freebsd-rc@FreeBSD.ORG Fri Mar 12 04:59:47 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 21003106566C; Fri, 12 Mar 2010 04:59:47 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 03B8F8FC20; Fri, 12 Mar 2010 04:59:45 +0000 (UTC) Received: by fxm1 with SMTP id 1so142962fxm.13 for ; Thu, 11 Mar 2010 20:59:44 -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; bh=UfzzI8KpY8YJ3TVNm9HrXjH/P7Fs/zwUTicSpBKnyW8=; b=EkazdndZE4AGKl6R6Uae/dNOp6clRk2wLuO9OgPA3RGFl1R0dhvZvs8OFugYAj499j RR10w0bBAXRPvkO7tNeLALBhkLEYIlho4Gt2nncE6W1WWKjddkWFU7F42JbiZxK/RmWn BLqbahE4QHYItyfzszQFsKaxTmz78xoKNxJcw= 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; b=wnE6X4MTYZDx7mnW60ccgctXeumc7HT9MfUPnnjmgcPGvivJrPXlM2oLMiZo16xxGH bLVE+KkOjH849pI6MI7xPoYRmt+WMGpXMSEBwxv2JamuGDR0qMFgk5QGbTGQjsNUaT6N N/qHRnpMcVBrcqjJkfP379CVFtg1QhXqugsgw= MIME-Version: 1.0 Received: by 10.239.189.12 with SMTP id r12mr427628hbh.94.1268369984675; Thu, 11 Mar 2010 20:59:44 -0800 (PST) In-Reply-To: <25ff90d61003110809s4cc775e9r2ff6ebee151be6f6@mail.gmail.com> References: <4B945AA7.6070000@FreeBSD.org> <20100309.072719.200228546.hrs@allbsd.org> <25ff90d61003082037v3519995bx7e119e9d14143db4@mail.gmail.com> <20100309.135917.161082188.hrs@allbsd.org> <25ff90d61003110809s4cc775e9r2ff6ebee151be6f6@mail.gmail.com> Date: Thu, 11 Mar 2010 23:59:44 -0500 Message-ID: <25ff90d61003112059r2648543bn812468893fc3b19@mail.gmail.com> From: David Horn To: Hiroki Sato Content-Type: multipart/mixed; boundary=001485f630826160b6048193660e 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: Fri, 12 Mar 2010 04:59:47 -0000 --001485f630826160b6048193660e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 =A0(ipv6-slaac_default_enable), and the >> dh> per-interface DHCPv4 (ifconfig_IF0=3D"dhcp") aka a meta configuratio= n >> dh> variable, and a per-interface IPv6 slaac (ifconfig_IF0=3D"slaac") ak= a a >> dh> meta configuration variable. >> >> =A0I think the global configuration can be realized by setting something >> =A0like ifconfig_DEFAULT_=3D"AUTO" instead of adding a new global >> =A0knobs. > > Yes, that is certainly one method that can work. > > I will put together two review versions of a diff. =A0One 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. > OK, now I am certain I have looked at this far too long at the moment, but here is a stab at a working diff (actually as promised, two diffs against -current, one without backwards compatibility logic). Background: Historically (8.0-RELEASE and prior), there was a global rc.conf knob for ipv6 (ipv6_enable, default=3D"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=3D1 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 Changelist: 1) New or updated global knob for interface configuration: ipv6_enable {global} =3D UNDEFINED/YES/NO, Default=3DUNDEFINED Old, depreciated knob for several ipv6 functions listed above (only in backwards compatible version) Takes precedence over per-interface setting (if it exists) ipv4_dhcp_default_enable {global} =3D YES/NO, Default=3DNO New, global knob for enabling any interface for dhcp by default that does not have a per-interface configuration over-ride. ipv6_slaac_default_enable {global} =3D YES/NO, Default=3DNO New, global knob for enabling any interface for ipv6 slaac by default that does not have a per-interface configuration over-ride. ipv6_prefer {global} =3D YES/NO, Default=3DNO Removed overloading of ipv6_prefer to no longer mean default to enable interface for ipv6 (-ifdisabled). This global variable now just effects rc.d/ip6addrctl behavior. Under seperate cover, I am proposing changing ipv6_prefer behavior to a more useful autoconfigured default (if it can be done reliably) to eliminate the need for the user to need to specify ipv6_prefer at all in most cases. (Check for global ipv6 address assigned to an up interface) TBD. Stay tuned... 2) New or updated interface specific pseudo-variables for ifconfig_IF and/or ifconfig_IF_ipv6: auto {interface-specific} =3D enable both IPv4 DHCP and IPv6 SLAAC noauto {interface-specific} =3D no automatic boot-time configuration - only slightly extended, as this already existed accept_rtadv {interface-specific} =3D enable SLACC via ipv6 router advertisement Note: Also an ifconfig IF inet6 parameter -accept_rtadv {interface-specific} =3D disable SLAAC/ACCEPT_RTADV for that interface Note: Also an ifconfig IF inet6 parameter slaac {interface-specific} =3D ALIAS for accept_rtadv, enable SLAAC via ipv6 router advertisement noslaac {interface-specific} =3D ALIAS for -accept_rtadv, disable SLAAC/ACCEPT_RTADV for that interface Note: Only really needed if global ipv6_slaac_default_enable knob is on dhcp {interface-specific} =3D enable IPv4 DHCP - No change, just listed for completeness sake nodhcp {interface-specific} =3D disable IPv4 DHCP Note: Only really needed if global ipv4_dhcp_default_enable knob is on 3) On Backwards compatible version: ipv6_enable is UNDEFINED by default. If the user has ipv6_enable=3D"NO" defined, this will now DISABLE ipv6 everywhere (just like it used to) If the user has ipv6_enable=3D"YES" define, this will now ENABLE ipv6 everywhere (just like it used to) 4) Misc changes/fixes: Changed ifconfig_up() to use ipv6_autoconfif() rather than re-checking some values for itself, and now allow ifconfig_em0_ipv6=3D"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. Changed ifalias_ipv6_[up|down]() to allow with and without user specified "inet6", and to use the ifconfig_IF_ipv6_aliasX not ifconfig_IF_aliasX, I can revert this change, but then the "inet6" component would be required. After thinking about this, it is a toss up. Change ipv6_network_interfaces to default to "AUTO" just like network_interfaces (consistency is the theme) I am perfectly happy with renaming any of these variable/pseudo variable names to any consensus approved names, or adding/removing aliases, etc. No bikesheds allowed. ;) If anyone requires, I guess I could remove the backwards compatible logic, but add a new global variable for people that want all interfaces disabled for ipv6 completely. As well, I am open to looking at the ifconfig_DEFAULT / ifconfig_DEFAULT_ipv6 syntax rather than adding ipv6_slaac_default_enable and ipv4_dhcp_default_enable global knobs if consensus concurs, but I think the FOO_enable syntax is probably more desirable. The only thing I am really shooting for is a consistant set of knobs and behaviors (as much as is sensible), and to allow a less complicated configuration set for ipv6 rc.conf moving forward. Once there is consensus, I will take a stab at updating the man page for rc.conf as well. Examples: Example 1: enable IPv4 dhcp, and IPv6 slaac on the em0 interface (which happens to be the only interface): In 8.0-RELEASE this would be: ifconfig_em0=3D"dhcp" ipv6_enable=3D"YES" Would now be any of the following (all four are functionally identical): ifconfig_em0=3D"auto" or ifconfig_em0=3D"dhcp slaac" or ifconfig_em0=3D"dhcp" ifconfig_em0_ipv6=3D"slaac" or ifconfig_em0=3D"dhcp accept_rtadv" As well, in the backwards compatible version: ifconfig_em0=3D"dhcp" ipv6_enable=3D"YES" will still work. Example 2: (wlan0)- enable IPv4 dhcp, and IPv6 link-local without slaac (bfe0)- disable IPv4 dhcp, and enable IPv6 slaac (bfe1)- disable IPv4 dhcp, and enable IPv6 static eui64 (bfe2)- enable IPv4 static with no IPv6 link-local In 8.0-RELEASE this would be not possible to disable ipv6 slaac on a per-interface basis, so would require a custom startup script using ndp to disable. The rest of the configuration would be: wlans_iwn0=3D"wlan0" ifconfig_wlan0=3D"wpa dhcp" ifconfig_bfe0=3D"up" ipv6_ifconfig_bfe1=3D"2001:db8:1:: eui64" ifconfig_bfe2=3D"inet 192.168.1.50 netmask 255.255.255.0" ipv6_enable=3D"YES" ndp script would be something like: ndp -i wlan0 nud -accept_rtadv ndp -i bfe2 disabled Would now be: wlans_iwn0=3D"wlan0" ifconfig_wlan0=3D"wpa dhcp" ifconfig_bfe0=3D"slaac" ifconfig_bfe1_ipv6=3D"2001:db8:1:: eui64" ifconfig_bfe2=3D"inet 192.168.1.50 netmask 255.255.255.0" ifconfig_bfe2_ipv6=3D"ifdisabled" I am still trying to track down one bug I have found in my testing (related to ifconfig and eui64 when no link-local address has yet been assigned to a down interface), and am still attempting to grok the $_cfg usage in ifconfig_up(), and I still have several more test cases to complete, but give it a spin (or read if you prefer), and let me know if I have gone horribly off track. As such, this is a work in progress. Comments welcome. --Thanks! --Dave Horn --001485f630826160b6048193660e Content-Type: text/plain; charset=US-ASCII; name="ipv6-network.backcompat.diff.txt" Content-Disposition: attachment; filename="ipv6-network.backcompat.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g6oikhn20 SW5kZXg6IGV0Yy9uZXR3b3JrLnN1YnIKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL25ldHdvcmsuc3Vicgko cmV2aXNpb24gMjA1MDE5KQorKysgZXRjL25ldHdvcmsuc3Vicgkod29ya2luZyBjb3B5KQpAQCAt OTYsNDUgKzk2LDQ3IEBACiAJIyBpbmV0NiBzcGVjaWZpYwogCWlmIGFmZXhpc3RzIGluZXQ2OyB0 aGVuCiAJCWlmIGlwdjZpZiAkMTsgdGhlbgotCQkJaWYgY2hlY2t5ZXNubyBpcHY2X2dhdGV3YXlf ZW5hYmxlOyB0aGVuCisJCQlpZiBpcHY2X2F1dG9jb25maWYgJDE7IHRoZW4KKwkJCQlfaXB2Nl9v cHRzPSJhY2NlcHRfcnRhZHYiCisJCQllbHNlCiAJCQkJX2lwdjZfb3B0cz0iLWFjY2VwdF9ydGFk diIKIAkJCWZpCi0JCWVsc2UKLQkJCWlmIGNoZWNreWVzbm8gaXB2Nl9wcmVmZXI7IHRoZW4KLQkJ CQlfaXB2Nl9vcHRzPSItaWZkaXNhYmxlZCIKLQkJCWVsc2UKLQkJCQlfaXB2Nl9vcHRzPSJpZmRp c2FibGVkIgorCisJCQkjIGlmY29uZmlnX0lGX2lwdjYKKwkJCWlmY29uZmlnX2FyZ3M9YGlmY29u ZmlnX2dldGFyZ3MgJDEgaXB2NmAKKwkJCWlmIFsgLW4gIiR7aWZjb25maWdfYXJnc30iIF07IHRo ZW4KKwkJCQlpZmNvbmZpZyAkMSBpbmV0NiAtaWZkaXNhYmxlZAorCQkJCSMgQmUgbmljZSB0byB1 c2VycyAob3B0aW9uYWwgaW5ldDYpCisJCQkJY2FzZSAke2lmY29uZmlnX2FyZ3N9IGluCisJCQkJ CWluZXQ2XCAqKQorCQkJCQkJaWZjb25maWcgJDEgJHtpZmNvbmZpZ19hcmdzfQorCQkJCQkJOzsK KwkJCQkJKikKKwkJCQkJCWlmY29uZmlnICQxIGluZXQ2IFwKKwkJCQkJCSAke2lmY29uZmlnX2Fy Z3N9CisJCQkJCQk7OworCQkJCWVzYWMKKwkJCQlfY2ZnPTAKIAkJCWZpCiAKLQkJCSMgYmFja3dh cmQgY29tcGF0aWJpbGl0eTogJGlwdjZfZW5hYmxlCi0JCQljYXNlICRpcHY2X2VuYWJsZSBpbgot CQkJW1l5XVtFZV1bU3NdKQotCQkJCV9pcHY2X29wdHM9IiR7X2lwdjZfb3B0c30gYWNjZXB0X3J0 YWR2IgotCQkJCTs7Ci0JCQllc2FjCisJCQkjIGJhY2t3YXJkIGNvbXBhdGlibGl0eTogJGlwdjZf aWZjb25maWdfSUYKKwkJCWlmY29uZmlnX2FyZ3M9YGdldF9pZl92YXIgJDEgaXB2Nl9pZmNvbmZp Z19JRmAKKwkJCWlmIFsgLW4gIiR7aWZjb25maWdfYXJnc30iIF07IHRoZW4KKwkJCQl3YXJuICJc JGlwdjZfaWZjb25maWdfJDEgaXMgb2Jzb2xldGUuIiBcCisJCQkJICAgICIgIFVzZSBpZmNvbmZp Z18kMV9pcHY2IGluc3RlYWQuIgorCQkJCWlmY29uZmlnICQxIGluZXQ2IC1pZmRpc2FibGVkCisJ CQkJaWZjb25maWcgJDEgaW5ldDYgJHtpZmNvbmZpZ19hcmdzfQorCQkJCV9jZmc9MAorCQkJZmkK KworCQllbHNlCisJCQlfaXB2Nl9vcHRzPSJpZmRpc2FibGVkIgogCQlmaQogCiAJCWlmIFsgLW4g IiR7X2lwdjZfb3B0c30iIF07IHRoZW4KIAkJCWlmY29uZmlnICQxIGluZXQ2ICR7X2lwdjZfb3B0 c30KIAkJZmkKLQotCQkjIGlmY29uZmlnX0lGX2lwdjYKLQkJaWZjb25maWdfYXJncz1gaWZjb25m aWdfZ2V0YXJncyAkMSBpcHY2YAotCQlpZiBbIC1uICIke2lmY29uZmlnX2FyZ3N9IiBdOyB0aGVu Ci0JCQlpZmNvbmZpZyAkMSBpbmV0NiAtaWZkaXNhYmxlZAotCQkJaWZjb25maWcgJDEgJHtpZmNv bmZpZ19hcmdzfQotCQkJX2NmZz0wCi0JCWZpCi0KLQkJIyBiYWNrd2FyZCBjb21wYXRpYmxpdHk6 ICRpcHY2X2lmY29uZmlnX0lGCi0JCWlmY29uZmlnX2FyZ3M9YGdldF9pZl92YXIgJDEgaXB2Nl9p ZmNvbmZpZ19JRmAKLQkJaWYgWyAtbiAiJHtpZmNvbmZpZ19hcmdzfSIgXTsgdGhlbgotCQkJd2Fy biAiXCRpcHY2X2lmY29uZmlnXyQxIGlzIG9ic29sZXRlLiIgXAotCQkJICAgICIgIFVzZSBpZmNv bmZpZ18kMV9pcHY2IGluc3RlYWQuIgotCQkJaWZjb25maWcgJDEgaW5ldDYgLWlmZGlzYWJsZWQK LQkJCWlmY29uZmlnICQxIGluZXQ2ICR7aWZjb25maWdfYXJnc30KLQkJCV9jZmc9MAotCQlmaQor CQkKIAlmaQogCiAJaWYgWyAke19jZmd9IC1lcSAwIF07IHRoZW4KQEAgLTI0NCwxMSArMjQ2LDE3 IEBACiAKIAlmb3IgX2FyZyBpbiAkX3RtcGFyZ3M7IGRvCiAJCWNhc2UgJF9hcmcgaW4KKwkJW0Fh XVtVdV1bVHRdW09vXSkgOzsKKwkJW0FhXVtDY11bQ2NdW0VlXVtQcF1bVHRdX1tScl1bVHRdW0Fh XVtEZF1bVnZdKSA7OwogCQlbRGRdW0hoXVtDY11bUHBdKSA7OwogCQlbTm5dW09vXVtBYV1bVXVd W1R0XVtPb10pIDs7CisJCVtObl1bT29dW0RkXVtIaF1bQ2NdW1BwXSkgOzsKKwkJW05uXVtPb11b U3NdW0xsXVtBYV1bQWFdW0NjXSkgOzsKIAkJW05uXVtPb11bU3NdW1l5XVtObl1bQ2NdW0RkXVtI aF1bQ2NdW1BwXSkgOzsKIAkJW1NzXVtZeV1bTm5dW0NjXVtEZF1bSGhdW0NjXVtQcF0pIDs7CisJ CVtTc11bTGxdW0FhXVtBYV1bQ2NdKSA7OwogCQlbV3ddW1BwXVtBYV0pIDs7CisJCS1bQWFdW0Nj XVtDY11bRWVdW1BwXVtUdF1fW1JyXVtUdF1bQWFdW0RkXVtWdl0pIDs7CiAJCSopCiAJCQlfYXJn cz0iJF9hcmdzICRfYXJnIgogCQkJOzsKQEAgLTI4Niw2ICsyOTQsMTIgQEAKIAogCWZvciBfYXJn IGluICRfdG1wYXJnczsgZG8KIAkJY2FzZSAkX2FyZyBpbgorCQlbTm5dW09vXVtBYV1bVXVdW1R0 XVtPb118W05uXVtPb11bRGRdW0hoXVtDY11bUHBdKQorCQkJcmV0dXJuIDEKKwkJCTs7CisJCVtB YV1bVXVdW1R0XVtPb10pCisJCQlyZXR1cm4gMAorCQkJOzsKIAkJW0RkXVtIaF1bQ2NdW1BwXSkK IAkJCXJldHVybiAwCiAJCQk7OwpAQCAtMjk4LDYgKzMxMiwxMCBAQAogCQllc2FjCiAJZG9uZQog CisJaWYgY2hlY2t5ZXNubyBpcHY0X2RoY3BfZGVmYXVsdF9lbmFibGU7IHRoZW4KKwkJcmV0dXJu IDAKKwlmaQorCiAJcmV0dXJuIDEKIH0KIApAQCAtNDEwLDYgKzQyOCwxNiBAQAogCQlyZXR1cm4g MQogCWZpCiAKKwkjIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk6ICRpcHY2X2VuYWJsZQorCWNhc2Ug JGlwdjZfZW5hYmxlIGluCisJW1l5XVtFZV1bU3NdfFtUdF1bUnJdW1V1XVtFZV18W09vXVtObl18 MSkKKwkJcmV0dXJuIDAKKwkJOzsKKwlbTm5dW09vXXxbRmZdW0FhXVtMbF1bU3NdW0VlXXxbT29d W0ZmXVtGZl18MCkKKwkJcmV0dXJuIDEKKwkJOzsKKwllc2FjCisKIAkjIGxvMCBpcyBhbHdheXMg SVB2Ni1lbmFibGVkCiAJY2FzZSAkX2lmIGluCiAJbG8wKQpAQCAtNDUwLDYgKzQ3OCw3IEBACiAj IGlwdjZfYXV0b2NvbmZpZiBpZgogIwlSZXR1cm5zIDAgaWYgdGhlIGludGVyZmFjZSBzaG91bGQg YmUgY29uZmlndXJlZCBmb3IgSVB2NiB3aXRoCiAjCVN0YXRlbGVzcyBBZGRyZXNzIENvbmZpZ3Vy YXRpb24sIDEgb3RoZXJ3aXNlLgorIwlDaGVja3MgcGVyLWludGVyZmFjZSBzZXR0aW5nIGZpcnN0 LCB0aGVuIGdsb2JhbCBkZWZhdWx0CiBpcHY2X2F1dG9jb25maWYoKQogewogCWxvY2FsIF9pZiBf dG1wYXJncyBfYXJnCkBAIC00ODMsMzAgKzUxMiw3MyBAQAogCiAJIyBiYWNrd2FyZCBjb21wYXRp YmlsaXR5OiAkaXB2Nl9lbmFibGUKIAljYXNlICRpcHY2X2VuYWJsZSBpbgotCVtZeV1bRWVdW1Nz XSkKKwlbWXldW0VlXVtTc118W1R0XVtScl1bVXVdW0VlXXxbT29dW05uXXwxKQogCQlyZXR1cm4g MAogCQk7OworCVtObl1bT29dfFtGZl1bQWFdW0xsXVtTc11bRWVdfFtPb11bRmZdW0ZmXXwwKQor CQlyZXR1cm4gMQorCQk7OwogCWVzYWMKIAogCV90bXBhcmdzPWBfaWZjb25maWdfZ2V0YXJncyAk X2lmIGlwdjZgCiAJZm9yIF9hcmcgaW4gJF90bXBhcmdzOyBkbwogCQljYXNlICRfYXJnIGluCi0J CWFjY2VwdF9ydGFkdikKKwkJW05uXVtPb11bQWFdW1V1XVtUdF1bT29dfFtObl1bT29dW1NzXVtM bF1bQWFdW0FhXVtDY10pCisJCQlyZXR1cm4gMQorCQkJOzsKKwkJLVtBYV1bQ2NdW0NjXVtFZV1b UHBdW1R0XV9bUnJdW1R0XVtBYV1bRGRdW1Z2XSkKKwkJCXJldHVybiAxCisJCQk7OworCQlbQWFd W1V1XVtUdF1bT29dfFtTc11bTGxdW0FhXVtBYV1bQ2NdKQorIAkJCXJldHVybiAwCisgCQkJOzsK KwkJW0FhXVtDY11bQ2NdW0VlXVtQcF1bVHRdX1tScl1bVHRdW0FhXVtEZF1bVnZdKQogCQkJcmV0 dXJuIDAKIAkJCTs7CiAJCWVzYWMKIAlkb25lCisgCisJX3RtcGFyZ3M9YF9pZmNvbmZpZ19nZXRh cmdzICRfaWZgCisgICAgICAgIGZvciBfYXJnIGluICRfdG1wYXJnczsgZG8KKyAgICAgICAgICAg ICAgICBjYXNlICRfYXJnIGluCisJCVtObl1bT29dW0FhXVtVdV1bVHRdW09vXXxbTm5dW09vXVtT c11bTGxdW0FhXVtBYV1bQ2NdKQorCQkJcmV0dXJuIDEKKwkJCTs7CisJCS1bQWFdW0NjXVtDY11b RWVdW1BwXVtUdF1fW1JyXVtUdF1bQWFdW0RkXVtWdl0pCisJCQlyZXR1cm4gMQorCQkJOzsKKwkJ W0FhXVtVdV1bVHRdW09vXXxbU3NdW0xsXVtBYV1bQWFdW0NjXSkKKyAJCQlyZXR1cm4gMAorIAkJ CTs7CisJCVtBYV1bQ2NdW0NjXVtFZV1bUHBdW1R0XV9bUnJdW1R0XVtBYV1bRGRdW1Z2XSkKKwkJ CXJldHVybiAwCisJCQk7OworCQllc2FjCisgICAgICAgIGRvbmUKIAotCSMgYmFja3dhcmQgY29t cGF0aWJpbGl0eTogJGlwdjZfaWZjb25maWdfSUYKLQlfdG1wYXJncz1gZ2V0X2lmX3ZhciAkX2lm IGlwdjZfaWZjb25maWdfSUZgCi0JZm9yIF9hcmcgaW4gJF90bXBhcmdzOyBkbwotCQljYXNlICRf YXJnIGluCi0JCWFjY2VwdF9ydGFkdikKKyAJIyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5OiAkaXB2 Nl9pZmNvbmZpZ19JRgorIAlfdG1wYXJncz1gZ2V0X2lmX3ZhciAkX2lmIGlwdjZfaWZjb25maWdf SUZgCisgCWZvciBfYXJnIGluICRfdG1wYXJnczsgZG8KKyAJCWNhc2UgJF9hcmcgaW4KKwkJW05u XVtPb11bQWFdW1V1XVtUdF1bT29dfFtObl1bT29dW1NzXVtMbF1bQWFdW0FhXVtDY10pCisJCQly ZXR1cm4gMQorCQkJOzsKKwkJLVtBYV1bQ2NdW0NjXVtFZV1bUHBdW1R0XV9bUnJdW1R0XVtBYV1b RGRdW1Z2XSkKKwkJCXJldHVybiAxCisJCQk7OworCQlbQWFdW1V1XVtUdF1bT29dfFtTc11bTGxd W0FhXVtBYV1bQ2NdKQorIAkJCXJldHVybiAwCisgCQkJOzsKKwkJW0FhXVtDY11bQ2NdW0VlXVtQ cF1bVHRdX1tScl1bVHRdW0FhXVtEZF1bVnZdKQogCQkJcmV0dXJuIDAKIAkJCTs7CiAJCWVzYWMK IAlkb25lCiAKKwlpZiBjaGVja3llc25vIGlwdjZfc2xhYWNfZGVmYXVsdF9lbmFibGU7IHRoZW4K KwkJcmV0dXJuIDAKKwlmaQorCQogCXJldHVybiAxCiB9CiAKQEAgLTU0Myw3ICs2MTUsNiBAQAog CWlmICEgaXB2NmlmICRfaWY7IHRoZW4KIAkJcmV0dXJuIDAKIAlmaQotCiAJaWZhbGlhc191cCAk e19pZn0gaW5ldDYgJiYgX3JldD0wCiAJaXB2Nl9wcmVmaXhfaG9zdGlkX2FkZHJfdXAgJHtfaWZ9 ICYmIF9yZXQ9MAogCWlwdjZfYWNjZXB0X3J0YWR2X3VwICR7X2lmfSAmJiBfcmV0PTAKQEAgLTcy NSwxMiArNzk2LDE2IEBACiAJIyBpZmNvbmZpZ19JRl9hbGlhc04gd2hpY2ggc3RhcnRzIHdpdGgg ImluZXQ2IgogCWFsaWFzPTAKIAl3aGlsZSA6IDsgZG8KLQkJaWZjb25maWdfYXJncz1gZ2V0X2lm X3ZhciAkMSBpZmNvbmZpZ19JRl9hbGlhcyR7YWxpYXN9YAorCQlpZmNvbmZpZ19hcmdzPWBnZXRf aWZfdmFyICQxIGlmY29uZmlnX0lGX2lwdjZfYWxpYXMke2FsaWFzfWAKIAkJY2FzZSAiJHtpZmNv bmZpZ19hcmdzfSIgaW4KKwkJIiIpCisJCQlicmVhaworCQkJOzsKIAkJaW5ldDZcICopCiAJCQlp ZmNvbmZpZyAkMSAke2lmY29uZmlnX2FyZ3N9IGFsaWFzICYmIF9yZXQ9MAogCQkJOzsKLQkJIiIp CisJCSopCisJCQlpZmNvbmZpZyAkMSBpbmV0NiAke2lmY29uZmlnX2FyZ3N9IGFsaWFzICYmIF9y ZXQ9MAogCQkJYnJlYWsKIAkJCTs7CiAJCWVzYWMKQEAgLTgxNiwxMyArODkxLDE2IEBACiAJIyBp ZmNvbmZpZ19JRl9hbGlhc04gd2hpY2ggc3RhcnRzIHdpdGggImluZXQ2IgogCWFsaWFzPTAKIAl3 aGlsZSA6IDsgZG8KLQkJaWZjb25maWdfYXJncz1gZ2V0X2lmX3ZhciAkMSBpZmNvbmZpZ19JRl9h bGlhcyR7YWxpYXN9YAorCQlpZmNvbmZpZ19hcmdzPWBnZXRfaWZfdmFyICQxIGlmY29uZmlnX0lG X2lwdjZfYWxpYXMke2FsaWFzfWAKIAkJY2FzZSAiJHtpZmNvbmZpZ19hcmdzfSIgaW4KKwkJIiIp CisJCQlicmVhaworCQkJOzsKIAkJaW5ldDZcICopCiAJCQlpZmNvbmZpZyAkMSAke2lmY29uZmln X2FyZ3N9IC1hbGlhcyAmJiBfcmV0PTAKIAkJCTs7Ci0JCSIiKQotCQkJYnJlYWsKKwkJKikKKwkJ CWlmY29uZmlnICQxIGluZXQ2ICR7aWZjb25maWdfYXJnc30gLWFsaWFzICYmIF9yZXQ9MAogCQkJ OzsKIAkJZXNhYwogCQlhbGlhcz0kKCgke2FsaWFzfSArIDEpKQpJbmRleDogZXRjL2RlZmF1bHRz L3JjLmNvbmYKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL2RlZmF1bHRzL3JjLmNvbmYJKHJldmlzaW9uIDIw NTAxOSkKKysrIGV0Yy9kZWZhdWx0cy9yYy5jb25mCSh3b3JraW5nIGNvcHkpCkBAIC0xNTgsNiAr MTU4LDggQEAKIGR1bW15bmV0X2VuYWJsZT0iTk8iCQkjIExvYWQgdGhlIGR1bW15bmV0KDQpIG1v ZHVsZQogaXBfcG9ydHJhbmdlX2ZpcnN0PSJOTyIJCSMgU2V0IGZpcnN0IGR5bmFtaWNhbGx5IGFs bG9jYXRlZCBwb3J0CiBpcF9wb3J0cmFuZ2VfbGFzdD0iTk8iCQkjIFNldCBsYXN0IGR5bmFtaWNh bGx5IGFsbG9jYXRlZCBwb3J0CitpcHY0X2RoY3BfZGVmYXVsdF9lbmFibGU9Ik5PIgkjIFNldCB0 byBZRVMgdG8gZGVmYXVsdCBhbGwgaW50ZXJmYWNlcworCQkJCSMgdG8gYXV0b21hdGljYWxseSB1 c2UgREhDUCBmb3IgSVB2NAogaWtlX2VuYWJsZT0iTk8iCQkJIyBFbmFibGUgSUtFIGRhZW1vbiAo dXN1YWxseSByYWNvb24gb3IgaXNha21wZCkKIGlrZV9wcm9ncmFtPSIvdXNyL2xvY2FsL3NiaW4v aXNha21wZCIJIyBQYXRoIHRvIElLRSBkYWVtb24KIGlrZV9mbGFncz0iIgkJCSMgQWRkaXRpb25h bCBmbGFncyBmb3IgSUtFIGRhZW1vbgpAQCAtNDM5LDggKzQ0MSwxMCBAQAogaWNtcF9ibWNhc3Rl Y2hvPSJOTyIJIyByZXNwb25kIHRvIGJyb2FkY2FzdCBwaW5nIHBhY2tldHMKIAogIyMjIElQdjYg b3B0aW9uczogIyMjCi1pcHY2X25ldHdvcmtfaW50ZXJmYWNlcz0ibm9uZSIJIyBMaXN0IG9mIElQ djYgbmV0d29yayBpbnRlcmZhY2VzCitpcHY2X25ldHdvcmtfaW50ZXJmYWNlcz0iYXV0byIJIyBM aXN0IG9mIElQdjYgbmV0d29yayBpbnRlcmZhY2VzCiAJCQkJIyAob3IgImF1dG8iIG9yICJub25l IikuCitpcHY2X3NsYWFjX2RlZmF1bHRfZW5hYmxlPSJOTyIgICMgU2V0IHRvIFlFUyB0byBlbmFi bGUgSVB2NiBTTEFBQy9hY2NlcHRfcnRhZHYKKwkJCQkjIG9uIGFsbCBpbnRlcmZhY2VzIGJ5IGRl ZmF1bHQKIGlwdjZfZGVmYXVsdHJvdXRlcj0iTk8iCQkjIFNldCB0byBJUHY2IGRlZmF1bHQgZ2F0 ZXdheSAob3IgTk8pLgogI2lwdjZfZGVmYXVsdHJvdXRlcj0iMjAwMjpjMDU4OjYzMDE6OiIJIyBV c2UgdGhpcyBmb3IgNnRvNCAoUkZDIDMwNjgpCiBpcHY2X3N0YXRpY19yb3V0ZXM9IiIJCSMgU2V0 IHRvIHN0YXRpYyByb3V0ZSBsaXN0IChvciBsZWF2ZSBlbXB0eSkuCg== --001485f630826160b6048193660e Content-Type: text/plain; charset=US-ASCII; name="ipv6-network.nobackcompat.diff.txt" Content-Disposition: attachment; filename="ipv6-network.nobackcompat.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g6oikve61 SW5kZXg6IGV0Yy9uZXR3b3JrLnN1YnIKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZXRjL25ldHdvcmsuc3Vicgko cmV2aXNpb24gMjA1MDE5KQorKysgZXRjL25ldHdvcmsuc3Vicgkod29ya2luZyBjb3B5KQpAQCAt OTYsNDUgKzk2LDM3IEBACiAJIyBpbmV0NiBzcGVjaWZpYwogCWlmIGFmZXhpc3RzIGluZXQ2OyB0 aGVuCiAJCWlmIGlwdjZpZiAkMTsgdGhlbgotCQkJaWYgY2hlY2t5ZXNubyBpcHY2X2dhdGV3YXlf ZW5hYmxlOyB0aGVuCisJCQlpZiBpcHY2X2F1dG9jb25maWYgJDE7IHRoZW4KKwkJCQlfaXB2Nl9v cHRzPSJhY2NlcHRfcnRhZHYiCisJCQllbHNlCiAJCQkJX2lwdjZfb3B0cz0iLWFjY2VwdF9ydGFk diIKIAkJCWZpCi0JCWVsc2UKLQkJCWlmIGNoZWNreWVzbm8gaXB2Nl9wcmVmZXI7IHRoZW4KLQkJ CQlfaXB2Nl9vcHRzPSItaWZkaXNhYmxlZCIKLQkJCWVsc2UKLQkJCQlfaXB2Nl9vcHRzPSJpZmRp c2FibGVkIgorCisJCQkjIGlmY29uZmlnX0lGX2lwdjYKKwkJCWlmY29uZmlnX2FyZ3M9YGlmY29u ZmlnX2dldGFyZ3MgJDEgaXB2NmAKKwkJCWlmIFsgLW4gIiR7aWZjb25maWdfYXJnc30iIF07IHRo ZW4KKwkJCQlpZmNvbmZpZyAkMSBpbmV0NiAtaWZkaXNhYmxlZAorCQkJCSMgQmUgbmljZSB0byB1 c2VycyAob3B0aW9uYWwgaW5ldDYpCisJCQkJY2FzZSAke2lmY29uZmlnX2FyZ3N9IGluCisJCQkJ CWluZXQ2XCAqKQorCQkJCQkJaWZjb25maWcgJDEgJHtpZmNvbmZpZ19hcmdzfQorCQkJCQkJOzsK KwkJCQkJKikKKwkJCQkJCWlmY29uZmlnICQxIGluZXQ2IFwKKwkJCQkJCSAke2lmY29uZmlnX2Fy Z3N9CisJCQkJCQk7OworCQkJCWVzYWMKKwkJCQlfY2ZnPTAKIAkJCWZpCiAKLQkJCSMgYmFja3dh cmQgY29tcGF0aWJpbGl0eTogJGlwdjZfZW5hYmxlCi0JCQljYXNlICRpcHY2X2VuYWJsZSBpbgot CQkJW1l5XVtFZV1bU3NdKQotCQkJCV9pcHY2X29wdHM9IiR7X2lwdjZfb3B0c30gYWNjZXB0X3J0 YWR2IgotCQkJCTs7Ci0JCQllc2FjCisJCWVsc2UKKwkJCV9pcHY2X29wdHM9ImlmZGlzYWJsZWQi CiAJCWZpCiAKIAkJaWYgWyAtbiAiJHtfaXB2Nl9vcHRzfSIgXTsgdGhlbgogCQkJaWZjb25maWcg JDEgaW5ldDYgJHtfaXB2Nl9vcHRzfQogCQlmaQotCi0JCSMgaWZjb25maWdfSUZfaXB2NgotCQlp ZmNvbmZpZ19hcmdzPWBpZmNvbmZpZ19nZXRhcmdzICQxIGlwdjZgCi0JCWlmIFsgLW4gIiR7aWZj b25maWdfYXJnc30iIF07IHRoZW4KLQkJCWlmY29uZmlnICQxIGluZXQ2IC1pZmRpc2FibGVkCi0J CQlpZmNvbmZpZyAkMSAke2lmY29uZmlnX2FyZ3N9Ci0JCQlfY2ZnPTAKLQkJZmkKLQotCQkjIGJh Y2t3YXJkIGNvbXBhdGlibGl0eTogJGlwdjZfaWZjb25maWdfSUYKLQkJaWZjb25maWdfYXJncz1g Z2V0X2lmX3ZhciAkMSBpcHY2X2lmY29uZmlnX0lGYAotCQlpZiBbIC1uICIke2lmY29uZmlnX2Fy Z3N9IiBdOyB0aGVuCi0JCQl3YXJuICJcJGlwdjZfaWZjb25maWdfJDEgaXMgb2Jzb2xldGUuIiBc Ci0JCQkgICAgIiAgVXNlIGlmY29uZmlnXyQxX2lwdjYgaW5zdGVhZC4iCi0JCQlpZmNvbmZpZyAk MSBpbmV0NiAtaWZkaXNhYmxlZAotCQkJaWZjb25maWcgJDEgaW5ldDYgJHtpZmNvbmZpZ19hcmdz fQotCQkJX2NmZz0wCi0JCWZpCisJCQogCWZpCiAKIAlpZiBbICR7X2NmZ30gLWVxIDAgXTsgdGhl bgpAQCAtMjQ0LDExICsyMzYsMTcgQEAKIAogCWZvciBfYXJnIGluICRfdG1wYXJnczsgZG8KIAkJ Y2FzZSAkX2FyZyBpbgorCQlbQWFdW1V1XVtUdF1bT29dKSA7OworCQlbQWFdW0NjXVtDY11bRWVd W1BwXVtUdF1fW1JyXVtUdF1bQWFdW0RkXVtWdl0pIDs7CiAJCVtEZF1bSGhdW0NjXVtQcF0pIDs7 CiAJCVtObl1bT29dW0FhXVtVdV1bVHRdW09vXSkgOzsKKwkJW05uXVtPb11bRGRdW0hoXVtDY11b UHBdKSA7OworCQlbTm5dW09vXVtTc11bTGxdW0FhXVtBYV1bQ2NdKSA7OwogCQlbTm5dW09vXVtT c11bWXldW05uXVtDY11bRGRdW0hoXVtDY11bUHBdKSA7OwogCQlbU3NdW1l5XVtObl1bQ2NdW0Rk XVtIaF1bQ2NdW1BwXSkgOzsKKwkJW1NzXVtMbF1bQWFdW0FhXVtDY10pIDs7CiAJCVtXd11bUHBd W0FhXSkgOzsKKwkJLVtBYV1bQ2NdW0NjXVtFZV1bUHBdW1R0XV9bUnJdW1R0XVtBYV1bRGRdW1Z2 XSkgOzsKIAkJKikKIAkJCV9hcmdzPSIkX2FyZ3MgJF9hcmciCiAJCQk7OwpAQCAtMjg2LDYgKzI4 NCwxMiBAQAogCiAJZm9yIF9hcmcgaW4gJF90bXBhcmdzOyBkbwogCQljYXNlICRfYXJnIGluCisJ CVtObl1bT29dW0FhXVtVdV1bVHRdW09vXXxbTm5dW09vXVtEZF1bSGhdW0NjXVtQcF0pCisJCQly ZXR1cm4gMQorCQkJOzsKKwkJW0FhXVtVdV1bVHRdW09vXSkKKwkJCXJldHVybiAwCisJCQk7Owog CQlbRGRdW0hoXVtDY11bUHBdKQogCQkJcmV0dXJuIDAKIAkJCTs7CkBAIC0yOTgsNiArMzAyLDEw IEBACiAJCWVzYWMKIAlkb25lCiAKKwlpZiBjaGVja3llc25vIGlwdjRfZGhjcF9kZWZhdWx0X2Vu YWJsZTsgdGhlbgorCQlyZXR1cm4gMAorCWZpCisKIAlyZXR1cm4gMQogfQogCkBAIC00MjMsMTIg KzQzMSw2IEBACiAJCXJldHVybiAwCiAJZmkKIAotCSMgYmFja3dhcmQgY29tcGF0aWJpbGl0eTog VHJ1ZSBpZiAkaXB2Nl9pZmNvbmZpZ19JRiBpcyBkZWZpbmVkLgotCV90bXBhcmdzPWBnZXRfaWZf dmFyICRfaWYgaXB2Nl9pZmNvbmZpZ19JRmAKLQlpZiBbIC1uICIke190bXBhcmdzfSIgXTsgdGhl bgotCQlyZXR1cm4gMAotCWZpCi0KIAljYXNlICIke2lwdjZfbmV0d29ya19pbnRlcmZhY2VzfSIg aW4KIAlbQWFdW1V1XVtUdF1bT29dKQogCQlyZXR1cm4gMApAQCAtNDUwLDYgKzQ1Miw3IEBACiAj IGlwdjZfYXV0b2NvbmZpZiBpZgogIwlSZXR1cm5zIDAgaWYgdGhlIGludGVyZmFjZSBzaG91bGQg YmUgY29uZmlndXJlZCBmb3IgSVB2NiB3aXRoCiAjCVN0YXRlbGVzcyBBZGRyZXNzIENvbmZpZ3Vy YXRpb24sIDEgb3RoZXJ3aXNlLgorIwlDaGVja3MgcGVyLWludGVyZmFjZSBzZXR0aW5nIGZpcnN0 LCB0aGVuIGdsb2JhbCBkZWZhdWx0CiBpcHY2X2F1dG9jb25maWYoKQogewogCWxvY2FsIF9pZiBf dG1wYXJncyBfYXJnCkBAIC00ODEsMzIgKzQ4NCw0NiBAQAogCQk7OwogCWVzYWMKIAotCSMgYmFj a3dhcmQgY29tcGF0aWJpbGl0eTogJGlwdjZfZW5hYmxlCi0JY2FzZSAkaXB2Nl9lbmFibGUgaW4K LQlbWXldW0VlXVtTc10pCi0JCXJldHVybiAwCi0JCTs7Ci0JZXNhYwotCiAJX3RtcGFyZ3M9YF9p ZmNvbmZpZ19nZXRhcmdzICRfaWYgaXB2NmAKIAlmb3IgX2FyZyBpbiAkX3RtcGFyZ3M7IGRvCiAJ CWNhc2UgJF9hcmcgaW4KLQkJYWNjZXB0X3J0YWR2KQorCQlbTm5dW09vXVtBYV1bVXVdW1R0XVtP b118W05uXVtPb11bU3NdW0xsXVtBYV1bQWFdW0NjXSkKKwkJCXJldHVybiAxCisJCQk7OworCQkt W0FhXVtDY11bQ2NdW0VlXVtQcF1bVHRdX1tScl1bVHRdW0FhXVtEZF1bVnZdKQorCQkJcmV0dXJu IDEKKwkJCTs7CisJCVtBYV1bVXVdW1R0XVtPb118W1NzXVtMbF1bQWFdW0FhXVtDY10pCisgCQkJ cmV0dXJuIDAKKyAJCQk7OworCQlbQWFdW0NjXVtDY11bRWVdW1BwXVtUdF1fW1JyXVtUdF1bQWFd W0RkXVtWdl0pCiAJCQlyZXR1cm4gMAogCQkJOzsKIAkJZXNhYwogCWRvbmUKLQotCSMgYmFja3dh cmQgY29tcGF0aWJpbGl0eTogJGlwdjZfaWZjb25maWdfSUYKLQlfdG1wYXJncz1gZ2V0X2lmX3Zh ciAkX2lmIGlwdjZfaWZjb25maWdfSUZgCi0JZm9yIF9hcmcgaW4gJF90bXBhcmdzOyBkbwotCQlj YXNlICRfYXJnIGluCi0JCWFjY2VwdF9ydGFkdikKKyAKKwlfdG1wYXJncz1gX2lmY29uZmlnX2dl dGFyZ3MgJF9pZmAKKyAgICAgICAgZm9yIF9hcmcgaW4gJF90bXBhcmdzOyBkbworICAgICAgICAg ICAgICAgIGNhc2UgJF9hcmcgaW4KKwkJW05uXVtPb11bQWFdW1V1XVtUdF1bT29dfFtObl1bT29d W1NzXVtMbF1bQWFdW0FhXVtDY10pCisJCQlyZXR1cm4gMQorCQkJOzsKKwkJLVtBYV1bQ2NdW0Nj XVtFZV1bUHBdW1R0XV9bUnJdW1R0XVtBYV1bRGRdW1Z2XSkKKwkJCXJldHVybiAxCisJCQk7Owor CQlbQWFdW1V1XVtUdF1bT29dfFtTc11bTGxdW0FhXVtBYV1bQ2NdKQorIAkJCXJldHVybiAwCisg CQkJOzsKKwkJW0FhXVtDY11bQ2NdW0VlXVtQcF1bVHRdX1tScl1bVHRdW0FhXVtEZF1bVnZdKQog CQkJcmV0dXJuIDAKIAkJCTs7CiAJCWVzYWMKLQlkb25lCisgICAgICAgIGRvbmUKIAorCWlmIGNo ZWNreWVzbm8gaXB2Nl9zbGFhY19kZWZhdWx0X2VuYWJsZTsgdGhlbgorCQlyZXR1cm4gMAorCWZp CisJCiAJcmV0dXJuIDEKIH0KIApAQCAtNTQzLDcgKzU2MCw2IEBACiAJaWYgISBpcHY2aWYgJF9p ZjsgdGhlbgogCQlyZXR1cm4gMAogCWZpCi0KIAlpZmFsaWFzX3VwICR7X2lmfSBpbmV0NiAmJiBf cmV0PTAKIAlpcHY2X3ByZWZpeF9ob3N0aWRfYWRkcl91cCAke19pZn0gJiYgX3JldD0wCiAJaXB2 Nl9hY2NlcHRfcnRhZHZfdXAgJHtfaWZ9ICYmIF9yZXQ9MApAQCAtNzI1LDMwICs3NDEsMTcgQEAK IAkjIGlmY29uZmlnX0lGX2FsaWFzTiB3aGljaCBzdGFydHMgd2l0aCAiaW5ldDYiCiAJYWxpYXM9 MAogCXdoaWxlIDogOyBkbwotCQlpZmNvbmZpZ19hcmdzPWBnZXRfaWZfdmFyICQxIGlmY29uZmln X0lGX2FsaWFzJHthbGlhc31gCisJCWlmY29uZmlnX2FyZ3M9YGdldF9pZl92YXIgJDEgaWZjb25m aWdfSUZfaXB2Nl9hbGlhcyR7YWxpYXN9YAogCQljYXNlICIke2lmY29uZmlnX2FyZ3N9IiBpbgot CQlpbmV0NlwgKikKLQkJCWlmY29uZmlnICQxICR7aWZjb25maWdfYXJnc30gYWxpYXMgJiYgX3Jl dD0wCi0JCQk7OwogCQkiIikKIAkJCWJyZWFrCiAJCQk7OwotCQllc2FjCi0JCWFsaWFzPSQoKCR7 YWxpYXN9ICsgMSkpCi0JZG9uZQotCi0JIyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5OiBpcHY2X2lm Y29uZmlnX0lGX2FsaWFzTi4KLQlhbGlhcz0wCi0Jd2hpbGUgOiA7IGRvCi0JCWlmY29uZmlnX2Fy Z3M9YGdldF9pZl92YXIgJDEgaXB2Nl9pZmNvbmZpZ19JRl9hbGlhcyR7YWxpYXN9YAotCQljYXNl ICIke2lmY29uZmlnX2FyZ3N9IiBpbgotCQkiIikKLQkJCWJyZWFrCisJCWluZXQ2XCAqKQorCQkJ aWZjb25maWcgJDEgJHtpZmNvbmZpZ19hcmdzfSBhbGlhcyAmJiBfcmV0PTAKIAkJCTs7CiAJCSop CiAJCQlpZmNvbmZpZyAkMSBpbmV0NiAke2lmY29uZmlnX2FyZ3N9IGFsaWFzICYmIF9yZXQ9MAot CQkJd2FybiAiXCRpcHY2X2lmY29uZmlnXyQxX2FsaWFzJHthbGlhc30gaXMgb2Jzb2xldGUuIiBc Ci0JCQkgICAgIiAgVXNlIGlmY29uZmlnXyQxX2FsaWFzTiBpbnN0ZWFkLiIKKwkJCWJyZWFrCiAJ CQk7OwogCQllc2FjCiAJCWFsaWFzPSQoKCR7YWxpYXN9ICsgMSkpCkBAIC04MTYsMzAgKzgxOSwx NiBAQAogCSMgaWZjb25maWdfSUZfYWxpYXNOIHdoaWNoIHN0YXJ0cyB3aXRoICJpbmV0NiIKIAlh bGlhcz0wCiAJd2hpbGUgOiA7IGRvCi0JCWlmY29uZmlnX2FyZ3M9YGdldF9pZl92YXIgJDEgaWZj b25maWdfSUZfYWxpYXMke2FsaWFzfWAKKwkJaWZjb25maWdfYXJncz1gZ2V0X2lmX3ZhciAkMSBp ZmNvbmZpZ19JRl9pcHY2X2FsaWFzJHthbGlhc31gCiAJCWNhc2UgIiR7aWZjb25maWdfYXJnc30i IGluCi0JCWluZXQ2XCAqKQotCQkJaWZjb25maWcgJDEgJHtpZmNvbmZpZ19hcmdzfSAtYWxpYXMg JiYgX3JldD0wCi0JCQk7OwogCQkiIikKIAkJCWJyZWFrCiAJCQk7OwotCQllc2FjCi0JCWFsaWFz PSQoKCR7YWxpYXN9ICsgMSkpCi0JZG9uZQotCi0JIyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5OiBp cHY2X2lmY29uZmlnX0lGX2FsaWFzTi4KLQlhbGlhcz0wCi0Jd2hpbGUgOiA7IGRvCi0JCWlmY29u ZmlnX2FyZ3M9YGdldF9pZl92YXIgJDEgaXB2Nl9pZmNvbmZpZ19JRl9hbGlhcyR7YWxpYXN9YAot CQljYXNlICIke2lmY29uZmlnX2FyZ3N9IiBpbgotCQkiIikKLQkJCWJyZWFrCisJCWluZXQ2XCAq KQorCQkJaWZjb25maWcgJDEgJHtpZmNvbmZpZ19hcmdzfSAtYWxpYXMgJiYgX3JldD0wCiAJCQk7 OwogCQkqKQogCQkJaWZjb25maWcgJDEgaW5ldDYgJHtpZmNvbmZpZ19hcmdzfSAtYWxpYXMgJiYg X3JldD0wCi0JCQl3YXJuICJcJGlwdjZfaWZjb25maWdfJDFfYWxpYXMke2FsaWFzfSBpcyBvYnNv bGV0ZS4iIFwKLQkJCSAgICAiICBVc2UgaWZjb25maWdfJDFfYWxpYXNOIGluc3RlYWQuIgogCQkJ OzsKIAkJZXNhYwogCQlhbGlhcz0kKCgke2FsaWFzfSArIDEpKQpJbmRleDogZXRjL3JjLmQvbmV0 aWYKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gZXRjL3JjLmQvbmV0aWYJKHJldmlzaW9uIDIwNTAxOSkKKysrIGV0 Yy9yYy5kL25ldGlmCSh3b3JraW5nIGNvcHkpCkBAIC00MSw4ICs0MSw2IEBACiBleHRyYV9jb21t YW5kcz0iY2xvbmV1cCBjbG9uZWRvd24iCiBjbWRpZm49CiAKLXNldF9yY3Zhcl9vYnNvbGV0ZSBp cHY2X2VuYWJsZSBpcHY2X3ByZWZlcgotCiBuZXR3b3JrX3N0YXJ0KCkKIHsKIAkjIFNldCB0aGUg bGlzdCBvZiBpbnRlcmZhY2VzIHRvIHdvcmsgb24uCkluZGV4OiBldGMvcmMuZC9pcDZhZGRyY3Rs Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIGV0Yy9yYy5kL2lwNmFkZHJjdGwJKHJldmlzaW9uIDIwNTAxOSkKKysr IGV0Yy9yYy5kL2lwNmFkZHJjdGwJKHdvcmtpbmcgY29weSkKQEAgLTIwLDggKzIwLDYgQEAKIHBy ZWZlcl9pcHY2X2NtZD0iaXA2YWRkcmN0bF9wcmVmZXJfaXB2NiIKIHByZWZlcl9pcHY0X2NtZD0i aXA2YWRkcmN0bF9wcmVmZXJfaXB2NCIKIAotc2V0X3JjdmFyX29ic29sZXRlIGlwdjZfZW5hYmxl IGlwdjZfcHJlZmVyCi0KIGlwNmFkZHJjdGxfcHJlZmVyX2lwdjYoKQogewogCWFmZXhpc3RzIGlu ZXQ2IHx8IHJldHVybiAwCkluZGV4OiBldGMvZGVmYXVsdHMvcmMuY29uZgo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBldGMvZGVmYXVsdHMvcmMuY29uZgkocmV2aXNpb24gMjA1MDE5KQorKysgZXRjL2RlZmF1bHRz L3JjLmNvbmYJKHdvcmtpbmcgY29weSkKQEAgLTE1OCw2ICsxNTgsOCBAQAogZHVtbXluZXRfZW5h YmxlPSJOTyIJCSMgTG9hZCB0aGUgZHVtbXluZXQoNCkgbW9kdWxlCiBpcF9wb3J0cmFuZ2VfZmly c3Q9Ik5PIgkJIyBTZXQgZmlyc3QgZHluYW1pY2FsbHkgYWxsb2NhdGVkIHBvcnQKIGlwX3BvcnRy YW5nZV9sYXN0PSJOTyIJCSMgU2V0IGxhc3QgZHluYW1pY2FsbHkgYWxsb2NhdGVkIHBvcnQKK2lw djRfZGhjcF9kZWZhdWx0X2VuYWJsZT0iTk8iCSMgU2V0IHRvIFlFUyB0byBkZWZhdWx0IGFsbCBp bnRlcmZhY2VzCisJCQkJIyB0byBhdXRvbWF0aWNhbGx5IHVzZSBESENQIGZvciBJUHY0CiBpa2Vf ZW5hYmxlPSJOTyIJCQkjIEVuYWJsZSBJS0UgZGFlbW9uICh1c3VhbGx5IHJhY29vbiBvciBpc2Fr bXBkKQogaWtlX3Byb2dyYW09Ii91c3IvbG9jYWwvc2Jpbi9pc2FrbXBkIgkjIFBhdGggdG8gSUtF IGRhZW1vbgogaWtlX2ZsYWdzPSIiCQkJIyBBZGRpdGlvbmFsIGZsYWdzIGZvciBJS0UgZGFlbW9u CkBAIC00MzksOCArNDQxLDEwIEBACiBpY21wX2JtY2FzdGVjaG89Ik5PIgkjIHJlc3BvbmQgdG8g YnJvYWRjYXN0IHBpbmcgcGFja2V0cwogCiAjIyMgSVB2NiBvcHRpb25zOiAjIyMKLWlwdjZfbmV0 d29ya19pbnRlcmZhY2VzPSJub25lIgkjIExpc3Qgb2YgSVB2NiBuZXR3b3JrIGludGVyZmFjZXMK K2lwdjZfbmV0d29ya19pbnRlcmZhY2VzPSJhdXRvIgkjIExpc3Qgb2YgSVB2NiBuZXR3b3JrIGlu dGVyZmFjZXMKIAkJCQkjIChvciAiYXV0byIgb3IgIm5vbmUiKS4KK2lwdjZfc2xhYWNfZGVmYXVs dF9lbmFibGU9Ik5PIiAgIyBTZXQgdG8gWUVTIHRvIGVuYWJsZSBJUHY2IFNMQUFDL2FjY2VwdF9y dGFkdgorCQkJCSMgb24gYWxsIGludGVyZmFjZXMgYnkgZGVmYXVsdAogaXB2Nl9kZWZhdWx0cm91 dGVyPSJOTyIJCSMgU2V0IHRvIElQdjYgZGVmYXVsdCBnYXRld2F5IChvciBOTykuCiAjaXB2Nl9k ZWZhdWx0cm91dGVyPSIyMDAyOmMwNTg6NjMwMTo6IgkjIFVzZSB0aGlzIGZvciA2dG80IChSRkMg MzA2OCkKIGlwdjZfc3RhdGljX3JvdXRlcz0iIgkJIyBTZXQgdG8gc3RhdGljIHJvdXRlIGxpc3Qg KG9yIGxlYXZlIGVtcHR5KS4K --001485f630826160b6048193660e-- From owner-freebsd-rc@FreeBSD.ORG Fri Mar 12 06:35:14 2010 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BCFA106564A; Fri, 12 Mar 2010 06:35:14 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64BA48FC12; Fri, 12 Mar 2010 06:35:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2C6ZED9006321; Fri, 12 Mar 2010 06:35:14 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2C6ZEjQ006317; Fri, 12 Mar 2010 06:35:14 GMT (envelope-from jh) Date: Fri, 12 Mar 2010 06:35:14 GMT Message-Id: <201003120635.o2C6ZEjQ006317@freefall.freebsd.org> To: jh@FreeBSD.org, freebsd-rc@FreeBSD.org, jh@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: conf/141258: /etc/rc.d/tmp may act incorrectly based on unprivleged local user actions 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: Fri, 12 Mar 2010 06:35:15 -0000 Synopsis: /etc/rc.d/tmp may act incorrectly based on unprivleged local user actions Responsible-Changed-From-To: freebsd-rc->jh Responsible-Changed-By: jh Responsible-Changed-When: Fri Mar 12 06:35:13 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=141258 From owner-freebsd-rc@FreeBSD.ORG Fri Mar 12 18:59:40 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 8C1FC106566B for ; Fri, 12 Mar 2010 18:59:40 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA758FC27 for ; Fri, 12 Mar 2010 18:59:40 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Fri, 12 Mar 2010 14:01:26 -0500 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::523 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-rc@freebsd.org X-SMFBL: ZnJlZWJzZC1yY0BmcmVlYnNkLm9yZw== Message-ID: <4B9A8B92.6050704@comcast.net> Date: Fri, 12 Mar 2010 13:44:34 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100311 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-rc@freebsd.org, freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: rc.d/rc.subr support for multiple FIBs 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: Fri, 12 Mar 2010 18:59:40 -0000 With multiple FIB support generally available in FreeBSD 8.0-RELEASE it would be quite beneficial to have the ability to build routing tables in secondary FIBs as well as start certain applications in certain FIBs from within rc.conf(5). I've done some poking around and came across two PRs which implement exactly what I'm looking for: http://www.freebsd.org/cgi/query-pr.cgi?pr=132483 http://www.freebsd.org/cgi/query-pr.cgi?pr=132476 My question is whether there are any plans to commit these into -CURRENT and possibly MFC them to a future 8.x-RELEASE. Having multiple FIBs available has been great so far, it goes hand and hand with Multi-IP Jails. The only thing missing are native methods for constructing the routing tables on boot (Yes, there is rc.local, but I don't want to go there...). Thanks, Steve Polyack From owner-freebsd-rc@FreeBSD.ORG Fri Mar 12 19:08:35 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 77AD5106566B for ; Fri, 12 Mar 2010 19:08:35 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3680F8FC21 for ; Fri, 12 Mar 2010 19:08:34 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 3EE5E19E023; Fri, 12 Mar 2010 20:08:34 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id EA16519E019; Fri, 12 Mar 2010 20:08:31 +0100 (CET) Message-ID: <4B9A912F.50105@quip.cz> Date: Fri, 12 Mar 2010 20:08:31 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.8) Gecko/20100205 SeaMonkey/2.0.3 MIME-Version: 1.0 To: Steve Polyack References: <4B9A8B92.6050704@comcast.net> In-Reply-To: <4B9A8B92.6050704@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: rc.d/rc.subr support for multiple FIBs 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: Fri, 12 Mar 2010 19:08:35 -0000 Steve Polyack wrote: > With multiple FIB support generally available in FreeBSD 8.0-RELEASE it > would be quite beneficial to have the ability to build routing tables in > secondary FIBs as well as start certain applications in certain FIBs > from within rc.conf(5). > > I've done some poking around and came across two PRs which implement > exactly what I'm looking for: > http://www.freebsd.org/cgi/query-pr.cgi?pr=132483 > http://www.freebsd.org/cgi/query-pr.cgi?pr=132476 > > My question is whether there are any plans to commit these into -CURRENT > and possibly MFC them to a future 8.x-RELEASE. Having multiple FIBs > available has been great so far, it goes hand and hand with Multi-IP > Jails. The only thing missing are native methods for constructing the > routing tables on boot (Yes, there is rc.local, but I don't want to go > there...). It seems there is not interest by developers or not enough man power to take it and commit. I wrote about this PR in my e-mail in January: http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html But it was left without any reply and all mentioned PRs are untouched. Miroslav Lachman From owner-freebsd-rc@FreeBSD.ORG Sat Mar 13 21:39:07 2010 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95FE4106566C; Sat, 13 Mar 2010 21:39:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6538FC23; Sat, 13 Mar 2010 21:39:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2DLd7br022934; Sat, 13 Mar 2010 21:39:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2DLd7hw022930; Sat, 13 Mar 2010 21:39:07 GMT (envelope-from linimon) Date: Sat, 13 Mar 2010 21:39:07 GMT Message-Id: <201003132139.o2DLd7hw022930@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-rc@FreeBSD.org, dougb@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: conf/144400: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound 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: Sat, 13 Mar 2010 21:39:07 -0000 Synopsis: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound Responsible-Changed-From-To: freebsd-rc->dougb Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 13 21:38:46 UTC 2010 Responsible-Changed-Why: dougb has volunteered to look at named bugs. http://www.freebsd.org/cgi/query-pr.cgi?pr=144400