[144290] in North American Network Operators' Group
RE: NAT444 or ?
daemon@ATHENA.MIT.EDU (Leigh Porter)
Wed Sep 7 16:37:21 2011
From: Leigh Porter <leigh.porter@ukbroadband.com>
To: David Israel <davei@otd.com>, "nanog@nanog.org" <nanog@nanog.org>
Date: Wed, 7 Sep 2011 20:37:57 +0000
In-Reply-To: <4E67D24F.10706@otd.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> -----Original Message-----
> From: David Israel [mailto:davei@otd.com]
> Sent: 07 September 2011 21:23
> To: nanog@nanog.org
> Subject: Re: NAT444 or ?
>=20
> 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.
> >
>=20
> 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 reso=
lved to a point, the more serious issue, I think, is applications that jus=
t do not work with double NAT. Now, I have not conducted any serious resea=
rch into this, but it seems that draft-donley-nat444-impacts does appear t=
o 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 onl=
y way a real idea as to how much NAT444 really doe break things will be op=
erational experience.
--
Leigh
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email=20
______________________________________________________________________
