Production-scale NAT64

Thu Aug 27 06:34:28 UTC 2015

* Mark Tinka <mark.tinka at 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