Date: Fri, 10 Apr 2020 21:47:00 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Neel Chauhan <neel@neelc.org> Cc: lev@freebsd.org, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, freebsd-hackers@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru> Subject: Re: Committing one ipfw(8) userland patch Message-ID: <202004110447.03B4l0x0020210@gndrsh.dnsmgr.net> In-Reply-To: <ef964fcb8f3f8671fbef5486a13a1163@neelc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Thank you all for your feedback. > > Using the same Phabricator revision here: > https://reviews.freebsd.org/D24234 > > I have added the src-ip4/dst-ip4 and src-ipv4/dst-ipv4 specifiers and > made src-ip/dst-ip dual-stack, to be consistent with me/me4/me6 > described in this thread. > > Could you all please give your opinions on it? I took a look at this and D24021 and am a bit confused as no changes are actually being made to the kernel ipfw code, so how does it know which are now dual vs single stack. As far as I can see no actual change would be experienced by the me/me4/me6 changes as they are all simply encoded as O_IP_{SRC,DST}_ME when it gets to the kernel. It could be I am missing something, it has been a very long time since I looked at the inards of ipfw. Also I am not sure if you want to attempt to flag no-op cases like ipfw add ip4 from me6 to any which I believe would be allowed and create a rule that never matched anything. (Actually with the current code I think it would still match local ipv4 address, which arguable is wrong.) > -Neel > > On 2020-04-10 04:10, Lev Serebryakov wrote: > > On 10.04.2020 13:46, Andrey V. Elsukov wrote: > > > >> On 07.04.2020 20:35, Rodney W. Grimes wrote: > >>> But that is not what this review does. I would be in support of > >>> changing the "official" names to src-ip4/dst-ip4/src-ip6/dst-ip6 > >>> and making src-ip/dst-ip a backwards compatible alias. > >> > >> I also think this idea sounds better. > > > > +1 I am glad people liked this solution, lets make sure it is implemented cleanly and in a 100% backwards compatible way, breaking ipfw rule sets is frowned upon by users. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202004110447.03B4l0x0020210>