In some email I received from Bernd Ernesti, sie wrote:
[...]
> > >> > Having to explicitly turn ip_filter *on* is a bug, in some
> > >> > environments.
> > >> Indeed. You don't want packets to leak during bootup.
> > >Can you turn it on before the interfaces are configured?  If so,
> > >that seems like a workable solution.
> You can that, i made the change to /etc/netstart to enable it again.
> 
> > Not really, no.  Yes, ip_fil on a firewall can be made to work
> > that way, if configured correctly.
> > 
> > But the behavior of the old and `fixed' versions in the face of
> > configuration errors; or booting single-user and "accidentally'
> > bringing up interfaces without enabling filtering; or when upgrading
> > kernels on the firewall, etc, is...  different.
> 
> We can't fix all problems with comes from humans.
> 
> Btw, why don't you use IPF_DEFAULT_PASS ? Thats all what you wanted.

What people have observed with the "old way" (as in how it is distributed)
is that the default return for a packet is "no match" when compiled into 
kernel (it defaults to pass when building as an LKM).  What isn't obvious
(and isn't documented I suspect) is that if you put IPF_DEFAULT_PASS (or
the equivalent from prior versions) in your kernel file as being some
number (i.e. options IPF_DEFAULT_PASS="FR_BLOCK") then they should make their
way into the compiled kernel.  My main concern with doing it this way is
it isn't particularly neat.

I'm working towards making all of these type things stored in global
variables so that they can be adb'd or linked in via sysctl for better
management and control.

Darren