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


Reply via email to