Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2112 closed Enhancement (fixed)

Provide ``ipv6='' parameter to trackers (patch provided)

Reported by: jch Owned by: charles
Priority: Normal Milestone: 1.80
Component: libtransmission Version: 1.61
Severity: Normal Keywords:
Cc: jhujhiti@…, jch@…

Description

If we're behind a NAT, we might very well be unreachable over IPv4 but reachable over IPv6. Hence, by giving out our IPv6 address to the tracker, we make it possible for two NATed peers to communicate as long as they have IPv6 (native or teredo, doesn't matter).

In case you need to test this, you'll find instructions for setting up IPv6 on

http://www.pps.jussieu.fr/~jch/software/ipv6-connectivity.html

--Juliusz

Attachments (2)

tracker-ipv6-parameter.patch (6.5 KB) - added by jch 12 years ago.
tracker-ipv6.patch (7.7 KB) - added by jch 12 years ago.

Download all attachments as: .zip

Change History (13)

Changed 12 years ago by jch

comment:1 follow-up: Changed 12 years ago by jhujhiti

  • Cc jhujhiti@… added

Regarding the concept, Transmission will (sometime, hopefully soon) be announcing twice, once for each address family. Why does the IPv4 tracker care about our IPv6 address in that announce, when we are going to contact the IPv6 tracker directly (sourced, of course, from the IPv6 address we attempt to guess)? This attempt to combine the announces raises other questions that are moot if we just announce twice.

Regarding the patch:

  • I cannot take issue with how the attempt to guess the source address is performed, but I think we can agree that it's a hack.
  • global_unicast_address() assumes that this NAT problem might only exist if we're on an RFC1918 subnet. This is a bad assumption to make. NAT is perfectly valid (useful even) in situations where inside addresses are global.
  • Why does tr_globalAddress() bother checking www.transmissionbt.com, only to ignore the result if it doesn't work?

comment:2 in reply to: ↑ 1 Changed 12 years ago by jch

Regarding the concept, Transmission will (sometime, hopefully soon) be announcing twice, once for each address family. Why does the IPv4 tracker care about our IPv6 address in that announce,

The transport used for contacting the tracker and the transport used for contacting other peers are unrelated. There's nothing that prevents me from contacting a tracker over IPv4 and receiving a list of IPv6 peers, or the opposite. (This actually happens when an ISP is firewalling TPB over IPv4 but not over IPv6 -- the tracker is then contacted over IPv6, but returns a mixed list including IPv4 peers).

When you contact a tracker over IPv4, as we currently do, the IPv4 address can be determined automatically by the tracker from the network-layer source address. However, if we are also listening on IPv6, we can provide an IPv6 address in addition.

Note that this is insecure -- we could, in principle, be lying about the IPv6 address, which is why the tracker may choose to discard this information. But that's not the client's problem -- we provide the information, the tracker chooses whether to trust it or not.

Providing our IPv6 address to the tracker is a good idea in any case, and is independent of whether we contact the tracker over both transports (which is a good idea too, but only marginally related to this particular ticket).

  • I cannot take issue with how the attempt to guess the source address is performed, but I think we can agree that it's a hack.

Using getnameinfo on a connected socket is the standard API for finding your address. The only bit that is troubling in my code is that I don't actually use the socket to send any packets -- I close it as soon as I've used it to find the address.

This is a standard technique under Unix, and you'll find multiple instances of this kind of code. One is the implementation of getaddrinfo in glibc. (Windows provides an explicit API, which is called GetBestInterfaceSomethingEx? or something like that.)

  • global_unicast_address() assumes that this NAT problem might only exist if we're on an RFC1918 subnet. This is a bad assumption to make. NAT is perfectly valid (useful even) in situations where inside addresses are global.

I'm not using global_unicast_address on IPv4, only on IPv6. (I never povide IPv4 to the tracker, only IPv6.) As you justly note, today's IPv4 Internet is too brittle to do this kind of things.

NAT is perfectly valid (useful even) in situations where inside addresses are global.

(NAT is never valid, but that's off-topic for this ticket.)

  • Why does tr_globalAddress() bother checking www.transmissionbt.com, only to ignore the result if it doesn't work?

I'm not sure I understand your question.

--Juliusz

comment:3 Changed 12 years ago by jch

After experimenting with similar code (in my own Bittorrent implementation, which has plenty of debugging printfs all around the place), the results are disappointing.

Most trackers appear to ignore the ipv6= argument, and rightly so. Additionally, the extra DNS lookup has the effect of slowing down everything when you're seeding a large number of torrents.

Please do not apply this patch.

(I'm not sure what proper etiquette is on this particular bug tracker, so I'm not closing this bug myself.)

--Juliusz

comment:4 Changed 12 years ago by charles

Juliusz: thanks for the update on this. That is kind of disappointing. :/

comment:5 Changed 12 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

comment:6 Changed 12 years ago by jch

  • Cc jch@… added
  • Resolution invalid deleted
  • Status changed from closed to reopened

Thanks to r9499, we've got almost of all the code needed to do that in the tree. So while it's most probably ineffective, this comes for free.

Most of the patch just moves code around; the actual new code is just the six lines in announcer.c, where I've put a long comment to explain the IPv6 mess.

This patch also includes a bug fix to the HTTP quoting code (it broke with octets over 128 when char is signed -- ah those PPC people).

--Juliusz

Changed 12 years ago by jch

comment:7 Changed 12 years ago by jch

Oh, and we don't pay the DNS delay that I mentioned previously because we're now caching our IPv6 address for half an hour -- that was part of r9499.

--Juliusz

comment:8 Changed 12 years ago by charles

  • Milestone changed from None Set to 1.80

comment:9 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:10 Changed 12 years ago by charles

added to trunk for 1.80 by r9513

comment:11 Changed 12 years ago by sim

(deleted spam)

Last edited 12 years ago by charles (previous) (diff)
Note: See TracTickets for help on using tickets.