On 2015-06-12 16:58, Ray Soucy wrote:
Wouldn't the simple play here be for Android to just throw up a
message
saying "This network does not support tethering" if SLAAC isn't
enabled,
and to let users complain to local operators if that's something they
want? Google doesn't get blamed, operators are happy, and ultimately
users
have a better experience because the expectations of the network are
clear
rather than trying something that will likely not work consistently
across
networks.
No.. there's one more step in the arms race.. if it's impossible to get
more
than one IPv6 address the user doesn't just give up and say 'oh well',
or
break down and pay the operator for tethering access - they enable NAT.
If
NAT isn't supported they will find a way to make it happen anyway.
IMO possibly the reason for leaving SLAAC as the only option is to try
and force
operators to have a configuration that allows some form of tethering..
perhaps
not dhcp-pd which might be nicer but at least not NAT.
Operators could combat this by coming up with an implementation of
SLAAC that
tries to force the client to only use one or perhaps a very limited
number of IPs.
I'm imagining a sort of timeout system where only one IP is really
allowed to
work at once.. perhaps you could allow more addrs to continue their
existing
TCP sessions but everything else gets reset except for the one
currently
active primary outbound IP. This could be combined with other
anti-tethering
features such as ttl monitoring and deep packet inspection / user agent
sniffing.
It's probably inevitable that operators will do this and the users will
be
forced to implement a NAT and proxy based tethering system to evade the
anti-
tether features anyway.. but forcing the use of SLAAC might delay it
for
a little while.
Rob
