27.02.08 @ 11:19 Andrey V. Elsukov wrote:
I talked to Roman when he submitted his first patch about
it's design. What you think about making TOK_SETIPTOSPRE not
an action, but a modifier? I think it will be much usable.
Agree. If it is more general ``modip'', one could wish to change more than
one IP field in the same rule.
A syntax example:
# ipfw add allow iptospre flashover ip from any to any
# ipfw add count iptospre immediate ip from any to any
# ipfw add skipto ....
Also I talked to Roman about extensible variant of this ability.
A syntax example:
<action> [{modip [DF|TOS|DSCP|TTL]}] <rule body>
Yes, that's what's really needed - I've seen people asking for ability to
change not only TOS (and more often DSCP), but TTL and DF bit. Moreover, I
think all features from RFC 3168, RFC 2780 should be supported, including
ECN bits (again in TOS byte). And, it must be consistent: all things you
can set with this action you should be able to check in the options
section. So that if user is able to match:
ipfw add count ip from any to any iptos reliability,congestion
then there must be possibility to write:
ipfw add count modip tos reliability,congestion
And vice versa, if one can able to modify a field:
ipfw add count modip dscp af11 ip from any to any
then he must be able to match it:
ipfw add count ip from any to any dscp af11
Other consistency question - currently we have ``ipprecedence'' option
which takes a numeric argument, and proposed patch uses symbolic names
like ``flashover''. It may be desirable to allow both forms to be used in
both TOS and DSCP fields (for both matching and setting), thus not
limiting to predefined bit names.
The other thing (apart from adding more ECN bits to the only one currently
existing ``congestion'' in iptos) is TTL-setting ability to make it not
only fixed, but relative also, like this for increment:
ipfw add count modip ttl +1 ip from any to any
It is questionable, though, will it be enough 16-bit single arg1 for
O_MODIP ipfw_insn. May be it should be two, and be a structure allowing
further extension (e.g. modifying any bytes, but that's far future)...
P.S. One more stylish comment on the patch - constants for TOS should not
be reinveneted, but taken where possible from system includes, e.g.
IPTOS_* from <netinet/ip.h> in this case.
--
WBR, Vadim Goncharov
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"