IPv6 Support

[NCommander]

Closes #3.

Adds IPv6 support to Phoenix BT tracker. Tested with RFC IP addresses. Tested with IPv4-only, and mixed IPv4/v6 hosts Handles seperate v4/v6 ports. Properly senses inbound connection Option to disable X-Forwarded-For support (security risk)

[enebe-nb]

There's one thing would like to be tested, but probably this can't be done easilly. (so shouldn't prevent this merge). If the tracker is setup on a host that prefix ipv4 addresses what will happen with the peers.

[lewisgoddard]

IP Formats

ipv4 = 194.66.82.11:1024
ipv4 = 194.66.82.11 port = 1024
ipv6 = 192.168.0.1:1024
ipv6 = [2607:f0d0:1002:51::4]:1024
ipv6 = [2607:f0d0:1002:51::4] port = 1024
ipv6 = 2607:f0d0:1002:51::4 port = 1024
ipv6 = [2607:f0d0:1002:0051:0000:0000:0000:0004]:1024
ipv6 = [2607:f0d0:1002:0051:0000:0000:0000:0004] port = 1024
ipv6 = 2607:f0d0:1002:0051:0000:0000:0000:0004 port = 1024
AND support any combination of 4 and 6

[lewisgoddard]

@enebe-nb Do you mean the prefixing like :ffff: ? (We already have a trim for that.)

[enebe-nb]

@lewisgoddard : The trim is done after classifying the ip (probably it never trim anything). In this workflow a prefixed IPv4 (::ffff:127.0.0.1) is identified as a IPv6 and stored as so, and send to the peers as a IPv6 address. I can't see what the peers will do with that, maybe they don't connect each other at all or maybe they work without any problem. A prefixed IPv4 'is' a valid IPv6 address, and it not wrong store as so, i just would like this to be tested.

[lewisgoddard]

I suppose ideally the ::ffff:127.0.0.1 should be stored as IPv4 and IPv6, unless there's a more verbose IPv6 available. I think peers that are IPv6 capable should handle that fine, it is a valid address.

[lewisgoddard]

I still have yet to actually test it, and likely won't do so until tomorrow, but this is looking really good.

[NCommander]

As a note on on ":ffff:127.0.0.1", that isn't really a "valid" IPv6 address as per the RFCs. Its simply a different notation of writing a v6 address (https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4), and while I can't cite it at the moment, I believe that form is deprecated, and unless the v6 host has valid routes for it, (i.e. 6to4 NAT), I don't think it would work. It doesn't work here when I test it.

If there are bittorrent torrents that actually send that form, then we probably need to special case it, turn it back into a v4 address and send it down the v4 codepath, but I think this is such an odd usecase we're better off going belly up and not supporting it.

[NCommander]

@lewisgoddard: you're welcome to use my test tracker if it will help.

[lewisgoddard]

I suppose it would give me another place to test, but I'll want to try locally too so I can see the database.

[NCommander]

I'll set you up with a shell account and an account with the local MySQL server.

On Tue, Aug 18, 2015 at 2:07 PM, Lewis Goddard notifications@github.com wrote:

I suppose it would give me another place to test, but I'll want to try locally too so I can see the database.

— Reply to this email directly or view it on GitHub https://github.com/eustasy/phoenix/pull/13#issuecomment-132301601.

[NCommander]

@lewisgoddard: check your email, I sent it to the one listed on your website

[lewisgoddard]

Thank you for your contribution, don't forget to claim your bounty!

[NCommander]

@lewisgoddard: just claimed it, needs approval. If you run into any issues with the v6 code, drop me a message and I'll be glad to look at it again.

[lewisgoddard]

Claim confirmed, thanks again!

[lewisgoddard]

Oh, I meant to ask, how did you find us?

[NCommander]

@lewisgoddard I saw the bounty on bountysource :). I've done a LOT of IPv6 work on previous projects so it seemed an relatively easy and straightforward thing to code and test.