* Mark Tinka <mark.tinka@seacom.mu>
On 27/Aug/15 07:16, Mark Andrews wrote:
Or why you are looking at NAT64 instead of DS-Lite, MAP-E, or MAP-T all of which are better solutions than NAT64. NAT64 + DNS64 which breaks DNSSEC.
Because with NAT64/DNS64/464XLAT, there isn't any "undo work" after the dust settles.
Hi Mark, There's not much difference between 464XLAT and MAP-*/DS-Lite/lw4o6 in this respect, the way I see it. In all cases you need four things: 0) Native IPv6. 1) A central component connected to the IPv4 internet and the IPv6. access network (464XLAT: "PLAT", MAP-*: "BR", DS-Lite/lw4o6: "AFTR") 2) Signalling to client that #1 exists and can be used (464XLAT: DNS64, others: DHCPv6 options). 3) A distributed component at the customer premise/nodes that acts on #2 and connects an isolated IPv4 network to the IPv6 access network (464XLAT: "CLAT", MAP-*: "CE", DS-Lite/lw4o6: "B4"). The necessary "undo work" in all cases is to disable #2. At that point components #1 and #3 will become un-used and can be removed if you care. My guess is that you'll care about removing #1 because it probably uses power and space in your PoP, but that you won't care about #3 because that's just an unused software function residing in a customer device you might not even have management access to. I'll grant you that with NAT64/DNS64 *without* 464XLAT there is no #3 to remove as part of your "undo work", but as I mentioned above I doubt you'll care about that particular distinction. Besides, since a CLAT is included by default in multiple client platforms, you can't really prevent your users from using 464XLAT if you're providing NAT64/DNS64 to begin with, unless you're doing something really weird like disabling DNS64 for the "ipv4only.arpa." hostname specifically. Tore