NAT444 or ?

Leigh Porter leigh.porter at ukbroadband.com
Wed Sep 7 20:37:57 UTC 2011



> -----Original Message-----
> From: David Israel [mailto:davei at otd.com]
> Sent: 07 September 2011 21:23
> To: nanog at 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.

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

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.



--
Leigh




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




More information about the NANOG mailing list