As I recall
from looking at it and my recent experiences, iptACCOUNT will
require
a serious rewrite to handle IPv6. It uses a kernel page to store stats
for
an IPv4 /24 (bytes & packets; in & out). Since IPv6 addresses
are
typically anywhere within a /64, that method becomes unworkable
(unthinkable,
really).
Another problem is that it uses 32-bit
counters. They roll over in about 34
seconds at saturated gigE
speeds. At 10G speeds, they can roll over in barely
more than 3
seconds.
The last problem I can readily identify is that IPv6
uses
- link local addresses
- a prefix for DHCP-assigned
addresses
- a prefix for SLAAC addresses
- possibly a prefix
for private addresses
That's potentially four addresses per NIC that
must be tracked.
I haven't yet thought of a way to modernize
iptACCOUNT and remain efficient
That bolt of lightning over my head
hasn't flashed on yet.
I seem to recall reading about ipset being
enhanced to track per-address
stats. It might be efficient if it
was written like the rest of ipset.
Neal
--
ipt_ACCOUNT
- see
http://www.intra2net.com/en/developer/ipt_ACCOUNT for details.
To
unsubscribe send a mail to
ipt_ACCOUNT+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx