Committing one ipfw(8) userland patch

[Rodney W. Grimes]

> 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 at freebsd.org