Graph over the endgame
2010-07-02
People have asked me to provide a graph, similar to Hustons figure 30
Here is one http://www.ipv4depletion.com/endgame.png.
The main differences are are that I’m not providing any historical data. Everything you see is the predictions moving forward. This makes it possible for me to zoom in more.What you are seeing is a stretched out version of the bottom right corner of Huston’s graph, from the vertical red line to the end of the graph.
My graph ends when the first RIR gets depleted. The graphs will be updated daily automatically.
Tags: graph
Loading ...
Nice graph, very illustrative. I am a bit puzzled about the jumps on IANA depletion. I would expect one of the RIRs – possibly APNIC or RIPE – to take the 6th last block and then they all get one more. Six in all in the last allocation.
But what I see is that AFRINIC and RIPE get 1.5 block, ARIN gets 2 and LAPNIC and APNIC get 2.5. 10 in all and I am puzzled about the halves.
Great stuff!
I actually cobbled together something last night (based on the default tool output), and put it up at http://www.fud.no/ipv6/gnuplot/lagerholm/. It’s pretty much the same graph, but I was thinking you might want to grab my xdata settings to get proper date formatting on the X axis?
It’s really interesting to see how the predictions vary. You’ve got APNIC grabbing three (2x/8) allocations in a row before ARIN followed by RIPE, while Huston has APNIC first, then ARIN, then APNIC, then RIPE, then APNIC again. And while you both agree APNIC will grab the last free /8, Huston predicts a really narrow “victory” – at that date he has AfriNIC as being very close to having only half a /8 left (figure 30a), as well as ARIN being very close to having only two /8s left (figure 30c) – and that’s the point where he has ARIN going to IANA for more (cf. his June 6 note at the top of the page). You currently have ARIN’s allocation threshold at only 1.47 /8s though, so it’s easy to see why you don’t think ARIN will be a contender for the last /8.
In any case it’ll be very interesting to follow how the endgame will actually play out, so thanks again for creating this site! Also thanks for the tip about the tool last night – for some reason I thought it would just spit out a new IANA depletion date projection, so I hadn’t actually tried it before. I thought it would be interesting if its output would also include projections of the when the 2nd, 3rd, and 4th RIR have depleted their inventories. Think that’s doable?
Finally I wanted to ask you what exactly a “burnrate unit” is. For instance, right now the old dashboard shows LACNIC having a burnrate of about 200 units. But what is meant by that, exactly?
Tore
Hi Michiel and thanks for your feedback.
Each allocation will be 2 blocks (other than if AfriNIC would allocate, they would only allocate 1 block). If you look carefully at the spikes you will see that they are 2 blocks “high”.
What is happening when the last RIR allocates the last block from IANA is that the other RIRs automatically get one block each like you say. Buth there is also the Various pool that will be distributed to the RIRs. That is why you see a quite large and messy increase in all of the RIR’s pool sizes at that time. Feel free to go to the “tools” tab and submit the form with the default settings. This will bring up a table with all the pool sizes at the different future times. That can perhaps explain the different pool sizes at the different times in greater detail.
———————–
Tore, thanks. I have made some changes to the graph. Unfortunately I can’t use gluplot, it is not supported on the godaddy web platform that my blog is on. (They don’t even support IPv6 so I guess I have to move all the stuff to some other more progressive hosting company soon).
My script that does the calculation is very flexible. The IANA policy is that the RIR should allocate when they expect that they can’t cover 9 months of demand. Tony Hain from Cisco told me that in reality the RIRs allocate when they can’t cover 6 months of demand. This is my default setting in my tool today. But you can change that if you want in the form before submitting. I also have code ready to set a fixed low threshold per RIR instead but I have not programmed the CGI to set this.
I agree that the current setting underestimates when ARIN allocates and perhaps overestimates when APNIC allocates. This might skew the estimated prediction date a little. I’m considering changing this. ARIN doesn’t really matter, they will still only get 2 block regardless of if you increase their low threshold.
APNIC might be overestimated. But on the other hand I’m concerned that we will see a small “RIR rush”. The RIRs will probably allocate according to the policy as we move closer to the depletion date. I’m suspecting that they would do so to make sure they get their fair share of what’s left.
Let me know if you would like me to run the tool with a fixed low threshold per RIR and let me know what settings you would suggest per RIR. Could be an interesting exercise…
Tore,
Take the number from the gauge and multiply it by 6,048,000 to get the actual burn rate from each RIR.
For example, LACNIC’s gauge is currently at 0.11. Using the formula above you can figure out that they have been burning 665,280 IPv4 addresses the latest 30 days.
There is also a little Easter egg that gets updated every day at:
http://www.ipv4depletion.com/gaugedata.txt
/Stephan
Stephan, I think the allocations on the IANA depletion day is incorrect in the graph (which is probably what Michiel was asking about). According to the tool, on that day, APNIC will get addresses worth 3.5 /8s, LACNIC/ARIN/AfriNIC 2.5, and RIPE 2.4.
But, as Michiel has already pointed out, the graph shows approximately this happening on IANA depletion day:
RIPE +1.5
AfriNIC +1.5
ARIN +2
LACNIC +2.5
APNIC +2.5
Surely that’s not correct (except for LACNIC)?
Tore
Hi Tore and Michiel,
A lot of stuff is happening on the IANA depletion day. Make sure you read all the lines from the output on that date.
I also take the set aside policies into account (for example for the RIPE region see http://www.ripe.net/ripe/policies/proposals/2010-02.html). These blocks are taken out from the equation (if you select to do so in the tool).
Perhaps that is what is confusing?
/S
Thanks Stephan, you hit the nail on its head and now I’m not confused anymore.
Tore
[...] Graph over the endgame Posted in External news by admin on 6 Jul 2010 People have asked me to provide a graph, similar to Hustons figure 30 Here is one http://www.ipv4depletion.com/endgame.png. The main differences are are that I’m not providing any historical data. Everything you see is the predictions moving forward. This makes it possible for me to zoom in more.What you are seeing is a stretched out version of the bottom right corner of Huston’s graph, from the vertical red line to the end of the graph. My graph ends when the first RIR gets depleted. The graphs will be updated daily automatically. Source: http://ipv4depletion.com/ [...]
“Hustouns’s figure 29”, not 30, I guess (you link the former, and cite the latter).
Hi Lapo,
The filename of Hustons figure 30 is oddly enough fig29.png. The figure I’m refering too is the one that is marked with figure 30 in his report.
http://www.potaroo.net/tools/ipv4/index.html
Whoops, my fault: I did check only the first image’s link (to check it was not 0-based) but didn’t notice the actual figure numbers are more ‘creative’ than that (e.g. figure 22 is fig24.png).
Stephen thanks for your explanation. That ends my confusion over the non integer values.
BTW, there is a problem with the “changes over time” section of your report. Since a few days the Huston graph is missing.
Hi Michiel,
I’m working on improving the graphs in the report. I made some changes to the template but I never had time to finish the graphs. I it should look nicer in a few days.
/S
Ok guys,
If everything worked over the night there should be some new graphs in the report section. Let me know if they make sense?
/S
Very nice, much nicer than the old ones.
I wonder what explains the various spikes though…
Tore
The spikes are errors in the input data. I need to manually go in and adjust the RIR pools after the RIR gets new blocks from IANA.
If I miss to do that, the tool will be confused and see that two block are gone but will still see the same pool size for all the RIRs. This will typically move the depletion date with about 2 months. That’s the explanation to the spikes you are seeing. The correct thing to do would be to replace those values with “undef” so that they don’t appear in the graph.
“I’m working on improving the graphs in the report. I made some changes to the template but I never had time to finish the graphs. I it should look nicer in a few days.”
It sure does. However…
“an estimate that was so god”
^
Freudian spelling error?