Netdev Archive on
help / color / mirror / Atom feed
From: Daniel Golle <>
To: Sven Eckelmann <>
	"Linus Lüssing" <>,
	"Nikolay Aleksandrov" <>,,
	"Roopa Prabhu" <>,,,
	"David S . Miller" <>,
	"Bjørn Mork" <>
Subject: Re: [gluon] Re: [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround
Date: Mon, 17 Aug 2020 15:24:38 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1830568.o5y0iYavLQ@sven-edge>

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 <> 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).




  parent reply	other threads:[~2020-08-17 14:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-16 20:24 Linus Lüssing
2020-08-16 22:08 ` [Bridge] " Stephen Hemminger
2020-08-16 22:10   ` David Miller
2020-08-23 15:42   ` Linus Lüssing
2020-08-23 17:19     ` Stephen Hemminger
2020-08-23 19:49     ` Felix Fietkau
2020-08-17  4:10 ` David Miller
2020-08-17  8:39 ` Bjørn Mork
2020-08-17 13:17   ` [gluon] " Sven Eckelmann
2020-08-17 13:35     ` Bjørn Mork
2020-08-17 14:24     ` Daniel Golle [this message]
2020-08-18  0:35 ` [bridge] fdde3c8b90: WARNING:at_net/core/rtnetlink.c:#rtnl_link_register kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [gluon] Re: [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).