Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 Privacy Extensions #16783

Open
ghost opened this issue Mar 30, 2022 · 4 comments
Open

IPv6 Privacy Extensions #16783

ghost opened this issue Mar 30, 2022 · 4 comments

Comments

@ghost
Copy link

ghost commented Mar 30, 2022

Suggestion

Please make it so that only temporary IPv6 addresses are bound to. The second half of the permanent address can be used to track a specific NIC over arbitrarily-long time periods. At the moment this can only be mitigated by only binding to IPv4 addresses or using a proxy.

Use case

No response

Extra info/examples/attachments

No response

@lucasmz-dev
Copy link

This is extremely important. qBittorrent binds to both the permanent IPv6, and non-permanent IPv6 currently.
The permanent IPv6 is announced, which is bad, you can get a MAC address from that IPv6, but not from the temporary one.

Usually, even if it's a bad practice to most, users get a different IPv6 prefix each time they restart their router. (My ISP personally seems to give me the same prefix when possible, but I guess if I restart my router too quickly, that's not the case.)

What can be done, is track and keep figuring out what IPv6 prefix is assigned to a certain subscription, the moment you see another IPv6 with the same host part. (I guess this is what the OP means by NIC im not too knowledgable about networking)

Perhaps these things might benefit in torrenting in a way, because you can try and figure out what peers are likely to seed, and those who are likely to only leech. However I don't believe torrent clients are using that, and so if anyone is using that to their advantage, it's malicious users, and honestly it's better that these clients don't try to judge users that way.

If a user wants to be recognized as a seeder, they would ask their ISP to set up their IPv6 (correctly) and give them a static prefix, and go over and enable DHCPv6 and get a static address, or even just randomize their MAC address and use the permanent IPv6 address.

@Digitalone1
Copy link

The permanent IPv6 is announced, which is bad, you can get a MAC address from that IPv6, but not from the temporary one.

Fortunately on Linux the permanent address is derived from the DUID, so you can't get the MAC address. But I see your point, it's not the best using this address since it's public and it does not change over time (unless you change the DUID, but that's another matter).

Solving this issue seems tricky because I wonder how you can understand if an address is persistent or generated by the privacy extension. The only solution that came to my mind is to use a blocklist so that you can't use a specific IPv6 (the persistent one, but you can also add other address to the list, if needed).

@Digitalone1
Copy link

I managed to resolve this issue blocking inbound and outbound connections on the port used by qBt with the persistent IPv6.

@riobard
Copy link

riobard commented Jan 27, 2025

For this to work, qBT needs to solve two issues as discussed in #21288 (comment) and #19285 (comment):

  1. The ability to bind to arbitrary addresses/interfaces (right now it can either bind to a specific address or all IPv4/6 addresses); and
  2. The ability to monitor changes in bound addresses/interfaces (right now the binding is static and will be useless once bound address/interface changes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants