From owner-freebsd-net@freebsd.org Tue Jun 18 08:39:49 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EDC315B0E73; Tue, 18 Jun 2019 08:39:49 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 0055969E82; Tue, 18 Jun 2019 08:39:47 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id DC90B4E64B; Tue, 18 Jun 2019 01:39:46 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19573.1560847186.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 01:39:46 -0700 Message-ID: <19574.1560847186@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 0055969E82 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rfg@tristatelogic.com designates 69.62.255.118 as permitted sender) smtp.mailfrom=rfg@tristatelogic.com X-Spamd-Result: default: False [-3.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[tristatelogic.com]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(-2.72)[ip: (-7.16), ipnet: 69.62.128.0/17(-3.58), asn: 14051(-2.82), country: US(-0.06)]; MX_GOOD(-0.01)[cached: mx1.tristatelogic.com]; RCPT_COUNT_TWO(0.00)[2]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-0.49)[-0.487,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14051, ipnet:69.62.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; SUBJECT_HAS_QUESTION(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:39:49 -0000 In message <9AF5DF39-9B81-4270-B25C-D089C971E924@punkt.de>, = "Patrick M. Hausen" wrote: > Am 18.06.2019 um 09:44 schrieb Ronald F. Guilmette : >> As I have already learned, the /etc/rc.firewall script also assumes bot= h the >> presence of, and the desirability of IPv6 support. And unless one edit= s that >> file manually... which I have been effectively forced to do... there is= no way >> to get it to simply NOT create and install multiple IPv6-related ipfw r= ules, >> EVEN THOUGH in my particular situation... which is still the most commo= n case... >> those extra and entirely superfluous IPv6 ipfw filtering rules are serv= ing >> no earthly purpose whatsoever and are only cluttering up my ipfw rule s= et, >> thus pointlessly making it harder for me to grok and maintain them all. > >Instead of messing with the system provided file you could >create a new one with only your own desired rules and then set >this rc.conf variable: > > firewall_script=3D"/etc/rc.firewall" Actually, no, that's not how one is supposed to enable one's own set of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly that one should do: firewall_enable=3D"YES" firewall_type=3D"path-to-my-rules-file" But I'm glad you brought it up. The funny thing is that even that doesn't work properly nowadays *or* like it used to in the past. I did that exact thing when putting together my shiny new 12.0-RELEASE system recently, as prescribed by the Handbook, just as I have done in the past on my prior FreeBSD systems. The result was no longer as expected. It seems that somwhere along the line, sometime between the last time I did a totally fresh install of FreeBSD (which I admit was some years ago now) and today, *somebody* apparently came to the conclusion that ordinary end lusers like me could not be fully trusted to supply 100% of their own ipfw rules, and thus, noadays, EVEN IF the user does exactly what you suggested, and tries (according to the guidance given in the Handbook) to supply his/her own set of ipfw rules, nowadays the /etc/rc.firewall script still gets invoked, and it *insists* on *adding* some ipfw rules to the set the user supplies in the named file. And to add insult to injury, some of those additional "whether you like it or not" ipfw rules specifically involve IPv6, which, as I have already said, I don't want, dont need, and which are just a pointless annoyance. Check it out for yourself if you don't believe me. (I have been debating with myself as to whether or not I should file a formal PR on this. I guess that I will. It is incredible but apparently true that even for those folks who want to write their own ipfw rule sets, 100%, *somebody* decided the we should not be allowed to do that 100% anymore. Apparently, I am not to be trusted to perform this task, for my own systems, all on my own anymore.) >As for the rest of your request, yes, I find it unreasonably in 2019 but >let's not get into a fight about that. IPv6 is here to stay. If you boot = any >Mac or Windows 10 desktop, IPv6 will be active and even necessary for >service autodiscovery and similar things to work. If true, I call that sloppy, careless, and lazy bad design. And that is being generous on my part. What services must be autodiscovered via IPv6 that could not be just as easily autodiscovered via IPv4 RFC1918 addresses... as had been done for at least a couple of decades already? (I have a printer right here next to me that has been successfully autodiscovered by Windows, by Linux, and by FreeBSD, all over an IPv4-only network.) I well and truly unxderstand that various entities have a clear financial interest in effectively forcing me... and hundreds of millions of others..= . to purchase all new equipmwent, but if what you said it true then that really takes the cake, because there is no compelling reason for it other than the commercial interests of various equipment vendors. There are two ways to induce people to do things that they otherwise would not do... carrots and sticks. For me, IPv6 right now is all sticks and no carrots. If I want to be abused, mistreated and forced to do things that I don't much feel like doing... well... I already have relatives for that. Regards, rfg