From owner-freebsd-questions@freebsd.org Tue Jun 18 08:33:45 2019 Return-Path: Delivered-To: freebsd-questions@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 E4ADB15B07F3; Tue, 18 Jun 2019 08:33:44 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3019269A93; Tue, 18 Jun 2019 08:33:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from bsdondell.lab.pwste.edu.pl ([IPv6:2001:678:618:3067:4d7c:5809:f7b3:c95f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id x5I8XdAa059962 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Jun 2019 10:33:39 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1560846820; bh=193YLTqEEij86qrqD0qKtyvf+cmdaXCWtIbfiExdG6s=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=DQmnypoxkVBpADC8t1z9MIFfsoZ1mOsCHN4eQl1wXI+qAGdqMTV3oDGT3iZsVRPTI 4T6eKiAow0ErkgF168180r081C7Jo8hzfRef81qIkNutZwuICZhDv/WF/DlTxrp0zx omz9QTADg1sILE1TNhn2ATWp33G/3yvJuzk740lvZAm3t5gYgtJy7TfRhAxZiJxVvf ZFE3MWFWazVj0l7t+TsLmGIzERvF4kw4sidArF9fNnj3jWXlKHx2m8lpxxWbyxit/O 02upUxgVnLr9WQtrtKdM8TsH5mwVgWaNcROVHPH1601VQiRo17RmdvFKRB74ewpJll CyxYV22BM4Byw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:678:618:3067:4d7c:5809:f7b3:c95f] claimed to be bsdondell.lab.pwste.edu.pl To: christian russell , "Ronald F. Guilmette" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <18748.1560843874@segfault.tristatelogic.com> From: Marek Zarychta Openpgp: preference=signencrypt Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Subject: Re: Eliminating IPv6 (?) Message-ID: Date: Tue, 18 Jun 2019 10:33:26 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y82voBVt9gqr51QdkbZu1xABDhKCgtYM6" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 08:33:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --y82voBVt9gqr51QdkbZu1xABDhKCgtYM6 Content-Type: multipart/mixed; boundary="BfDSwDzC7bR85rPfzkw1pWXvCEn7cc9TH"; protected-headers="v1" From: Marek Zarychta To: christian russell , "Ronald F. Guilmette" Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Message-ID: Subject: Re: Eliminating IPv6 (?) References: <18748.1560843874@segfault.tristatelogic.com> In-Reply-To: --BfDSwDzC7bR85rPfzkw1pWXvCEn7cc9TH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 18.06.2019 o=C2=A010:09, christian russell pisze: > My opinion is that being able to practically ignore IPv6, without opera= tional detraction, is a reasonable degree of freedom. FreeBSD isn=E2=80=99= t pushing IPv6 any more or less than any other mainstream OSes. > > Given a set number of developer hours I would prefer that IPv6 be fully= implemented and functionally "ignorable" as opposed to dev time being sp= ent allowing an essentially cosmetic opting out of IPv6 functionality. E= ven more generally I would prefer any dev time time be spent on active is= sues and new features. > >> I ask again, is this really such an unreasonable thing to hope for? > If I were allocating work-hours on FreeBSD development my answer would = be: =E2=80=9Cyup" =C2=AF\_(=E3=83=84)_/=C2=AF > > Christian Dual stack support looks like a reasonable solution these days and works fine in 99% of network scenarios. From the other hand the ability to completely disable legacy IP should be considered as well. Some people consider IPv6 only network to be providing a sufficient degree of freedom but in 2019 we still lack DHCPv6 client in base. --=20 Marek Zarychta > >> On Jun 18, 2019, at 12:44 AM, Ronald F. Guilmette wrote: >> >> In message ,=20 >> 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=3D= yes in the >>> /etc/src.conf >>> or else some utilities compiled with INET6 by default will query kern= el >>> for IPv6-specific data (like routing entries) and complain that your = kernel does=20 >>> 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 b= ecause >> that feature is present in the kernel, that does not imply that anythi= ng in >> userland -has- to actually make any use of it at all. >> >> *Something* is doing ifconfig on my loopback (lo0) interface. What is= that >> thing and how can I get it to stop doing that? >> >> As I have already learned, the /etc/rc.firewall script also assumes bo= th the >> presence of, and the desirability of IPv6 support. And unless one edi= ts that >> file manually... which I have been effectively forced to do... there i= s no way >> to get it to simply NOT create and install multiple IPv6-related ipfw = rules, >> EVEN THOUGH in my particular situation... which is still the most comm= on case... >> those extra and entirely superfluous IPv6 ipfw filtering rules are ser= ving >> 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= =2E >> >> Clearly, if doesn't have to be this way. Some maintainers just decide= d that >> I and all other IPv4-only users should get stuck dealing with a lot of= useless, >> unnecessary and distracting IPv6 stuff, whether I like it or not, and = presumably >> 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 a= nd what >> isn't "for my own good". >> >> I can and will most certainly get down and grovel around in the variou= s >> /etc/rc.d/ scripts and will comment out those parts that do things lik= e >> 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 = could >> simply select the "No, I don't want to have to deal with IPv6 at all r= ight >> now" option. >> >> Is that really an unreasonable hope, expectation, and request? >> >> I understand that the kernel will still -offer- the IPv6 support. But = if no >> -other- software on my system actually takes the kernel up on that off= er, >> 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 s= aid >> 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 t= he >> 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 I= Pv6 >> "features" that (a) do not help us one iota and that (b) are all just = a >> big and pointless distraction that muddles everything and unnecessaril= y >> complicates and complexifies ordinary system maintenance tasks. >> >> IPv6 is great and I'm sure I'll be using it someday. But today is not= that >> 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 abou= t 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 wil= l >> be remembered, in future, at every mention of IPv6. I hope that all o= f the >> IPv6 evanglists will take a moment to stop and think about that, and t= hat >> 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 a= re ready, >> willing, and able to do so. >> >> >> Regards, >> rfg >> >> >> P.S. In case I have again failed to be clear, I am proposing a new /e= tc/rc.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? >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"= > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --BfDSwDzC7bR85rPfzkw1pWXvCEn7cc9TH-- --y82voBVt9gqr51QdkbZu1xABDhKCgtYM6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl0Iod0ACgkQdZ/s//1S jSwZvwf/agEmz2iZbmOJQGdC5jiR5/Gd3VXDj4XI2XtHXcc1btqowrmaPB4gEREn 6lMihXMMM3p4FWoO6W87AuoNcxiX3vnkdGre/K+m19tuPLybDryXl11C7FZOSXrS 0TYgPapR+uyhBhs3j4MLxOn2HLgWpwOFXfOUc/gb2LKTIFGySEllgbbv5iQL+tFC DVzwLyHGBp7anwK3DDWYICSyyxpoDR6onYU0sZeuGO/UN9FruJRQW3b8WoDKgAyh /FtSPSbE83R3Ut3c+LiF3nDBiPkqzxVmYHCYSBLAiLfZmKMw40mFSXAsWeWIrL1L bpaxFwRIf9kHu//dVGVafelanAWWDg== =qhLx -----END PGP SIGNATURE----- --y82voBVt9gqr51QdkbZu1xABDhKCgtYM6--