Only block IPv6 internet. I use local IPv6 prefixes like 2000::/3 and fd00::/8...
Only block IPv6 internet. I use local IPv6 prefixes like 2000::/3 and fd00::/8 and that rule breaks everything for me.
This keeps blocking IPv6 but only internet prefix
Merge request reports
Activity
assigned to @kali
changed milestone to %Desktop 0.21.6
@rany thanks for this! I have some questions:
- what about what you requested in #493 (moved) instead? is there a reason why we shouldn't do that instead of this?
- you say you use the prefix 2000::/3, but in this commit, you are blocking it, I'm not sure I understand how to reconcile that.
- this change would only block traffic that is destined for 2000::/3, and not any other ipv6 traffic. Maybe I don't get it, but it seems like that would introduce leaks of v6 traffic?
Edited by micah@micah For that second question I actually made a typo, I meant 200::/3 and it belongs to yggdrasil network.
As for #493 (moved) it would properly stop clients from trying to connect to IPv6 websites when firewall is not an option (no root on Android, etc.). For example, if we set --block-ipv6 it means that some badly written Android apps that don't use Happy Eyeballs will not just timeout if it happens that they're trying to connect to an IPv6 host
Another client that is affected is RiseupVPN.sh which doesn't use a firewall anymore and here are differences between using it with and without
block-ipv6.Without
--block-ipv6(just times out, making browsing a lot slower):$ time nc -6zvv google.com 80 ^C real 0m26.509s user 0m0.010s sys 0m0.010sWith
--block-ipv6:$ time nc -6zvv google.com 80 nc: connect to google.com (2607:f8b0:4020:807::200e) port 80 (tcp) failed: Network is unreachable real 0m0.020s user 0m0.015s sys 0m0.004sEdited by rany-
Ok, I believe I understand what you are proposing now:
Instead of just outright rejecting all ipv6 traffic, instead you are proposing to change it to only reject 2000::/3.
I wouldn't describe 2000::/3 as "the range assigned to the internet", it is more correct to call it "Global Unicast", which could be considered "The Internet".... but because we need to be careful about unintended leaks, we need to clarify that there are exceptions to this definition, those exceptions are:
- Multicast addresses: Multicast is covered by the address range ff00::/8
- Example networks: these should not go to the internet, but could be possible. This range is 2001:db8::/32
- 6to4A: These are ipv6 to ipv4 translation addresses. These are 2002::/16
- Orchid: This is an experimental network, like the "Example network" they shouldn't be seen on routers: 2001:0010::/28
- Benchmarking: Like Orchid and Example networks, these networks are more or less documentation and are typically filtered by routers, as they should not appear on the internet: 2001:0002::/48
- Toredo: This is a mapped address allowing IPv6 tunneling through IPv4 NATs. The address is formed using the Teredo prefix, the server’s unique IPv4 address, this is the network: 2001:0000::/32
Blocking only 2000::/3 would not block any of the above, it would still allow the above. From that above list, it seems to me that we definitely do not want to be allowing multicast, 6to4, and toredo traffic to go out. The Example, Orchid and Benchmarking netblocks are arguably never going to be accepted by routers anyways, so they could be ignored, but it might be better to simply block them.
It sounds like you want to allow the yggdrasil network, and fd00::/8.
According to the Yggdrasil FAQ, it is actually using the 0200::/7 range, not 200::/3. We need to be precise about these numbers, because if we fail to do so, we will open leaks. The 0200::/7 range was deprecated by the IETF. So it is not a network that routers, that are properly configured, would use. So we could consider adding a rule that will allow this range, ideally we should prohibit this range, unless we can identify that the traffic is actually yggdrasil encrypted traffic. I'm not sure how to do that.
Now, fd00::/8... this is a ULA netblock, which is "Unique Local Address". The problem with these addresses is that they permit communication between nodes on different links and so certainly aren’t link-local in scope. Their global scope is characteristically different than addresses from the actual Global Unicast Allocation (2000::/3) in that ULAs are not currently indicated for routing on the Internet. So what does that mean? It means they are typically used as the equivalent of IPv4 private addresses. This means that they are routed exclusively within a private network. Lets say you are at a University or a corporation, and it gives you a ULA, and you are on the VPN, and we allow the ULA address range, then your device is able to communicate with other devices on that network, because those ULAs are not private to your computer, but routed exclusively within the enterprise private network. So these are a cross between link-local and global.
The question comes down to: when on the VPN, should we allow communication on the private network. In Ipv4 land, that is all of RFC1918, which we do not allow at the moment. There might be an argument for allowing that, but it also might be a surprise to some.
In an ideal scenario, we would block all of this by default (which is what we do now), but have an advanced option that would let you, if you knew what you were doing, to allow fd00::/8. Or even to let you put in any arbitrary network that you would like to allow. We aren't there yet, but that could be a nice option.
Edited by micah -
Sorry if I don't get it but why is fd00::/8 an issue? As far as I'm aware it's sort of like IPv4's LAN ranges (192.168.0.0/16, etc.)
We are also blocking the ipv4 RFC1918 ranges (which is the name for what you are calling the LAN ranges).
These ranges are fine in some cases, and not fine in other cases. There is no safe setting that works for everyone. This is why we are looking at an option for people to allow these, if they understand the risks.
@rany: the commit 45939be0 wants to allow custom exceptions for private networks. can you check if that version of bitmask-root would work for your case?
thanks!
Edited by Kali Kaneko-
hey - I was wondering if after me merging 45939be0 this MR is still needed :)
edit: And I just now realized that I had asked the same 1 month ago. I'll be closing this, but please feel free to re-open if the mentioned mechanism doesn't work for you or you need further modifications.
Edited by Kali Kaneko
