NAT444 or ?

Dorn Hetzel dorn at hetzel.org
Wed Sep 7 20:13:26 UTC 2011


On Wed, Sep 7, 2011 at 4:05 PM, Leigh Porter
<leigh.porter at ukbroadband.com>wrote:

>
> 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.
>
> ACLs and blocklists are going to be a problem, perhaps, as LSN becomes more
> and more common, such things will gradually die out.
>
> 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.
>
> 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
> ;-)
>
>
Perhaps it can be made ever so slightly less ugly if endpoints get an
"address" that consists of a 32 bit IP address + (n) upper bits of port
number.

This might be 4 significant bits to share an IP 16 ways, or 8 significant
bits to share it 256 ways, or whatever.

In a perfect world, all of the endpoints sharing a single IP would be off a
single concentration point of whatever sort (same tower, etc)...

The end users can still do their own NAT then, their NAT device just has to
restrict the external port range to the one assigned (or have packets with
bad source ports dropped when sent).

Ok, not really pretty, but maybe a little less ugly than twice NAT, and at
least users could have "fixed" addresses (including the upper bits of port
number).

Of course, the 0000 value for upper port bits can be reserved for "business"
grade users so they get the nice ports like 80, etc.



More information about the NANOG mailing list