[141588] in North American Network Operators' Group
Re: Quick comparison of LSNs and NAT64
daemon@ATHENA.MIT.EDU (Jeff Hartley)
Thu Jun 9 11:18:31 2011
In-Reply-To: <BANLkTimKBa5hY3sAMTzB6W51mGhGXqMoFw@mail.gmail.com>
Date: Thu, 9 Jun 2011 11:18:23 -0400
From: Jeff Hartley <intensifysecurity@gmail.com>
To: Cameron Byrne <cb.list6@gmail.com>, Mark Andrews <marka@isc.org>,
Aleksi Suhonen <nanog-poster@axu.tm>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
> On Jun 9, 2011 1:32 AM, "Mark Andrews" <marka@isc.org> wrote:
>>
>>
>> In message <4DF053AA.50400@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 thi=
nk
>> > 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 c=
an
>> > 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 whi=
le
>> for the DHCP option to be refreshed without push support.
>>
>> > The smallest granularity of load-balancing easily available with NAT44=
4
>> > is per customer or per customer group. DNS64 allows per flow granulari=
ty
>> > for load-balancing without even breaking a sweat.
>> >
>> > I've been testing NAT64 at home using a public NAT64 trial and general=
ly
>> > 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. =A0The AFTR box can be on the other
>> side of the world or out sourced if you want it to be. =A0The same
>> can be done with NAT64.
>>
>> > The biggest downsides I've encountered are:
>> >
>> > I. =A0 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. =A0Networked games usually use some sort of a tracker to help clie=
nts
>> > find games to connect to, and those only use plain IP addresses too. A=
nd
>> > 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 tha=
t
>> > 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 hel=
p
>> > both NAT boxes cope.
>> >
>> > My 2 cents delivered,
>> >
>> > --
>> > =A0 =A0 =A0 =A0 =A0Aleksi Suhonen
>> >
>> > =A0 =A0 =A0 () ascii ribbon campaign
>> > =A0 =A0 =A0 /\ 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 o=
ver
> 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 su=
ch
> 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@i=
sc.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.
-Jeff
