[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6to4 relay and Teredo relay load - Bittorrent. Now with numbers!




On 14/10/2007, at 12:24 PM, Nathan Ward wrote:


On 14/10/2007, at 5:07 AM, james woodyatt wrote:

On Oct 13, 2007, at 02:35, Jeroen Massar wrote:

Be happy that they already have IPv6 implemented, BT might actually be
one of the few things that might generate lots of traffic on IPv6.

Highly unlikely. Ubiquitous IPv6 stateful packet filters that behave the same way as the filters in IPv4/NAT gateways will give BitTorrent users the same hassles on IPv6 as they currently endure on IPv4/NAT. The incentive for BitTorrent users to migrate to IPv4 simply isn't there unless they're willing to turn off those filters.

So far, there appears to be no let up in the demand for these filters on IPv6. It's possible that a long-term solution to this problem might emerge in five or ten years, but I wouldn't expect much before then.

Of the hosts that attempted to connect to me:
- Over 50% had 135/TCP open.
- Several had 22/TCP open, and everything else closed (returning RST).
- One had 80/TCP open, and everything else simply dropping packets.

That 135/TCP is open is certainly surprising - these were all hosts using the Windows-like single-host-on-6to4 addressing, ie. 2002:V4V4:V4V4::V4V4:V4V4.

I did some more digging. Here's some interesting data:
- 1 hour of collecting packets directed to my BT client's DHT port (it uses UDP).
- 3134 unique hosts talked to me.
- 1535 IPv4
- 1599 IPv6 (!!)

IPv6 hosts:
- 20 were non-6to4 (ie outside 2002::/16)
- zero were Teredo (ie 2001::/32)

IPv6 6to4 (2002::/16) hosts:
- 1288 were "Windows-style" 6to4 addresses - as mentioned above.
- 19 were using a non-zero "subnet" part (ie, bits 49-64 inclusive), more detail below.

Non-windows style addresses (291 hosts):
- 277 were using EUI-64, and all had the locally administered bit set.
- 14 were not using EUI-64, 9 of these had a non-zero subnet part. Only one had :: in the address, bits 49-128 were 1::1.
- No MAC-48.

6to4 "subnet" part (only 19 hosts):
- Only one had 0x0001 in the subnet part, and zero had 0x000a or greater.


The bit I find the most astonishing, is the ratio of v4:v6 hosts. My understanding of BT's DHT is that it is used to find peers to exchange data with - this means that if DHT is effective, there's likely to be a huge amount of BT data between DHT peers going over 6to4. Luckily, only a very small amount (0.63%) is likely to go via a 6to4 relay.

Also interesting is where people are not using EUI-64. I guess this is using the privacy extensions stuff.

I noted that of the hosts I attempted to send DHT data to, the ones that didn't reply were about 20% IPv6 and 80% IPv4. As I look higher in the number of reply packets, the hosts that replied were about 95% IPv6 and 5% IPv4. That indicates to me that IPv6 is working around the IPv4 NAT problem better than the available IPv4 solutions for this application.
Of the traffic coming to my IP addresses, 62% was IPv6 and 38% was IPv4.

I'll see if I can get "replied" percentages for IPv4 and IPv6, where I sent data to a host and got a reply vs. didn't get a reply. I'm not sure if that's relevant though, as this is UDP and might not have any kind of response required at a higher level. If there is a response required, I'll see if I can find some hosts who I have talked to over both IPv4 and IPv6, and see if there's any notable lack of replies when using either protocol.

--
Nathan Ward