On 18/03/2010, at 3:06 AM, Sander Steffann wrote:

Hi Kristoff,

...

Shane Kerr schreef:

...

I noticed this site in someone's signature: http://ipv4depletion.com/ It uses a different prediction than the well-known one by Geoff Huston, although the results are not too different (which I guess is good): http://ipv4depletion.com/?page_id=4

I have HE's "bye bye v4" applet running in my iGoogle, which bases itself on the statistics from poratoo.net, and that one has a prediction-date of October the 1st 2011 (562 days to go).

Anybody any idea why there is almost 200 days of difference between these two predections?

The difference is explained on http://ipv4depletion.com/?page_id=4 (section "Compare the different estimate")

I had a shot at explaining the differences as well in http://www.potaroo.net/ispcol/2009-05/ipv4model.html. - The published ARIN data is different as they use a different method of recording a subsequent allocation that fits within an existing assignment window than the other RIRs. I comb back through the diffs in the ARIN data and use an altered file that attempts to correct this. - I use smoothing across the data before attempting to perform a least squares best fit. The assignment data is "chunky" because 50% of the addresses head out in 1% of the allocations. If you don't smooth the data the large allocation events tend to bias the model to predicted higher consumption. - I've been used an order 2 polynomial for the curve fit, rather than exponential. it looks to me that it offers a better fit (see http://www.potaroo.net/tools/ipv4/fig24.png for a comparison of linear, exponential and O(2) polynomial fit) These are just mathematical models, and like any predictive model they assume that tomorrow is derived from today. In reality tomorrow is the combination of many factors, and, thankfully, tomorrow still holds some element of uncertainty! I'd like to quote the last section of the article I wrote last year in May 2009, as I think its relevant: "It is certainly possible to tweak this model in various ways. The RIR allocation algorithm could be refined to take into account weekdays and weekends, and also simulate the range of individual allocation sizes for each RIR. I could also use Fourier analysis to extract out some of the strong periodic elements in the data series and use these functions to form the predictive model. Alternatively, the least squares best fit algorithm could use a weighting on the data points to give a higher weighting to more recent data over older data. The RIR data could be assessed in further detail to resolve some of the lingering inconsistencies. "But, ultimately the real question here is what would all this refinement to the address consumption model achieve over and above what we already know about this situation in terms of its predictive capability? "Its clear to say that the exhaustion of the unallocated IPv4 address pools within the current distribution regime is as close to a certainty as anything is in this world. Sometime soon, or maybe a little sooner, or maybe just a little later, the IPv4 unallocated address pools will run out for each RIR, and at that stage changes will necessarily come into play. Within two or maybe three years from today the current lines of supply of IPv4 addresses will probably dry up. Given the skewed nature of the distribution of allocations it is difficult to be any more precise than this and although the mathematical model may claim today that exhaustion will occur at 10:32 am on the 14th of June 2011, the range of uncertainty in such a prediction spans years rather than seconds. No matter when it does occur, after that time the life of an IPv4-only network will start to get quite messy and certainly very expensive, and it will only get worse from then over time. "If this looming exhaustion of the current supply of IPv4 addresses isn't a sufficiently loud and clear message to each and every player in this industry to DEPLOY IPV6 PRODUCTS AND SERVICES NOW! then I'm very much afraid that no other message is going to work either." regards, Geoff