On Thu, Jun 9, 2011 at 10:39 AM, Cameron Byrne <[email protected]> wrote: > On Jun 9, 2011 1:32 AM, "Mark Andrews" <[email protected]> wrote: >> >> >> In message <[email protected]>, 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: [email protected] >> >
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
