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