Android (lack of) support for DHCPv6

[lorenzo at colitti.com (Lorenzo Colitti)]

On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert <hugo at slabnet.com> wrote:

> Pardon my ignorance as I don't currently have field experience with
>> 464xlat, but my understanding of the technique is that it is (for the most
>> part) dependent on the network cooperating (by providing a DNS64 and NAT64)
>> for it to work properly.
>>
>
My point was not "on a SLAAC network, it's possible to implement 464xlat".
It was, "on a one-address-per-device network, it's impossible to support
464xlat".

Here, 464xlat is just an example of a new technology that needs a separate
IP address in order to function. There are other current examples, and
unless we get stuck in a one-address-per-device word, there will be future
examples too.

Multiple posters on the bug/request are coming from enterprise/campus
> networks that have existing AUPs and enforcement techniques prohibiting
> certain network functions (e.g.  content filtering, restricted outbound
> access, etc.), and would be making an *active choice* as to whether they do
> or do not want to support functions such as tethering, 464xlat, etc.


Sure, but today, it is not common practice for networks to prohibit a
device from tethering or from using IPv4-only applications on user-managed
devices. From a user's point of view, going to a world where such things
are prohibited is a regression.

And there it is:  "SLAAC is better and it isn't that hard; use it
> instead."  It is up to the network operator to make the design choices that
> best fit their network, including if their design goals are to *restrict*
> certain network functions.  You are saying that you know better.
>

I don't think that's a useful argument to make, since you are also saying
that you know better.