<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
John,<br>
<br>
John Curran wrote:
<blockquote cite="mid:5196084E-5CD0-490F-AD42-0C791E8528E5@arin.net"
type="cite">
<div>
<div>On Feb 5, 2010, at 9:23 AM, Bob Atkins wrote:</div>
</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">Generally, I am pleased with
the IPv6 allocation fees being waived currently - it is quite simply
why we applied for an IPv6 block. However, when I look at what is being
proposed for IPv6 address charges - they are outrageous when you take
into consideration that IPv6 is a virtually unlimited resource. IPv6 is
a license for ARIN to print money. We are all going to be operating
with IPv4 and IPv6 address space for a <i><u><b>long</b></u></i> time -
that very fact will substantially increase ARIN's revenue based on the
current fee structure. As a small ISP I find this very fact very
troubling. Just as the market is eating itself alive from competitive
pressure - when we must spend more in ARIN fees, equipment and training
to deploy IPv6 and it will be virtually impossible to for us to recover
any additional revenue from the use and delegation (to our customers)
of IPv6 space. ARIN is maintaining what I call an IPv4 <i><u><b>scarcity</b></u></i> fee
structure for IPv6 space which is totally at odds with the monumental
amount of address space that is available.<br>
</div>
</blockquote>
<div><br>
</div>
Given the size of the IPv6 allocations, and present need-basis </div>
<div>requirements that must be assessed before an *additional* </div>
<div>allocation, it is quite likely that an ISP that comes in with an </div>
<div>*additional* allocation request would presently need to supply </div>
<div>a very significant amount of documentation that would need</div>
<div>to be reviewed. I'm not saying this is "good" or "bad", but </div>
<div>simply reflects what actions ARIN will need to take based on </div>
<div>present policy. If this is recovered via ongoing fee schedule,</div>
<div>then everyone will pay their share regardless of whether they</div>
<div>make additional IPv6 requests or not. If it is
transaction-based,</div>
<div>then just the party asking for the additional block will be
paying</div>
<div>for those costs.</div>
</blockquote>
Given the enormous amount of IPv6 address space that is available I
don't understand why there would be the need for a rigorous, IPv4 level
of review, which you seem to imply the need for a significant amount of
staff to handle such reviews. I would think that basic delegation
analysis would likely suffice and I do understand that some personnel
are necessary. However, its not like doling out another /32 to /22 IPv6
allocation is going to have much of an impact on the reserves of IPv6
space.<br>
<br>
With our /32 IPv6 allocation, I don't expect to need another IPv6
allocation until we have grown about 1000 times larger than we are
which, (sadly) is unlikely to occur in my lifetime. :-( I suspect that
this would be the case for virtually all regional ISPs the world over
leaving just a handful of very large telcos that may need another
allocation after their initial /22 - perhaps by the year 2150... ;-)<br>
<br>
Given the existing 'standard' that almost 99% of enterprise customers
have of using NAT for IPv4 based on the 'security' benefits that NAT
offers - we rarely assign much more than a /29 of IPv4 space to our
enterprise customers. The typical IT geek is often horrified by the
idea of having 'real' IP address space internally. While we ISPs are
being asked to head down the IPv6 path, I find it likely that we may
end up using <u><i><b>microscopic</b></i></u><i><u><b></b></u></i>
amounts of it assigned to customer router interfaces that just want to
NAT everything internally to private IPv4 space. I don't think I'm
alone in this observation and I really think that it may be <i><u><b>decades</b></u></i>
before IPv6 utilization rises to the level of present day IPv4
utilization so I kinda doubt there are going to be very many additional
IPv6 allocation requests any time in the next say, 20 or 30 years.<br>
<blockquote cite="mid:5196084E-5CD0-490F-AD42-0C791E8528E5@arin.net"
type="cite">
<div>
<div bgcolor="#ffffff" text="#000000"><br>
</div>
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">IPv6 fees for a /32 should be
about $100/year - at most! Larger blocks could be sold on an economy of
scale basis rather than a linear multiplier of the cost of a /32 block.
The entire process should be fully automated - requiring minimal
support staff. An even better solution would be to create some
competition in the IPv6 address management arena by allowing the
existence of multiple IPv6 registrars in the same way that is done for
domain names.<br>
</div>
</blockquote>
<br>
</div>
<div>One of the reasons that ARIN is investing significantly </div>
<div>in automation is precisely to aim for lower costs (and </div>
<div>hence lower fees) for those items which can be </div>
<div>automated. The current roadmap is available online </div>
<div>here: <<a moz-do-not-send="true"
href="https://www.arin.net/knowledge/roadmap.html">https://www.arin.net/knowledge/roadmap.html</a>> </div>
<div>Automation of maintenance will go far in reducing the</div>
<div>ongoing costs and allowing fee schedules which meet</div>
<div>expectations of the community.</div>
</blockquote>
Thanks - its good to see this happening.<br>
<blockquote cite="mid:5196084E-5CD0-490F-AD42-0C791E8528E5@arin.net"
type="cite">
<div><br>
</div>
<div>/John</div>
<div><br>
</div>
<div>John Curran</div>
<div>President and CEO</div>
<div>ARIN</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<table border="0" cellpadding="2" cellspacing="0" width="569">
<tbody>
<tr bgcolor="#000099" valign="middle">
<td colspan="2"><font color="#ffffff"
face="Verdana, Arial, Helvetica, sans-serif" size="2"><strong>Bob
Atkins </strong></font><font color="#ffffff"> </font></td>
</tr>
<tr valign="middle">
<td colspan="2"><font face="Verdana, Arial, Helvetica, sans-serif"
size="1"><em>President/CEO</em></font></td>
</tr>
<tr valign="middle">
<td width="233">
<p align="center"><font
face="Verdana, Arial, Helvetica, sans-serif" size="1"><b><font
color="#000080"><span
style="font-weight: bold; font-family: Trebuchet MS;"><a
href="http://www.digilink.net"><img
src="cid:part1.04030402.07090403@digilink.net" alt="DigiLink, Inc."
style="border: 0px solid ; width: 216px; height: 48px;"></a></span></font></b><br>
<font color="#006600">Business Inter-net-working</font><br>
<font color="#000099"><strong><em>The Cure for the Common ISP!</em></strong></font></font></p>
</td>
<td width="328">
<p align="right"><font color="#666666"
face="Verdana, Arial, Helvetica, sans-serif" size="1">Phone: </font><font
face="Verdana, Arial, Helvetica, sans-serif" size="1">(310) 577-9450<br>
</font><font color="#666666"
face="Verdana, Arial, Helvetica, sans-serif" size="1">Fax: </font><font
face="Verdana, Arial, Helvetica, sans-serif" size="1">(310) 577-3360</font><font
face="Verdana, Arial, Helvetica, sans-serif" size="1"><br>
<font color="#666666">eMail:</font> <a class="moz-txt-link-abbreviated" href="mailto:bob@digilink.net">bob@digilink.net</a><br>
</font></p>
</td>
</tr>
</tbody>
</table>
<p> </p>
</div>
</body>
</html>