nanog at daork.net
Wed Aug 20 12:10:36 CDT 2008
On 20/08/2008, at 4:42 PM, Nathan Ward wrote:
> Teredo uses 3544/UDP to for Client<->Server communication. That is
> for relay discovery when needed, and the qualification procedure -
> not much traffic. Client<->Relay communication MAY use 3544/UDP,
> Client<->Client communication MAY use 3544/UDP.
> In my experience (packets I have been analysing in the last 24 hours
> for example) suggests that not many actual data packets are on UDP/
> I'll get some exact numbers on that in a few hours if you like.
Over a 16 hour period, I captured Teredo encapsulated packets. I run
my own Teredo server and so on, so I can statically set what my Teredo
IPv6 address is.
I'm running Azureus on this, and also on a 6to4 address on the same
host. Running DHT so I talk to as many peers as possible.
Azureus DHT uses lots of very small UDP over IPv6 packets (100b or
so), so those are my "data" packets. The rest is just Teredo
My numbers here are actually low, because of various 6to4 routing
things that I don't really care to go in to in too much detail. I
estimate that I'm missing 40-50% of the traffic that I'd normally see
if I had IPv6 over only Teredo. I'll re-run this test properly when I
get a chance, but it'll only make the numbers bigger.
I exchanged packets with a total of 4177 IPv6 hosts.
- 767 hosts were on Teredo.
- 2657 hosts were on 6to4.
- 753 hosts were on neither Teredo or 6to4.
(I have a whole other rant around these vs. IPv4 as well.)
The stats in the document produced by Arbor that was posted on
Slashdot suggest 12Mbit/s of Teredo traffic. Their method for
determining "Teredo" was to look for 3544/UDP and 3545/UDP.
Of my total 96,148 packets, 27,676 were UDP over IPv6 data packets (ie
not teredo maintenance). They are all very small.
- 24,175 (87%) of those 27,676 UDP over IPv6 data packets were on non-
well known Teredo ports.
o 18,436 (76%) of those 24,175 are going through a relay somewhere.
57,624 (59.9%) of the total 96,148 packets were on non-well known
Teredo ports. (including Teredo maintenance stuff).
- 34,766 (60%) of those 57,624 are going through a relay somewhere.
So, somewhere in the region of 60%-87% of Teredo packets were missed
by the report.
60%-76% of those packets missed are going through relays.
So, assuming that all Teredo users do small packets, and talk to a
large number of hosts like I do (100b or so packets, lots and lots of
Teredo maintenance packets), the report misses about 17.9Mbit of data.
If we go to the other end of the scale, and assume that most users do
more data than I do (say, they load web pages, do file transfers and
things), and talk to fewer hosts, we trend towards the 87% mark, in
which case the report misses 80Mbit of data.
1) The report misses 18-80Mbit of total Teredo traffic.
2) The report misses 11-61Mbit of Teredo traffic going through relays.
(a sub-set of the total Teredo traffic).
The report observes approx 150Mbit/s peak IPv6 traffic.
18-80Mbit of data is not an insignificant error: 12% - 53%.
So, we know that Teredo is currently under-estimated.
This is when I'm talking IPv6 to other end hosts running an
application that doesn't know how to talk to the Teredo stack on
Windows hosts (the majority of the remote ends).
So, now that uTorrent 1.8 is out, with it's ability to use the Teredo
stack, are we likely to see an increase in that 60-87% percentage,
because of Teredo<->Teredo direct communication? Yes, Teredo<->Teredo
communication always goes on non-well-known ports. This Arbor report
is going to even more out of date, fast.
If you're deploying non-Teredo IPv6 service (native, 6to4, whatever),
you're going to have your end users talking to Teredo users, and 6to4
users. This number is going to grow. Get some relays, because the
publicly available ones are going to start hurting soon, and any
traffic you push through them is going to go slow. Whether you are
pushing bittorrent or not, other people will be, and your non-
bittorrent traffic will suffer.
ps. maths might be broken, it's late in my part of the world.
 Because the packets I miss (the 40-50% that I estimate) are me ->
6to4 connected end host packets, they would go through a relay as
well, so this number would be higher if I was catching all those
 My understanding is that Azureus can't talk to the Teredo stuff,
I'll have to ask some Java coder friends to confirm that.
More information about the NANOG