[180720] in North American Network Operators' Group
Re: Android (lack of) support for DHCPv6
daemon@ATHENA.MIT.EDU (Lorenzo Colitti)
Wed Jun 10 02:43:57 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <20150610053603.GD2530@bamboo.slabnet.com>
From: Lorenzo Colitti <lorenzo@colitti.com>
Date: Wed, 10 Jun 2015 15:43:32 +0900
To: Hugo Slabbert <hugo@slabnet.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert <hugo@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.
