On Mon, Aug 17, 2020 at 03:17:37PM +0200, Sven Eckelmann wrote: > On Monday, 17 August 2020 10:39:00 CEST Bjørn Mork wrote: > > Linus Lüssing <linus.luessing@xxxxxxxxx> writes: > [...] > > This is not a bug. They are deliberately breaking IPv6 because they > > consider this a feature. You should not try to work around such issues. > > It is a fight you cannot win. Any workaround will only encourage them > > to come up with new ways to break IPv6. > > Who are "they" and where is this information coming from? And what do they > gain from breaking IPv6? Wouldn't it be easier for them just to disable IPv6 > than adding random looking bugs? They are Google and they want IPv6 to be used in a way which exposes as much user data as possible to their servers (that's my guess). Every additional identifying bit is like gold for them (that's their business model). Hence they like SLAAC and addressing schemes which reflect the network topology and are enforcing that direction beyond good reason (that should be obvious[1] to everyone[2] by now[3], no matter what the reasons for that are). You may say, hey, SLAAC also allows me to use Privary Extension and I'm sure your browser will make use of that. But does the DNS resolver? And what about all those Google services running in background? I'm not sure all of them instruct the kernel to open every single socket using a privacy source address... Simply, when relying on SLAAC + Privary Extensions it's up to the (mobile) client to avoid being very easily tracked. When using DHCPv6 the situation is like it was for v4 (ok, it's still a bit worse because you can distinguish clients much better). As a work-around, I've been limiting source EUI-64 addresses from leaving my local network -- but that's surely not what everyone would want to make sure their local devices MAC addresses aren't leaked and also just breaking v6 in yet another way. I don't consider NAT66 an option and would like to avoid even connection-tracking on v6 as it was promissed :). Tethering should work using DHCPv6 prefix delegation imho rather than ND-proxy or NAT66 which are both quite a burden for the battery-powered device offering the tethering gateway (ie. each forwarded packet then needs CPU intervention, I can't see anything great about that). [1]: https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/ [2]: https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-frustrates-enterprise-network-admins/ [3]: https://lostintransit.se/2020/05/22/its-2020-and-androids-ipv6-is-still-broken/
