From owner-freebsd-net@freebsd.org Tue Jun 18 07:44:37 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 975C815D2251; Tue, 18 Jun 2019 07:44:37 +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 1265396434; Tue, 18 Jun 2019 07:44:35 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: by segfault.tristatelogic.com (Postfix, from userid 1237) id A4FC34E654; Tue, 18 Jun 2019 00:44:34 -0700 (PDT) From: "Ronald F. Guilmette" cc: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: Eliminating IPv6 (?) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18747.1560843874.1@segfault.tristatelogic.com> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2019 00:44:34 -0700 Message-ID: <18748.1560843874@segfault.tristatelogic.com> X-Rspamd-Queue-Id: 1265396434 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.79 / 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.77)[ip: (-7.27), ipnet: 69.62.128.0/17(-3.64), asn: 14051(-2.86), 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.84)[-0.836,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 07:44:37 -0000 In message , = Eugene Grosbein wrote: >18.06.2019 10:10, Ronald F. Guilmette wrote: > >> How can I turn off IPv6 entirely without rebuilding the kernel? > >You cannot. GENERIC kernel specifically enables IPv6 support and you need= to >disable it at compile time. >And if you do, you better rebuild the world too using WITHOUT_INET6=3Dyes= in the >/etc/src.conf >or else some utilities compiled with INET6 by default will query kernel >for IPv6-specific data (like routing entries) and complain that your kern= el does = >not know about it. > >World built WITHOUT_INET6 has no such rough edges. OK, so I obviously expressed myself badly. Let me try again. IPv6 support is enabled in a the stock kernel. OK. Fine. But just becau= se that feature is present in the kernel, that does not imply that anything i= n userland -has- to actually make any use of it at all. *Something* is doing ifconfig on my loopback (lo0) interface. What is tha= t thing and how can I get it to stop doing that? As I have already learned, the /etc/rc.firewall script also assumes both t= he presence of, and the desirability of IPv6 support. And unless one edits t= hat 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 rule= s, EVEN THOUGH in my particular situation... which is still the most common c= ase... those extra and entirely superfluous IPv6 ipfw filtering rules are serving no earthly purpose whatsoever and are only cluttering up my ipfw rule set, thus pointlessly making it harder for me to grok and maintain them all. Clearly, if doesn't have to be this way. Some maintainers just decided th= at I and all other IPv4-only users should get stuck dealing with a lot of use= less, unnecessary and distracting IPv6 stuff, whether I like it or not, and pres= umably for our own good. I really wish that maintainers would allow me a bit more freedom, and show me the courtesy and respect to allow me to decide for myself what is and w= hat isn't "for my own good". I can and will most certainly get down and grovel around in the various /etc/rc.d/ scripts and will comment out those parts that do things like ifconfig'ing my loopback interface for IPv6, whether I like it or not. But there ought to be some single /etc/rc.conf variable via which one coul= d simply select the "No, I don't want to have to deal with IPv6 at all right now" option. Is that really an unreasonable hope, expectation, and request? I understand that the kernel will still -offer- the IPv6 support. But if n= o -other- software on my system actually takes the kernel up on that offer, then the kernel's IPv6 support becomes like the tree that falls in the forrest when there is nobody around to hear it. It might as well be said that it makes no sound, and no difference to anything at all. It is clearly not necessary for me or anyone else to have to rebuild the kernel... *and* world... just in order to get rid of what are, for the majority of users here in 2019, still a bunch of utterly superfluous IPv6 "features" that (a) do not help us one iota and that (b) are all just a big and pointless distraction that muddles everything and unnecessarily complicates and complexifies ordinary system maintenance tasks. IPv6 is great and I'm sure I'll be using it someday. But today is not tha= t day... not for me, and also not for one hell of a lot of other users. The fact that I and others are effectively being forced to even think about it= , due to an absence of reasonable and easily accessible userland options, is actually a big turn-off, and leaves a bad taste in the mouth which will be remembered, in future, at every mention of IPv6. I hope that all of th= e IPv6 evanglists will take a moment to stop and think about that, and that they'll stop effectively forcing those of us who don't need it to both use IPv6 and to think about it, whether we like it or not, and before we are r= eady, willing, and able to do so. Regards, rfg P.S. In case I have again failed to be clear, I am proposing a new /etc/r= c.conf option. Something simple and intutive like: ipv6=3D"NO" That in turn should be checked -and- respected by all relevant /etc/rc,d/ scripts. I ask again, is this really such an unreasonable thing to hope for?