[arin-discuss] Good Stewardship by example, I'd like to RETURN a /20
VAUGHN THURMAN - SWIFT SYSTEMS INC
Vaughn at SwiftSystems.com
Thu Jul 23 12:30:38 EDT 2009
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 <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_01_lg.jpg>
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_01_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_01_sm.jpg
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 <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_02_lg.jpg> Month
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_02_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_02_sm.jpg
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 <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_03_lg.jpg> Average
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_03_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_03_sm.jpg
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 <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_04_lg.jpg> Data
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_04_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_04_sm.jpg
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, <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_05_lg.jpg> Post-2000 History Basis
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_05_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_05_sm.jpg
Figure 6: IPv4 Lifetime Projections —Polynomials and <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_06_lg.jpg> Exponentials
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_06_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_06_sm.jpg
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 <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_07_lg.jpg>
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_07_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_07_sm.jpg
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 <http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_08_lg.jpg>
<http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_08_lg.jpg> http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_08_sm.jpg
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 <http://www.cisco.com/web/about/ac123/ac147/ac174/ac235/about_cisco_ipj_archive_article09186a00801a0cc3.html> Myth of IPv6," The Internet Protocol Journal, Volume 6, No. 2, June 2003.
[13] Geoff Huston, "IPv4: <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-4/ipv4.html> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-discuss/attachments/20090723/c7a22ff6/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/c7a22ff6/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/c7a22ff6/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/c7a22ff6/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/c7a22ff6/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/c7a22ff6/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/c7a22ff6/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/c7a22ff6/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/c7a22ff6/attachment-0007.jpg>
More information about the ARIN-discuss
mailing list