From owner-freebsd-hackers  Fri Aug 16 22:20:35 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA17189
          for hackers-outgoing; Fri, 16 Aug 1996 22:20:35 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA17184
          for <hackers@freebsd.org>; Fri, 16 Aug 1996 22:20:25 -0700 (PDT)
Message-Id: <199608170520.WAA17184@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA037259220; Sat, 17 Aug 1996 15:20:20 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: ipfw/ipfilter - what will it be?
To: hackers@freebsd.org
Date: Sat, 17 Aug 1996 15:20:20 +1000 (EST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Well, the discussion went a long way and ended up in a "when I was a lad...".

For those wondering, IP filter is my pet project and although I try to keep
up with what other similar products do, just because someone else implements
a feature in a certain way, does not mean I'll match it.  I don't believe
that adding "line numbers" is a "forward step" for such a product.  The
reference to BASIC was to show where that style of thinking has gone to
today: tools such as Visual BASIC no longer have line numbers, C doesn't,
etc.  If a "tag" is desired such that it represents a grouping of related
objects (such as used by Cisco's IOS for ACL's or as people have done with
in ipfw & taken it further), then they should be just that - arbitary tags.
In the context of IP filter, I don't see what that does for the performance
or usefulness of a packet filter which resides in the kernel.  IMHO, those
are the sort of things you want in your rule file, which you edit and then
load into the kernel and comments fill that role quite well, I believe.

For DIVERT, at present this remains a FreeBSD only feature, at present, but
sounds a lot like something I was thinking of some time ago.  However, if
the purpose is for NAT and how it can be implemented in userland, c.f.
screend vs ipfw (need I say more ?).

Reading Linux's IP source code, you can see some of the flunky things
they've done (reassembling all packets going through the box on a routing
box, assuming all TCP/IP packets are destined for the host - regardless of
IP#).  Flunky features are easy to add if that becomes the priority.

In summary, I'm not about to add things just so the FreeBSD team will add
it to their release, which may or may not be the same as I distribute.

Darren