Date: Tue, 18 Jun 2019 22:31:00 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Mailinglists FreeBSD <freebsd-questions@freebsd.org> Subject: Re: Eliminating IPv6 (?) Message-ID: <CAN6yY1sk-LU16di6E_V5xf_ujQXsv7c2Zid7ae_azAojgwuH2Q@mail.gmail.com> In-Reply-To: <24393.1560893271@segfault.tristatelogic.com> References: <CAPS9%2BSvvHLC-MBWpHXBf6utscLyrtPvdtbiekk2OA1y4asH0=w@mail.gmail.com> <24393.1560893271@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 18, 2019 at 2:28 PM Ronald F. Guilmette <rfg@tristatelogic.com> wrote: > In message <CAPS9+SvvHLC-MBWpHXBf6utscLyrtPvdtbiekk2OA1y4asH0= > w@mail.gmail.com> > Andreas Nilsson <andrnils@gmail.com> wrote: > > >But why are you even running rc.firewall if it does not do what you want? > > You are asking me the very question that *I* have been asking myself > since my "upgrade" to 12.0. > > Why is /etc/rc.firewall even being executed? I never explicitly asked for > that, but that seems to just be a by-product of how things are arranged > these days.... a by-product that I have no direct control over. > > >Just set firewall_script="/path/to/script" and your good to go, no ipv6 > >anywhere to be found. > > That is *not* what the Handbook says. Please read it. > > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > > The way that I am reading section 30.4.1 is that it is telling the user to > put BOTH of these things into /etc/rc.conf: > > firewall_enable="YES" > firewall_type="path-to-my-rules-file" > > And indeed, that is -exactly- what I have done on my prior FreeBSD > systems... > enable *and* configure. > > One or the other of those /etc/rc.conf lines nowadays apparently triggers > /etc/rc.firewall to run. I never explicitly asked for that to run, but > it did anyway. I am just going with the flow. > > > Regards, > rfg I was hoping to avoid this as I have not worked with IPv6 since I retired 8 years ago and I worked on this back before then by a couple of years. My memory is not perfect, so excuse any minor errors. I do know that back when I ran CURRENT I ran into a problem booting the system after ipfw and ipfw6 were merged. It stopped while starting the network if I had IPv6 enabled. At that time, IPv6 was not This was because I used the default net.inet.ip.fw.default_to_accept=0, so an automatic "65535 deny ip from any to any" was placed in ipfw. (This has long been the case and provided precedence for further automatic rules.) The problem is that IPv6 could not start unless certain IPv6 packets are allowed. I know NDP is required and, generally, certain ICMPv6 types are also needed. Without those, rules, IPv6 startup would block, unable to perform SLAAC, the default addresss assignment method and DHCPv6, if used. The result was a set of rules that are required for IPv6 to come up was added to the rules set by default. I have never seen this clearly documented except in the code and it has been changed several times over the years. On at least one case, a change broke my rule set as, unlike the reject by default rule and default loopback rule, were assigned real numbers which might fall into places in a rule-set that caused incorrect behavior. (Note: I have not read the handbook section on this in a while, so it may be documented by now.) This really needs proper documentation but it is now assumed by most OSes including Windows, MacOS, Linux and FreeBSD that IPv6 and IPv4 will be enabled by default. As time goes on, it will likely be more and more likely that disabling IPv6 will become difficult if networks are used at all. It already really requires a custom kernel to completely remove it and, even then, some IPv6 code is still be in the kernel, but unreachable unless someone has spotted these and '#ifdef"ed them. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1sk-LU16di6E_V5xf_ujQXsv7c2Zid7ae_azAojgwuH2Q>