[144297] in North American Network Operators' Group
Re: NAT444 or ?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Sep 7 20:21:21 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <D181DDABABE57E4DB72FEE00331478643BAD38@EALPO1.ukbroadband.com>
Date: Wed, 7 Sep 2011 17:18:15 -0700
To: Leigh Porter <leigh.porter@ukbroadband.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 7, 2011, at 1:05 PM, Leigh Porter wrote:
>=20
>=20
>> -----Original Message-----
>> From: Seth Mos [mailto:seth.mos@dds.nl]
>> Sent: 07 September 2011 20:26
>> To: NANOG
>> Subject: Re: NAT444 or ?
>>=20
>> 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
>> The summary is that with anything less then 20 tcp sessions per user
>> simultaneous google maps or earth was problematic. =46rom 15 and
>> downwards almost unsable.
>>=20
>> He deducted from testing that about 10 users per IP was a more
>> realistic limit without taking out the entire CGN "experience".
>>=20
>> On a personal note, this isn't even taking into question things like
>> broken virus scanners or other software updates that will happily try
>> to do 5 sessions per second, or a msn client lost trying to do 10 per
>> second. The most the windows IP stack will allow on client versions.
>>=20
>> The real big issue that will be the downfall of NAT444 is the issue
>> with ACLS and automatic blocklists and the loss of granular access
>> control on that which the ISP has no control of. Which roughly
>> estimates to the internet.
>>=20
>> Regards,
>>=20
>> Seth
>=20
> I was thinking of an average of around 100 sessions per user for =
working out how things scale to start with. It would also be handy to be =
able to apply sensible limits to new sessions, say limit the number of =
sessions to a single destination IP address and apply an overall session =
limit of perhaps 200 sessions per source IP address.
>=20
> ACLs and blocklists are going to be a problem, perhaps, as LSN becomes =
more and more common, such things will gradually die out.
>=20
I think that such things will kill the NAT444 user experience rather =
than having the NAT444 user experience problems kill the block lists.
The people maintaining said lists are generally trying to protect larger =
systems from abusers and don't have any strong motivation to preserve =
the user experience of particular ISPs or particular subsets of users.
> Considering that offices, schools etc regularly have far more than 10 =
users per IP, I think this limit is a little low. I've happily had =
around 300 per public IP address on a large WiFi network, granted these =
are all different kinds of users, it is just something that operational =
experience will have to demonstrate.
>=20
Yes, but, you are counting individual users whereas at the NAT444 level, =
what's really being counted is end-customer sites not individual users, =
so the term
"users" is a bit misleading in the context. A given end-customer site =
may be from 1 to 50 or more individual users.
> I would love to avoid NAT444, I do not see a viable way around it at =
the moment. Unless the Department of Work and Pensions release their /8 =
that is ;-)
>=20
The best mitigation really is to get IPv6 deployed as rapidly and widely =
as possible. The more stuff can go native IPv6, the less depends on =
fragile NAT444.
Owen
>=20
> --
> Leigh
>=20
>=20
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email=20
> ______________________________________________________________________
