On 22/02/2010, at 2:12 PM, Joel Wiramu Pauling wrote:

...

There are lots of techniques.

I guess the first way to unravel this is ask why you want to count Teredo traffic?

Let's assume I manage a large network, with no current native v6 to the edge but a lot of clients at my edge which will have teredo on (win7 etc). And I want to snapshot how much of my total traffic is tunneled v6.

This will let me do a few things:

a) Capacity plan for say a Teredo relay b) Get a feel for what might happen when I deliver v6 to the edge

Actually having Teredo users on your network now will not help you plan for a Teredo relay, unless you infer that everyone with IPv6 in your network also has (and is using) Teredo, and that everyone that has Teredo will use your native IPv6. Both of these are unrealistic in your situation as a provider that does not provide CPE or mandate which OS users use and which OS options are enabled. Teredo relays are used by your native IPv6 users who want to send traffic to Teredo users (either on your network, or elsewhere). Your first stab at this, looking for 2001:0000 in packets does not work, because those bytes are going to be inside the payload of UDP over IPv4 messages. Netflow doesn't get you that sort of information - it gives you up to L4 headers only, and on a per-flow basis with some key things - it does not give you full headers for every packet. Your second stab at this, counting traffic to/from certain relays and servers also doesn't work, because you are not counting traffic between two Teredo users, which is in my estimation going to be by far the majority of Teredo traffic in your network. The only way I have found to estimate Teredo traffic on an IPv4-only network is to use netflow, and process as follows: 1) Look for messages to 3544/UDP and 3545/UDP. There should be one every 30 seconds from every active Teredo stack in your network. 2) Take note of the source IPv4 address and UDP source port of the messages captured by the above. 3) Look for messages to/from these IPv4 address and UDP port combinations. 4) Age out old combinations perhaps 5 minutes after the last time you see a 3544/UDP or 3545/UDP message. This is going to catch a large portion of the traffic - I'm not sure that this will catch Teredo traffic to/from a host behind what the Teredo RFC dubs a symmetric NAT. Initial thinking about it suggests that it will catch some. You might also want to figure out population of active Teredo stacks - just do step 1 above. -- Nathan Ward