Erik Nordmark writes: > For the first item, for the set of callouts we have (IPsec policy > lookup/enforcement, IPsec application of encrypt/decrypt, IPQoS > classification, IPQoS queueing/dropping, IP Filter drop/allow, IP Filter > NAT, IP observability), is that there isn't a lot of commonality for > their placement; maybe a few of them need to be at exactly the same > place in the stack.)
That's certainly true. > I don't think it makes sense to have 7 generic transmit and 7 generic > receive hooks that can all do the most complex operation. Nor do I, though, somewhat confusingly, it seems to be close to the direction that other platforms are taking. > > As things stand today, there is no one, generally-available, generic > > framework for packet inspection. Every project to date places its own > > hooks into IP, sometimes labels them as yet another "generic > > solution," and then drives on. That alone is worth some advice. > > The solution to that might be to not claim that any of them are generic. > If it turns out that two hooks end up in the same place, then we can > collapse them into one hook. That's exactly what I'd suggest. There's likely also a lot of simplification available once the "one hook for all (or most or many) users" design goal is dropped. It's no longer necessary, for instance, to have elaborate registration mechanisms. The things that need to be explained to the ARC members are why all of the previous claims to generic hook features are unusable and why generic hooks aren't even considered feasible. That's something I'd hoped to do back when we were writing the filtering document, but that essentially go no consensus and went nowhere. Darren Reed writes: > The biggest problem I can see with combining the two is that as a > result of discussion over the design, I abandoned trying to resolve > the problem of multiple consumers for the same hook. The result > here would be not being able to use /dev/ipnet/* at the same time > as IPFilter if both used the same hook rather than their own. Is it a problem, though, that actually needs to be solved? I think that's the unclear part for both projects. > The root of that decision is trying to answer the question of > "if both are enabled, who should see a packet first and how does > one specify that preference or its inverse?" > > ...for which no good answer could be found :( Yep. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
