Re: CGN fixed/hashed nat question

[William Herrin <bill () herrin us>]

On Wed, Jan 23, 2013 at 4:31 PM, Jean-Francois Mezei
<jfmezei_nanog () vaxination ca> wrote:
> Generally speaking for CGN setups, how many end users are NATed to a
> single public IP address ?
>
> In terms of traceability, there is a huge difference between loading
> 200k end users onto 1 public IP and putting say 5 end users per public IP.
>
> In the later case, it becomes possible to assign a good range of ports
> to each of the 5 users on that IP address. In the former case, it isn't.
>
> An ISP who nats 5 customers to each public IP address reduces fivefold
> the need for pulic IP addresses, which is still a major accomplishement.


If you'll entertain a guess, it'll shake out around 64:1.


If I were designing it (I'm not) it might look something like this:

A CIDR block of customer private IPs will map to a particular CGN box.
(e.g. 100.67.64.0/18, 16,000ish customers)

That box will have roughly 6 bits fewer public IPs available for the
translations (64:1 ratio, e.g. 203.0.113.0/24).

Multiple such mappings allowed per CGN box.

The box will algorithmically allocate 256 ports to each interior IP,
consuming about 1/4 of the exterior ports. All 256 are on the same
exterior IP. No logging need be generated where customers need fewer
than 256 translations at once. Which is most people all the time and
many of the rest most of the time.

The algorithm will exclude the .0 and .255 external addresses from
use, mapping the respective internal IPs to the other externals.

The box will dynamically allocate port ranges in blocks of 256ish
ports to the very active interior customers upon demand when no
further translations are available in that customer's existing blocks.
It will log once upon allocation of the port range and once again upon
release of the range when no translations are active for a timeout
period.

When allocating dynamic port ranges it will try to match the
algorithmically picked IP address if port blocks are available but
will fail over to other IP addresses rather than refuse an outbound
connection.


I note that any algorithmic assignment is going to come up weak on
draft-ietf-behave-lsn-requirements's REQ-15 but that's a "should"
anyway and I'm willing to risk it.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin () dirtside com  bill () herrin us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004