[j-nsp] NAT64 on an M7i

[Phil Mayers]

On 03/02/11 14:17, Kevin Oberman wrote:
>> Date: Thu, 03 Feb 2011 13:33:33 +0000
>> From: Phil Mayers<p.mayers at imperial.ac.uk>
>> Sender: juniper-nsp-bounces at puck.nether.net
>>
>> On 02/02/11 19:50, Vlad Ion wrote:
>>> hmm... so NAT64 supported just in 10.4 not in 10.3 as well?
>>>
>>> @ Phil - I can tell you how well both NAT-PT and NAT64 will work on J-series
>>> in about a month when I will be done testing them... even tho it doesn't
>>> match exactly the profile of M7i
>>
>> Interesting; I didn't realise the low-end devices also supported NAT-PT.
>> We have some J-series on support.
>>
>> What's the basic config syntax? I have just spent an hour looking at the
>> awful Juniper documentation, and can't decipher it.
>
> Just to make things clear as mud, NAT64 is a mechanism that does address
> and protocol translation or NAT-PT, but it is probably best not to call
> it that as "NAT-PT" was an old technique that was defined in an RFC and
> was officially abandoned by the IETF. NAT64 is an externally similar
> technique that is based on a new I-D and internally very different from
> the old NAT-PT.

This is a source of some confusion to me.

NAT64 seems to make several (sensible) changes compared to NAT-PT:

  1. DNS ALG is replaced by an external DNS64 server, and the DNS64 
algorithm is DNSSEC-capable

  2. As a result of 1. the NAT64 does not need to be in the default 
route, and merely needs to have the NAT64 prefix routed to it

...but it's not obvious to me what *else* changed; the I-Ds are a bit... 
well, incomprehensible (to me) is probably the only phrase I can use. If 
you have any pointers to the differences, I'd be interested.

Put another way: how can I tell if a device implements "real" NAT64 or a 
hacked-up version of NAT-PT that doesn't need the DNS ALG? Why would it 
matter?