Jump to content

IPv6 (NOT Teredo) handling


bschmidt

Recommended Posts

Hello,

just a short question I thought of doing some traffic analysis on our university network and from a few (short) observations with live torrent traffic.

We all know that µTorrent 1.8 now has a button to enable IPv6 on the host and uses IPv6 to do connections. However, when doing short µTorrent tests on a _native_ host (NOT inside the 2001::/32 Teredo range, but in a normal ISP-assigned native subnet) I could not see any IPv6 peers used at all, even though I guess it should have learned a few through PEX, and since I did not have any portforwarding on the IPv4 NAT configured IPv6 connectivity would have been better than IPv4 (inbound connections would have been possible).

As another datapoint, I'm running an IPv6-only Azureus client (IPv6-only by having an IP-Filter from 0.0.0.0 to 255.255.255.255 configured) against a few IPv4-only trackers, again on a host with native (not Teredo) connectivity. Azureus does IPv6 DHT and PEX, so by learning the IPv6 address of another dualstacked peer it can (and does) learn IPv6-enabled µTorrent peers.

The puzzling thing here is, that I could see literally dozens of Teredo µTorrent peers and a few native or 6to4 connected Azureus peers, but _no_ native or 6to4 µTorrent peer. I know that native IPv6 isn't that widespread yet (although it's gaining fast), but to my knowledge Windows actually configures and prefers 6to4 over Teredo (less complicated protocol) when having a public (non-RFC1918) IPv4 address somewhere, which is not that uncommon (think of anyone not using a router but a cablemodem or direct on-the-host PPPoE dialup).

Those two experiences start to make me think that µTorrent only deals with IPv6 if the local address is a Teredo one, but not where it would actually make sense (native end-to-end connectivity). I could be wrong and just have drawed the wrong conclusion here, so I'm asking:

Is there any special handling regarding the type of IPv6 connectivity in µTorrent?

Thanks,

Bernhard

Link to comment
Share on other sites

There are a few Teredo-specific exceptions that uTorrent should probably not have:

- when checking in to the tracker, &ipv6= is only sent if a Teredo address exists

- when sending a peer address to a peer connection (over v4) 'ipv6' is only sent if a Teredo address exists

I do not believe this will entirely prevent native IPv6 operation. If the connection to the tracker is v6, and v6 peers are returned, uT should connect to them over v6, and v6 addresses will be shared via PEX.

Do you have a setup where you can test this simple case? (Two v6 native uTorrent peers and one v6 native tracker).

Link to comment
Share on other sites

Okay, that's just as I thought. Is there any special reason for this behaviour or is it considered a bug and going to be changed at some point in the future?

It does not prevent IPv6 operation with IPv6-enabled trackers (as you said, it will receive IPv6 peers from the tracker and connect to them), but on IPv4-only trackers it more or less limits you to Teredo peers. While Teredo is better than nothing, using a very complicated protocol only with pretty bad scaling factors (when µTorrent was released most of the very few global Teredo relays got overloaded, took me a couple of weeks to get that fixed) for its NAT-traversal abilities while not using the better-scaling native or 6to4 connectivity looks like a bad move to me.

No offense, I'm very happy about this being the second mainstream IPv6 torrent application, I just think it could be even better :-)

Bernhard

Link to comment
Share on other sites

You're reading it right, but they do have the same purpose. Both 6to4 and Teredo are transitioning mechanisms, designed to (automatically) configure a way to access the single(!) IPv6 "internet" from a client only connected to IPv4.

There is a certain hierarchy involved. When you enable IPv6 on Windows it basically

* tries to get a ("native") IPv6 address on it's network links

* tries (semi)statically configured tunneling mechanisms like ISATAP or tunnelbrokers

* tries to configure 6to4 connectivity (which always succeeds if it has a public IPv4 address)

* tries to configure Teredo

Unless there is one of the rare cornercases this is a "first-out-of-4" thing. If it succeeds configuring native IPv6 it will never use any transitioning mechanisms, if it succeeds configuring 6to4 it won't do Teredo. Which is not a problem, because there are public relays deployed worldwide that provide connectivity between the three basic connection methods to IPv6 (ISP-based addressing similar to today's IPv4, 6to4 and Teredo).

By sending your own IPv6 address in PEX only if you have Teredo you limit yourself to the "worst" way of connecting to IPv6 (Teredo is very complicated and not very many relays are deployed worldwide), while the real IPv6 advantages shine more when you are using native.

Bernhard

Link to comment
Share on other sites

That is one of the reasons.

These relays are generally operated by an ISP. The most significant other reason is that Teredo is a pretty complicated protocol and the only usable (relay) implementation is Miredo on Unix. 6to4 relays can be (and usually are) run on some bored Cisco router somewhere within your network, which is generally preferred by many people (networking people hate servers and vice versa :-) ).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...