On Sat, 29 Jun 2002, Henrik Nordstrom wrote:
[...]
> I proposed adding a new class of iptables things between matches and
> targets, being neither a match for filtering or a target that
> determines the ultimate fate of the packet. The names proposed for
> these in the discussion was modifiers or actions.
I believe we have four possibilities
- multiple targets
It has been rejected several times with good reasons: too error-prone
for the users and it would require heavy modifications both in the
kernel and the userspace.
- a new class: actions
With the new class, we would have to following skeleton of a rule:
IP match data
list of matches
list of actions
single target
Using any action would make sense only when the target is ACCEPT and
alike, so the actions function as 'always true' matches.
One also has to note, that we have a nice, visible separation of matches
and targets by name: matches are lowercased, while targets are
uppercased. How could actions be fit into this scheme? How could one
decide by glimpse that we are speaking about a match, action or
target?
[I'd name the new class as 'action' instead of 'modifier', because '-m'
is reserverd but '-a' is not.]
- rewrite the IPT_CONTINUE targets as matches
What would be solved by actions so nicely is biting here:
order-dependecy. Users should keep in mind, that the rule of
thumb is that 'always true' matches must come at the end of the rules.
But one has to note that the 'match' instead of 'action' approach would
lead a little bit more flexibility as well: actions have only effect
when all matches are true in the rule. (What is drawback from one point
of view, advantage from another one.)
The cases, when we have match/target pairs (like 'mark/MARK, ecn/ECN,
dscp/DSCP, etc) could be unified into single matches. (The 'recent'
match is a really nice example for such a solution. It could have been
introduced as a separated 'recent' match and a 'RECENT' target as well.)
- do nothing: the problem can always be solved by introducing custom
chains :-)
> So the question to the Netfilter core team is if it would be OK to add
> a new option and "module class" to the userspace tools, and have the
> existing IPT_CONTINUE targets dual-register as both a target and a
> match. I can try to whip something together if this is seen as
In my opinion the match solution would be better, cleaner.
Regards,
Jozsef
-
E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED]
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary