Subject: Reality (was RE: Stupid NAT tricks and how to stop them.)

From: "Tony Hain" <[email-masked]>
Date: Sun, 9 Apr 2006 22:43:05 -0700

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-masked]]
> Sent: Wednesday, March 29, 2006 2:23 AM
> To: Tony Hain
> Cc: 'Austin Schutz'; [email-masked]; [email-masked];
> 'Keith Moore'; [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Apr 2006 11:21:32 +0200

> want, how about looking at the big picture?

[...]

> historical growth.

The problem is that nothing matches historical growth, because it  
contains elements that have proven resistant against modeling. (Note  
that Geoff has three different projections and the linear one doesn't  
hit the ceiling in 2012, with 0.75 /8s per month = 151 million/year  
this date would be 2015.)

> Also, taking a very short term view creates misleading

I don't see it. If I use a formula of deltayear(n) = deltayear(n-1) *  
x and start in 2000, the best fit (where the yearly differences  
between the projection and reality as a percentage added up equals  
zero) is a an x of 1.09. This is obviously ridiculous because both  
2002 and 2005 are off by around 30% (93 vs 69 million and 120 vs 168  
million). If I ignore 2002 and 2003 it comes out to 15%. This lands  
us in 2010 as the year IPv4 runs out, by the way, with the projection  
for this year at 180 million addresses. At 9% this would be early  
2014 with a projection of 131 million addresses used this year.

The only way I can fit the projections closely to reality is by  
picking 2002 as my start date and assuming 34% growth. This way,  
we're out very close to the turn of the decade, but it does mean  
we'll be using up 222 million IPv4 addresses this year. And that's  
something that the current figures just don't seem to support, even  
though 2006 so far as increased from 35 million when I wrote my  
earlier message to 45 million now. However, for 222 million it would  
have been something like 61 million by now. (But looking at the data  
this closely doesn't do much good.)

The good news is that at the end of the year, we'll have a much  
better picture: either the mini-trend of around 34% growth in yearly  
address use that started after 2002 will turn out to have continued  
more or less, or it turns out it wasn't a trend after all, just like  
the dip in 2002 wasn't a new trend. Until that time, I'll continue to  
assume 2010 - 2015 with 2012 as the most likely moment for IPv4 to  
run out.

> By the time anything could be done there wouldn't be enough left to  

I don't think the actual changing is the hard part, but coming up  
with a new policy that is better than what we have now, is. We'll  
never really run out of /24s and blocks that aren't much larger  
because even though <= /18 blocks make up 90% of all allocations they  
make up less than 10% of the total address space used, i.e., less  
than a /8 a year. So we only have to reclaim a single /8 per year to  
accommodate those requests. For the really big blocks that ISPs are  
burning through so fast these days, I don't see a reasonable policy  
that can slow this down without basically making IPv4 effectively run  
out for them at the time of the policy change rather than when we're  
really out. Either you give those ISPs what they need or they'll have  
to start putting more than one customer behind a single address.

So a policy change to make the IPv4 space last longer for the big  
users would be impossible. There are two things we can do, however:

- try to avoid destructive end-game behavior, for instance by  
imposing a maximum block size at one point
- set aside a limited amount of IPv4 addresses (like the last 100  
million addresses) for smaller address users rather than give the  
last bit to the large users

There is however and interesting policy question: should we allow  
IPv4 addresses to be sold? Some people are in favor of this, but I  
don't see the upside of formally allowing it. (People are going to do  
it to some degree anyway.) The down side is that you can forget about  
getting back sizable legacy space chunks and people have even more of  
an incentive to hoard address space rather than use it. And this will  
break up the address space in much smaller fragments which doesn't  
help the routing table.

With the advent of RIR-anchored address space certificates the RIRs  
must decide whether they allow trading or sub-delegation of address  
space or prohibit it.

> need all the time there is left to develop a managed IPv6  

We only get to cry wolf so many times. You and Geoff came up with  
predictions last year, I suggest you both do the same this year and  
the following ones. But accept that if it really turns out to be 2009  
or even 2008 the transition will be a painful one for many people  
anyway and the numbers just aren't hard enough yet to make people  
want to start experiencing that pain now when it's still possible to  
rationalize the problem away.

> will not be any new IPv4 space to deploy it.

When we run out of IPv4 space obviously very many people will have  
IPv4 addresses and they'll want to keep using them. This won't be so  
much the end date for IPv4 as the start date for IPv6.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 10 Apr 2006 20:35:09 +1000

>>/8's per month going out from the RIRs to hit a 2012 date don't

I suppose I should respond here, particularly as the quote about using linear
models is not a correct one.

The projection model I use is updated daily at http://ipv4.potaroo.net
using a rolling window of the past 1000 days to generate a predictive
model of address consumption.

Today's projection of IANA pool exhaustion is September 2011 and RIR
pool exhaustion a little over a year later (assuming that the RIR pool
can be cleaned out with 100% efficiency - which is an unrealistic
assumption, of course).

The growth model used is an exponential one, and the report shows the
fit of linear, exponential and O(2) polynomial curves to the data used
for projection (Figure 22). The choise of exponential is based on a decent
least squares linear best fit to the logarithm of the smoothed data.

I use a 1000 day baseline (i.e. the last 1000 days of hourly data) to produce
the projection model. i.e. the model assumes that tomorrow will be
a lot like today, and the changes will be the same changes that were
evident in the past.

The trend predictor I use in the growth in the advertised address range
in the BGP table, and I derive RIR and IANA consumption figures from
a combination of this primary trend plus a related trend in the growth
of the unadvertised address pool relative to the growth in the advertised
address pool

I then model RIR behaviour in order to model IANA pool consumption
in order to derive a date of pool exhaustion, using existing
IANA to RIR address allocation procedures as the basis of the model.

How good is this technique? I guess we'll know in about 6 years or so,
but the nature of this daily update is that it will tend to self-correct
over time. Late 2005 was a large 'bubble' of addresses entering the
routing table - as happened early 2003. Currently the growth
rate is lower than this recent peak. This makes predictor models a
little more challenging in terms of figuring out whether there is
any sense in artificially weighting more recent data over older
data.

The one thing I'll note here is that this model makes no consideration
of any form of 'run' on remaining address resources, nor any consideration
of a change in allocation practices, nor a change in industry
demands over and above what's already visible in trend production.

I notice that this thread is labelled "reality". Projections are not reality,
they are always guesses to one extent or another as to what will happen.
Reality is, of course, what has happened and what is happening.
So, to some extent all of this  predicting stuff is just fun with numbers.
The reasonable high level bits to take away from this exercise and others
that have occurred and will no doubt occur in the future, is that there is
an increasing level of certainty that the current forms of access
and distribution of IPv4 addresses will experience a discontinuity
sometime in the next 4 - 8 years.

regards,

   Geoff