<div dir="ltr">I would be opposed to a flat out cap that allows requests under a <div>certain size to not require need and requests over that size to require </div><div>need.<div><br></div><div style>This is an unfair burden to organizations who require lots of address </div>

<div style>space for growth.</div><div style>  <br></div><div style>Consider a small rural residential ISP, with a /22.</div><div style>- This ISP is using a single /24 for loopback, point-to-point, </div><div style>management network, and corporate network.</div>

<div style><br></div><div style>- This IPS has 615 customers each with a single IPv4 address.</div><div style><br></div><div style>- This ISP has seen fairly linear growth of 600 customers every two years.</div><div style>

<br></div><div style>In 6 months they will exhaust their currently held space.</div><div style>They already qualify for another /22.</div><div style>Once they get this additional /22 that gives them addresses to cover 4 years.</div>

<div style>(/22 is about 3.4 years of customer + 6 months current available)</div><div style><br></div><div style>A /12 represents 6,990 years worth of address space</div><div style>A /16 represents 218 years of address space</div>

<div style>A /20 represents 13.5 years of address space</div><div style><br></div><div style>Should small organizations be able to by a virtually unlimited amount of </div><div style>address if they can afford it?</div><div style>

<br></div><div style>Should a large organization (who can demonstrate need) only be permitted</div><div style>to buy two years worth of address space?</div><div style><br></div><div style>In this example a /22 provides a 4 year window, I would argue that needs </div>

<div style>based transfers for larger than a /22 would need to support a 4 year window</div><div style>for fairness.</div><div style><br></div><div style>Remember the community discussed how much (in units of time) an organization</div>

<div style>should be able to purchase.  The though was two years should be reasonably </div><div style>long for an organization who did not plan for IPv6 deployment to get one more </div><div style>allocation, and still deploy IPv6 before running out.  </div>

<div style><br></div><div style>If all organizations deployed IPv6 in a serious way in the next two years, the IPv4 </div><div style>depletion problem would essentially be solved.</div><div style><br></div><div style>The problem is the community as a whole has failed to deploy IPv6 in a timely </div>

<div style>fashion.  This is because it has real costs, and generates no new products, services,</div><div style>or revenue.  Corporations have been short sighted in their investments, and have </div><div style>concluded that then only need to deploy IPv6 just before their organization runs out</div>

<div style>of IPv4 (that is the orgs that are paying attention and planning for IPv6).  Since </div><div style>everyone runs out at different times, you can't move to IPv6-only until a critical mass</div><div style>of organizations has already run out and embraced IPv6 in a real way.</div>

<div style><br></div><div style>Organizations have also realized they only have to do native IPv4 for shortly longer </div><div style>than their competitors then they can force all new customers into some sort of </div><div style>

provider based large scale NAT (CGN 444 + IPv6 / GCN 644).</div><div style><br></div><div style>So now people are bracing for a slow and painful transition to IPv6.</div><div style><br></div><div style>Never mind anti-competitive behavior of cornoring the market on IPv4 addresses,</div>

<div style>think about reasonable players the feel the need to stockpile enough addresses</div><div style>to continue doing native IPv4 longer than their competition in order to not loose </div><div style>their customer base to competitors who can offer a better native IPv4 product when</div>

<div style>you can't.</div><div style><br></div><div style>Which means getting years worth of IPv4 space...</div><div style>Which means we are not going to run out...</div><div style>Which means we can continue to save by deferring the cost</div>

<div style>of deploying IPv6...</div><div style>Which menas buying more space...</div><div style>(if we are not ready to deploy IPv6  buy two more years worth)</div><div style>(or if the industry hasn't embraced IPv6 in a real way buy enough to last until it has)</div>

<div style><br></div><div style><br></div><div style>If you are looking to make needs justification easier then maybe something like:</div><div style>- any org can transfer a single /22 no need required</div><div style>- any org can transfer up to four times the amount of address rounded to </div>

<div style>nearest CIDR utilized in the last year</div><div style>   * (jan 1, had 14 M addresses in use, dec 31 had  17M) 3M = /20 qualify for /18</div><div style>- any org who transfered a /22 can get an additional /22 when the current one is 80% </div>

<div style>utilized even if they have utilized less than a 513 addresses in the last year</div><div style>   *( jan 1 had 711 addresses, dec 31 had 820) 109 = /25 </div><div style><br></div><div style>But agin the community will have to accept a four year window, which will likely do </div>

<div style>bad things to IPv6 deployment.  If you made the threshold a /23, then you could keep </div><div style>the two year window... but they why not just go to RIPE or APNIC and get a /22 from</div><div style>the soft landing policy?</div>

<div style><br></div><div style>___Jason</div><div style><br></div><div style><br></div><div style><br></div><div style> </div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div></div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 13, 2013 at 10:17 AM, Mike Burns <span dir="ltr"><<a href="mailto:mike@nationwideinc.com" target="_blank">mike@nationwideinc.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div style="font-size:12pt;font-family:'Calibri'">
<div>Hi Brian,</div>
<div> </div>
<div>Thanks for your thoughts. </div>
<div>No doubt a more vigorous transfer market will lead to more router 
misconfigurations.</div>
<div>I think a knowledgeable middle-man could help mitigate that, and would take 
business from the guy getting into the game without networking knowledge you 
mention below.</div>
<div> </div>
<div>There is real uncertainty when dealing with the registries. A recent 
transaction took nearly a month to complete, most of which was spent in the back 
and forth of a justification. It’s always a fingers-crossed situation for buyer 
and seller. One broker told me she does the “happy dance” every time a deal 
makes it through justification.</div>
<div> </div>
<div>Your point about moving to IPv6 is important, because that move is the 
800lb gorilla in the room.</div>
<div>Nobody knows when the move will happen or  how long it will take, but 
when it happens it is bound to affect IPv4 prices negatively.</div>
<div>Who would speculate under these conditions?  </div>
<div>What if we limited his total purchases to a /12, or his aggregate holdings 
to a /12, otherwise he would be needs-tested?</div>
<div> </div>
<div>Regards,</div>
<div>Mike</div>
<div> </div>
<div> </div>
<div> </div>
<div style="font-size:small;font-style:normal;text-decoration:none;font-family:'Calibri';display:inline;font-weight:normal">
<div style="FONT:10pt tahoma">
<div><font size="3" face="Calibri"></font> </div>
<div style="BACKGROUND:#f5f5f5">
<div><b>From:</b> <a title="bjones@vt.edu" href="mailto:bjones@vt.edu" target="_blank">Brian Jones</a> </div>
<div><b>Sent:</b> Thursday, June 13, 2013 9:30 AM</div>
<div><b>To:</b> <a title="mike@nationwideinc.com" href="mailto:mike@nationwideinc.com" target="_blank">Mike Burns</a> </div>
<div><b>Cc:</b> <a title="mike@iptrading.com" href="mailto:mike@iptrading.com" target="_blank">Mike Burns</a> ; <a title="arin-ppml@arin.net" href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a> </div>

<div><div class="h5">
<div><b>Subject:</b> Re: [arin-ppml] A Redefinition of IPv4 Need post 
ARINrun-out(was:Re:Against2013-4)</div></div></div></div></div>
<div> </div></div><div><div class="h5">
<div style="font-size:small;font-style:normal;text-decoration:none;font-family:'Calibri';display:inline;font-weight:normal">Mike,<br clear="all">See inline comments.<br><br>
<div class="gmail_quote">On Wed, Jun 12, 2013 at 10:05 PM, Mike Burns <span dir="ltr"><<a href="mailto:mike@nationwideinc.com" target="_blank">mike@nationwideinc.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><u></u>
  <div bgcolor="#ffffff">
  <div><font face="Arial">Hi Brian,</font></div>
  <div><font face="Arial"></font> </div>
  <div><font face="Arial">I understand that there is a danger of overpurchasing 
  (by whomever's definition) that comes from the removal of a needs test for 
  transfers.</font></div>
  <div><font face="Arial">In most cases we rely on the price of the addresses to 
  provide some check on this practice, as it would for the overpurchasing of any 
  other asset a corporation may choose to invest in. </font><font face="Arial">I 
  think we should leave those definition of what an overpurchase is to the 
  buyers, who will have a range of intended purposes, projected growth rates, 
  planning horizons and other considerations. At least with a cap of some sort 
  we limit the overpurchase risk to overall address usage 
  efficiency.</font></div>
  <div><font face="Arial"></font> </div>
  <div><font face="Arial">A vibrant market is one of the best mechanisms to 
  prevent what you mention-the problem of addresses sitting idle while real need 
  exists.</font></div></div></blockquote>
<div><br><br>At the risk of contradicting myself, I'm not sure a vibrant market 
is the <i>best </i>answer for the networking community, but I don't disagree 
that what you propose would invigorate the market. See my comments below about 
network stability.<br><br> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
  <div bgcolor="#ffffff">
  <div><font face="Arial">As the price of addresses rise and transactional 
  roadblocks diminish, idle addresses will come into the market. As the need 
  rises, the price will rise, driving efficiencies in the utilization of 
  addresses and wringing the most efficiency through the highest and best use of 
  the addresses.</font></div></div></blockquote>
<div><br>I would agree that as demand rises the prices will increase, but maybe, 
just maybe most folks will be considering the move to IPv6 where these 
contentions and price increases will not exist.<br> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
  <div bgcolor="#ffffff">
  <div><font face="Arial"></font> </div>
  <div><font face="Arial"></font><font face="Arial"></font><font face="Arial">And as I 
  mentioned, due to the needs test requirement, these early IPv4 address 
  transactions almost always involve neophyte parties on either side of the 
  transaction, separated by language, culture, and an ocean. Often these parties 
  are not familiar with their own RIR policy, much less the policy of another 
  region. Most of the time the decision to sell or buy addresses has to overcome 
  corporate inertia and antipathy to new, unusual, and unlikely-to-be-repeated 
  transactions. This means education about the RIRs and their position squarely 
  in the middle of the buyer and the seller.</font></div>
  <div><font face="Arial"></font> </div>
  <div><font face="Arial">How likely is this transaction to occur for small 
  allocations like the /24 needed by Mr. Ryerse of this thread?</font></div>
  <div><font face="Arial"></font> </div>
  <div><font face="Arial">I contend that removing the needs requirement will allow 
  for less uncertainty in what is currently a fraught process for both buyers 
  and sellers, leading to more transactions, more price stability, and simpler 
  transactions for all parties, including ARIN, who will avoid the time and 
  effort of needs testing transfers.</font></div>
  <div><font face="Arial"></font> </div></div></blockquote>
<div><br>I appreciate your contention, and it is possible that some of the 
things you mention may actually pan out, but I do not agree with the "less 
uncertainty" part of your statement. I would contend removing all needs 
assessment would create more uncertainty by promoting that anyone can get in the 
game of brokering IP addresses regardless of their knowledge about networking. 
Also by increasing the amount of times IP addresses get swapped around the 
Internet could increase the possibility for networking instability and router 
misconfiguration issues. <br><br>--<br>Brian<br><br> </div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
  <div bgcolor="#ffffff">
  <div><font face="Arial">Regards,</font></div>
  <div><font face="Arial">Mike</font></div>
  <div><font face="Arial"></font> </div>
  <div><font face="Arial"></font> </div>
  <div><font face="Arial"></font> </div>
  <blockquote style="BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px" dir="ltr">
    <div>
    <div style="FONT:10pt arial">----- Original Message ----- </div>
    <div style="FONT:10pt arial;BACKGROUND:#e4e4e4"><b>From:</b> <a title="bjones@vt.edu" href="mailto:bjones@vt.edu" target="_blank">Brian 
    Jones</a> </div>
    <div style="FONT:10pt arial"><b>To:</b> <a title="mike@iptrading.com" href="mailto:mike@iptrading.com" target="_blank">Mike Burns</a> </div></div>
    <div>
    <div>
    <div style="FONT:10pt arial"><b>Cc:</b> <a title="arin-ppml@arin.net" href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a> ; <a title="mike@nationwideinc.com" href="mailto:mike@nationwideinc.com" target="_blank">Mike Burns</a> </div>


    <div style="FONT:10pt arial"><b>Sent:</b> Wednesday, June 12, 2013 9:28 
    PM</div>
    <div style="FONT:10pt arial"><b>Subject:</b> Re: [arin-ppml] A Redefinition 
    of IPv4 Need post ARINrun-out(was:Re:Against 2013-4)</div>
    <div> </div>
    <p>Hi Mike, </p>
    <p>I suppose it is just my old school thinking that you should be at least 
    "this tall" to ride the ride. Given your explanations below I could relax my 
    requirements for demonstrating technical support need for transfers. I 
    actually didn't realize we were only considering transfers and not the 
    remaining free blocks, so thank you for clarifying that. </p>
    <p>It still seems that inefficient use of address space could occur when a 
    bidder buys much larger blocks than needed due to the lack of any structured 
    needs requirements. At a minimum a block of addresses could sit idle and 
    unused while needs exists elsewhere. But really IPv6 should be the best 
    solution for those needing addresses moving forward any way... :) </p>
    <p>Brian <br></p>
    <p>On Jun 12, 2013 3:15 PM, "Mike Burns" <<a href="mailto:mike@iptrading.com" target="_blank">mike@iptrading.com</a>> 
    wrote:<br>><br>> Hi Brian,<br>>  <br>> Thanks for your 
    input.<br>>  <br>> May I ask why you think there should be a 
    requirement for demonstration of minimal technical need for transfers, if 
    the reason is not to prevent hoarding and price manipulation?<br>>  
    <br>> Remember we are talking only about transfers, and not the 
    intelligent allocation of the remaining IPv4 free pool, and that money will 
    be the determining factor in who receives IPv4 addresses under the current 
    transfer policy, so long as the needs test is met. That is, we are already 
    at a point where the highest bidder will get the addresses, irrespective of 
    what his justified need for the addresses is, just that he has met the RIR 
    need test.<br>>  <br>> I have been operating under the assumption 
    that the underlying reason for requiring the needs test for transfers which 
    are already priced is to prevent a buyer without needs from damaging the 
    market through hoarding or cornering. I understand that many people simply 
    do not like the idea that address blocks can be bought and sold, and that 
    money has any influence on who gets addresses, but we are beyond that 
    now.<br>>  <br>> Regards,<br>> Mike<br>>  
    <br>>  <br>> From: Brian Jones<br>> Sent: Wednesday, June 12, 
    2013 2:54 PM<br>> To: Mike Burns<br>> Cc: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>> Subject: Re: [arin-ppml] A 
    Redefinition of IPv4 Need post ARIN run-out(was:Re:Against 
    2013-4)<br>>  <br>><br>> Maybe that was utopian thinking on my 
    part. It would be nice to disregard what happens with IPv4 space but that 
    seems to invite some sort of chaos and the last thing needed is more 
    chaos...<br>><br>> Intelligent allocation of the remaining IPv4 space 
    is important in my opinion.<br>><br>> From Dave Farmer's email 
    earlier:<br>> "I think the more important issue is an appropriate 
    criteria on the lower-end and for new enterants, the current slow-start for 
    IPv4 isn't going to work, post-ARIN free pool.  Yes, I know eliminating 
    need alltogether eliminates that problem, but I'm not sure I can get myself 
    all the way there.  I'd like to see some minimal technical criteria 
    that entitles someone to be able to buy up to between a /16 and a /12 and 
    more than just that they have the money to do so.  Maybe its just as 
    simple as demonstrating efficient use of at least a /24.  If you can't 
    do that then you can only buy a /24, then you utilize it and you qualify for 
    bigger blocks. "<br>><br>> Regardless of whether the size blocks 
    discussed is agreeable or not, I do agree wth the part about the need for 
    "...minimal technical criteria that entitles someone to be able to buy up to 
    between a /16 and a /12 and more than just that they have the money to do 
    so."<br>><br>> (Of course I support the idea that we all move to 
    IPv6!) :)<br>><br>> --<br>> Brian<br>><br>><br>> On Wed, 
    Jun 12, 2013 at 11:20 AM, Mike Burns <<a href="mailto:mike@nationwideinc.com" target="_blank">mike@nationwideinc.com</a>> wrote:<br>>><br>>> 
    Hi Brian, Matthew, and Martin,<br>>>  <br>>> Can I take 
    your plus ones to indicate support of the cap even in the face of the shell 
    company issue?<br>>> (As well as support of the idea that we should 
    all move to IPv6.)<br>>>  <br>>> Regards,<br>>> 
    Mike<br>>>  <br>>>  <br>>> From: Brian 
    Jones<br>>> Sent: Wednesday, June 12, 2013 11:03 AM<br>>> To: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>>> Subject: Re: [arin-ppml] A 
    Redefinition of IPv4 Need post ARIN run-out (was:Re:Against 
    2013-4)<br>>>  <br>>>  <br>>>  
    <br>>>  <br>>>  <br>>> On Tue, Jun 11, 2013 at 
    10:42 PM, Martin Hannigan <<a href="mailto:hannigan@gmail.com" target="_blank">hannigan@gmail.com</a>> 
    wrote:<br>>>><br>>>> On Tue, Jun 11, 2013 at 10:24 PM, 
    cb.list6 <<a href="mailto:cb.list6@gmail.com" target="_blank">cb.list6@gmail.com</a>> 
    wrote:<br>>>>><br>>>>><br>>>>> On Jun 
    11, 2013 7:15 PM, "Matthew Kaufman" <<a href="mailto:matthew@matthew.at" target="_blank">matthew@matthew.at</a>> wrote:<br>>>>> 
    ><br>>>>> > When will we start caring about IPv6 and start 
    ignoring IPv4??? Who cares if people set up shells to acquire v4 space from 
    others? Let 'em, and get v6 deployed already.<br>>>>> 
    ><br>>>>><br>>>>> 
    +1<br>>>>><br>>>>> 
    CB<br>>>><br>>>><br>>>> 
    +1<br>>>><br>>>> Best,<br>>>><br>>>> 
    -M<br>>>><br>>>><br>>><br>>><br>>> 
    +1<br>>><br>>> --<br>>> 
    Brian<br>>><br>>>  
    <br>>>><br>>>><br>>>> 
    _______________________________________________<br>>>> 
    PPML<br>>>> You are receiving this message because you are 
    subscribed to<br>>>> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>>>> Unsubscribe or manage 
    your mailing list subscription at:<br>>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>>>> 
    Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any 
    issues.<br>>><br>>>  <br>>> 
    ________________________________<br>>> 
    _______________________________________________<br>>> PPML<br>>> 
    You are receiving this message because you are subscribed to<br>>> the 
    ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>>> Unsubscribe or manage 
    your mailing list subscription at:<br>>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>>> 
    Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any 
    issues.<br>><br>>  
</p></div></div></blockquote></div></blockquote></div>
<div> </div></div></div></div></div></div></div>
<br>_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><font color="#555555" face="'courier new', monospace"><div>

<span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div>

<div><font face="'courier new', monospace"><br></font></div></span></div></font>
</div>