Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Jun 2002 22:41:08 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        "'Luigi Rizzo'" <rizzo@icir.org>
Cc:        arch@freebsd.org
Subject:   Re: ipfw rewrite - new snapshot available
Message-ID:  <Pine.BSF.4.21.0206132239250.97512-100000@InterJet.elischer.org>
In-Reply-To: <20020613171319.D93980@iguana.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Luigi.

I haven't had a chance to look at it yet..
Too busy at USENIX.. 

I'll try look at it after I et back  after I do KSE-MIII after..... :-)


On Thu, 13 Jun 2002, 'Luigi Rizzo' wrote:

> [Bcc to -net]
> 
> Hi,
> as I mentioned in a posting to -net a few days ago, over the past
> weeks I have done an extensive rewrite of the ipfw code (both userland
> and kernel) in an attempt to make it faster, more flexible and more
> manageable.
> 
> The code is now almost ready for commit, so I would appreciate
> some feedback if any of you feels like trying it and, even
> better, run some performance test. You can fetch the code from
> 
>         http://info.iet.unipi.it/~luigi/ipfw5.20020613.tgz
> 
> This is for a -current after May 15th, and replaces
> 
>         sys/netinet/ip_fw.c
>         sys/netinet/ip_fw.h
>         sys/netinet/ip_dummynet.c
>         sbin/ipfw/ipfw.c
> 
> The idea behind this work was to replace the old ipfw rules
> (macroinstructions) with a set of microinstructions, each of them
> performing a single operation such as matching an address, or a
> port range, or a protocol flag, etc.  -- much in the spirit of BPF
> and derivatives -- and to let the userland front-end compile ipfw(8)
> commands into an appropriate set of microinstructions.
> 
> There are several advantages in using this technique: first of all,
> instructions are typically shorter and faster, because the old
> code had to check for the presence of all the possible options
> (there are over 25 of them!) in a rule, whereas the new one can
> simply do just the things that are required.
> 
> I have implemented all the actions (accept/deny/pipe/divert/forward
> ...) and almost all the 25+ (ouch!) different options that can be
> specified in a rule. The syntax for the userland program is 100%
> backward compatible.
> 
> I have also implemented a few extensions to demonstrate the flexibility
> of the new approach: you can put "or" connectives between fields,
> so you can write things like
> 
>     ipfw add allow ip from host1 or host2 or host3 or not net1/24 to any
> 
> and the like, and this greatly simplifies writing rulesets as
> you can imagine.
> 
> Other extensions (in the form of address sets, multiple rule
> chains to be used on layer-2 and layer-3 firewalls, etc. will
> be trivial to implement.
> 
> 	cheers
> 	luigi
> 
> -----------------------------------+-------------------------------------
>   Luigi RIZZO, luigi@iet.unipi.it  . Dip. di Ing. dell'Informazione
>   http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
>   TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
>   Mobile   +39-347-0373137
> -----------------------------------+-------------------------------------
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0206132239250.97512-100000>