What is this bittorrent network flow? [closed] - networking

Question

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I've recorded some network traffic in my home that only appear up while running BitTorrent or uTorrent.
I've been reading the bittorrent protocol descriptions, but I am stuck trying to figure out a particular network flow.
Can someone help me identify what the following bittorrent network traffic is exactly?
It lasts quite a long time, even after stopping downloads.
All packets are in one direction - from my local machine running Bittorrent to a remote machine.
Here is data payload of one packet (copied from Wireshark):
00000000 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000010 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000020 20 5a 01 45 bd 13 b1 65 01 04 44 4a e7 d5 04 04 Z.E...e ..DJ....
00000030 01 00 00 00 05 02 ea cf ........
All the packets in the network flow are similar, here are two more:
00000038 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000048 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000058 20 5a 01 45 bd 13 b1 65 01 04 08 8e 35 9f 04 04 Z.E...e ....5...
00000068 01 00 00 00 05 02 ea cf ........
00000070 60 00 00 00 00 00 3b 15 20 01 00 00 9d 38 6a b8 `.....;. ....8j.
00000080 04 b9 18 bf 9c 90 d8 81 20 01 00 00 9d 38 6a b8 ........ ....8j.
00000090 20 5a 01 45 bd 13 b1 65 01 04 12 3e ba 6c 04 04 Z.E...e ...>.l..
000000A0 01 00 00 00 05 02 ea cf ........
These bittorrent packets are typically several seconds apart, and this flow seems to go on indefinitely. Which one of the bittorrent protocols describes this network flow?

Answer 1

I just sent a response to you on our mailing list, but I'm gonna post here too in case anyone else stumbles across it and finds it useful.
They're Teredo packets (with no payload). Wireshark can decode these
but it doesn't do so without coercion.
http://en.wikipedia.org/wiki/IPv6_packet
http://en.wikipedia.org/wiki/Teredo_tunneling
One of your packets dissected:
IP Version: 6
Traffic Class: 0 0
Flow Label: 0 00 00
Payload Length: 00 00
Next Header: 3b (indicates that there is no payload present)
Hop Limit: 15
Source: 20 01 00 00 9d 38 6a b8 04 b9 18 bf 9c 90 d8 81
Destination: 20 01 00 00 9d 38 6a b8 20 5a 01 45 bd 13 b1 65
The source and destination also encode the source and destination
public ipv4 addresses and ports.
The hop-by-hop options header (in type-length-value format) follows in
this case. The possible types can be found here:
http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
So we have this:
01 04: c3 ae 60 38 ("PadN", random bytes)
04 04: 01 00 00 00 ("Tunnel Encapsulation Limit")
05 02: ea cf ("Router Alert")
No clue what the value of the router alert field is here. I would
expect it to be listed here:
http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xml
But it looks like either that's out of date or the Teredo
implementation you're using is doing something non-standard (or
there's something I've missed).
Anyways, these are clearly keep-alive packets. We're not directly
triggering them in the client as far as I know. I believe they're sent
by your Teredo driver to keep your tunnels open.