Instead of dissecting the numbers into chunks that give you the answer you want, how about looking at the big picture? http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf shows the IANA to RIR on the top line (updated through 7-Apr-06), with the next line being the sum of the RIRs going out (yes it is smoother than the IANA line, but they do track closely in the big picture). Note that the combined RIR pool is tracking policy since the output side total matches the input side from IANA about 18 months ago (individual RIR rates may vary). It is also interesting to note that recently the RIRs are handing out address blocks faster than they are acquiring them because the gap in the projections of the top two lines narrows over time.
Another interesting issue is the recent overall growth rate for RIPE handing out address blocks is significantly faster than any other (despite the large blocks in ARIN & APNIC), while Geoff's numbers in the BGP space show that APNIC region customers are announcing what they get at a faster rate than RIPE region customers. Are these blocks that will never show up in the routing system, or is there some reason that it takes longer to deploy space in Europe? Also note that ARIN & APNIC have approximately the same growth rates. The real issue is that Geoff's linear projections against the current .75 /8's per month going out from the RIRs to hit a 2012 date don't match the historical growth. Also, taking a very short term view creates misleading windows that lead to claims like yours that we are now on a slower pace than last year, so not to worry. While the graph does show that we were above the projection curve last year and below it so far this year, the overall trend since Jan 2000 is tracking the projection very tightly. Changing the RIR policy is a hopeless cause. This would have to be a simultaneous global change and the process for getting global agreement takes at least 2 years (as shown by the only global agreement they have; IPv6 policy, and the much longer time it is taking to debate changes to it). By the time anything could be done there wouldn't be enough left to worry about. You are correct that we don't know what will happen in the future. Unrealistically long projections don't serve anyone except those who look for solace in the fantasy land where nothing changes. The world needs the wake up call that reality is about to hit them in the face and they will need all the time there is left to develop a managed IPv6 deployment plan. If they don't start now they will be forced into a crash deployment when they try to get more space and find out the pool had long ago run dry. The IETF as a whole needs to wake up as well and stop developing for a dead end technology. By the time any new work items make it through the process there will not be any new IPv4 space to deploy it. Tony > -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 29, 2006 2:23 AM > To: Tony Hain > Cc: 'Austin Schutz'; [EMAIL PROTECTED]; iab@iab.org; > 'Keith Moore'; ietf@ietf.org > Subject: Re: Stupid NAT tricks and how to stop them. > > On 29-mrt-2006, at 2:17, Tony Hain wrote: > > >> In the past 10 years, there have been several years where the growth > >> of the growth was less than the year before: > > >> 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 > >> 2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5 > > >> (The numbers represent the number of addresses used up in that year > >> as a percentage of the 3.7 billion total usable IPv4 addresses.) > > > Part of the problem here is that the allocation bundles don't map > > well into > > nice clean annual buckets. It is the overall trend that matters, > > not the > > fact that any given year had a higher or lower growth rate. > > That's why I prefer to look at the RIR->ISP figures rather than the > IANA->RIR figures. I have a few scripts on my server to download the > statistics from the RIR FTP sites and parse them. (Have a look at > http://bgpexpert.com/addrspace.php if you want to peruse the numbers > yourself.) This is what the RIRs gave out the past few years: > > 78.24 M 2000 > 89.07 M 2001 > 68.97 M 2002 > 87.82 M 2003 > 128.58 M 2004 > 168.53 M 2005 > 35.14 M 2006 > > >> This basically means that unless things take a radical turn, the > >> long- > >> term trend is accelerating growth so that remaining 40% will be gone > >> in less than 9 years. Probably something like 7, as Geoff Huston > >> predicts. > > > While the exact date of exhaustion is impossible to predict, > > Geoff's 2012 > > target is presented to placate those in serious denial. The > > fundamental burn > > rate has been compound growth since 2000, and there is no reason > > for it to > > slow. > > Look above. 35 million this quarter so far means we're going to end > up below last year's 168 million unless things _really_ start cooking > the next quarters. If you drill down a bit more we're actually > recovering from a fairly big slump late last year. In order to > deplete IPv4 (including the RIR reserves which are at an all time > high of nearly 400 million) in 2010 the yearly address use needs to > grow by an average 30%: > > Addresses left year end used that year > > 2006 1304 175 > 2007 1077 228 > 2008 781 296 > 2009 396 384 > 2010 -104 500 > > While a 30% growth rate isn't unprecedented (2003: 27%, 2004: 46%, > 2005: 31%), I have a hard time imagining how this can continue year > after year. At some point, all of this has to relate to something in > the real world. In North America and Europe, IP penetration is such > that doing more of the same can't be exponential because you reach > 100% within a few years. The rest of the world could have exponential > growth for a longer time, but since the top 12 countries take up 75% > of all yearly IPv4 address usage those remaining 25% can't fuel a 30% > growth on their own at this point. > > Now all of this doesn't mean there can't be any new developments that > change address usage, but it does mean it will have to be something > new, like every cell phone getting its own IP address. The figures > over the past few years suggest that high growth happens in short > burst after which there is a relapse. The average growth since 2000 > was 16% even though 2003 - 2005 were double or triple that. If we > land at 150 million this year it will have been 13%. At 16% we'll be > out of IPv4 addresses in 2011, at 13% in 2012. So the difference > between 30% and 13% is only two years... > > > In fact at the past NANOG meeting John asked if anyone saw reason for > > ARIN to pursue modifying the policy, and there was dead silence as no > > organization was willing to slow their business model for 'the > > global good'. > > The question is: would modifying the policies to be more restricting > be "the global good"? John Klensin says that we're out of IPv4 > addresses for all intents and purposes anyway because the addresses > are too hard to get as it is. If it gets harder at the one hand this > means life gets more difficult, but at the other hand it means we get > to limp along for longer, making the period where IPv4 is painful but > not painful enough to adopt IPv6 even longer. > > However, it might make sense for the RIRs to stop giving out such > ridiculously large blocks: > > mysql> select rir, country, day, descr, num from addrspace where type > = 'ipv4' and day >= '2000-01-01' order by num desc, day desc limit 8; > +---------+---------+------------+------------+----------+ > | rir | country | day | descr | num | > +---------+---------+------------+------------+----------+ > | apnic | JP | 2005-02-08 | 126.0.0.0 | 16777216 | > | arin | US | 2005-04-19 | 73.0.0.0 | 12582912 | > | ripencc | FR | 2006-03-02 | 90.0.0.0 | 8388608 | > | ripencc | FR | 2005-03-02 | 86.192.0.0 | 4194304 | > | ripencc | GB | 2005-02-07 | 86.128.0.0 | 4194304 | > | apnic | CN | 2004-12-23 | 59.192.0.0 | 4194304 | > | apnic | JP | 2004-05-20 | 60.64.0.0 | 4194304 | > | ripencc | DE | 2004-03-10 | 84.128.0.0 | 4194304 | > +---------+---------+------------+------------+----------+ > > If Softbank in Japan really needs 16 million addresses then it > doesn't matter whether they get 1 /8 or 16 /12s, but if it turns out > they really need 9 million then having them come back for /12s means > they'll only end up using 9 of those and not wasting much address > space, while with a /8 they'd be wasting 7 million addresses. At > these levels routing table issues don't come into play. > > [when we're out of IPv4 addresses] > > >> At that point, it becomes a no-brainer to add IPv6 to > >> bypass the IPv4 NAT and soon people who still have enough IPv4 space > >> will want to use IPv6 too because that gives them easier access to > >> people who don't have an IPv4 address. > > > While you are correct, this seems to understate the case. The compound > > consumption rate of the last 5+ years has been during wide > > deployment of > > nat. While many still disbelieve, there really are organizations > > that have > > exceeded the capacity set aside in rfc1918 and for business reasons > > are > > refusing to deal with multi-layered internal nat. They understand > > the real > > cost of this broken technology, and will not go there. > > Sounds like a good use for class E... > > Actually I think the significance of NAT as an IPv4 address > conservation tool is overstated. Yes, if you'd start giving every box > with an RFC 1918 address a real address you'd be out of IPv4 > addresses before the day is over, but that was never a realistic > scenario anyway. And before NAT we had proxies which allow the same > thing for applications that support them. > > >> It would also help if by that time all software would work over IPv6. > > > Unfortunately this is a case of the application dev community > > needing a > > serious wake up call. The unrealistically long lifetime projections > > for IPv4 > > don't help in this regard either. > > But unrealistically short projections won't help either. The truth > is, that we simply don't know what's going to happen with any degree > of certainty. Given that fact, I'd rather start with projections on > the long side and adjust them down gradually. That way, people will > see that this is serious within a few years. By giving out very short > projections that have to be revised upwards people may assume this is > going to continue indefinitely so they really don't have to do > anything. And if it's really 2009 we'll be in trouble regardless of > what we say now because there isn't enough time to get people into > action fast enough to make for a smooth transition. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
