The pools used in IPFilter 4 for selecting a rule group for
further processing are hash pools. This means that the there
can be no overlaps between the various IP address blocks
specified in the group-map. *This* means that it is not as
powerful as would have been the case if they were tree pools.
More specifically: it is not possible to specify that
processing should continue with a rule group for an IP range
with a hole.
One particular case is to specify default processing. The
ability to specify 0.0.0.0/0 (with holes!) would have been
one way of doing it. As things stand there are a number of
other possibilities which lead to questions:
1) if a group-map has a default rule group, is this taken
as a default if there is no match, or is it simply a
shorthand for use when defining the pool?
2) is it possible to do a simple membership test on the
contents of a group-map pool as if it were a table pool
before using the "call" rule to actually switch to the
group selected in the group-map?
Obviously, the second "solution" could be used with two pools:
one a group-map pool and the other a table pool; however this
leads to two pools that could get out-of-step when being
updated and in any case is a duplication of data the is best
avoided if practical.
It would certainly be helpful if the *intended* behaviour in
this area could be documented for clarity in the future.
--
David Pick
