RE: NAT444 or ?

["Dan Wing" <dwing () cisco com>]

> -----Original Message-----
> From: Leigh Porter [mailto:leigh.porter () ukbroadband com]
> Sent: Wednesday, September 07, 2011 1:38 PM
> To: David Israel; nanog () nanog org
> Subject: RE: NAT444 or ?
>
>
>
> > -----Original Message-----
> > From: David Israel [mailto:davei () otd com]
> > Sent: 07 September 2011 21:23
> > To: nanog () nanog org
> > Subject: Re: NAT444 or ?
> >
> > On 9/7/2011 3:24 PM, Seth Mos wrote:
> > > I think you have the numbers off, he started with 1000 users
> sharing
> > the same IP, since you can only do 62k sessions or so and with a
> > "normal" timeout on those sessions you ran into issues quickly.
> > >
> >
> > Remember that a TCP session is defined not just by the port, but by
> the
> > combination of source address:source port:destination
> > address:destination port.  So that's 62k sessions *per destination*
> per
> > ip address.   In theory, this particular performance problem should
> > only
> > arise when the NAT gear insists on a unique port per session (which
> is
> > common, but unnecessary) or when a particular destination is
> > inordinately popular; the latter problem could be addressed by
> > increasing the number of addresses that facebook.com and google.com
> > resolve to.
>
> Good point, but aside from these scaling issues which I expect can be
> resolved to a point, the more serious issue, I think, is applications
> that just do not work with double NAT. Now, I have not conducted any
> serious research into this, but it seems that draft-donley-nat444-
> impacts does appear to have highlight issues that may have been down to
> implementation.

Draft-donley-nat444-impacts conflates bandwidth constraints with CGN
with in-home NAT.  Until those are separated and then analyzed carefully,
it is harmful to draw conclusions such as "NAT444 bad; NAT44 good".

> Other simple tricks such as ensuring that your own internal services
> such as DNS are available without traversing NAT also help.

Yep.  But some users want to use other DNS servers for performance
(e.g., Google's or OpenDNS servers, especially considering they
could point the user at a 'better' (closer) CDN based on Client
IP), to avoid ISP DNS hijacking, or for content control (e.g.,
"parental control" of DNS hostnames).  That traffic will, necessarily,
traverse the CGN.  To avoid users burning through their UDP port 
allocation for those DNS queries it is useful for the CGN to 
have short timeouts for port 53.

> Certainly some more work can be done in this area, but I fear that the
> only way a real idea as to how much NAT444 really doe break things will
> be operational experience.

Yep.  (Same as everything else.)

-d


> --
> Leigh
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________