Support IPv6 - Githubissues

webtorrent / bittorrent-dht

🕸 Simple, robust, BitTorrent DHT implementation

https://webtorrent.io

MIT License

1.22k stars 204 forks source link

Support IPv6 #88

Open feross opened 8 years ago

feross commented 8 years ago

There's a BEP that describes how to add support: http://www.bittorrent.org/beps/bep_0032.html

ralphtheninja commented 8 years ago

:100:

ralphtheninja commented 8 years ago

@feross If you wanted to participate in both IPv4 and IPv6 DHTs, would that mean two instances of bittorrent-dht or can you see this module supporting both at the same time?

mafintosh commented 8 years ago

You need two instances i think as it changes the messages sent quite a bit unfortunately On Tue, 5 Jan 2016 at 17:20, Lars-Magnus Skog notifications@github.com wrote:

If you wanted to participate in both IPv4 and IPv6 DHTs, would that mean two instances of bittorrent-dht or can you see this module supporting both at the same time?

— Reply to this email directly or view it on GitHub https://github.com/feross/bittorrent-dht/issues/88#issuecomment-169049095 .

Aaron1011 commented 8 years ago

I'm interested in working on this.

feross commented 8 years ago

@Aaron1011 Nice, @mafintosh and I would be happy to merge your work in :)

Aaron1011 commented 6 years ago

If there's still interest, I'd be happy to revive my PRs.

feross commented 6 years ago

@mafintosh What are your thoughts on getting in IPv6 support? @Aaron1011 offered to revive his PRs. I think together we can tackle reviewing them once he's updated them. Thoughts?

Aaron1011 commented 6 years ago

@feross: Just checking back in - any update on whether or not I should revive my PRs?

Aaron1011 commented 6 years ago

Checking back in again.

bmpandrade commented 6 years ago

@Aaron1011 @feross and @mafintosh any development on this? Any help needed to bring this to a new release?

Aaron1011 commented 6 years ago

@bmandrade: I would be interested in reviving my PRs, @feross and @mafintosh are interested in them.

makew0rld commented 5 years ago

@Aaron1011 any idea of a timeline on that? IPv6 would be much appreciated.

Aaron1011 commented 5 years ago

@makeworld-the-better-one: That depends on whether or not @feross and @mafintosh think it makes sense for me to revive these PRs.

makew0rld commented 5 years ago

@Aaron1011 Would you be willing to do it anyway? There's definitely a lot interest in this working whether they support it or not, and it seems like @feross and @mafintosh haven't been responding.

makew0rld commented 5 years ago

@Aaron1011 Just checking in again on what you think of going ahead with your PRs as I said above.

Aaron1011 commented 5 years ago

@makeworld-the-better-one: My main concern is that I'll end up reviving them, only for them not to be considered. Should that happen, they'll likely become unuseable again as changes continue to happen to Webtorrent.

makew0rld commented 5 years ago

@Aaron1011 I understand that, I'm not sure what to tell you. I know that I, @tomeshnet, @cabal-club, @datproject, and the many others who depend on this repo would be very happy to have an IPv6 version to use, but I understand you not wanting to maintain a fork. I'm confused why @feross and @mafintosh haven't replied yet, but if they aren't responding then maybe it makes sense to update it and hopefully they can take over later. Tell me what you decide, thanks for your time either way.

makew0rld commented 5 years ago

@Aaron1011 I have emailed @feross and @mafintosh about this, hopefully they will be able to respond here soon.

feross commented 5 years ago

I haven't had time to dig into this yet. If other WebTorrent contributors or @mafintosh want to chime in and share whether the existing PRs look like a reasonable approach, I think that would be quite helpful.

kravietz commented 4 years ago

Any progress? If there are existing PRs then what is the problem with getting them merged? I'm sure many people are interested in it as using any protocol that relies on bidirectional connections is a pain to use in NATed IPv4 networks, and IPv6 resolves this issue completely.

makew0rld commented 3 years ago

See this comment, Feross would like to have these PRs merged. They just need some work because of how much the repo has changed since they were originally made.

gilad905 commented 3 years ago

I know this thread is 2 years old, but if there's any new info about this of if bittorrent-dht now supports ipv6 somehow, I'd appreciate someone letting me know :) thanks

resession commented 3 years ago

I know this thread is 2 years old, but if there's any new info about this of if bittorrent-dht now supports ipv6 somehow, I'd appreciate someone letting me know :) thanks

yep, this is one of the beps that is needed and would help a lot

lucasmz-dev commented 1 year ago

WebTorrent doesn't support IPv6? Wow.

lucasmz-dev commented 1 year ago

Yesterday it has been 6 years since this was posted. (Actually my mom's birthday!) IPv6 is increasing in traffic volume and adoption more and more every day, and with the need for CGNAT in most places, this is getting more and more needed.

Here's a take, P2P without IPv6 support is useless. Most people at this point seem to be in CGNAT ESPECIALLY outside North America. This means these people can only use WebTorrent in a way where they can only connect to people to have been privileged enough to get a public IP, suddenly the health of single torrents are dependable on random people instead of everyone that downloaded a torrent and is seeding, because now most people cannot download from everyone that's seeding, only those who have been lucky enough or are paying for it.

Please support this.

Only thing I would like to note is that most torrent clients out there have an issue where they leak the permanent SLAAC address. The last 64 bits of a computer's permanent SLAAC address basically identify a computer, that can be used to track a computer across multiple prefixes handed out to an internet subscriber. To solve this, modern OSes will generate addresses that have essentially random info as the 64 bits and those change every 24 hours that most applications will use, because of the nature of torrents, you only wanna announce some of them.

Here's some scenarios:

Using SLAAC, the user will get 3 addresses. One that essentially local, which is the link local address. One that is globally routable, a 'permanent' IPv6 address that contains identifiable information on it. A third one, which is a globally routable address that has no identifiable information on it and changes every 24 hours.
Using DHCPv6, the user will get 2 addresses. One that is local, which is the link local address, and one that is global which is gotten from DHCPv6.

In the SLAAC situation, you'll want to not announce the permanent address. You can probably use some library to check this as they are either EUI-64/MAC address based. (I do not know how these things get converted to 64 bits tbh)

In the DHCPv6, you can announce all addresses with no issue, addresses can be permanent but you can't identify devices through them.

All of this is theoretically optional, though if you wanna do everything actually right this is how you would do it if I'm saying everything correctly.

jech commented 9 months ago

Only thing I would like to note is that most torrent clients out there have an issue where they leak the permanent SLAAC address.

That's quite easy to avoid, and the BEP actually hints at the solution. (I'm the author.)

Before you start the IPv6 DHT, you determine the address used for outgoing connections, which is normally a temporary address. You then bind the UDP socket to that address, and you're no longer leaking the stable address.

Note that this is actually required: the DHT requires that you use a single source address for all DHT packets, independent of the destination.