Context Navigation

← Previous Ticket
Next Ticket →

Ticket #1111 (new enhancement)

Opened 2 years ago

Last modified 4 weeks ago

Support for IPv6?

Reported by:	Elvis Bosch	Owned by:	rakshasa
Priority:	high	Milestone:
Component:	rtorrent	Version:
Severity:	minor	Keywords:	IPv6
Cc:

Description

When can we expect support for IPv6?

The most simple support (working IPv6 only) should be trivial to implement. The only real problem should occur when working with trackers/swarms, that use IPv4 and IPv6 at the same time. For this case I found some interessting suggestions at:

http://tinyurl.com/3dorca http://tinyurl.com/3bajew

Attachments

Change History

Changed 14 months ago by anonymous

Supporting IPv6 purely for the transport of tracker announces and .torrent file download would be next to trivial (change CURLOPT_IPRESOLVE to CURL_IPRESOLVE_WHATEVER in curl_get.cc). Supporting ipv6 peer connections would be considerably more effort on the other hand.

Note that CURL_IPRESOLVE_WHATEVER may not work if libcurl is built with c-ares, as c-ares can currently return only ipv4 or ipv6 addresses. So if you set it to CURL_IPRESOLVE_V6 it may break ipv4 trackers if libcurl is built with c-ares. I'm not sure if recent libcurl versions fix this.

Changed 13 months ago by anonymous

Not sure if it is appropriate to add this here, but ever since TPB started supporting IPv6 I've been unable to use any of their torrents, no errors, just no peers to connect to. Changing the tracker address to the IPv4 address of tracker.thepiratebay.org makes it all work again. Not sure if this is simply the way this is supposed to work like this (since it does make sense to me that if you connect to a tracker over IPv6 you only get IPv6 peers, of which there probably aren't too many.), but might be worth mentioning for other people experiencing the same problem.

Additionally maybe it would be nice if there was a way to force IPv6 to be disabled for the transitional period.

Changed 13 months ago by nanonyme

Hmm, if it's true that you only get IPv4 addresses when connecting to the tracker over IPv4, would just mean the client needs to poll the tracker double the amount of times (half on IPv4, half on IPv6) if the client has both native IPv4 and native IPv6. Bittorrent over a tunnel is pretty much moronic. rakshasa, while I understand doing a dual-stack client (which would be the preferred way) requires quite a bit of work, would making an IPv6-only "fork" be that hard? I've only taken a look on the surface level on the source code and appears code split wasn't immediately obvious to me.

Changed 10 months ago by anonymous

The lack of IPv6 is the only thing turning me away from rtorrent. So far deluge has all I want but it sounds like rtorrent may have a lower resource usage but since it lacks IPv6 it's not an option.

Also I don't see why bittorrent over a tunnel is moronic. It sounds more like a moronic comment to me...

Many tunnel providers are trying to convince people to use IPv6 so provide good bandwidth and limited or no traffic shaping which is more then can be said for many ISPs in many places. Of course if your ISP is shaping tunneled IPv6 it may not help much but they may not, particularly if it's local traffic (and quite a number of countries have local tunnel providers). And remember it cuts both ways. If you IPv6 connectivity is no worse and no better then you IPv4 even if tunneled, it could still help you if the seeder or (if you aren't a leecher who cares little about giving back) a leecher and the peer has decent better IPv6 connectivity then IPv4 (whether tunneled or native). Obviously you should abuse a free service but many tunnel providers are encouraging this sort of usage. Let's not forget that SixXs? a conglemerate of tunnel providers offer a IPv6 ONLY tracker with free seeding (obviously only for legal content). Finally if there are decent IPv6 peers particularly on a rare file, why not use them tunneled if that's the only option to you even if your IPv6 connectivity is worse then IPv4 it may still be better? The simple fact is, there are many good reasons why IPv6 whether tunneled or native provides advantages, if it's not added soon rtorrent is going to be left behind.

P.S. Let's not forget many people are using and paying for internet enabled 'VPNs' to get around traffic restrictions. Sometimes VPNs in far away countries. That's hardly moronic if it's the only way for them to get decent torrents. And if they don't care about latency (and bt isn't really latency sensitive) why not use the VPN that gives the best performance for the best price no matter what country? This may not be great for the internet but it's not their fault the system is so borked. And using IPv6 with a free tunnel broker that's in the same country in addition is obviously far better then that.

Changed 10 months ago by anonymous

If it's so easy, why didn't you do it in 5 minutes already?

Fact is, adding IPv6 support in rtorrent is SIGNIFICANTLY more work than you expect. It's not just "a few lines of code" here and there. There are thousands of lines of code you'd have to review, to check if they break if the address family is now different (for instance because they attempt to store a network address in a 32-bit integer), in addition to writing new code for just about any function that uses networking. Many things will just not work in IPv6, like DHT which will require a modification to the protocol. So those need to make sure that they don't accidentally use IPv6 addresses/sockets. And all that without making the regular IPv4 code less efficient and buggier.

I estimate that if you were to pay someone to add IPv6 support, the number of hours of work required would likely not let you get away with under $500. Twice that would not be surprising either. And that's not even including fixing the inevitable bugs that will show up. So, how much is IPv6 support worth to you again?

Changed 3 months ago by Steinar H. Gunderson

Here are IPv6 patches for current libtorrent/rtorrent. They're written by myself, and to the best of my knowledge will make rtorrent conform to BEP 7 ( http://www.bittorrent.org/beps/bep_0007.html).

http://home.samfundet.no/~sesse/libtorrent-0.12.6-ipv6.patch http://home.samfundet.no/~sesse/rtorrent-0.8.6-ipv6.patch

The changes can be summarized as follows:

rak (same changes in libtorrent and rtorrent): Extend the socket_address class to support IPv6 where needed, including string parsing.
libtorrent: Open an IPv6 socket if supported, and communicate with mapped-v4 addresses on that socket for IPv4. (I haven't actually checked if I can do without send()-ing to mapped-v4 addresses or not.)
libtorrent: Send IPv6 address (after a priority order, which prefers global addresses and discourages secondary/privacy addresses) in ipv6= header if not already sending an ip= header.
libtorrent: Support IPv6 addresses in compact (binary) format.
rtorrent: If a HTTP connection (e.g. to a tracker) fails due to name resolution problems, try once more over IPv6. (IOW, IPv6 connections are supported, but IPv4 connections are always preferred, since by far the easiest way to give the tracker our global IPv4 address is to connect to it over IPv4.)
rtorrent: Widen the IP field a bit in the peer list, and truncate IP addresses that are too long by replacing the overlong part with "...".

All changes are #ifdef-ed with RAK_USE_INET6. I've tested this lightly against different clients and trackers, and it generally seems to work about as well as the other clients I've tried. That doesn't mean there still can't be bugs, of course.

Possible caveats:

I haven't actually tried with --disable-ipv6, but I guess that will be caught pretty quickly.
I honestly don't know enough about the libtorrent ABI to say if this change warrants an ABI bump or not it or not, but I have the feeling it might. (Also, RAK_USE_INET6 might cause an ABI change, in which case rtorrent and libtorrent need to be compiled with the same --{enable,disable}-ipv6 option.)
I haven't tried compiling on anything but Linux, but I don't use anything non-POSIX (except the IPv6 address discovery, which has a POSIX fallback).
Privacy addresses could be handled more elegantly; in particular, when connecting to an IPv6 tracker we will most likely connect using a privacy address that may disappear between now and the next tracker connect. There are several ways of mitigating this (like watching the address and reconnect to the tracker once it goes away, binding to a non-privacy address when connecting, or binding to the address we gave the tracker to keep it from going away), but in practice the problem will be relatively small, especially as privacy addresses are pretty rare outside Windows.
The IPv6 DHT extension is not implemented.

BTW, whoever up in this thread claimed an rtorrent IPv6 patch must be a huge amount of work and cost at least $500... I'm not sure how much you've looked at rtorrent source before, but it wasn't. I'd gladly take $450, though, if you really want to pay =)

Changed 3 months ago by josef

Nice work, although I'm sure you had to work for more than a few hours... maybe you're just underestimating your hourly worth ;)

Now to the comments... I haven't been able to compile it on either Linux or FreeBSD.

On Linux 2.6.28 (Kubuntu 9.10 x86_64) I get a compile error and some warnings:

local_addr.cc: In function ‘bool torrent::get_local_address(sa_family_t, rak::socket_address*)’:
local_addr.cc:206: warning: comparison between signed and unsigned integer expressions
local_addr.cc:208: warning: comparison between signed and unsigned integer expressions
local_addr.cc:225: error: ‘IFA_F_DADFAILED’ was not declared in this scope

It seems that the IFA_F_DADFAILED #define was added in a later kernel. You should probably add checks for all of them and default them if they do not exist.

Furthermore, s6_addr32 is not a posix member of in6_addr, on FreeBSD I get errors in socket_fd.cc and local_addr.cc, for instance:

socket_fd.cc:60: error: ‘const struct in6_addr’ has no member named ‘s6_addr32’

The only reliably defined member is uint8_t s6_addr.

Also, I think the dummy IPv6 for retrieving the local address (on systems other than Linux) should be in the documented example network, 2001:db8::/32, and the dummy IPv4 should be in 192.0.2.0/24. Or at least some other addresses that are guaranteed to never become valid addresses. Actually, the local address should perhaps be determined separately for each destination address, for multihomed setups with not just one default route.

Finally, you mention that the DHT ipv6 extension isn't implemented, are you going to work on that? Currently DHT is completely broken and produces an error message when trying to start it:

DHT error: Address not af_inet

And a question regarding this:

+AddressList::parse_address_compact_ipv6(const std::string& s) {
+  if (sizeof(const SocketAddressCompact6) != 18)
+    throw internal_error("ConnectionList::AddressList::parse_address_compact_ipv6(...) bad struct size.");
+
+  std::copy(reinterpret_cast<const SocketAddressCompact6*>(s.c_str()),
+           reinterpret_cast<const SocketAddressCompact6*>(s.c_str() + s.size() - s.size() % sizeof(SocketAddressCompact)),
+           std::back_inserter(*this));
+}

Shouldn't it be " % sizeof(SocketAddressCompact6)" instead of SocketAddressCompact?

Changed 3 months ago by Steinar H. Gunderson

josef: Thanks for your comments. I'll try to respond as best as I can:

IFA_D_DADFAILED: Yes, this should have an #ifdef.
Lack of s6_addr32: I'm a bit surprised, but okay. :-)
2001:db8::/32: The problem with this is that you're not really guaranteed to have a route there. For instance, on my router I have a full BGP table and thus no default route; 2001:db8::/32 simply not have a route entry, but 2001:700::/32 will definitely unless all Nordic universities drop off the IPv6 Internet entirely. (I considered using 2001::/32, but that's Teredo and would probably prefer a Teredo address, which is not good.) Another alternative would be the tracker's IPv6 address, but of course the tracker might not have IPv6. In any case, we can only give one ipv6= address here, so we can't really distinguish between multiple destinations.
DHT: OK, that's not good. I'll fix that later today.
SocketAddressCompact?6: Nice catch. I'll update the patch.

follow-up: ↓ 28 Changed 3 months ago by Steinar H. Gunderson

Here's an updated patch:

http://home.samfundet.no/~sesse/libtorrent-0.12.6-ipv6-02.patch

No changes needed to rtorrent from the last patch. Changes:

IFA_D_* are not #ifdef-ed for one by one.
All use of s6_addr32 have been replaced by casts (where const) and memcpy (where not, so we won't get aliasing issues).
IPv4 DHT should now work properly. I haven't been able to find a tracker where there are IPv6 DHT clients; thus, I haven't done anything to DHT for IPv6.
The SocketAddressCompact?6 typo has been fixed. Since 6 is a multiple of 18, I don't think it had much practical effect except for malformed replies (where it may have caused a theoretical security problem?).

Note that I'm not honestly sure if FreeBSD supports mapped-v4 on IPv6 sockets at all. If they don't, one would need to change into using separate v4 and v6 sockets, which would be more intrusive. I don't think we need to fix everything at the same time to get such a patch merged -- BSD users can simply use --disable-ipv6 and keep on going as before.

Changed 3 months ago by Steinar H. Gunderson

FWIW, the only reference I could find says that only OpenBSD has done this, and the relevant RFC seems to be RFC4942 ( http://www.ietf.org/rfc/rfc4942.txt) which pretty clearly says mapped-v4 addresses in APIs (as opposed to on the wire) are not deprecated (near the end of section 2.2).

If OpenBSD thinks this is a reasonable decision, by all means they are free to think so (although I respectfully disagree). I guess it's up to the rTorrent developer(s) to figure out if that should block this patch or not -- it's not hard to check for such behavior at configure time and disable IPv6 if so, so it should not cause any regressions.

Changed 3 months ago by anonymous

They're not deprecated as such. It was a security consideration of OpenBSD to disallow dual-stack sockets, because it's possible that someone might write an app which fails to apply IPv4-based access rules correctly for mapped-ipv4 addresses. Yeah... not only do they take away the gun so you can't you shoot yourself in the foot, they also pad the foot so heavily that you can't even walk anymore. Sigh.

I doubt this is up for discussion, so you would need to have a facility for opening two sockets on OpenBSD, one for ipv4 and one for ipv6.

Does it work to compile with patch, but configure --disable-ipv6? Then the OpenBSD issue shouldn't be a blocker.

in reply to: ↑ 22 Changed 3 months ago by josef

Replying to Steinar H. Gunderson:

* IPv4 DHT should now work properly.

It still needed some work, because it assumed the family was af_inet and used the address accordingly. The IPV4 is used as key and hashing salt, so the easiest way to fix this was to translate mapped addresses, without that change it couldn't validate received packets and just discarded them. Currently it still can't process actual IPV6 packets however. Patch is at http://ovh.ttdpatch.net/~jdrexler/rt/experimental/fix-dht-ipv6.diff

It would be useful if you could put the ipv4-from-ipv6 normalization from socket_fd.cc into rak::socket_address_inet6, though, I could've reused that code here.

Changed 2 months ago by josef

OK, DHT works now, thanks.

For completeness sake I tried compiling with --disable-ipv6, and got three errors where sa_inet6 wasn't protected by an #ifdef:

../../../rak/socket_address.h:389: error: ‘sa_inet6’ was not declared in this scope
peer_list.cc:69: error: ‘const class rak::socket_address’ has no member named ‘sa_inet6’
peer_list.cc:70: error: ‘const class rak::socket_address’ has no member named ‘sa_inet6’

The first error also repeats for rtorrent.

Also, I'm of the opinion that if OpenBSD wants to have a broken IPv6 stack, it's their job to make apps work with it. If they want rtorrent to use ipv6 on their platform, they can go fix it themselves. Such standards-defying behaviour should not be encouraged and they need to be aware of the costs it would force upon others.

follow-ups: ↓ 33 ↓ 59 Changed 2 months ago by anonymous

Actually, it only works on Linux, where I can a sockaddr_in to an IPv6 socket and Linux does the translation. But on *BSD that doesn't work, so the code you have in SocketFd::connect also needs to be refactored into socket_address. Maybe a socket_address_inet6::from_inet function.

Something else that *BSD is picky about, is that the last argument to sendto needs to be not just "big enough", but *exactly* the expected value, so the calls needs to be different for each protocol.

Here's how I got it to work in the meantime: http://ovh.ttdpatch.net/~jdrexler/rt/experimental/fix-ipv6_socket_datagram.diff

in reply to: ↑ 32 ; follow-up: ↓ 34 Changed 2 months ago by anonymous

Replying to anonymous:

Actually, it only works on Linux, where I can a sockaddr_in to an IPv6 socket and Linux does the translation. But on *BSD that doesn't work, so the code you have in SocketFd::connect also needs to be refactored into socket_address. Maybe a socket_address_inet6::from_inet function.

It's pretty easy separating this out. I'll do it.

Something else that *BSD is picky about, is that the last argument to sendto needs to be not just "big enough", but *exactly* the expected value, so the calls needs to be different for each protocol.

That can be fixed by just using length().

Here's how I got it to work in the meantime: http://ovh.ttdpatch.net/~jdrexler/rt/experimental/fix-ipv6_socket_datagram.diff

I tried incorporating this patch, but it seems to be missing something -- m_ipv6_socket is not defined for SocketDatagram??

in reply to: ↑ 34 Changed 2 months ago by anonymous

Replying to josef:

Though I have to wonder why SocketFd isn't derived from SocketBase (and thus Event) in the first place. The Event<->SocketFd casts are pretty ugly.

Well, in general rtorrent uses casting way too much for my preference. It's extremely unobvious that you cannot add a member to SocketFd? without getting random data overwritten since the struct is a different size (that one took me a while to track down). That's not my decision, though, and I take it it is like that because someone in charge likes it that way. :-)

In any case, I've made updated patches -- they should fix compiling without IPv6, and I've pulled the mapped address conversion into rak. It also uses .length() a few places, so it might fix the remaining BSD DHT problems. It's untested except for compilation on Linux, though.

http://home.samfundet.no/~sesse/libtorrent-0.12.6-ipv6-04.patch http://home.samfundet.no/~sesse/rtorrent-0.8.6-ipv6-04.patch

follow-up: ↓ 38 Changed 2 months ago by jakllsch@kollasch.net

SocketFd::set_priority() should have:

#ifdef RAK_USE_INET6
  if (m_ipv6_socket == true)
        return setsockopt(m_fd, IPPROTO_IPV6, IPV6_TCLASS, &opt, sizeof(opt)) == 0;
  else
#endif

Also, the s6_addr32 part of the sockaddr union is not standardized, and thus is not consistently available on all platforms, please use s6_addr instead. (Actually, if you don't mind referencing private elements it is possible. See CUPS's http.h for example.)

With those two things addressed, this works on NetBSD, to the limited extent I tested it.

in reply to: ↑ 37 Changed 2 months ago by anonymous

Replying to jakllsch@…:

SocketFd::set_priority() should have: {{{ #ifdef RAK_USE_INET6 if (m_ipv6_socket == true) return setsockopt(m_fd, IPPROTO_IPV6, IPV6_TCLASS, &opt, sizeof(opt)) == 0; else #endif }}}

That's a compile error; there's no m_ipv6_socket member in SocketFd?. Did you really try this?

Also, the s6_addr32 part of the sockaddr union is not standardized, and thus is not consistently available on all platforms, please use s6_addr instead.

The patch hasn't used s6_addr32 for a long time (actually, since the first version); did you try an old version?

Changed 2 months ago by anonymous

Thanks a lot for the patch Steinar!

I think -05 leaks socket fds on the tracker connection though. After patching rtorrent I get more and more entries like that in lsof:

lxbsc03:~/torrent# lsof -p pidof rtorrent -n | grep identify rtorrent 15491 root 6u sock 0,4 0t0 1151728627 can't identify protocol rtorrent 15491 root 11u sock 0,4 0t0 1151726788 can't identify protocol rtorrent 15491 root 12u sock 0,4 0t0 1151726931 can't identify protocol rtorrent 15491 root 13u sock 0,4 0t0 1151727325 can't identify protocol rtorrent 15491 root 15u sock 0,4 0t0 1151728604 can't identify protocol rtorrent 15491 root 30u sock 0,4 0t0 1151727957 can't identify protocol rtorrent 15491 root 33u sock 0,4 0t0 1151727480 can't identify protocol rtorrent 15491 root 41u sock 0,4 0t0 1151728355 can't identify protocol rtorrent 15491 root 49u sock 0,4 0t0 1151728116 can't identify protocol rtorrent 15491 root 57u sock 0,4 0t0 1151728369 can't identify protocol rtorrent 15491 root 96u sock 0,4 0t0 1151728583 can't identify protocol rtorrent 15491 root 103u sock 0,4 0t0 1151728564 can't identify protocol rtorrent 15491 root 110u sock 0,4 0t0 1151728574 can't identify protocol rtorrent 15491 root 126u sock 0,4 0t0 1151728595 can't identify protocol

I can force the list to grow by forcing tracker announcements (T). This affects both IPv4 and IPv6 trackers. I could not reproduce this using unpatched sources.

Changed 2 months ago by anonymous

Sorry that looks ugly.

lxbsc03:~/torrent# lsof -p `pidof rtorrent` -n | grep identify
rtorrent 15491 root    6u  sock        0,4       0t0 1151728627 can't identify protocol
rtorrent 15491 root   10r  sock        0,4       0t0 1151729890 can't identify protocol
rtorrent 15491 root   11u  sock        0,4       0t0 1151726788 can't identify protocol
rtorrent 15491 root   12u  sock        0,4       0t0 1151726931 can't identify protocol
rtorrent 15491 root   13u  sock        0,4       0t0 1151727325 can't identify protocol
rtorrent 15491 root   15u  sock        0,4       0t0 1151728604 can't identify protocol
rtorrent 15491 root   22u  sock        0,4       0t0 1151730154 can't identify protocol
rtorrent 15491 root   23u  sock        0,4       0t0 1151730320 can't identify protocol
rtorrent 15491 root   26u  sock        0,4       0t0 1151730315 can't identify protocol
rtorrent 15491 root   30u  sock        0,4       0t0 1151727957 can't identify protocol
rtorrent 15491 root   33u  sock        0,4       0t0 1151727480 can't identify protocol
rtorrent 15491 root   41u  sock        0,4       0t0 1151728355 can't identify protocol
rtorrent 15491 root   49u  sock        0,4       0t0 1151728116 can't identify protocol
rtorrent 15491 root   57u  sock        0,4       0t0 1151728369 can't identify protocol
rtorrent 15491 root   96u  sock        0,4       0t0 1151728583 can't identify protocol
rtorrent 15491 root  103u  sock        0,4       0t0 1151728564 can't identify protocol
rtorrent 15491 root  110u  sock        0,4       0t0 1151728574 can't identify protocol
rtorrent 15491 root  126u  sock        0,4       0t0 1151728595 can't identify protocol

Eventually after a couple of hours the rtorrent process either blows up or stops transfering.

follow-up: ↓ 51 Changed 8 weeks ago by anonymous

So I've applied the patch and built out a version of rtorrent that ostensibly supports IPv6. Using lsof, I confirmed that rtorrent's listen port was bound to IPv6, so it appears the patch was applied correctly and rtorrent was built out properly.

I then decided to try out one of SixXS' IPv6-only torrents. Unfortunately, when I added the .torrent file, the tracker returned the following error:

"We only accept direct connections, specifying the ip option thus is not accepted"

So... thoughts? :)

in reply to: ↑ 50 ; follow-up: ↓ 52 Changed 8 weeks ago by Steinar H. Gunderson

Replying to anonymous:

I then decided to try out one of SixXS' IPv6-only torrents. Unfortunately, when I added the .torrent file, the tracker returned the following error: "We only accept direct connections, specifying the ip option thus is not accepted" So... thoughts? :)

IIRC SixXS' torrent service is broken -- their seeds are all offline. (I filed a ticket for it but was told it's not a supported service.)

I haven't seen that error before, though, and I'm unable to reproduce it. Connecting to http://www.sixxs.net/tools/tracker/torrents/65e7d990b15ae4d3a1142dcbb15cb582a8863357.torrent I find one peer and downloading proceeds as usual. What's your configuration -- operating system? Type of IPv6 connectivity? Do other IPv6-only trackers (like the ones on http://ipv6.torrent.ubuntu.com:6969/) work?

in reply to: ↑ 51 ; follow-up: ↓ 53 Changed 8 weeks ago by anonymous

Replying to Steinar H. Gunderson:

Replying to anonymous:

I then decided to try out one of SixXS' IPv6-only torrents. Unfortunately, when I added the .torrent file, the tracker returned the following error: "We only accept direct connections, specifying the ip option thus is not accepted" So... thoughts? :)

IIRC SixXS' torrent service is broken -- their seeds are all offline. (I filed a ticket for it but was told it's not a supported service.) I haven't seen that error before, though, and I'm unable to reproduce it. Connecting to http://www.sixxs.net/tools/tracker/torrents/65e7d990b15ae4d3a1142dcbb15cb582a8863357.torrent I find one peer and downloading proceeds as usual. What's your configuration -- operating system? Type of IPv6 connectivity? Do other IPv6-only trackers (like the ones on http://ipv6.torrent.ubuntu.com:6969/) work?

Ahah! After spending 15 minutes writing up a reply, I think I just figured out the problem. I'd mistakenly had the "ip:" setting defined in my .rtorrent.rc. That setting defines the IP that's reported to the tracker, and is useful if, for some reason, you need to explicitly tell the tracker what your external IP is.

Well, my guess is rtorrent was reporting that IPv4 IP to the tracker, even though I'm dual-stacked and have a local IPv6 address.

Sounds to me like this might be something that should be addressed, though I'm not sure how. Presumably rtorrent provides the tracker with both the IPv4 and IPv6 addresses, if the host is on a dual-stack machine. So I would think, if the "ip" option is specified, that should only affect the IPv4 address reported.

In principle, you could also add an "ip6" (or something) address option to override that value, as well, but given the whole point of such a setting is to work around NAT, and one of the main points of IPv6 is to make NAT obsolete, such a setting would be fairly pointless.

in reply to: ↑ 52 Changed 8 weeks ago by anonymous

Replying to anonymous:

Ahah! After spending 15 minutes writing up a reply, I think I just figured out the problem. I'd mistakenly had the "ip:" setting defined in my .rtorrent.rc. That setting defines the IP that's reported to the tracker, and is useful if, for some reason, you need to explicitly tell the tracker what your external IP is.

Well, this is perfectly legal, and all the more important when you connect to the tracker over IPv6. The tracker will only get one of your IP addresses from the connection itself, so if you want it to use IPv4 as well you have to specify an ip= parameter. The fact that SixXS' tracker doesn't accept that is, well, not a bug in rtorrent.

Note that if you connect to a tracker over IPv4 (the default if the tracker supports it), rtorrent will include an ipv6= flag with the best local IPv6 address it can find.

Changed 7 weeks ago by anonymous

Question about 'bind' option (aka) -b. I know some people use the 'bind' option, along with multihoming, for doing traffic shaping of rtorrent (the TOS flags don't seem to be set reliably, though that's a separate issue). I was going to fiddle around with this, but alas, it seems the -b option breaks things. If I try to bind to the existing interface on my machine using it's IPv4 address, I get:

Could not open/bind port for listening: Invalid argument

If I try to bind using the v6 address, I get:

Failed to parse command line option: Could not set bind address: Address family for hostname not supported.

And that's all without actually getting multihoming up and running. Is this expected behaviour?

follow-up: ↓ 57 Changed 7 weeks ago by anonymous

As an aside, I'm not convinced that:

setsockopt(m_fd, IPPROTO_IPV6, IPV6_TCLASS, &opt, sizeof(opt))

is actually resulting in the TOS flag being set for IPv4 connections over a v6 socket (tcpdump indicates the tos flag is set to 0, even through an strace indicates that setsockopt is being called correctly).

Unfortunately, I can find little mention via Google of the IPV6_TCLASS socket option on Linux, so I have no idea where the problem actually lies (ie, is IPV6_TCLASS even supported (it should be, but...)? If so, is it expected to work for v4 addresses accessed over a v6 socket?).

in reply to: ↑ 56 Changed 7 weeks ago by anonymous

Replying to anonymous:

As an aside, I'm not convinced that: setsockopt(m_fd, IPPROTO_IPV6, IPV6_TCLASS, &opt, sizeof(opt)) is actually resulting in the TOS flag being set for IPv4 connections over a v6 socket (tcpdump indicates the tos flag is set to 0, even through an strace indicates that setsockopt is being called correctly). Unfortunately, I can find little mention via Google of the IPV6_TCLASS socket option on Linux, so I have no idea where the problem actually lies (ie, is IPV6_TCLASS even supported (it should be, but...)? If so, is it expected to work for v4 addresses accessed over a v6 socket?).

And just to follow up on my own post, I've tested with stock rtorrent and the TOS flag is set correctly. This says to me that IPV6_TCLASS isn't supported for IPv4-mapped addresses (that's just a guess, though).

in reply to: ↑ 59 Changed 4 weeks ago by anonymous

Replying to tg@…:

Actually, on Debian unstable it wouldn’t, either, after the recent netbase upgrade which defaults to disabling this oft-criticised “feature”.

This is wrong; the patch is tested and developed on Debian unstable with the bindv6only sysctl set to 1.

I don't necessarily agree with your assessment of dual-stack sockets as “oft-criticised”, by the way -- the only criticism I've seen of the concept come from people using or developing OpenBSD. In any case, I don't know how useful complaining about it further is; if you want to contribute code to accomodate OpenBSD's peculiarities, I'm sure it will be considered, but looking from the rest of the thread here I don't really think you'll be successful in getting others to do that work for you.

/* Steinar */

Changed 4 weeks ago by Bernhard

All Debian does is to change the system-wide default of IPV6_V6ONLY to true, so applications don't have to deal with v4-mapped address when they are not ready to do so. See http://lists.debian.org/debian-devel/2009/10/msg00541.html by Marco d'Itri (the Debian maintainer responsible for this change).

Applications are encouraged to set that socket option to whatever they expect. Steinar's patch does this in multiple locations

+ int zero = 0; + return setsockopt(m_fd, IPPROTO_IPV6, IPV6_V6ONLY, &zero, sizeof(zero)) != -1;

so he's fine either way.

If OpenBSD does not implement this at all that's their problem. They could have just set that to 1 by default to work around the mild "security problems" introduced by users not expecting their v6-program to listen to v4.

Add/Change #1111 (Support for IPv6?)

Author

Your email or username:

E-mail address and user name can be saved in the Preferences.

Comment (you may use WikiFormatting here):

Action

leave as new

Note: See TracTickets for help on using tickets.

Download in other formats:

Context Navigation

Ticket #1111 (new enhancement)

Support for IPv6?

Description

Attachments

Change History

follow-up: ↓ 2 Changed 2 years ago by anonymous

in reply to: ↑ 1 Changed 2 years ago by anonymous

Changed 17 months ago by anonymous

Changed 14 months ago by Fefe

Changed 14 months ago by anonymous

Changed 14 months ago by anonymous

Changed 14 months ago by rakshasa

Changed 14 months ago by anonymous

Changed 13 months ago by anonymous

Changed 13 months ago by anonymous

Changed 13 months ago by nanonyme

Changed 13 months ago by anonymous

Changed 11 months ago by anonymous

Changed 10 months ago by anonymous

Changed 10 months ago by anonymous

Changed 10 months ago by anonymous

Changed 8 months ago by dimko

Changed 8 months ago by ert

Changed 3 months ago by Steinar H. Gunderson

Changed 3 months ago by josef

Changed 3 months ago by Steinar H. Gunderson

follow-up: ↓ 28 Changed 3 months ago by Steinar H. Gunderson

Changed 3 months ago by tg@mirbsd.org

Changed 3 months ago by Steinar H. Gunderson

Changed 3 months ago by Steinar H. Gunderson

Changed 3 months ago by anonymous

Changed 3 months ago by Steinar H. Gunderson

in reply to: ↑ 22 Changed 3 months ago by josef

Changed 3 months ago by Steinar H. Gunderson

Changed 2 months ago by tg@mirbsd.org

Changed 2 months ago by josef

follow-ups: ↓ 33 ↓ 59 Changed 2 months ago by anonymous

in reply to: ↑ 32 ; follow-up: ↓ 34 Changed 2 months ago by anonymous

in reply to: ↑ 33 ; follow-up: ↓ 35 Changed 2 months ago by josef

in reply to: ↑ 34 Changed 2 months ago by anonymous

Changed 2 months ago by anonymous

follow-up: ↓ 38 Changed 2 months ago by jakllsch@kollasch.net

in reply to: ↑ 37 Changed 2 months ago by anonymous

Changed 2 months ago by Steinar H. Gunderson

Changed 2 months ago by Steinar H. Gunderson

Changed 2 months ago by anonymous

Changed 2 months ago by anonymous

Changed 2 months ago by anonymous

Changed 2 months ago by Steinar H. Gunderson

Changed 2 months ago by anonymous

Changed 2 months ago by Steinar H. Gunderson

Changed 2 months ago by Bernhard Schmidt

follow-up: ↓ 49 Changed 2 months ago by Steinar H. Gunderson

in reply to: ↑ 48 Changed 2 months ago by anonymous

follow-up: ↓ 51 Changed 8 weeks ago by anonymous

in reply to: ↑ 50 ; follow-up: ↓ 52 Changed 8 weeks ago by Steinar H. Gunderson

in reply to: ↑ 51 ; follow-up: ↓ 53 Changed 8 weeks ago by anonymous

in reply to: ↑ 52 Changed 8 weeks ago by anonymous

Changed 8 weeks ago by rakshasa

Changed 7 weeks ago by anonymous

follow-up: ↓ 57 Changed 7 weeks ago by anonymous

in reply to: ↑ 56 Changed 7 weeks ago by anonymous

Changed 6 weeks ago by anonymous

in reply to: ↑ 32 ; follow-up: ↓ 60 Changed 5 weeks ago by tg@mirbsd.org

in reply to: ↑ 59 Changed 4 weeks ago by anonymous

Changed 4 weeks ago by Bernhard

Add/Change #1111 (Support for IPv6?)

Download in other formats: