Quick comparison of LSNs and NAT64

Jeff Hartley intensifysecurity at gmail.com
Thu Jun 9 15:18:23 UTC 2011

On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne <cb.list6 at gmail.com> wrote:
> On Jun 9, 2011 1:32 AM, "Mark Andrews" <marka at isc.org> wrote:
>> In message <4DF053AA.50400 at axu.tm>, Aleksi Suhonen writes:
>> > Hello,
>> >
>> > Some people were talking about Large Scale NATs (LSN) or Carrier Grade
>> > NATs (CGN) yesterday. Comments included that DS-Lite and NAT64 are
>> > basically LSNs and they suffer from all the same problems. I don't think
>> > that NAT64 is as bad as other LSNs and here's why:
>> >
>> > NAT64 scales much better than NAT44 and NAT444(*)
>> >
>> > The trick is with its companion DNS64. If you need more NAT64 capacity,
>> > you can just add more NAT64 boxes with unique /96 prefixes around your
>> > network and have your DNS64 load-balance traffic to those boxes. You can
>> > also map one A record into two AAAA records of different NAT64 boxes, in
>> > case that works better with some application protocols.
>> You can add more capacity with DS-Lite as well though it does take a while
>> for the DHCP option to be refreshed without push support.
>> > The smallest granularity of load-balancing easily available with NAT444
>> > is per customer or per customer group. DNS64 allows per flow granularity
>> > for load-balancing without even breaking a sweat.
>> >
>> > I've been testing NAT64 at home using a public NAT64 trial and generally
>> > I've been very happy with it:
>> >
>> > http://www.trex.fi/2011/dns64.html
>> >
>> > A neat feature I've liked is that I don't have to pass all my traffic
>> > via the NAT64 box, and so it doesn't have to be between me and the
>> > Internet. NAT44 usually acts as a fuse between me and my Internet.
>> You don't have to pass all the traffic through the AFTR box or the
>> LSN when dual stacked either.  The AFTR box can be on the other
>> side of the world or out sourced if you want it to be.  The same
>> can be done with NAT64.
>> > The biggest downsides I've encountered are:
>> >
>> > I.   Some streaming websites use IP addresses in their video stream
>> > URLs, so DNS64 doesn't get asked and that traffic won't flow via NAT64.
>> > Thankfully these are a minority.
>> Not a problem with DS-Lite or NAT444.
>> > II.  Networked games usually use some sort of a tracker to help clients
>> > find games to connect to, and those only use plain IP addresses too. And
>> > some games only query for A records, and thus can't benefit from DNS64
>> > either.
>> Not a problem with DS-Lite or NAT444
>> > So I guess the optimal way to stretch the lifetime of IPv4 while still
>> > moving toward IPv6 all the time would be to dual-stack customers and
>> > deploy both NAT64/DNS64 and some other LSN which can handle the two
>> > downsides above. All the traffic that you can shift to NAT64 means that
>> > your other LSN (which doesn't scale as well) can handle that much more
>> > traffic before becoming a bottleneck. And naturally, you'll want to
>> > shift all that youtube/facebook/whatever traffic to native IPv6 to help
>> > both NAT boxes cope.
>> >
>> > My 2 cents delivered,
>> >
>> > --
>> >          Aleksi Suhonen
>> >
>> >       () ascii ribbon campaign
>> >       /\ support plain text e-mail
>> >
>> > (*) NAT44 means the normal NAT from private IPv4 addresses to public
>> > IPv4 addresses. NAT444 means that there are two layers of NAT boxes:
>> > usually one at customer premises and the other at the ISP, doing LSN.
>> >
> All good and accurate info. I would just restate that nat64 unlike nat444
> does not need to be "on path", this is what drives its improved scaling over
> nat444.
> Also, unlike ds-lite, nat64 works without any special client, such as the b4
> function in the ds-lite architecture. Any fully functional ipv6 system such
> as win7 can work out of the box (ipv4 only apps being the exception)
> Finally, ds-lite and nat444 are just crutches for ipv4. Nat64 pushes ipv6 by
> making ipv6 end to end and forcing applications to be AF agnostic .... as
> where the others enable ipv4 without any backpressure.
> Each solution fits well for some set of constraints and objectives
> Cb
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

A handy/succinct phrase I often use for that (in total agreement, of course) is:
   "NAT444 is NOT an IPv6 Transition Technology".

Using an "anycast"-flavored model, where all DNS64 servers synthesize
using the same prefix[es] and all NAT64 gateways are otherwise out of
the critical path (injecting said prefix[es]), is indeed a highly
scalable methodology.  I've been deploying as such for the last ~6mo
with great success.

What was surprising was how Enterprise-applicable this has been in
"v6-only access client" trials.  The lack of need for gaming,
streaming radio/media (i.e., "hard-coded IPv4 literals"), and desktop
VoIP/P2P apps have turned out exceedingly well.


More information about the NANOG mailing list