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.