-----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 ?
I think you have the numbers off, he started with 1000 users sharing
On 9/7/2011 3:24 PM, Seth Mos wrote: 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 ______________________________________________________________________