[ppml] My view on IPv4 (was: Re: IPv4 wind-down)

[Michel Py]

Hi Iljitsch,


>>> Iljitsch van Beijnum wrote:
>>> It will be the kind of NAT where a service provider puts 10,
>>> 100 or even 1000 customers behind a single IP address, and
>>> the number of usable TCP ports starts being a problem.

>> Michel Py wrote:
>> This is not as bad as it appears. I have some customers with
>> 100 to 300 PCs out of a single IP and I never saw the number
>> of simultaneous  ports above 1K out of a possible 64K.

> Isn't TCP TIME_WAIT 240 seconds? That means that you get to
> set up 64k / 240 = 273 new TCP sessions per second. When
> browsing the web, you can easily create several new sessions
> per second for short periods. Depending on the activity of
> the users, I'm expecting problems to occur somewhere between
> 100 and 1000 users behind a single IP address.

The way I understand it, the TCP TIME_WAIT situation you describe is not
relevant to a NAT box, and here's why: it was designed to prevent ghost
packets in the network to pollute a newly open TCP session with
irrelevant data on the same port number from an older connection.

Therefore, the NAT box should indeed keep track of the sessions in
TIME_WAIT state, but it does not mean it can't re-use the port for
another inside/outside NAT translation from another inside host to
another outside host, because then the ghost packets will not have the
correct pair and will be discarded at the NAT box, which is why
TIME_WAIT was designed to begin with.

To cause a problem, the situation you describe requires that all inside
hosts try to access the same outside server at the same time. 

Also, keep in mind that putting 16 times more users on a pool of 16 IP
addresses considerably increases the pool of IP/ports pairs available
for NAT translation. In a large NAT pool, the number of IP/ports pairs
in use tends to join the average number of established sessions per host
times the number of hosts (plus some overhead).

I maintain that a 1000:1 overload still is a rather conservative target.


> The simplest way to overcome NAT problems is to get IPv6
> through it and have the applications use IPv6. Microsoft
> is already doing this for some peer-to-peer stuff.

With no success. Although I have been accused many times of being an M$
zealot, frankly I can understand why some would prefer developing their
own NAT traversal mechanism instead of relying on MSN messenger servers.
It still is simpler to make an app x2NAT capable than to rewrite it for
IPv6 and deal with the uncertainties of Teredo.

I have seen Vista PCs from several OEMs coming out of the factory with
the IPv6 stack loaded, and in almost every case the factory Vista load
has been wiped out to get rid of all the annoying pieces of software
gunk (such as toolbars, useless utilities and so on) that PC makers like
to install. I regret to report that Teredo and the v6 stack are part of
this gunk, and that no corporate-installed Vista PC I have seen so far
has the IPv6 stack (when they don't wipe out Vista altogether and
install XP instead that is).


> [large snip of stuff I generally agree with]
> I think the psychological point of no return will be reached
> when the number of addresses left in the  IPv4 pool is equal
> to or lower than three times what was used in the previous year.

That is the one argument I don't buy and here's why: some have been
spreading serious FUD about the world coming to an end when the v4 space
is depleted, resulting in everyone stockpiling IPv4 addresses at all
levels in the food chain. End sites have requested more IPs than they
really need, and ISPs have allocated /28s and /27s without question to
small businesses who use only one IP just because they requested a
static one. There is a lot of IPv4 fat out there and unfortunately the
people to be convinced of migrating to v6 are v4-fat, partly because
they binged on v4 addresses before the supply ends.

For the time being, getting a little leaner still is way cheaper than
deploying v6; as long as the big players can live for a while on their
fat reserves, nothing's happening.


> My goal isn't IPv6 deployment (although I'm not dead set
> against seeing a thriving market for IPv6 consultancy...)

Hehehe I would never have guessed that ;-)


>>> Therefore, any policy that seeks to artifically avoid running out
>>> is harmful because it perpetuates an address starvation model.

>> And any policy that seeks to artificially accelerate the running  
>> out is suicide,

> Which is certainly not something I favor.

There have been some discussions about discreetly killing IPv4 in order
to deploy IPv6.

Michel.