On Nov 22, 2013, at 5:12 PM, Warren Kumari <warren(_at_)kumari(_dot_)net> wrote:
So, something that has always confused me abut the CGN deployment discussions
and scaling is the number of customers (victims?!) that people want to put
behind an IP…
If you are an operating ISP with e.g a /18 you can have ~16,000 customers[0].
Great, you are still growing, and want to add another 10,000 users, good for
you.
For some reason at this point many ISPs start talking about putting on the
order of 100s of users behind an IP, then the discussion turns into port
starvation and scaling and such…
Yes, it does. However, if all the really grabby services your users are
running work over IPv6, that becomes a non-problem. You only need IPv4 for
the long tail stuff, and that generally doesn't consume a bazillion ports at a
time.
What's wrong with putting 2 users behind each IP? Are you really planning on
doubling your size *before* significant advances in v6 deployment and CGN
scaling come about? Yes? Ok, so put 4 users behind one IP (note, I did not
say "device") -- are you really planning on quadrupling in the next few
years? And if so, are you hiring? :-P
If indeed your market is static, this is a non-problem, since you already have
enough IP addresses to support it. Apparently this is not true of all ISPs.
Seriously, I don't get the "If we deploy CGN's we have to cram as many users
behind one address as possible…" bit -- can anyone enlighten me?
You cram as many as you have to. Have to may be dictated by current growth,
by planned growth, or by planned non-growth, and you will choose your port
allocations accordingly. Bear in mind that not all the world is flush with IP
addresses and fully built out.
I've run some big NATs (for example, for AOL's corporate network) and yes it
sucks, but you can minimize your (and your customer's) pain by overloading as
little as possible….
Of course. Nobody is going to deploy any of this stuff if they don't have to!
If you have enough IP addresses, dual stack is fine, and you can tunnel IPv4
if you get to the point where you want to avoid having to manage a dual-stack
infrastructure outside of the core.