<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:18.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Times New Roman","serif";
font-weight:bold;}
span.contentheaderalt
{mso-style-name:contentheaderalt;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText>Here you go...<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<h2>A Pragmatic Report on IPv4 Address Space Consumption<o:p></o:p></h2>
<p class=MsoNormal style='margin-bottom:12.0pt'><a name=content></a><em><span
style='font-family:"Calibri","sans-serif"'>by Tony Hain, Cisco Systems</span></em><br>
<br>
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 <em><span
style='font-family:"Calibri","sans-serif"'>Internet Assigned Numbers Authority</span></em>
(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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_01_lg.jpg"
target="_blank">Figure 1: IANA /8 Allocations</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_01_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=415 height=303 id="Picture_x0020_1"
src="cid:image001.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_01_sm.jpg"></span></a><br>
<br>
<span class=contentheaderalt>Allocations</span><br>
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 <em><span style='font-family:
"Calibri","sans-serif"'>Regional Internet Registries</span></em> (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 <em><span style='font-family:"Calibri","sans-serif"'>Class E</span></em>—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.<br>
<br>
The projection published at <a href="http://bgp.potaroo.net/ipv4"
target="_blank">http://bgp.potaroo.net/ipv4</a> [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.<br>
<br>
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 <em><span
style='font-family:"Calibri","sans-serif"'>Classless Interdomain Routing</span></em>
(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.<br>
<br>
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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_02_lg.jpg"
target="_blank">Figure 2: IANA Allocations to RIRs —Raw /8 Allocations per
Month</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_02_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=406 height=241 id="Picture_x0020_2"
src="cid:image002.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_02_sm.jpg"></span></a><br>
<br>
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.<br>
<br>
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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_03_lg.jpg"
target="_blank">Figure 3: IANA Allocations to RIRs —Sliding-Window 24-Month
Average</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_03_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=412 height=247 id="Picture_x0020_3"
src="cid:image003.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_03_sm.jpg"></span></a><br>
<br>
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.<br>
<br>
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. <a
href="http://www.nav6tf.org/documents/e-Nations-data.pdf" target="_blank">http://www.nav6tf.org/documents/e-Nations-data.pdf</a><br>
<br>
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.<br>
<br>
<span class=contentheaderalt>Projections</span><br>
Differing from recent articles and section 5 of the report at <a
href="http://bgp.potaroo.net/ipv4" target="_blank">http://bgp.potaroo.net/ipv4</a>
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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_04_lg.jpg"
target="_blank">Figure 4: IPv4 Lifetime Projection —Non-Linear Nature of Raw
Data</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_04_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=360 height=227 id="Picture_x0020_4"
src="cid:image004.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_04_sm.jpg"></span></a><br>
<br>
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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_05_lg.jpg"
target="_blank">Figure 5: IPv4 Lifetime Projections —Order-N Polynomials,
Post-2000 History Basis</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_05_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=353 height=231 id="Picture_x0020_5"
src="cid:image005.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_05_sm.jpg"></span></a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_06_lg.jpg"
target="_blank">Figure 6: IPv4 Lifetime Projections —Polynomials and
Exponentials</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_06_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=357 height=275 id="Picture_x0020_6"
src="cid:image006.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_06_sm.jpg"></span></a><br>
<br>
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).<br>
<br>
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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_07_lg.jpg"
target="_blank">Figure 7: IPv4 Lifetime Projection —5-Year History Basis</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_07_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=353 height=227 id="Picture_x0020_7"
src="cid:image007.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_07_sm.jpg"></span></a><br>
<br>
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 <em><span style='font-family:
"Calibri","sans-serif"'>return-on-investment</span></em> (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.<br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_08_lg.jpg"
target="_blank">Figure 8: IPv4 /8 Pool —5-Year History-Based Projection</a><br>
<br>
<a
href="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_08_lg.jpg"
target="_blank"><span style='color:blue;text-decoration:none'><img border=0
width=371 height=291 id="Picture_x0020_8"
src="cid:image008.jpg@01CA0B91.5A154FB0"
alt="http://www.cisco.com/web/about/ac123/ac147/images/ipj/ipj_8-3/83_ipv4_figure_08_sm.jpg"></span></a><br>
<br>
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.<br>
<br>
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.<br>
<br>
<span class=contentheaderalt>Reserved Space</span><br>
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.<br>
<br>
<span class=contentheaderalt>Reclaiming Allocations</span><br>
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.<br>
<br>
<span class=contentheaderalt>Summary</span><br>
<em><span style='font-family:"Calibri","sans-serif"'>Network Address
Translation</span></em> (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.<br>
<br>
<span class=contentheaderalt>References</span><br>
[1] <a href="http://www.iana.org/assignments/ipv4-address-space" target="_blank">http://www.iana.org/assignments/ipv4-address-space</a><br>
<br>
[2] <a href="http://www.arin.net/" target="_blank">http://www.arin.net/</a><br>
<br>
[3] <a href="http://www.ripe.net/" target="_blank">http://www.ripe.net/</a><br>
<br>
[4] <a href="http://www.apnic.net/" target="_blank">http://www.apnic.net/</a><br>
<br>
[5] <a href="http://www.lacnic.net/" target="_blank">http://www.lacnic.net/</a><br>
<br>
[6] <a href="http://www.afrinic.net/" target="_blank">http://www.afrinic.net/</a><br>
<br>
[7] <a href="http://www.rfc-editor.org/rfc/rfc3330.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc3330.txt</a><br>
<br>
[8] <a href="http://www.rfc-editor.org/rfc/rfc1700.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc1700.txt</a><br>
<br>
[9] <a href="http://www.rfc-editor.org/rfc/rfc2050.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc2050.txt</a><br>
<br>
[10] <a href="http://bgp.potaroo.net/ipv4" target="_blank">http://bgp.potaroo.net/ipv4</a><br>
<br>
[11] <a href="http://www.rfc-editor.org/rfc/rfc791.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc791.txt</a><br>
<br>
[12] Geoff Huston, "<a
href="http://www.cisco.com/web/about/ac123/ac147/ac174/ac235/about_cisco_ipj_archive_article09186a00801a0cc3.html">The
Myth of IPv6</a>," <em><span style='font-family:"Calibri","sans-serif"'>The
Internet Protocol Journal</span></em>, Volume 6, No. 2, June 2003.<br>
<br>
[13] Geoff Huston, "<a
href="http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-4/ipv4.html">IPv4:
How long do we have?</a>," <em><span style='font-family:"Calibri","sans-serif"'>The
Internet Protocol Journal</span></em>, Volume 6, No. 4, December 2003.<br>
<br>
<span class=contentheaderalt>Another Perspective</span><br>
<em><span style='font-family:"Calibri","sans-serif"'>Ed.: We asked Geoff Huston
to provide some feedback on this article and he responded with the following:</span></em><br>
<br>
Dear Editor,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <a href="http://bgp.potaroo.net/ipv4/"
target="_blank">http://bgp.potaroo.net/ipv4/</a>)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<o:p></o:p></p>
<p class=MsoNormal align=right style='text-align:right'><em><span
style='font-family:"Calibri","sans-serif"'>—Geoff Huston</span></em><br>
<a href="mailto:gih@apnic.net">gih@apnic.net</a> <o:p></o:p></p>
<p class=MsoNormal><br>
<span class=contentheaderalt>A Virtual Roundtable</span><br>
<em><span style='font-family:"Calibri","sans-serif"'>Ole</span></em>: 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).<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Ole</span></em>: So when
do we actually run out?<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>John</span></em>: 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 <em><span style='font-family:"Calibri","sans-serif"'>Internet
Corporation for Assigned Names and Numbers</span></em> [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.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Fred</span></em>: 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 <em><span style='font-family:"Calibri","sans-serif"'>my</span></em>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>John</span></em>:
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>:
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Fred</span></em>: 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.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>John</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Ole</span></em>: It is
frequently stated that North America is immune to the address exhaustion
problem.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>: 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.<br>
<br>
Ole: There is widespread opinion that NAT will solve the problems for a long
time to come.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>: 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.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>: 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.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Ole</span></em>: 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 <em><span style='font-family:"Calibri","sans-serif"'>Government OSI
Profile</span></em> (GOSIP) and that they too will disappear.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>: 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.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>:
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Ole</span></em>: Closing
thoughts?<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Tony</span></em>: 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.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Geoff</span></em>: 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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>John</span></em>: 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 <em><span style='font-family:"Calibri","sans-serif"'>that</span></em>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Fred</span></em>: 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 <em><span style='font-family:"Calibri","sans-serif"'>not</span></em>
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
<em><span style='font-family:"Calibri","sans-serif"'>are</span></em> 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 <em><span style='font-family:"Calibri","sans-serif"'>National Science
Foundation</span></em> (NSF) and others are sufficiently "researchy"
to not be ready for wide-scale deployment in the necessary timeframe.<br>
<br>
As such, from my perspective, there is a present call to action.<br>
<br>
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.<br>
<br>
<em><span style='font-family:"Calibri","sans-serif"'>Ole</span></em>: Thank
you, gentlemen!<br>
<br>
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 <em><span style='font-family:
"Calibri","sans-serif"'>IPv6 Forum Fellow</span></em> 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: <a href="mailto:ahain@cisco.com">ahain@cisco.com</a><br>
<br>
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 <em><span style='font-family:"Calibri","sans-serif"'>The ISP Survival Guide</span></em>,
ISBN 0-471-31499-4, <em><span style='font-family:"Calibri","sans-serif"'>Internet
Performance Survival Guide: QoS Strategies for Multiservice Networks</span></em>,
ISBN 0471-378089, and co-author of <em><span style='font-family:"Calibri","sans-serif"'>Quality
of Service: Delivering QoS on the Internet and in Corporate Networks</span></em>,
ISBN 0-471-24358-2, a collaboration with Paul Ferguson. All three books are
published by John Wiley & Sons. E-mail: <a href="mailto:gih@apnic.net">gih@apnic.net</a><br>
<br>
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: <a href="mailto:klensin@jck.com">klensin@jck.com</a><br>
<br>
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: <a href="mailto:fred@cisco.com">fred@cisco.com</a><o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>-----Original Message-----<br>
From: Piche, Dennis [mailto:piched@anx.com] <br>
Sent: Thursday, July 23, 2009 12:25 PM<br>
To: VAUGHN THURMAN - SWIFT SYSTEMS INC<br>
Cc: Brent Sweeny; arin-discuss@arin.net<br>
Subject: Re: [arin-discuss] Good Stewardship by example,I'd like to RETURN a
/20<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>I need a user ID to access this report!<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>Sent from my iPhone<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>On 2009-07-23, at 11:56 AM, "VAUGHN THURMAN - SWIFT
SYSTEMS INC" <Vaughn@SwiftSystems.com <o:p></o:p></p>
<p class=MsoPlainText> > wrote:<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> Brent,<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Sorry if I came across as name calling - that's good
feedback. Let <o:p></o:p></p>
<p class=MsoPlainText>> me tone it down a bit, be a bit more constructive,
and go more at <o:p></o:p></p>
<p class=MsoPlainText>> the root of the issue, i.e. my concern regarding
throwing our hands <o:p></o:p></p>
<p class=MsoPlainText>> up too easily.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> I am stating that, in my humble opinion, the
previous study is not <o:p></o:p></p>
<p class=MsoPlainText>> based wholly on verified facts, but rather on
supposition and <o:p></o:p></p>
<p class=MsoPlainText>> speculation layered upon partially verified data.
Further, it <o:p></o:p></p>
<p class=MsoPlainText>> included sources who had an interest in moving the
world forward <o:p></o:p></p>
<p class=MsoPlainText>> towards IPv6 at a faster pace (sell new
hardware/software/services, <o:p></o:p></p>
<p class=MsoPlainText>> etc.). This is not (on it's own) a valid basis for
current <o:p></o:p></p>
<p class=MsoPlainText>> decisions about how to smooth an impending rough
transition. The <o:p></o:p></p>
<p class=MsoPlainText>> stakes have been raised and it's time to do our job
as a membership <o:p></o:p></p>
<p class=MsoPlainText>> and work in the interest of the larger community -
our eco-system as <o:p></o:p></p>
<p class=MsoPlainText>> it were.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> There is ample corroborated testimony (to indicate
the existence of <o:p></o:p></p>
<p class=MsoPlainText>> substantial reclamation opportunities) within the
postings on this <o:p></o:p></p>
<p class=MsoPlainText>> list (over just the last 72 hours) to serve as
evidence warranting a <o:p></o:p></p>
<p class=MsoPlainText>> grand jury. I qualify that statement with: provided
people would <o:p></o:p></p>
<p class=MsoPlainText>> swear to their recent statements, etc. So, it seems
we should be as <o:p></o:p></p>
<p class=MsoPlainText>> inquisitive as the law would when our own interests
are at stake. <o:p></o:p></p>
<p class=MsoPlainText>> This is especially true for the smaller operators
that need some <o:p></o:p></p>
<p class=MsoPlainText>> headroom while this inevitable transition occurs.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> I can quote a recent study by a conservative think
tank and another <o:p></o:p></p>
<p class=MsoPlainText>> from a liberal think tank - both on a current hot
topic (never mind <o:p></o:p></p>
<p class=MsoPlainText>> the issue, don't want to bunny trail here). Each
offers a <o:p></o:p></p>
<p class=MsoPlainText>> diametrically opposed viewpoint of the same data.
Each effectively <o:p></o:p></p>
<p class=MsoPlainText>> presents a favorable subset of the data without
exposing the <o:p></o:p></p>
<p class=MsoPlainText>> weakness of certain suppositions used to arrive at
the seemingly <o:p></o:p></p>
<p class=MsoPlainText>> data based results. In fact, both will assume their
viewpoint upon <o:p></o:p></p>
<p class=MsoPlainText>> the same data and it has to color the result.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Data is objective, analysis is subjective.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> It sounds to me like there is a lot of unanalyzed
data yet to be <o:p></o:p></p>
<p class=MsoPlainText>> given the "Colombo"...<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> "The /8's are too hard to get back without
fragmentation and <o:p></o:p></p>
<p class=MsoPlainText>> everyone would fight to the death to keep their
unused space. So <o:p></o:p></p>
<p class=MsoPlainText>> let's look at the remaining data"<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Colombo: "Yes, but Sir, I have just one more
question..." which is <o:p></o:p></p>
<p class=MsoPlainText>> how we get at the missed opportunity for solutions.
That's all I <o:p></o:p></p>
<p class=MsoPlainText>> want us to do.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Hope that more politely expands upon my point: We
are not in a <o:p></o:p></p>
<p class=MsoPlainText>> situation where inaction is acceptable unless it is
based upon <o:p></o:p></p>
<p class=MsoPlainText>> aggressively verified data... in other words I
suggest that ARIN <o:p></o:p></p>
<p class=MsoPlainText>> *should* contact the holders of large blocks of
unused space *anew* <o:p></o:p></p>
<p class=MsoPlainText>> and see what their feeling is about being good
corporate Internet <o:p></o:p></p>
<p class=MsoPlainText>> citizens in the face of a crisis headed towards
public attention. <o:p></o:p></p>
<p class=MsoPlainText>> Offer press releases praising them for their good
deeds, and <o:p></o:p></p>
<p class=MsoPlainText>> honorable mention at various events, and you might
be quite <o:p></o:p></p>
<p class=MsoPlainText>> surprised what a well placed call from senior
resources could <o:p></o:p></p>
<p class=MsoPlainText>> accomplish. I'm an optimist.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Of course, a stick should be behind the back that
wears that <o:p></o:p></p>
<p class=MsoPlainText>> friendly smile. I believe it should have written on
it: "The power <o:p></o:p></p>
<p class=MsoPlainText>> of the press".<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> In my opinion, ARIN can reach that stick faster than
small operators <o:p></o:p></p>
<p class=MsoPlainText>> can on our own, but we can band up and reach it if
ARIN feels bound <o:p></o:p></p>
<p class=MsoPlainText>> or otherwise unable to do so. That stick is the
data verifier we <o:p></o:p></p>
<p class=MsoPlainText>> need. I am not suggesting we fight bears, but
rather that we be <o:p></o:p></p>
<p class=MsoPlainText>> brave enough to make sure they are not just wooly
caterpillars in an <o:p></o:p></p>
<p class=MsoPlainText>> oversized (allocation) bear suit before we checkmark
those caves as <o:p></o:p></p>
<p class=MsoPlainText>> being off limits.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> Best regards,<o:p></o:p></p>
<p class=MsoPlainText>> ~Vaughn<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> -----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>> From: Brent Sweeny [mailto:sweeny@indiana.edu]<o:p></o:p></p>
<p class=MsoPlainText>> Sent: Thursday, July 23, 2009 11:09 AM<o:p></o:p></p>
<p class=MsoPlainText>> To: Vaughn Thurman - Swift Systems<o:p></o:p></p>
<p class=MsoPlainText>> Cc: arin-discuss@arin.net<o:p></o:p></p>
<p class=MsoPlainText>> Subject: Re: [arin-discuss] Good Stewardship by
example, I'd like to <o:p></o:p></p>
<p class=MsoPlainText>> RETURN a /20<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> the fact that someone has already "studied the
issue" (precisely as <o:p></o:p></p>
<p class=MsoPlainText>> you<o:p></o:p></p>
<p class=MsoPlainText>> suggest be done) and the data behind the facts of
the study disagree <o:p></o:p></p>
<p class=MsoPlainText>> with<o:p></o:p></p>
<p class=MsoPlainText>> your assumption doesn't make them a
"naysayer"; it makes them much <o:p></o:p></p>
<p class=MsoPlainText>> more<o:p></o:p></p>
<p class=MsoPlainText>> convincing, and the name-calling doesn't change the
facts nor their<o:p></o:p></p>
<p class=MsoPlainText>> inevitable conclusions. If you assert that ARIN
needs to expend <o:p></o:p></p>
<p class=MsoPlainText>> resources to<o:p></o:p></p>
<p class=MsoPlainText>> try to disprove Tony's (and Geoff's) pretty careful
analysis, it'd be<o:p></o:p></p>
<p class=MsoPlainText>> necessary to have more than that you don't like the
conclusions as a <o:p></o:p></p>
<p class=MsoPlainText>> reason:<o:p></o:p></p>
<p class=MsoPlainText>> you'd have to have some factual basis for convincing
us their <o:p></o:p></p>
<p class=MsoPlainText>> analysis is<o:p></o:p></p>
<p class=MsoPlainText>> flawed and must be redone. Absent that, we have to
be grownups, <o:p></o:p></p>
<p class=MsoPlainText>> accept the<o:p></o:p></p>
<p class=MsoPlainText>> facts, and try to use "a group this bright"
to do the best we can <o:p></o:p></p>
<p class=MsoPlainText>> with the<o:p></o:p></p>
<p class=MsoPlainText>> facts -- and move forward, not backwards.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> On 7/22/2009 8:23 PM, Vaughn Thurman - Swift Systems
wrote:<o:p></o:p></p>
<p class=MsoPlainText>>> Wow, so out come the naysayers... "Shut up
you little fleas. Don't <o:p></o:p></p>
<p class=MsoPlainText>>> you<o:p></o:p></p>
<p class=MsoPlainText>>> know that the experts have spoken? Why study the
issue when others <o:p></o:p></p>
<p class=MsoPlainText>>> have<o:p></o:p></p>
<p class=MsoPlainText>>> already said it is not worth it."<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> The power of the press and public opinion are
pretty powerful. <o:p></o:p></p>
<p class=MsoPlainText>>> Does a<o:p></o:p></p>
<p class=MsoPlainText>>> protracted battle against the interests of small
ISP types or the<o:p></o:p></p>
<p class=MsoPlainText>>> "Internet community" really suit HP,
Apple, or any of the other space<o:p></o:p></p>
<p class=MsoPlainText>>> Easters if in the public eye? Think about the
good will a few have<o:p></o:p></p>
<p class=MsoPlainText>>> gotten on this list by committing to return
space..<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> You don't get what you don't ask for.<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> Try! Aim high and risk falling short. Aiming
low is too easy to<o:p></o:p></p>
<p class=MsoPlainText>>> succeed at for a group this bright.<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> ~Vaughn<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> Sent from my handheld<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> On Jul 22, 2009, at 7:48 PM, Owen DeLong
<owen@delong.com<o:p></o:p></p>
<p class=MsoPlainText>>> <mailto:owen@delong.com>> wrote:<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>> On Jul 22, 2009, at 1:06 PM, Steve Wagner
wrote:<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> As a note it's not just the /8's. I am
in Idaho. The State of <o:p></o:p></p>
<p class=MsoPlainText>>>>> Idaho<o:p></o:p></p>
<p class=MsoPlainText>>>>> has a Class B 164.165.0.0 All State
government activities sit <o:p></o:p></p>
<p class=MsoPlainText>>>>> behind<o:p></o:p></p>
<p class=MsoPlainText>>>>> two different firewalls.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> Micron technology 137.201.0.0. Sits
behind firewalls<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> And so forth into perpetuity it seems<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> In this regard by reclaiming this
address space that companies <o:p></o:p></p>
<p class=MsoPlainText>>>>> have,<o:p></o:p></p>
<p class=MsoPlainText>>>>> particularly when the coropration sits
behind NAT firewalls is<o:p></o:p></p>
<p class=MsoPlainText>>>>> unjustified. The ones I listed above
use Private address space<o:p></o:p></p>
<p class=MsoPlainText>>>>> behind the firewall i.e. 10.X.X.X etc.
So why then would a company<o:p></o:p></p>
<p class=MsoPlainText>>>>> entity that does this need to retain
their public Class A, B, C <o:p></o:p></p>
<p class=MsoPlainText>>>>> etc.<o:p></o:p></p>
<p class=MsoPlainText>>>>> There is no technical or administrative
justification I can see.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> Nevertheless, there was a comment about
pre ARIN and Contract Law.<o:p></o:p></p>
<p class=MsoPlainText>>>>> Unfortunatley this may play the larger
role over common sense.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> While this is not the ultimate solution,
it certainly can stem the<o:p></o:p></p>
<p class=MsoPlainText>>>>> tide for many years.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> It would be an interesting study to
examine the allocated IP <o:p></o:p></p>
<p class=MsoPlainText>>>>> address<o:p></o:p></p>
<p class=MsoPlainText>>>>> space by entity and determine how many
of these organizations sit<o:p></o:p></p>
<p class=MsoPlainText>>>>> behind a NAT firewall, and only use a
small portion of their <o:p></o:p></p>
<p class=MsoPlainText>>>>> allocation.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>> Reclamation has been repeatedly studied,
and, in general, the<o:p></o:p></p>
<p class=MsoPlainText>>>> conclusion matches the following excerpt
from a Cisco Journal <o:p></o:p></p>
<p class=MsoPlainText>>>> article:<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>
<http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html
<o:p></o:p></p>
<p class=MsoPlainText>>>>
>http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> Reclaiming Allocations<o:p></o:p></p>
<p class=MsoPlainText>>>>> Another debate occasionally resurfaces
about reclaiming some of the<o:p></o:p></p>
<p class=MsoPlainText>>>>> early allocations to further extend the
lifetime of IPv4. Hopefully<o:p></o:p></p>
<p class=MsoPlainText>>>>> this article has shown that the ROI for
that approach is going to <o:p></o:p></p>
<p class=MsoPlainText>>>>> be<o:p></o:p></p>
<p class=MsoPlainText>>>>> extremely low. Discussions around the
Internet community show there<o:p></o:p></p>
<p class=MsoPlainText>>>>> is an expectation that it will take
several years of substantive<o:p></o:p></p>
<p class=MsoPlainText>>>>> negotiation (in multiple court systems
around the globe) to <o:p></o:p></p>
<p class=MsoPlainText>>>>> retrieve<o:p></o:p></p>
<p class=MsoPlainText>>>>> any /8s. Then following that effort and
expense, the likelihood of<o:p></o:p></p>
<p class=MsoPlainText>>>>> even getting back more than a few /8
blocks is very low. Following<o:p></o:p></p>
<p class=MsoPlainText>>>>> the allocation growth trend, after
several years of litigation the<o:p></o:p></p>
<p class=MsoPlainText>>>>> result is likely to be just a few months
of additional resource <o:p></o:p></p>
<p class=MsoPlainText>>>>> added<o:p></o:p></p>
<p class=MsoPlainText>>>>> to the pool—and possibly not even a
whole month. All this assumes<o:p></o:p></p>
<p class=MsoPlainText>>>>> IANA does not completely run out before
getting any back, because<o:p></o:p></p>
<p class=MsoPlainText>>>>> running out would result in pentup
demand that could immediately<o:p></o:p></p>
<p class=MsoPlainText>>>>> exhaust any returns.<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>> If you can come up with credible figures
indicating that there are <o:p></o:p></p>
<p class=MsoPlainText>>>> at<o:p></o:p></p>
<p class=MsoPlainText>>>> least 28 /8s worth of reclaimable space out
there, then, reclamation<o:p></o:p></p>
<p class=MsoPlainText>>>> efforts might be more interesting, but, I
tend to doubt that is the<o:p></o:p></p>
<p class=MsoPlainText>>>> case. If you can't reclaim at least 14 /8s,
you don't even buy an<o:p></o:p></p>
<p class=MsoPlainText>>>> additional year.<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>> Owen<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> Regards,<o:p></o:p></p>
<p class=MsoPlainText>>>>> Steve Wagner<o:p></o:p></p>
<p class=MsoPlainText>>>>> Vice President of Operations<o:p></o:p></p>
<p class=MsoPlainText>>>>> Syringa Networks, LLC<o:p></o:p></p>
<p class=MsoPlainText>>>>> 3795 S Development Ave, Suite 100<o:p></o:p></p>
<p class=MsoPlainText>>>>> Boise, ID 83705<o:p></o:p></p>
<p class=MsoPlainText>>>>> Office: 208.229.6104<o:p></o:p></p>
<p class=MsoPlainText>>>>> Main: 208.229.6100<o:p></o:p></p>
<p class=MsoPlainText>>>>> Emergency: 1.800.454.7214<o:p></o:p></p>
<p class=MsoPlainText>>>>> Fax: 208.229.6110<o:p></o:p></p>
<p class=MsoPlainText>>>>> Email:<o:p></o:p></p>
<p class=MsoPlainText>>>>>
<mailto:Stwagner@syringanetworks.net>Stwagner@syringanetworks.net<o:p></o:p></p>
<p class=MsoPlainText>>>>>
<mailto:Stwagner@syringanetworks.net><o:p></o:p></p>
<p class=MsoPlainText>>>>> Web:
<http://www.syringanetworks.net>www.syringanetworks.net<o:p></o:p></p>
<p class=MsoPlainText>>>>> <http://www.syringanetworks.net><o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> "Idaho's Premier Fiber Optic
Network"<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> Privilege and Confidentiality Notice<o:p></o:p></p>
<p class=MsoPlainText>>>>> The information in this message is
intended for the named <o:p></o:p></p>
<p class=MsoPlainText>>>>> recipients<o:p></o:p></p>
<p class=MsoPlainText>>>>> only. It may contain information that is
privileged, confidential <o:p></o:p></p>
<p class=MsoPlainText>>>>> or<o:p></o:p></p>
<p class=MsoPlainText>>>>> otherwise protected from disclosure. If
you are not the intended<o:p></o:p></p>
<p class=MsoPlainText>>>>> recipient, you are hereby notified that
any disclosure, copying,<o:p></o:p></p>
<p class=MsoPlainText>>>>> distribution, or the taking of any
action in reliance on the <o:p></o:p></p>
<p class=MsoPlainText>>>>> contents<o:p></o:p></p>
<p class=MsoPlainText>>>>> of this message is strictly prohibited.
If you have received this<o:p></o:p></p>
<p class=MsoPlainText>>>>> e-mail in error, do not print it or
disseminate it or its contents.<o:p></o:p></p>
<p class=MsoPlainText>>>>> In such event, please notify the sender
by return e-mail and delete<o:p></o:p></p>
<p class=MsoPlainText>>>>> the e-mail file immediately thereafter.
Thank you.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> -----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>>>>> From: arin-discuss-bounces@arin.net<o:p></o:p></p>
<p class=MsoPlainText>>>>>
<mailto:arin-discuss-bounces@arin.net> [<o:p></o:p></p>
<p class=MsoPlainText>>>>>
<mailto:arin-discuss-bounces@arin.net>mailto:arin-discuss- <o:p></o:p></p>
<p class=MsoPlainText>>>>> bounces@arin.net]<o:p></o:p></p>
<p class=MsoPlainText>>>>> On Behalf Of John Osmon<o:p></o:p></p>
<p class=MsoPlainText>>>>> Sent: Wednesday, July 22, 2009 1:43 PM<o:p></o:p></p>
<p class=MsoPlainText>>>>> To:
<mailto:arin-discuss@arin.net>arin-discuss@arin.net<o:p></o:p></p>
<p class=MsoPlainText>>>>> <mailto:arin-discuss@arin.net><o:p></o:p></p>
<p class=MsoPlainText>>>>> Subject: Re: [arin-discuss] Good
Stewardship by example, I'd like <o:p></o:p></p>
<p class=MsoPlainText>>>>> to<o:p></o:p></p>
<p class=MsoPlainText>>>>> RETURN a /20<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> On Wed, Jul 22, 2009 at 01:32:19PM
-0400, Joe Maimon wrote:<o:p></o:p></p>
<p class=MsoPlainText>>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>>> John Osmon wrote:<o:p></o:p></p>
<p class=MsoPlainText>>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>>>> We're aren't going to save the
IPv4 world by returning space, but<o:p></o:p></p>
<p class=MsoPlainText>>>>>>> we *will* make it easier on soe
folks that are coming to the <o:p></o:p></p>
<p class=MsoPlainText>>>>>>> table<o:p></o:p></p>
<p class=MsoPlainText>>>>>>> (relatively) late.<o:p></o:p></p>
<p class=MsoPlainText>>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>>> Hate to be a downer, but not at the
current burn rate.<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> Actually, I agree -- but don't tell the
folks that think getting<o:p></o:p></p>
<p class=MsoPlainText>>>>> a couple of /8s back from HP, Apple, and
the DOD is going to <o:p></o:p></p>
<p class=MsoPlainText>>>>> significant<o:p></o:p></p>
<p class=MsoPlainText>>>>> difference in the timing of IPv4
exhaustion. :-)<o:p></o:p></p>
<p class=MsoPlainText>>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>> I still think that anything you aren't
using should go back to the<o:p></o:p></p>
<p class=MsoPlainText>>>>> pool that allows new comers a chance to
participate in<o:p></o:p></p>
<p class=MsoPlainText>>>>> commerce/communication. I don't,
however, think that a slew of<o:p></o:p></p>
<p class=MsoPlainText>>>>> /20s (or /8s) are going to make a big
impact.<o:p></o:p></p>
<p class=MsoPlainText>>>>>
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>>>>> ARIN-Discuss<o:p></o:p></p>
<p class=MsoPlainText>>>>> You are receiving this message because you
are subscribed to<o:p></o:p></p>
<p class=MsoPlainText>>>>> the ARIN Discussion Mailing List (<o:p></o:p></p>
<p class=MsoPlainText>>>>>
<mailto:ARIN-discuss@arin.net>ARIN-discuss@arin.net<o:p></o:p></p>
<p class=MsoPlainText>>>>> <mailto:ARIN-discuss@arin.net>).<o:p></o:p></p>
<p class=MsoPlainText>>>>> Unsubscribe or manage your mailing list
subscription at:<o:p></o:p></p>
<p class=MsoPlainText>>>>> <http://lists.arin.net/mailman/listinfo/arin-discuss>http://lists.arin.net/mailman/listinfo/arin-discuss<o:p></o:p></p>
<p class=MsoPlainText>>>>> Please contact info@arin.net
<mailto:info@arin.net> if you <o:p></o:p></p>
<p class=MsoPlainText>>>>> experience<o:p></o:p></p>
<p class=MsoPlainText>>>>> any issues.<o:p></o:p></p>
<p class=MsoPlainText>>>>>
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>>>>> ARIN-Discuss<o:p></o:p></p>
<p class=MsoPlainText>>>>> You are receiving this message because
you are subscribed to<o:p></o:p></p>
<p class=MsoPlainText>>>>> the ARIN Discussion Mailing List
(ARIN-discuss@arin.net<o:p></o:p></p>
<p class=MsoPlainText>>>>> <mailto:ARIN-discuss@arin.net>).<o:p></o:p></p>
<p class=MsoPlainText>>>>> Unsubscribe or manage your mailing list
subscription at:<o:p></o:p></p>
<p class=MsoPlainText>>>>> http://lists.arin.net/mailman/listinfo/arin-discuss<o:p></o:p></p>
<p class=MsoPlainText>>>>> Please contact info@arin.net if you
experience any issues.<o:p></o:p></p>
<p class=MsoPlainText>>>><o:p> </o:p></p>
<p class=MsoPlainText>>>>
_______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>>>> ARIN-Discuss<o:p></o:p></p>
<p class=MsoPlainText>>>> You are receiving this message because you
are subscribed to<o:p></o:p></p>
<p class=MsoPlainText>>>> the ARIN Discussion Mailing List
(ARIN-discuss@arin.net<o:p></o:p></p>
<p class=MsoPlainText>>>> <mailto:ARIN-discuss@arin.net>).<o:p></o:p></p>
<p class=MsoPlainText>>>> Unsubscribe or manage your mailing list
subscription at:<o:p></o:p></p>
<p class=MsoPlainText>>>>
http://lists.arin.net/mailman/listinfo/arin-discuss<o:p></o:p></p>
<p class=MsoPlainText>>>> Please contact info@arin.net <mailto:info@arin.net>
if you <o:p></o:p></p>
<p class=MsoPlainText>>>> experience<o:p></o:p></p>
<p class=MsoPlainText>>>> any issues.<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> --- <o:p></o:p></p>
<p class=MsoPlainText>>>
---------------------------------------------------------------------<o:p></o:p></p>
<p class=MsoPlainText>>><o:p> </o:p></p>
<p class=MsoPlainText>>> _______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>>> ARIN-Discuss<o:p></o:p></p>
<p class=MsoPlainText>>> You are receiving this message because you are
subscribed to<o:p></o:p></p>
<p class=MsoPlainText>>> the ARIN Discussion Mailing List
(ARIN-discuss@arin.net).<o:p></o:p></p>
<p class=MsoPlainText>>> Unsubscribe or manage your mailing list
subscription at:<o:p></o:p></p>
<p class=MsoPlainText>>>
http://lists.arin.net/mailman/listinfo/arin-discuss<o:p></o:p></p>
<p class=MsoPlainText>>> Please contact info@arin.net if you experience
any issues.<o:p></o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>><o:p> </o:p></p>
<p class=MsoPlainText>> _______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>> ARIN-Discuss<o:p></o:p></p>
<p class=MsoPlainText>> You are receiving this message because you are
subscribed to<o:p></o:p></p>
<p class=MsoPlainText>> the ARIN Discussion Mailing List
(ARIN-discuss@arin.net).<o:p></o:p></p>
<p class=MsoPlainText>> Unsubscribe or manage your mailing list subscription
at:<o:p></o:p></p>
<p class=MsoPlainText>> http://lists.arin.net/mailman/listinfo/arin-discuss<o:p></o:p></p>
<p class=MsoPlainText>> Please contact info@arin.net if you experience any
issues.<o:p></o:p></p>
</div>
</body>
</html>