RFC: documented and actual behaviour of "ipfw tee"

[Luigi Rizzo]

There a difference between the documented and actual behaviour of
"ipfw tee" which occurs when there are multiple rules with the same
number, e.g.

	rule_id number  body
	r1      500     tee port1 dst-ip 1.2.3.0/24
	r2      500     tee port2 dst-ip 1.2.4.0/24
	r3      500     accept ip from any to any
	r4      510     count ip from any to any

+ the manpage says "processing continues with the NEXT RULE"
  (so after r1 we have r2, then r3, ...);
+ the implementation behaves as "processing continues with the
  NEXT NUMBERED RULE" (ie. after 500 continues with 510).

The actual behaviour is an artifact of how "divert" is implemented:
diverted packet only carry the rule number so we cannot tell, on a
reinject, which of the rules numbered "500" matched, and we restart
from the next one. Tee was implemented as an extension of divert.

Skipping rules in my opinion is very unintuitive, but there is
no way to fix it (unless we extend the API) as the rule_id is only
known within the kernel.

For 'tee', however, packets  the situation is different because the
copy of the packet that remains in the kernel does not lose knowledge
of the matching rule so we can easily continue from the very next
rule, same as it happens for dummynet packets with one_pass=0 (and
tee'd netgraph packets, which I think already do "the right thing").

Since I am doing some work in this are of the code, I'd like to ask
opinions on how to proceed:

    A. preserve the current behaviour and fix the manpage;
    B. fix the code to behave as the manpage says;
    C. introduce a sysctl to choose between A and B.
	Of course this moves the problem on which default
	to choose :)

Because it is a very special case that I doubt many people have hit,
I'd be inclined to do B and consider the old behaviour a bug.

	cheers
	luigi