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