Subject: Re: Take #3 - final proposed patch for ipsec/bpf/ipfilter integration
To: Noriyuki Soda <soda@sra.co.jp>
From: Darren Reed <avalon@caligula.anu.edu.au>
List: tech-net
Date: 05/14/2003 23:20:12
In some mail from Noriyuki Soda, sie said:
> 
> >>>>> On Wed, 14 May 2003 22:46:31 +1000 (Australia/ACT),
> 	Darren Reed <avalon@caligula.anu.edu.au> said:
> 
> > While it's good and well to say this, lets look at the reality of the
> > situation.  If you go through "struct ifnet" you will find a number of
> > fields or bits defined for things that are explicitly related to IP.
> > So to bring up that sort of argument at this point in the history of
> > IP in the BSD kernel is really a bit late.  Technically, you are correct
> > but practically, I do not think this is a major concern.
> 
> Which structure member are you talking about here?
> 
> Currently, if_capabilities, if_capenable, if_csum_flags_{tx,rx} are
> used only for IP related purpose.
> But these members are not limited for IP. Other protocol can use these
> members too, if underlying hardware supports that protocol.
> 
> Or, are you talking about other member?
> If so, which one?

No, these are what I was thinking of.

But what difference does it make whether it's 1 bit or 32 or 64 bits
that are used for a specific protocol ?  The point is that they're
already there and used in that way.

I had thoughts of achieving this same goal in other ways but all were
more trouble.  In some ways, i find this a very good model.  Afterall,
there is nothing that requires it still to be IP traffic that is
associated with the virtual interface.

Maybe I should call the structure member "if_enc" or something else ?
It matters not, to me, what the name of it is, only what it does.

There's nothing presently requiring it be only used with IPSec, just
that IPSec is the only user of it and if_ipsec was what came to my
mind the easiest.  Similar reasons for constructing the name ipsec_pcn0.

Darren