[arin-ppml] fair warning: less than 1000 days lefttoIPv4 exhaustion

[Iljitsch van Beijnum]

On 5 mei 2008, at 9:59, <michael.dillon at bt.com>  
<michael.dillon at bt.com> wrote:

>  Last year, less than 300 days ago, this counter showed 1300 days  
> and it was publicised a lot. I checked it several months later and  
> the number had gone up to more than 1400, I believe. Now suddenly it  
> is down to 1000!!!

> It almost seems like we consume addresses slower than average for a  
> while, then a large allocation goes out and we have suddenly  
> consumed more than the average amount.

Almost... This is the amount of address space given out per month the  
last 16 months:

+---------+--------+--------+
| month   | allocs | Maddrs |
+---------+--------+--------+
| 2007-01 |    436 |  18.12 |
| 2007-02 |    459 |  16.92 |
| 2007-03 |    572 |  21.25 |
| 2007-04 |    511 |  10.24 |
| 2007-05 |    559 |  20.02 |
| 2007-06 |    488 |  19.61 |
| 2007-07 |    493 |  21.28 |
| 2007-08 |    471 |  17.02 |
| 2007-09 |    518 |   8.54 |
| 2007-10 |    572 |  14.41 |
| 2007-11 |    500 |  13.55 |
| 2007-12 |   1337 |  15.86 |
| 2008-01 |    501 |   7.66 |
| 2008-02 |    537 |  23.03 |
| 2008-03 |    523 |  13.28 |
| 2008-04 |    980 |  28.18 |
+---------+--------+--------+

As you can see, the difference between months can be almost a factor  
4. Looking at just the allocations of 1048576 addresses or more (/12)  
the difference is even bigger:

+---------+--------+--------+
| month   | allocs | Maddrs |
+---------+--------+--------+
| 2007-01 |      6 |   9.96 |
| 2007-02 |      2 |   5.24 |
| 2007-03 |      8 |  13.48 |
| 2007-04 |      2 |   3.41 |
| 2007-05 |      5 |  11.53 |
| 2007-06 |      6 |  11.53 |
| 2007-07 |      7 |  14.68 |
| 2007-08 |      4 |   9.96 |
| 2007-09 |      1 |   2.10 |
| 2007-10 |      2 |   4.19 |
| 2007-11 |      3 |   5.24 |
| 2007-12 |     25 |  12.06 |
| 2008-01 |      1 |   1.05 |
| 2008-02 |      7 |  13.63 |
| 2008-03 |      2 |   3.15 |
| 2008-04 |     18 |  18.24 |
+---------+--------+--------+

(The "allocs" number isn't completely accurate as I need to insert  
fake negative allocations to compensate for ARIN's backdating behavior.)

This data really doesn't allow for many conclusions, except that  
things keep going up on average.

> Since we have no way of knowing when larger allocations will happen  
> perhaps the 1.5 year figure is more likely than the 3 year figure.

No, 1.5 years is almost impossible. There are still 1.05 billion IPv4  
addresses unused in the IANA and RIR pools, burning those up at 700  
million per year while we did 196 last year and 73 so far this year  
doesn't really follow.

> In any case, the exact runout date is irrelevant. What is more  
> important is knowing the nearest possible date for runout since that  
> is the date you want to target with your IPv6 readiness plans. If  
> you are IPv6 ready in 1.5 years, then it doesn't matter when IPv4  
> addresses run out. If you need 3 years to become IPv6 ready, then  
> you have a problem.

If you need 3 years you really have to start TODAY. And even then you  
may run into some trouble, but probably not. But don't forget that the  
IPv4 internet won't grind to a halt when we run out of fresh v4  
addresses, it's only the people who need new addresses at that point  
who'll have trouble. And probably really only the ones who need large  
blocks. I don't think there will be a time that a /256 will be  
impossible to get for some time to come, if ever.

Turning on v6 on a bunch of routers is fairly trivial. (You do need  
routers that can forward v6 at full speed, though.) Turning on v6 on a  
simple server is slightly harder. Doing the same for a massively load  
balanced / distributed service is somewhat of a challenge. But the  
real issues are all these little management scripts all over the place  
that keep businesses running, and the fact that we still don't have  
any idea how we're going to deploy IPv6 over broadband. I'm really  
concerned about that part, so far nobody seems interested in solving  
that issue.