On 03/02/11 14:17, Kevin Oberman wrote:
Date: Thu, 03 Feb 2011 13:33:33 +0000
From: Phil Mayers<p.may...@imperial.ac.uk>
Sender: juniper-nsp-boun...@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?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
