On Wed, Jun 10, 2015 at 2:36 PM, Hugo Slabbert <h...@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.
