[arin-discuss] Good Stewardship by example, I'd like to RETURN a /20

[Lee Howard]

Thanks for pointing this report out again.
Tony has been maintaining a graph at http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf
Geoff Huston's report is at http://www.potaroo.net/tools/ipv4/index.html
As time has passed, and Tony and Geoff have refined their models and added new data, their models have tended to converge: both now expect IANA to allocate the last new /8 around the middle of 2011, and RIRs to run out sometime in 2012.
You can also see NRO stats at http://www.nro.net/documents/presentations/nro-jointstats_06-30-09.pdf

Using those resources, you can calculate your own believed rate of future IPv4 allocation.  Add the number of /8s you think can be reclaimed, and you can figure out how much more time could be squeezed.

All of that assumes current trends.  We could certainly change policy to alter the allocation rate; see PPML, and Jean Camp's presentation from ARIN XXIII  https://www.arin.net/participate/meetings/reports/ARIN_XXIII/pdf/monday/ipv4_last_eights.pdf

For those of you too busy to follow all of the above links, the summary is:
Current policies and allocation rates extrapolate to show IANA allocating the last IPv4 /8 mid-2011.  What, if anything, should be changed?  Be specific.

Lee




From: VAUGHN THURMAN - SWIFT SYSTEMS INC <Vaughn at SwiftSystems.com>
>To: arin-discuss at arin.net
>Sent: Thursday, July 23, 2009 12:30:38 PM
>Subject: Re: [arin-discuss] Good Stewardship by example, I'd like to RETURN a /20
>
> >
>
>
>Here you go...
> 
>A Pragmatic Report on IPv4 Address Space Consumption
>by Tony Hain, Cisco Systems
>
>>When I interact with people from all around the world discussing IPv6, there
>continue to be questions about the projected lifetime for IPv4. This article
>presents consumption rate and lifetime projections based on publicly available Internet Assigned Numbers Authority >(IANA) data. In addition, there is discussion about why the widely quoted
>alternative projection may be flawed, thus leading everyone to believe we have
>much more time than we might.
>
>Figure 1: IANA /8 Allocations
>
>
>
>Allocations
>>The chart in Figure 1 shows the distribution of all 256 IANA /8 allocation
>units in IPv4 [1] as of July 1, 2005. The Central registry represents the
>allocations made prior to the formation of the Regional Internet Registries (RIRs). ARIN
>(North America) [2], RIPE NCC (Europe) [3], APNIC (Asia/Pacific) [4], LACNIC
>(Latin America) [5], and AfriNIC (Africa) [6] are the organizations managing
>registrations for each of their respective regions. RFC 3330 [7] discusses the
>state of the Defined and Multicast address blocks. The Experimental block (also
>known as Class E—RFC
>1700 [8]) was reserved, and many widely deployed IPv4 stacks considered its use
>to be a configuration error. The bottom bar shows the remaining useful global
>IPv4 pool. To be clear, when the IANA pool is exhausted there will still be
>space in each of the RIR pools, but by current policy [9] that space is
>expected to be only enough to last each RIR between 12 and 18 months.
>
>>The projection published at http://bgp.potaroo.net/ipv4 [10] is often quoted as the
>definitive reference for IPv4 consumption. This report presents a viewpoint
>consistent with that author's long-standing position that we do not need to
>change from IPv4 to IPv6 anytime soon, thus showing an extended lifetime for
>IPv4.
>
>>The approach used in the potaroo report is to take the simple exponential fit
>to the allocation data since 1995. As discussed later in this article, this
>approach includes the effects of the policy shift to Classless Interdomain Routing >(CIDR) and subsequent digestion of prior allocations, the lull in IANA
>allocations to the RIRs for two full years, as well as the fact that the model
>used does not generate a particularly close fit to the actual run rate over the
>10-year period.
>
>>Although this author agrees that over very long timeframes (20–50 years) there
>will be substantial variations in the consumption rate for any number of
>reasons, the opportunity for events that would reduce the recent rate in the timeframe
>of the remaining IANA IPv4 pool is not evident. That said, there are numerous
>things that could increase the consumption rate and exhaust the pool even
>sooner than this projection.
>
>Figure 2: IANA Allocations to RIRs —Raw /8 Allocations per
>Month
>
>
>
>>The graph in Figure 2 shows the raw per-month IANA allocations since 1995. In
>raw form it is difficult to discern the trend, or develop an expectation about
>the overall lifetime of the remaining pool.
>
>>Taking a closer look at Figure 3, smoothing the data with a 24-month sliding
>window (averaging over 12 months back and 12 months forward) exposes the
>underlying reality that the combined rate and quantity of /8 allocations has
>been steadily accelerating since 2000 (the graphs for 12-, 18-, and 24-month
>sliding windows show the same fundamental trend). Though a few of the
>allocations may arguably have been "one-time" events, those are lost
>as statistically insignificant in the extended and continuing overall growth
>rate.
>
>Figure 3: IANA Allocations to RIRs —Sliding-Window 24-Month
>Average
>
>
>
>>Taken by itself, the most recent allocation rate (22 /8s over the 18 months
>leading up to July 1, 2005) suggests that the remaining pool of 64 /8s will be
>exhausted in about 5 years, even if growth abruptly flattens out to hold around
>1 /8 per month. Unfortunately at this point there is no reason to believe the
>allocation rates will slow or that they will turn downward again. All the gain
>of CIDR absorbing the pre-1995 allocations has already been incorporated, and
>there is no obvious economic bubble that might burst to lower demand within the
>time window of the remaining pool.
>
>>To the contrary, the following URL shows potential demand (to bring developing
>countries up to just 20-percent connectivity, which is half of what the
>existing Internet world enjoys today) that will swamp the remaining pool, even
>in the face of much stricter allocation policies. http://www.nav6tf.org/documents/e-Nations-data.pdf
>
>>So this view of the sustained trend in allocation growth rate suggests that the
>lifetime of the remaining central IPv4 pool is 4 years +/-1.
>
>Projections
>>Differing from recent articles and section 5 of the report at http://bgp.potaroo.net/ipv4 >that hint at linearity in growth, Figure 4 shows that the raw data after 1995
>is clearly nonlinear. It starts with a decelerating rate through mid-1998 as
>the pre-1995 allocations were absorbed (precipitated by the allocation policy
>shift from class-based to CIDR), followed by a 2-year lull (only 1 /8 per
>year), then a return to accelerating growth from mid-2000 onward.
>
>Figure 4: IPv4 Lifetime Projection —Non-Linear Nature of Raw
>Data
>
>
>
>>This suggests that using the past 10-year IANA data is likely to skew the
>projection toward a much longer period than the recent allocation data would
>support. Although a longer lifetime projection helps to avoid short-term panic,
>it can mislead people into believing there is substantial time to worry about
>this later, resulting in a much bigger problem when reality blindsides everyone
>sooner than they expected.
>
>Figure 5: IPv4 Lifetime Projections —Order-N Polynomials,
>Post-2000 History Basis
>
>
>
>Figure 6: IPv4 Lifetime Projections —Polynomials and
>Exponentials
>
>
>
>>As in any statistical endeavor there are many ways to evaluate the data. The
>various projections in Figures 5 and 6 show different mathematical models
>applied to the same raw data. Depending on the model chosen, the nonlinear
>historical trends in Figure 6 covering the last 5- and 10-year data show that
>the remaining 64 /8s will be allocated somewhere between 2009 and 2016, with no
>change in policy or demand (though as discussed previously there are already
>reasons to err toward 5-yearbased nonlinear models).
>
>>Adding to that, policy is continually changing. ARIN, for example, has recently
>clarified its policy allowing organizations that demonstrate they have exceeded
>the capacity of the private space defined in RFC 1918 to acquire IPv4 address
>blocks from the remaining public pool, even when it is clear these allocations
>will never be announced to the global Internet. The other regions already have
>similar policies or are likely to follow suit because the most vocal members of
>the RIR community have adamantly commented against expanding the private IPv4
>range. This policy approach coupled with persistent demand means the actual run
>rate is going to continue increasing as the large organizations begin consuming
>public space where they had been using private to support their network growth.
>For example, one large enterprise has steady growth over 1 percent per month,
>which currently requires an efficiently managed /12 per year for its expanding
>network. The enterprise is less than a year from exhausting all the space
>provided in RFC 1918, so it was very interested in the ARIN policy that allows
>the enterprise to continue growing through public space. Additionally, multiple
>commercial service providers expect to reach the capacity of the 1918 space
>within 12 to 18 months, just supporting management addresses on their existing
>devices. This does not take into consideration their pending deployment of new
>services, which they expect will use several new IPv4 addresses per device with
>marketing targets measured in multiple millions of units.
>
>Figure 7: IPv4 Lifetime Projection —5-Year History Basis
>
>
>
>>The graph in Figure 7 hints at the likely outcome as word spreads about the
>perception of policy liberalization and the demonstrable exhaustion of the
>remaining global IPv4 pool landing within the return-on-investment (ROI) period for new
>equipment.. It is based on the same raw historical data as the frequently quoted
>long-term projection on potaroo's Figure 2.4, but the more aggressive fit on
>the most recent data set describes a significantly higher consumption rate and
>shorter lifetime for the remaining pool.
>
>Figure 8: IPv4 /8 Pool —5-Year History-Based Projection
>
>
>
>>The graph in Figure 8 provides the exhaustion perspective, showing the entire
>address pool from the publication of IP Version 4 [11] (note that data prior to
>1995 is accurate as to where it was allocated, but with very coarse granularity
>as to exactly when). The projection curve is based on the IANA allocations from
>January 2000 onward.
>
>>Only time will tell which projection is correct, but it will already take a
>fairly significant stalling event to slow consumption and put the actual
>allocation curve back on the extended track in potaroo's Figure 2.4.
>
>Reserved Space
>>There are occasionally arguments that the 16 /8s reserved in the experimental
>space could be used. Although this is likely to be possible for some IP stack
>implementations, for others it is not. At a minimum, some quick tests show that
>Windows 95 through Windows 2003 Server systems consider that block to be a
>configuration error and refuse to accept it. The operational ability to
>restrict the space to a select stack implementation is limited, and the amount
>of space there does not really help even if deployment and operations were
>trivial. Assuming the sustained growth trend in allocations continues, by the
>time the remaining 64 /8s in the IANA pool are finished the rate would be
>approaching 3 /8 allocations per month, so the entirety of the old Class E
>space would amount to about 6 months of run rate.
>
>Reclaiming Allocations
>>Another debate occasionally resurfaces about reclaiming some of the early
>allocations to further extend the lifetime of IPv4. Hopefully this article has
>shown that the ROI for that approach is going to be extremely low. Discussions
>around the Internet community show there is an expectation that it will take
>several years of substantive negotiation (in multiple court systems around the
>globe) to retrieve any /8s. Then following that effort and expense, the
>likelihood of even getting back more than a few /8 blocks is very low.
>Following the allocation growth trend, after several years of litigation the
>result is likely to be just a few months of additional resource added to the
>pool—and possibly not even a whole month. All this assumes IANA does not
>completely run out before getting any back, because running out would result in
>pentup demand that could immediately exhaust any returns.
>
>Summary
>Network Address
>Translation (NAT) and CIDR did their jobs and bought the 10 years
>needed to get IPv6 standards and products developed. Now is the time to
>recognize the end to sustainable growth of the IPv4-based Internet has arrived
>and that it is time to move on. IPv6 is ready as the successor, so the gating
>issue is attitude.. When CIOs make firm decisions to deploy IPv6, the process is
>fairly straightforward. Staff will need to be trained, management tools will
>need to be enhanced, routers and operating systems will need to be updated, and
>IPv6-enabled versions of applications will need to be deployed. All these steps
>will take time—in many cases multiple years. The point of this article has been
>to show that the recent consumption rates of IPv4 will not be sustainable from
>the central pool beyond this decade, so organizations would be wise to start the
>process of planning for an IPv6 deployment now. Those who delay may find that
>the IANA pool for IPv4 has run dry before they have completed their move to
>IPv6. Although that may not be a problem for most, organizations that need to
>acquire additional IPv4 space to continue growing during the transition could
>be out of luck.
>
>References
>>[1] http://www.iana.org/assignments/ipv4-address-space
>
>>[2] http://www.arin.net/
>
>>[3] http://www.ripe.net/
>
>>[4] http://www.apnic.net/
>
>>[5] http://www.lacnic.net/
>
>>[6] http://www.afrinic.net/
>
>>[7] http://www.rfc-editor.org/rfc/rfc3330.txt
>
>>[8] http://www.rfc-editor.org/rfc/rfc1700.txt
>
>>[9] http://www.rfc-editor.org/rfc/rfc2050.txt
>
>>[10] http://bgp.potaroo.net/ipv4
>
>>[11] http://www.rfc-editor.org/rfc/rfc791.txt
>
>>[12] Geoff Huston, "The
>Myth of IPv6," The
>Internet Protocol Journal, Volume 6, No. 2, June 2003.
>
>>[13] Geoff Huston, "IPv4:
>How long do we have?," The
>Internet Protocol Journal, Volume 6, No. 4, December 2003.
>
>Another Perspective
>Ed.: We asked Geoff Huston
>to provide some feedback on this article and he responded with the following:
>
>>Dear Editor,
>
>>There are, of course, many ways to undertake predictions, and over the
>millennia humanity has explored a wide diversity of them.. In every case the
>challenge is to make predictions that end up being closely correlated to the
>unfolding story, and of course hindsight is always the harshest judge of such
>predictions.
>
>>Tony's work takes a different base point for making the projection from earlier
>work that I did in this area. Tony looks at the rate of allocation from the
>IANA to the RIRs, and bases his predictions on the trends visible in that time
>series of data. By contrast, I used the assumption that assigned addresses are
>destined for use in the public IPv4 Internet, and I used the trends visible in
>the amount of advertised address space as the basis for the predictions of
>consumption.
>
>>One of the more interesting data artifacts is the first-order differential of
>the rate at which the span of addresses announced in the IPv4 public Internet
>has increased over time. (Figure 4.4 of http://bgp.potaroo.net/ipv4/)
>
>>One interpretation of this data is that there are two phases of recent
>activity: prior to March 2003 and post-March 2003. Prior to March 2003 the
>longer-term address growth rate was the equivalent of some 3.5 /8 blocks per
>year.
>
>>Post-March 2003 we see a different consumption growth rate, fluctuating between
>5 and 8 /8s per year, with a mean value of some 7.5 /8s per year. There is no
>strongly obvious longer-term compound growth rate visible in this view of the
>data. Given some 64 /8s remaining in the IANA pool as of July 2005 and a base
>consumption rate of a mean of 7.5 /8s per year, the simple division yields 8.5
>years, or 2014 as the time of forecast exhaustion of the IANA address pool. At
>that point the RIRs will be holding about 25 /8 blocks in their unallocated
>pools, and a further two years of allocations could be made from these pools.
>
>>So I would offer the view that the post-2003 data offers a perspective of
>exhaustion of the unallocated address pools in 2016, with the caveat that such
>a prediction assumes that the current address demand levels will continue, the
>actions of industry players are invariant, and the current address allocation
>policies will continue as they are at present.
>
>>Of course these three caveats represent relatively major assumptions about the
>future—and are perhaps unlikely to happen. It is likely that there will be
>changes in all these factors in the coming years, and these will obviously
>impact these predictive models.
>
>>To summarize, I observe that these different predictive approaches yield
>slightly different outcomes, but not beyond any reasonable error margin for
>predictions of this nature.. Sometime in the forthcoming 5 to 10 years the
>current address distribution policy framework for IPv4 will no longer be
>sustainable for the current industry address consumption model because of
>effective exhaustion of the unallocated address pool.
>
>>When looking at this prediction from the perspective of the service provider
>enterprise, the prediction can be re-expressed as a problem relating to
>investment lifecycles. The ISP industry and the enterprise sector have already
>made considerable investments in IPv4-based infrastructure in equipment,
>infrastructure, and operational capability, and we are seeing some considerable
>reluctance to add to this with additional investment into IPv6 capability at
>this time. The direction of the use of various forms of NAT-based approaches
>and increasing use of application layer gateways in the public and enterprise
>environments can be seen as an effort to extend the lifetime of the existing
>infrastructure investment. In a volume-based market with relatively low revenue
>margins, this position certainly has some sound rationale from a business
>management perspective. But I agree with Tony here that such business
>approaches are ultimately short-term in nature, because they do not allow IPv4
>to encompass indefinite further decades of Internet growth in a silicon-dense
>world.
>
>>However, in terms of understanding the next few years of a process of industry
>transition of protocol infrastructure into IPv6 deployment, perhaps the real
>issues here are more centered on competitive business factors and sector
>investment profiles than they are about detailed introspection of trends within
>various number series.
>
>>The numbers all indicate that this is not a matter that can be deferred
>indefinitely. Tony's call for some timely attention to the need to commence
>investment in IPv6-based service infrastructure is one that I hope the industry
>is listening to attentively.
>—Geoff Huston
>gih at apnic.net 
>
>A Virtual Roundtable
>Ole: Let's
>open this discussion on the point of measurement methods. We invited John
>Klensin and Fred Baker to join Geoff and Tony in the discussion at our virtual
>round table. (We often all see each other at IETF meetings, but there is seldom
>enough time to gather everyone around a real table, hence this discussion took
>place with a few rounds of e-mail).
>
>Geoff: As I
>said in my response letter, Tony's work takes a different base point for making
>the projection from the earlier work that I did in this area. My work has
>focused on the trends from the addresses used in the public IPv4 Internet, and
>then deriving projections on consumption based on this data. It assumes that
>the influencing factor for address consumption is the use of addresses in the
>public IPv4 Internet.
>
>Tony: As Geoff
>noted, he and I have discussed over time that we are looking at different parts
>of the data set and coming to different conclusions. One specific point that
>distorts the approaches is the time delay between IANA allocation to the RIRs
>and the appearance of that space for public use.. In particular, his comment
>about 5 to 8 /8s per year is based on the delayed public use data that will
>eventually catch up with the fact that IANA has allocated 13 /8s just since the
>beginning of 2005. If the allocation rates had close to linear growth, the
>delay would not be a big factor. Another point of distortion is the potential
>for some of the allocations to never show up as publicly routed.
>
>Ole: So when
>do we actually run out?
>
>Geoff: There
>are many specific milestones that will pass in sequence. The unallocated
>address pool held by IANA will exhaust first, and then the RIR pools of
>unallocated data will drain. At that point there is no stream of
>"new" addresses to fuel further growth, and that is probably a
>reasonable point in time to say that we have "run out." Assuming that
>the current business influential factors and allocation policies remain in
>place, then the projection models from recent data indicate that this
>"run-out" date is around 2016, or some 11 years from now. Of course
>these are unlikely assumptions as the prospect of exhaustion draws nearer, and
>there may be a "last-minute rush" of address allocation requests from
>the service provider industry that could draw in that projected
>"run-out" date. Such additional consumption pressures are difficult
>to factor in to trend-based predictive models, of course. It is also
>conceivable that the industry could shift its attention almost entirely to
>IPv6-based protocol infrastructure in the coming years, in which case the
>"run-out" projection for IPv4 would extend out further in time simply
>because of the translation of the consumption activity to the IPv6 address pool.
>
>Tony: As I
>noted early on in my article, there will still be pool available at each of the
>RIRs when the IANA pool that I focused on is exhausted. In the past I have said
>we would never completely run out because nobody could afford that last address,
>but in light of the accelerating consumption of IPv4 coupled with the
>less-than-aggressive deployment of IPv6, I can see how the pool might actually
>run dry..
>
>John: In
>practical terms, the point at which one has "run out" of address
>space is not tied to being the last applicant to the RIRs for an address pool.
>I have suggested that point will never arise: the RIRs (and, to the extent to
>which the Internet
>Corporation for Assigned Names and Numbers [ICANN] can make
>decisions, the IANA), will continually recalibrate policies to prevent
>"running out." Of course the inevitable consequence of those
>recalibrations is that, although one does not need to worry about approaching
>an RIR and being told "no space left," the combination of monetary,
>justification, and general aggravation costs is such that one does not even
>want to contemplate being the applicant for the next-to-last available block.
>That reasoning says that looking at the date on which near exhaustion is
>reached is relatively uninteresting. The more important question is when one
>enters the end game for IPv4 space because, as soon as the end game begins, the
>space is essentially exhausted.
>
>>I suggest that the criterion for entrance into the end game is not measured
>statistically but by looking at the point at which one needs to start designing
>networks and subnets, not in a way that is optimal from a network architecture
>or network management and growth standpoint, but in order to conserve address
>space and/or to avoid extended discussions with applicable RIRs (or one's ISP
>that deals with the RIR). From that point of view, we have already run out, and
>probably ran out a couple of years ago. Every time someone who has multiple
>machines is pointed to private address space because of a presumed shortage, it
>is an indication that we have already run out of space. Every time China
>manages to make a successful political point—regardless of the country's actual
>internal dynamics and economics—about its inability to get addresses for its
>population, it is an indication that we have already run out of address space.
>Every time an ISP decides to use private space to manage its backbone, it is an
>indication that we have already run out of address space.
>
>Fred: I have
>made the same point, from a point of view of economics. In essence, when a
>commodity is common and demand is low, there are calls to squander it because
>it costs nothing—something one hears a lot of in the IPv6 community. When
>supply and demand are comparable, a market develops, and I need to tell you that
>I certainly pay for the IPv4 addresses at my >house. When demand outstrips supply, we enter a regulated market of some kind,
>and our current allocation policies certainly reflect a regulated market. The
>step after a regulated market is a black market, and it is not too hard to find
>that either..
>
>John:
>Actually, in our present situation, there is an intermediate step before things
>deteriorate completely into a black market. Although it is unlikely that any
>significant fraction of the early IPv4 academic, research, or commercial
>allocations could be recovered and reused, there are governmental allocations
>that might be recovered under significant political pressures. Unfortunately,
>in addition to politicizing the allocation process much more than we have seen
>so far, such moves might push the present users of those allocations toward
>NATs in ways that would make the ultimate transition to IPv6 more difficult
>while not gaining very much additional time for the IPv4 space.
>
>Tony:
>Political pressure or not, simple logistics argues against this. Given the rate
>of growth in consumption, any reclaimed government space would be consumed in
>substantially less time than it would take to rebuild their network and release
>it. Even a small network sitting on a /16 would take at least a year to release
>that much space, and at the current spot on the escalating curve that /16
>represents around 2 hours of IANA run rate. Getting back a whole /8 would
>logistically take several years, and then at that point on the curve the result
>would be about a week of run rate. If several of these government organizations
>have a mesh of direct interactions and head down the same path, the resulting
>overlap in the private address space would require creating a complex NAT
>system worthy of a Nobel Prize. Reclamation is a nice bar-room debate topic,
>but the return on investment is extremely low. If an organization were to
>consider rebuilding its network to release an IPv4 allocation, it would make
>much more sense for that organization to rebuild it as IPv6 than to move
>publicly addressed nodes behind a NAT.
>
>Geoff: It
>would be strongly preferred by all, I would suggest, that the "black
>market" option be avoided. If the consequence of the exhaustion of the
>unallocated pool of IPv4 addresses is the trading of alreadyallocated IPv4
>addresses, then a responsible way for the industry to support that scenario is
>to encourage such a market to operate with the support of some form of
>"clear title" that could legitimate trading transactions. Without
>structure and stability in a trading market, the value of the trade is
>meaningless, and in this case the potential for chaos in the network itself is
>undeniable.
>
>Fred: We are
>in fact starting to see networks designed to be IPv6-only or IPv6-dominant (the
>latter being a network that might use IPv4 internally but offer only IPv6
>services to some or all of its customers) in China, Japan, and other places.
>The economic argument is the one these operators are primarily giving—they
>state that they see a roadmap to the number of addresses that they need in
>IPv6, while in IPv4 they are significantly constrained. This sounds to me a lot
>like John's comments about network design, but the other way—rather than
>designing their networks to what they perceive as IPv4 addressing policy
>limitations, they are choosing a path that they perceive as giving them
>options.
>
>>We also see evidence of networks designing themselves to the limits of address
>allocation in IPv4, usually using multiple layers of NATs. For quite a while,
>for example, China Unicom used multiple layers of NAT in order to work around
>what the company felt was a deficiency in its ability to get IPv4 addresses
>from its national registry. As I understand it, the company has changed its
>strategy to include getting IPv4 address allocations directly from APNIC, and
>at the same time to deploy an IPv6 network in parallel to move away from IPv4
>dependence.
>
>John: There is
>another factor at work in this. Transitions are never free. If we are going to
>design and build out a substantially new network, we are rapidly reaching the
>point—some would say that we have reached it already—at which it is cheaper to
>design and build that network for IPv6, making whatever arrangements are needed
>at its interconnection points with IPv4 networks, than to build in IPv4 and
>face a transition later. As those decisions are increasingly made, it may both
>reduce pressure on new IPv4 allocations and create free pools of IPv4 space
>that could be recovered and reused. For example, the U.S. Department of Defense
>(DoD) has announced a fairly aggressive schedule for moving to IPv6. If they
>meet that schedule and were then willing to free up the IPv4 space that they
>would presumably no longer be using, it would free up the equivalent of several
>/8s. While I agree with Tony that this hypothetical case would be unlikely to
>make any significant difference in the long run, it illustrates another
>difficulty with trying to make assertions about what is happening by
>statistical projections alone.
>
>Ole: It is
>frequently stated that North America is immune to the address exhaustion
>problem..
>
>Tony: Well
>despite persistent rumors and press statements to that effect, ARIN continues
>to consume about 30 percent of the annual allocation from IANA. If the past
>allocations were sufficient to stave off global exhaustion, why the continued
>consumption? In any case, when the central pool is exhausted the North American
>region will be in the same situation as everyone else—unable to expand or
>acquire new IPv4 addresses.
>
>Geoff: We are
>seeing growth in Internet-based services in all regions of the industry,
>including North America. And network growth needs to be fueled by network
>addresses. We are seeing a combination of a continued demand for further
>addresses, and the use of various forms of network configurations that attempt
>to make the most efficient use of already-allocated addresses. There is little
>data to suggest that any region, including that of North America, is in a
>position of immunity from these growth-related factors.
>
>>Ole: There is widespread opinion that NAT will solve the problems for a long
>time to come.
>
>Geoff: The ISP
>industry certainly has made considerable investments there, and many millions
>of end users today use the Internet behind NAT devices. Given the size of this
>investment and the factors of inertia in large-scale service markets, it is
>reasonable to predict that NATs will be around for quite some time. But NATs
>add cost to network services. If we are talking about a network that is
>restricted to servicing the communications needs of people, then this is a
>relatively high-value activity, and the additional costs of the deployment of
>NATs are being absorbed within the cost base of the network service economy.
>And for such human activity-based services this may well continue for some
>time, given the existing levels of industry investment in service
>infrastructure that includes the use of NATs. Certainly any new application
>that is adopted by the Internet user population needs to work across a wide
>variety of NAT configurations. From this perspective it is likely that IPv4 and
>NATs will continue to be part of the Internet landscape for a long time to
>come.
>
>>But although this approach has the potential to service a portfolio of service
>markets for some time to come, it cannot service all forms of service
>markets—not in the future nor even today. It does not solve all the
>"problems" and certainly does not encompass all the opportunities
>that the Internet offers. The potential of IPv6 is one that includes an address
>span designed to match the full potential of the volume-driven silicon
>industry, both now and in a future that extends out for many decades to come.
>One likely scenario for IPv6 is in servicing a truly massive device-dense
>environment. This scenario encompasses far more than services that are
>primarily directed at human end users. And the associated service market will
>be more akin to that of a relatively undifferentiated commodity market, where
>simplicity and low cost are the dominant service provider discriminants.
>Because of their additional complexity and associated incremental cost, NATs
>are marginalized in such commodity markets directed at servicing device
>density, and it is there that the true leverage of the IPv6 address span
>becomes a major influential factor..
>
>Tony: As Geoff
>notes, NAT has been widely available and deployed globally over the same
>timeframe as the recent consumption. Yet the accelerating growth trend
>continues, consuming to the point where only 25 percent of the total IPv4 space
>remains available. Although NAT does slow the rate of public address
>consumption from what it might otherwise be, it creates more problems than it
>solves. Geoff also raises the economic investment in NAT to date, which is an
>interesting contrast to many complaints I hear about the cost of deploying
>IPv6. Most people who look at what it will take to deploy IPv6 in their network
>are very quick to dismiss this investment in the array of costs associated with
>NAT. Often they insist on a demonstration of value for the IPv6 investment
>while at the same time they refuse to allow consideration of removing their
>development, and ongoing operational support costs for IPv4 NAT.
>
>>Although I agree that in the interim overlap period the costs are additive, in
>the long term staying on the IPv4/NAT path those costs only compound, whereas
>on the IPv6 path they disappear. The duration of that overlap is somewhat
>self-controlled as a direct trade-off between the costs for running both
>protocols in parallel versus the costs associated with aggressively moving the
>end systems and applications to IPv6.
>
>Ole: Another
>area frequently discussed on various lists is that the U.S. DoD and Federal
>Government mandates for service availability in 2008 are just another instance
>of the Government OSI
>Profile (GOSIP) and that they too will disappear.
>
>Tony: What
>these discussions miss is that the situation is entirely different now. In the
>early 1990s the U.S. GOSIP effort was directed by a strong desire to
>consolidate the array of protocols in use at that time toward a common one.
>Other governments had similar efforts that led them collectively toward a suite
>that was developed with international governmental input. IPv4 was an
>alternative to the mandate with applications already supporting it, while the
>OSI protocols existed in some router products but did not have many
>applications available.
>
>>At this point the existing government networks are already consolidated, and
>there is no alternative. Yes, IPv6 still has fledgling application support, but
>the IPv4 pool is no longer a sustainable resource to draw on, and there is no
>other option. So the government networks either stop growing or, as the U.S.
>DoD and Government agencies have announced, they will move to IPv6. This
>implies preparing the application community to meet the impending reality.
>
>Geoff:
>Although the strategic directions of one single—but relatively large—market
>player does have some bearing on the direction of the global market in
>Internet-based service provision, I do not see evidence that this will be
>sufficient to influence the entire market in any particular direction. This was
>certainly evident in the case of GOSIP some years ago, and continues to be an
>aspect of the market today. The global communications sector carries the impetus
>and burden of massive investment in infrastructure, process, technology,
>services, and consumer product portfolios. The sector has already undergone a
>revolutionary change with the advent of the Internet over the past decade.
>Doubtless there is considerable reluctance on the part of many sector players
>to continue to invest in further change in the protocol infrastructure of
>Internet-based services. On the other hand, the upheavals in the service
>provider sector have also eliminated much historical complacency about the
>stability of these markets and the adequacy of the associated service
>portfolio. It is reasonable to suggest that this sector is now very attentive
>to the prospect of expanded markets and new service opportunities that can take
>advantage of the existing infrastructure to create new revenue streams. So I
>think it is the current dynamics of the service provider sector and the
>potential for new service markets that would be the most persuasive factor for
>service providers to invest in an IPv6 protocol infrastructure.
>
>Ole: Closing
>thoughts?
>
>Tony: As I
>said at the end of my article, now is the time to recognize that we have
>reached the end of sustainable growth in IPv4. For most existing organizations
>that can foretell they have as much space as they will need for the next
>decade, this is not really an internal problem. Where these organizations will
>have a concern is when they deal with newcomers or others that have been forced
>into IPv6 because of exhaustion of the pool. Those organizations that foresee
>expansion and growth should evaluate Geoff's analysis as well as mine and weigh
>their plans against the risks of either or both of us being wrong.
>
>>In any case it only makes sense to start IPv6 capability discussions with the
>product vendors now. Product development cycles can be lengthy, and the only
>way for the vendor community to mesh with an organization's deployment plans is
>to have sufficient notice about those plans and timeframes.. It would also be
>wise for the organization's network architects to start thinking about the
>impacts of an IPv6 deployment. Both protocol versions are packet-based and the
>names start with IP, but there are enough differences in the details that it is
>worth taking a fresh look to see what might be easier or cheaper than just
>blindly deploying IPv6 identically to the IPv4 deployment.
>
>Geoff: The
>Internet continues to present challenges to the communications sector, and I
>would suggest that the underlying influential factor is the combination of the
>silicon and software industries that continue to fuel the demand side with
>fascinating, innovative, and compelling uses of communications that continue to
>surprise us with their continual restatement of the size of the domain in which
>we operate. We appear to be moving beyond servicing devices that are activated
>and influenced primarily by direct human activity, such as e-mail and Web use,
>and we are now looking at various command, control, and monitoring functions
>that embed themselves deeply in other devices and in other elements of our
>infrastructure. This encompasses larger concepts such as "smart
>buildings" and "smart traffic control," and they reach all the
>way down to the level of embedding into consumer devices and even
>identification tags. This is not a world that can readily be serviced by an
>IPv4 protocol infrastructure, and we are already seeing various levels of
>network indirection in both NATs and various forms of overlay networks to
>attempt to compress this new scale of basic network addressing demands into the
>IPv4 environment. This appears to be a complex, and therefore costly task. But
>the expectation here is that the service industry is heading toward a commodity
>utility function, where the essential attributes of the underlying network are
>simplicity and efficiency. These factors suggest that the market
>characteristics that arise from the propulsion of the silicon and software
>industries are inexorably tugging the communications service industry to
>embrace simple, scalable, and efficient networking technologies. It is in this
>space that the essential attribute of IPv6, that of the size of the address
>pool, has its most effective leverage. Here the "run out" of IPv4
>will inevitably focus our common attention on how best to engage with future
>needs and roles. And in this perspective the IPv6 technology has a critical and
>central role.
>
>John: Tony, I
>think we need to assume that, when it comes down to translating the projections
>into an answer to the "when do we need to get serious about IPv6?"
>question, both you and Geoff are, to a considerable extent, wrong. Geoff's
>articles and projections have been interpreted by some people as containing a
>"there is no problem, we can continue with IPv4 until we all retire"
>message. Viewed from that direction, yours can be seen as "we cannot be
>quite that >complacent." Instead, I think we should all be looking at going directly
>to IPv6 in newer network installations rather than concentrating on whether we
>can get enough IPv4 space for them. We also need to be examining—now, not a few
>years in some projected future—the applications and services for end networks
>and end users, not just backbone and ISP services and operations. One of my
>particular concerns is that we have enterprise and customer support people and
>protocols all over the world who are used to thinking about things in an IPv4
>world, including the support advantages of "all NAT-based end networks
>look the same" architectures. The need to retrain them to think about
>things differently, and to design and build new tools for their use, may
>suggest a more time-consuming and expensive transition than changing over the
>networks themselves.
>
>Fred: What is
>clear to me from this discussion, Geoff's prior analysis, and Tony's analysis
>here, is that there is a timeline. We are not >debating whether IPv4 address availability is limited or whether it can be
>"saved" by address allocation policy, nor are we debating the
>economic or technical impacts of more or less draconian allocation policies. We
>are debating
>what constitutes the end game, when and why that end game will become
>important, and whether perhaps we are already seeing the first steps of it. We
>are also not debating whether perhaps some new architecture would be preferred
>over the one in IPv6; if we had an alternative on the table today we could
>discuss that, but experience tells us that the proposals being considered by
>the National Science
>Foundation (NSF) and others are sufficiently "researchy"
>to not be ready for wide-scale deployment in the necessary timeframe.
>
>>As such, from my perspective, there is a present call to action.
>
>>What U.S. DoD and recent congressional hearings have recommended is in keeping
>with the IETF's recommendation and with the IPv6 address allocation strategies
>of the RIRs. The simplest transition strategy involves presently procuring
>equipment, operating systems, and applications that are IPv6-capable in
>preference to systems that are limited to IPv4. At some point in the future,
>perhaps in the 2008–2010 timeframe, we should plan to turn on IPv6 networking
>capabilities throughout our networks, and this means gaining experience with
>IPv6 on a smaller scale in 2005–2007 in our networks, in server applications,
>and in user systems. Turning down IPv4 capabilities, which is the endpoint of
>such a transition, is a business decision that does not need to be made
>hastily; we should presume that coexistence will be important for a decade, and
>probably more.
>
>Ole: Thank
>you, gentlemen!
>
>>TONY HAIN is currently the Senior Technical Leader, IPv6 technologies, with
>Cisco Systems. In addition to providing guidance to the various internal
>product teams, he was also co-chair of the IETF working group developing IPv6
>transition tools. His IETF participation since 1987 includes a term on the Internet
>Architecture Board from 1997 to 2001. Named an IPv6 Forum Fellow in 2004, he is currently
>serving as Technology Director on the forum's North American IPv6 Task Force
>steering committee. Prior to joining Cisco in 2001, he spent 5 years at
>Microsoft, where his roles included Program Manager for IPv6 as well as Network
>Analyst for the CIO's office. Prior to Microsoft, he was the Associate Network
>Manager for the U.S. Department of Energy's Internet effort, ESnet. With this
>range of roles, spanning the space between the implementation technologists and
>senior management, he brings a real-world viewpoint to the deployment decision
>process. E-mail: ahain at cisco.com
>
>>GEOFF HUSTON holds a B..Sc. and a M.Sc. from the Australian National University.
>He has been closely involved with the development of the Internet for the past
>decade, particularly within Australia, where he was responsible for the initial
>build of the Internet within the Australian academic and research sector, and
>has served his time with Telstra, where he was the Chief Scientist in the
>company's Internet area. Geoff is currently the Internet Research Scientist at
>the Asia Pacific Network Information Centre (APNIC). He served as a member of
>the Internet Architecture Board from 1999 until 2005, and currently co-chairs
>the Site Multi-homing and Routing Operations IETF Working Groups. He is author
>of The ISP Survival Guide,
>ISBN 0-471-31499-4, Internet
>Performance Survival Guide: QoS Strategies for Multiservice Networks,
>ISBN 0471-378089, and co-author of Quality
>of Service: Delivering QoS on the Internet and in Corporate Networks,
>ISBN 0-471-24358-2, a collaboration with Paul Ferguson. All three books are
>published by John Wiley & Sons. E-mail: gih at apnic.net
>
>>JOHN KLENSIN is an independent consultant based in Cambridge, Massachusetts. He
>has been involved in the design, development, and deployment of ARPANET and
>Internet applications, and occasionally lower-layer technologies, since the
>late 1960s and early 1970s. He has also been intermittently involved with
>Internet administrative and policy issues since the early 1980s. His current
>work primarily focuses on internationalization of the Internet on both
>technical and policy dimensions. E-mail: klensin at jck.com
>
>>FRED BAKER has worked in the data communications industry, building network
>elements such as switches and routers, since 1978. His involvement with
>Internet technology started in 1986, and with the IETF in 1989. He has
>contributed to the development of OSPF, QoS, PPP, SNMP MIBs, and a variety of
>other technologies. He has also held a variety of management positions,
>including chairing various working groups, participating in the IAB, and
>chairing the IETF. He currently serves on the Technical Advisory Board of the
>U.S. Federal Communications Commission and as the Chairman of ISOC's Board of
>Trustees. E-mail: fred at cisco.com
> 
> 
>-----Original Message-----
>>From: Piche, Dennis [mailto:piched at anx.com] 
>>Sent: Thursday, July 23, 2009 12:25 PM
>>To: VAUGHN THURMAN - SWIFT SYSTEMS INC
>>Cc: Brent Sweeny; arin-discuss at arin.net
>>Subject: Re: [arin-discuss] Good Stewardship by example,I'd like to RETURN a
>/20
> 
>I need a user ID to access this report!
> 
>Sent from my iPhone
> 
>On 2009-07-23, at 11:56 AM, "VAUGHN THURMAN - SWIFT
>SYSTEMS INC" <Vaughn at SwiftSystems.com 
> > wrote:
> 
>> Brent,
>>  
>> Sorry if I came across as name calling - that's good
>feedback.  Let  
>> me tone it down a bit, be a bit more constructive,
>and go more at  
>> the root of the issue, i.e. my concern regarding
>throwing our hands  
>> up too easily.
>>  
>> I am stating that, in my humble opinion, the
>previous study is not  
>> based wholly on verified facts, but rather on
>supposition and  
>> speculation layered upon partially verified data. 
>Further, it  
>> included sources who had an interest in moving the
>world forward  
>> towards IPv6 at a faster pace (sell new
>hardware/software/services,  
>> etc.).  This is not (on it's own) a valid basis for
>current  
>> decisions about how to smooth an impending rough
>transition.  The  
>> stakes have been raised and it's time to do our job
>as a membership  
>> and work in the interest of the larger community -
>our eco-system as  
>> it were.
>>  
>> There is ample corroborated testimony (to indicate
>the existence of  
>> substantial reclamation opportunities) within the
>postings on this  
>> list (over just the last 72 hours) to serve as
>evidence warranting a  
>> grand jury.  I qualify that statement with: provided
>people would  
>> swear to their recent statements, etc.  So, it seems
>we should be as  
>> inquisitive as the law would when our own interests
>are at stake.    
>> This is especially true for the smaller operators
>that need some  
>> headroom while this inevitable transition occurs.
>>  
>> I can quote a recent study by a conservative think
>tank and another  
>> from a liberal think tank - both on a current hot
>topic (never mind  
>> the issue, don't want to bunny trail here).  Each
>offers a  
>> diametrically opposed viewpoint of the same data. 
>Each effectively  
>> presents a favorable subset of the data without
>exposing the  
>> weakness of certain suppositions used to arrive at
>the seemingly  
>> data based results.  In fact, both will assume their
>viewpoint upon  
>> the same data and it has to color the result.
>>  
>> Data is objective, analysis is subjective.
>>  
>> It sounds to me like there is a lot of unanalyzed
>data yet to be  
>> given the "Colombo"...
>>  
>> "The /8's are too hard to get back without
>fragmentation and  
>> everyone would fight to the death to keep their
>unused space.  So  
>> let's look at the remaining data"
>>  
>> Colombo:  "Yes, but Sir, I have just one more
>question..."  which is  
>> how we get at the missed opportunity for solutions. 
>That's all I  
>> want us to do.
>>  
>> Hope that more politely expands upon my point:  We
>are not in a  
>> situation where inaction is acceptable unless it is
>based upon  
>> aggressively verified data...  in other words I
>suggest that ARIN  
>> *should* contact the holders of large blocks of
>unused space *anew*  
>> and see what their feeling is about being good
>corporate Internet  
>> citizens in the face of a crisis headed towards
>public attention.   
>> Offer press releases praising them for their good
>deeds, and  
>> honorable mention at various events, and you might
>be quite  
>> surprised what a well placed call from senior
>resources could  
>> accomplish.  I'm an optimist.
>>  
>> Of course, a stick should be behind the back that
>wears that  
>> friendly smile.  I believe it should have written on
>it: "The power  
>> of the press".
>>  
>> In my opinion, ARIN can reach that stick faster than
>small operators  
>> can on our own, but we can band up and reach it if
>ARIN feels bound  
>> or otherwise unable to do so.  That stick is the
>data verifier we  
>> need.  I am not suggesting we fight bears, but
>rather that we be  
>> brave enough to make sure they are not just wooly
>caterpillars in an  
>> oversized (allocation) bear suit before we checkmark
>those caves as  
>> being off limits.
>>  
>> Best regards,
>> ~Vaughn
>>  
>>  
>> -----Original Message-----
>> From: Brent Sweeny [mailto:sweeny at indiana.edu]
>> Sent: Thursday, July 23, 2009 11:09 AM
>> To: Vaughn Thurman - Swift Systems
>> Cc: arin-discuss at arin.net
>> Subject: Re: [arin-discuss] Good Stewardship by
>example, I'd like to  
>> RETURN a /20
>>  
>> the fact that someone has already "studied the
>issue" (precisely as  
>> you
>> suggest be done) and the data behind the facts of
>the study disagree  
>> with
>> your assumption doesn't make them a
>"naysayer"; it makes them much  
>> more
>> convincing, and the name-calling doesn't change the
>facts nor their
>> inevitable conclusions.  If you assert that ARIN
>needs to expend  
>> resources to
>> try to disprove Tony's (and Geoff's) pretty careful
>analysis, it'd be
>> necessary to have more than that you don't like the
>conclusions as a  
>> reason:
>> you'd have to have some factual basis for convincing
>us their  
>> analysis is
>> flawed and must be redone.  Absent that, we have to
>be grownups,  
>> accept the
>> facts, and try to use "a group this bright"
>to do the best we can  
>> with the
>> facts -- and move forward, not backwards.
>>  
>> On 7/22/2009 8:23 PM, Vaughn Thurman - Swift Systems
>wrote:
>>> Wow, so out come the naysayers... "Shut up
>you little fleas. Don't  
>>> you
>>> know that the experts have spoken? Why study the
>issue when others  
>>> have
>>> already said it is not worth it."
>>>  
>>> The power of the press and public opinion are
>pretty powerful.   
>>> Does a
>>> protracted battle against the interests of small
>ISP types or the
>>> "Internet community" really suit HP,
>Apple, or any of the other space
>>> Easters if in the public eye?  Think about the
>good will a few have
>>> gotten on this list by committing to return
>space..
>>>  
>>> You don't get what you don't ask for.
>>>  
>>> Try!  Aim high and risk falling short.  Aiming
>low is too easy to
>>> succeed at for a group this bright.
>>>  
>>> ~Vaughn
>>>  
>>> Sent from my handheld
>>>  
>>> On Jul 22, 2009, at 7:48 PM, Owen DeLong
><owen at delong.com
>>> <mailto:owen at delong.com>> wrote:
>>>  
>>>>  
>>>> On Jul 22, 2009, at 1:06 PM, Steve Wagner
>wrote:
>>>>  
>>>>> As a note it's not just the /8's. I am
>in Idaho.  The State of  
>>>>> Idaho
>>>>> has a Class B 164.165.0.0 All State
>government activities sit  
>>>>> behind
>>>>> two different firewalls.
>>>>>  
>>>>> Micron technology 137.201.0.0. Sits
>behind firewalls
>>>>>  
>>>>> And so forth into perpetuity it seems
>>>>>  
>>>>> In this regard by reclaiming this
>address space that companies  
>>>>> have,
>>>>> particularly when the coropration sits
>behind NAT firewalls is
>>>>> unjustified.  The ones I listed above
>use  Private address space
>>>>> behind the firewall i.e. 10.X.X.X etc.
>So why then would a company
>>>>> entity that does this need to retain
>their public Class A, B, C  
>>>>> etc.
>>>>> There is no technical or administrative
>justification I can see.
>>>>>  
>>>>> Nevertheless, there was a comment about
>pre ARIN and Contract Law.
>>>>> Unfortunatley this may play the larger
>role over common sense.
>>>>>  
>>>>> While this is not the ultimate solution,
>it certainly can stem the
>>>>> tide for many years.
>>>>>  
>>>>> It would be an interesting study to
>examine the allocated IP  
>>>>> address
>>>>> space by entity and determine how many
>of these organizations sit
>>>>> behind a NAT firewall, and only use a
>small portion of their  
>>>>> allocation.
>>>>>  
>>>> Reclamation has been repeatedly studied,
>and, in general, the
>>>> conclusion matches the following excerpt
>from a Cisco Journal  
>>>> article:
>>>>  
>>>>
><http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html 
>>>>
>>http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html
>>>>  
>>>>> Reclaiming Allocations
>>>>> Another debate occasionally resurfaces
>about reclaiming some of the
>>>>> early allocations to further extend the
>lifetime of IPv4. Hopefully
>>>>> this article has shown that the ROI for
>that approach is going to  
>>>>> be
>>>>> extremely low. Discussions around the
>Internet community show there
>>>>> is an expectation that it will take
>several years of substantive
>>>>> negotiation (in multiple court systems
>around the globe) to  
>>>>> retrieve
>>>>> any /8s. Then following that effort and
>expense, the likelihood of
>>>>> even getting back more than a few /8
>blocks is very low. Following
>>>>> the allocation growth trend, after
>several years of litigation the
>>>>> result is likely to be just a few months
>of additional resource  
>>>>> added
>>>>> to the pool—and possibly not even a
>whole month. All this assumes
>>>>> IANA does not completely run out before
>getting any back, because
>>>>> running out would result in pentup
>demand that could immediately
>>>>> exhaust any returns.
>>>>  
>>>>  
>>>> If you can come up with credible figures
>indicating that there are  
>>>> at
>>>> least 28 /8s worth of reclaimable space out
>there, then, reclamation
>>>> efforts might be more interesting, but, I
>tend to doubt that is the
>>>> case. If you can't reclaim at least 14 /8s,
>you don't even buy an
>>>> additional year.
>>>>  
>>>> Owen
>>>>  
>>>>>  
>>>>> Regards,
>>>>> Steve Wagner
>>>>> Vice President of Operations
>>>>> Syringa Networks, LLC
>>>>> 3795 S Development Ave, Suite 100
>>>>> Boise, ID 83705
>>>>> Office: 208.229.6104
>>>>> Main: 208.229.6100
>>>>> Emergency: 1.800.454.7214
>>>>> Fax: 208.229.6110
>>>>> Email:
>>>>>
><mailto:Stwagner at syringanetworks.net>Stwagner at syringanetworks.net
>>>>>
><mailto:Stwagner at syringanetworks.net>
>>>>> Web:
><http://www.syringanetworks.net>www.syringanetworks.net>
>>>>> <http://www.syringanetworks.net>
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> "Idaho's Premier Fiber Optic
>Network"
>>>>>  
>>>>> Privilege and Confidentiality Notice
>>>>> The information in this message is
>intended for the named  
>>>>> recipients
>>>>> only. It may contain information that is
>privileged, confidential  
>>>>> or
>>>>> otherwise protected from disclosure. If
>you are not the intended
>>>>> recipient, you are hereby notified that
>any disclosure, copying,
>>>>> distribution, or the taking of any
>action in reliance on the  
>>>>> contents
>>>>> of this message is strictly prohibited.
>If you have received this
>>>>> e-mail in error, do not print it or
>disseminate it or its contents.
>>>>> In such event, please notify the sender
>by return e-mail and delete
>>>>> the e-mail file immediately thereafter.
>Thank you.
>>>>>  
>>>>>  
>>>>> -----Original Message-----
>>>>> From: arin-discuss-bounces at arin.net
>>>>>
><mailto:arin-discuss-bounces at arin.net> [
>>>>>
><mailto:arin-discuss-bounces at arin.net>mailto:arin-discuss- 
>>>>> bounces at arin.net]
>>>>> On Behalf Of John Osmon
>>>>> Sent: Wednesday, July 22, 2009 1:43 PM
>>>>> To:
><mailto:arin-discuss at arin.net>arin-discuss at arin.net
>>>>> <mailto:arin-discuss at arin.net>
>>>>> Subject: Re: [arin-discuss] Good
>Stewardship by example, I'd like  
>>>>> to
>>>>> RETURN a /20
>>>>>  
>>>>> On Wed, Jul 22, 2009 at 01:32:19PM
>-0400, Joe Maimon wrote:
>>>>>>  
>>>>>>  
>>>>>> John Osmon wrote:
>>>>>>  
>>>>>>>  
>>>>>>> We're aren't going to save the
>IPv4 world by returning space, but
>>>>>>> we *will* make it easier on soe
>folks that are coming to the  
>>>>>>> table
>>>>>>> (relatively) late.
>>>>>>  
>>>>>> Hate to be a downer, but not at the
>current burn rate.
>>>>>  
>>>>> Actually, I agree -- but don't tell the
>folks that think getting
>>>>> a couple of /8s back from HP, Apple, and
>the DOD is going to  
>>>>> significant
>>>>> difference in the timing of IPv4
>exhaustion.  :-)
>>>>>  
>>>>> I still think that anything you aren't
>using should go back to the
>>>>> pool that allows new comers a chance to
>participate in
>>>>> commerce/communication.  I don't,
>however, think that a slew of
>>>>> /20s (or /8s) are going to make a big
>impact.
>>>>>
>_______________________________________________
>>>>> ARIN-Discuss
>>>>> You are receiving this message because you
>are subscribed to
>>>>> the ARIN Discussion Mailing List (
>>>>>
><mailto:ARIN-discuss at arin.net>ARIN-discuss at arin.net
>>>>> <mailto:ARIN-discuss at arin.net>).
>>>>> Unsubscribe or manage your mailing list
>subscription at:
>>>>> <http://lists.arin.net/mailman/listinfo/arin-discuss>http://lists.arin.net/mailman/listinfo/arin-discuss
>>>>> Please contact info at arin.net
><mailto:info at arin.net> if you  
>>>>> experience
>>>>> any issues.
>>>>>
>_______________________________________________
>>>>> ARIN-Discuss
>>>>> You are receiving this message because
>you are subscribed to
>>>>> the ARIN Discussion Mailing List
>(ARIN-discuss at arin.net
>>>>> <mailto:ARIN-discuss at arin.net>).
>>>>> Unsubscribe or manage your mailing list
>subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-discuss
>>>>> Please contact info at arin.net if you
>experience any issues.
>>>>  
>>>>
>_______________________________________________
>>>> ARIN-Discuss
>>>> You are receiving this message because you
>are subscribed to
>>>> the ARIN Discussion Mailing List
>(ARIN-discuss at arin.net
>>>> <mailto:ARIN-discuss at arin.net>).
>>>> Unsubscribe or manage your mailing list
>subscription at:
>>>>
>http://lists.arin.net/mailman/listinfo/arin-discuss
>>>> Please contact info at arin.net <mailto:info at arin.net>
>if you  
>>>> experience
>>>> any issues.
>>>  
>>> --- 
>>>
>---------------------------------------------------------------------
>>>  
>>> _______________________________________________
>>> ARIN-Discuss
>>> You are receiving this message because you are
>subscribed to
>>> the ARIN Discussion Mailing List
>(ARIN-discuss at arin.net).
>>> Unsubscribe or manage your mailing list
>subscription at:
>>>
>http://lists.arin.net/mailman/listinfo/arin-discuss
>>> Please contact info at arin.net if you experience
>any issues.
>>  
>>  
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are
>subscribed to
>> the ARIN Discussion Mailing List
>(ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription
>at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any
>issues.
>
>
>-----Inline Attachment Follows-----
>
>>_______________________________________________
>ARIN-Discuss
>You are receiving this message because you are subscribed to
>the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-discuss
>Please contact info at arin.net if you experience any issues.


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 38851 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 39998 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 45793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 32967 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 31672 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 46248 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 27679 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 38920 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/ba993d76/attachment-0007.jpg>