nanog mailing list archives

RE: NAT444 or ?


From: Leigh Porter <leigh.porter () ukbroadband com>
Date: Wed, 7 Sep 2011 20:37:57 +0000



-----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.

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 
______________________________________________________________________


Current thread: