nanog mailing list archives
RE: NAT444 or ?
From: "Dan Wing" <dwing () cisco com>
Date: Thu, 8 Sep 2011 10:04:29 -0700
-----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 userssharingthe 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 bythecombination of source address:source port:destination address:destination port. So that's 62k sessions *per destination*perip address. In theory, this particular performance problem should only arise when the NAT gear insists on a unique port per session (whichiscommon, 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 ______________________________________________________________________
Current thread:
- RE: what about the users re: NAT444 or ?, (continued)
- RE: what about the users re: NAT444 or ? Dan Wing (Sep 13)
- Re: what about the users re: NAT444 or ? Owen DeLong (Sep 14)
- Re: NAT444 or ? Mark Tinka (Sep 10)
- Re: NAT444 or ? Jean-Francois . TremblayING (Sep 07)
- Re: NAT444 or ? David Israel (Sep 07)
- RE: NAT444 or ? Leigh Porter (Sep 07)
- Re: NAT444 or ? Mike Jones (Sep 08)
- Re: NAT444 or ? Carlos Martinez-Cagnazzo (Sep 08)
- RE: NAT444 or ? Leigh Porter (Sep 09)
- Re: NAT444 or ? Randy Bush (Sep 09)
- RE: NAT444 or ? Dan Wing (Sep 08)
- Re: NAT444 or ? Owen DeLong (Sep 13)
- RE: NAT444 or ? Dan Wing (Sep 13)
- Re: NAT444 or ? Simon Perreault (Sep 07)
- RE: NAT444 or ? Dan Wing (Sep 08)
- RE: NAT444 or ? Dan Wing (Sep 08)
- RE: NAT444 or ? Dan Wing (Sep 08)
- Re: NAT444 or ? Mark Tinka (Sep 09)