[ipv6-wg at ripe.net] IPv6 traffic measurement

Hi Savitha, Gert,

Regarding IPv6 accounting using a PCAP program:

| > http://sf.net/projects/yaps-pcap/
| 
| I took a look at your project at the above URL. Looks
| good. But the catch here is that it is a packet
| sniffer. An accounting tool essentially uses packet
| sniffers generally libpcap but does something more
| than that (using SNMP MIBS, or something like that).
| The advantage of this is it can be used for large
| enterprises/networks and the most important point is
| if the network is migrated to gigabit Ethernet or
| something packet sniffers would'nt work as they don't
| follow a standard.
Well, scaling is the problem we had at AS12859 also,
when we upgraded from an STM1 to multiple dark fibers
carrying GigE. 

Allthough today's hardware is indeed capable of examining
line rate gigabit traffic, it's not optimal and kind of
difficult to get the traffic to a single measuring point
when you have multiple exitpoints.

This is actually exactly why I wrote YANA (Yet Another
Netflow Analyser) two weeks ago. What this does is extend
the way YAPS works (accounting IPv4 addresses using pcap),
to support IPv4 accounting per interface per cflow source;

This way, one can answer questions like "What is the top10
speaker at the DE-CIX shared medium (fa0/2 @ cis1.de-cix) ?"
or "From AS-BIT, who talks the most to AS3356 at AMS-IX
(ge-0/1/0.100 @ jun1.ams-ix); Not to plug this software,
but it seems natural to respond to your scaling issue. It's
well under control using (statistical) flow management.o

Back to IPv6. Gert seems interrested, and at least so am I.
What I need is to change the source code a bit to use a new
hashing library which I wrote for YANA. It is able to hash
IPv6 addresses too and should be just as fast on both
endian platforms, taking only memory for the IPv6 addresses
that actually use resources.

Gert (or others), would you be interrested in per-prefix (ie,
per /48 or per /64) statistics, or per-host (/128) stats ?
I am interrested in all three of them, but implementing it
takes careful consideration. The /128 approach can be
aggregated into accounting per /64 or other size, of course
using potentially a lot more memory .. at 48 bytes per counter,
if somebody started sending traffic to your /32, you'd quickly
end up exhausting available primary storage on the measuring
box.

One method I could think of, is only initializing a new counter
for a /128 which you've actually seen *outbound* traffic on. 
This way, random junk and portscanning will not explode your
counter counts that much. It still remains difficult though,
due to the numbers of (potentially) active IPv6 addresses ...

Another is timestamping. We could make counters disappear
after N seconds of idletime; this way noise can be eliminated
and all idle IPv6 (and IPv4) addresses are eliminated... hmm,
thinking aloud on this forum may help.

Any other thoughts on this (YAPS and YANA) approach ?

Does anybody want to help test (even develop?) this software ?

-- 
---------- - -    - - -+- - -    - - ----------
Pim van Pelt                 Email: pim at ipng.nl
http://www.ipng.nl/             IPv6 Deployment
-----------------------------------------------