<div dir="ltr"><div> I find much of your argument flawed -- you seem to have chosen a conclusion and then tried to wrap theories around it.<br></div><div><br></div><div>Re-read the nrpm... for a transfer to be recognized by ARIN, the criteria of justified need still applies. The "substantial market buys" you referenced still had justified need applied to them ---- the only difference between getting space directly from ARIN and getting it on the secondary market [aside from cost] is the window of time you can justify need for. Directly from ARIN you can get 3 months justified need and on the secondary market you can request up to 24 months need. <br>
</div><div><br></div><div>Unless you participated in the engineering and design of each of the networks you reference, you can not have first hand knowledge of how addressing policy affected their decisions. You are making guesses from the outside, based on the size of their customer base and what you see today. In atleast one mobile provider you reference, I can say -with direct knowledge- that your conclusion is wrong. The move to CGN has nothing to do with justified need and everything to do with whether it is financially responsible to continue investing in a finite resource. Sure providers could buy up space on the secondary market for another year or 2 - and then what? The price for v4 could rise exorbitantly, to the point where the cost of an address becomes a significant cost toward offering the service. You will be stuck in the same place and out a bunch of cash. Or you can have multiple customers share an address, recover a bunch of space and continue to grow your business without investing in the secondary market. Its the expense of the secondary market itself, that makes CGN more appealing. </div>
<div><br></div><div>With regard to use of RFC1918 space - again - unless you were involved in making the decision at those companies - you can not authoritatively say why they made the decision they did. You are speculating that they chose to use 1918 space because they were unable or unwilling to justify need - and that is very unlikely to be the case. Network Engineers tend to be reasonable, logical folks who give great thought to where public address space is necessary and where it isn't, as well as the pros and cons of using both. They may have chosen to respect a shared resource and conserve space, or been unsure how large the network would grow, or been unable to justify [to their mgr, themselves or whoever] the additional ARIN fees for being in a larger allocation category. </div>
<div><br></div><div>Fair does not mean that every organization gets the same thing. The NEEDS of every organization are different. This is why ARIN takes the time to read through the request and help ensure that what the organization gets, meets their needs... not their competitor or neighbor's needs. <br>
</div><div><br></div><div><a href="http://imbloghoppin.blogspot.com/2011/08/power-of-bandaid.html">http://imbloghoppin.blogspot.com/2011/08/power-of-bandaid.html</a><br></div><div><br></div><div><br></div><div>Where I do empathize with you, is the problem you described about getting v6 address space from your provider for a lab and they wouldn't give you more than a /56. However, that is a business decision by your ISP. As of today, there is no mandatory minimum IPv6 assignment size for ISP's to their customers, only a small reference to a recommendation. In fact, justified need is not a requirement in making reallocations to customers in IPv6, so abolishing justified need would not affect the v6 assignment size your ISP offers. If you would like to see that changed - then read up on how we got there and submit a proposal to change it (<a href="https://www.arin.net/policy/pdp_appendix_b.html">https://www.arin.net/policy/pdp_appendix_b.html</a>) Otherwise, it is an issue between you and your provider and should be taken up with them directly. </div>
<div><br></div><div>--Heather </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 1:13 AM, cb.list6 <span dir="ltr"><<a href="mailto:cb.list6@gmail.com" target="_blank">cb.list6@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Need-based justification is being reviewed in RIPE [1]<br>
<br>
That spurred me to review need based justification in ARIN for both<br>
IPv4 and IPv6.<br>
<br>
I would like to present some facts for review so that the ARIN<br>
community can judge the success of need-based justification and<br>
consider the role it will have in future policy.<br>
<br>
First, as of this writing, ARIN still has 2.47 /8s free [2].<br>
Excluding the last /8 which is locked in a way by policy, that leaves<br>
approximately 24 Million addresses in the free pool. Assuming a free<br>
market cost of $10 per IPv4 address, that is $240 million worth of<br>
IPv4 cost off-set from which one would have to pay the free ipv4<br>
market for those addresses. This is a relevant sum on nearly any<br>
balance sheet. So, it is not acceptable to say folks are turning away<br>
from it because ARIN is offering that space in a fair way. The free<br>
pool is relevant.<br>
<br>
There is a case that the need-based policy has done well, and it has<br>
done well for some. Comcast, for example, has 18 million subscribers<br>
and 70 Million IPv4 addresses [3]. For simple math, we can call that<br>
3.8 addresses for every 1 customer. Then, you have a network like<br>
Metro PCS who has 9 million subscribers (2.2 million of which are LTE)<br>
[4] on what i can tell is 1,024 IPv4 addresses. Which is a<br>
0.000113778 IPv4 addresses per subscriber from ARIN. I do not speak<br>
for Metro PCS, i just found their case interesting.<br>
<br>
So, there are winners and losers in need-based. Winners puts more<br>
time and money into the process, losers are busy optimizing other<br>
parts of their business instead of working the ARIN system. Looking<br>
back at [3], winners are also big companies with a lot of resource<br>
and ... they probably send people to ARIN meetings and ... maybe they<br>
even send lawyers to ARIN meetings. I don't know, i have never been<br>
to an ARIN meeting myself.<br>
<br>
So far, i hope we have seen that the free pool as of today is relevant<br>
and that need-based is not strictly "fair" in how the distribution<br>
happens, and that there are winners and losers. Winners invest more<br>
time and effort, and sometimes time and effort is from lawyers not<br>
engineers.<br>
<br>
Now, there is more. Many organizations have found ARIN unsuitable for<br>
their address needs. We know that in 2011 when the free pool was much<br>
larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a<br>
bankruptcy court [6]. Amazon among others has also made substantial<br>
market buys. These companies are obviously not getting what they want<br>
from a need-based policy, and i assume they made cogent business case<br>
to close these deals. The difference is they have the money to work<br>
the policy like Comcast, but instead they worked a different angle<br>
also applying money. But, need-based is not a about money. Is it?<br>
It is about justified need, or the appearance of such. It would<br>
appear that Amazon and Microsoft could justify need, but the<br>
need-based policy does not appear to work for them. I am aware of the<br>
transfer policy and how need is, for some reason, a different standard<br>
there.<br>
<br>
So, that is open market end of things, organizations pay millions of<br>
dollars instead of thousands of dollars to not use a need-based policy<br>
of the ARIN free pool. Seems like the symptom of something broken.<br>
<br>
Here is another symptom of something broken. The largest internet<br>
growth engine is mobile. Mobile contributes a huge amount of traffic,<br>
growth, and "stuff" on the Internet. If Zuck does not mention mobile<br>
20 times in an earnings call, FB stock dives. AT&T wireless and<br>
Verizon Wireless both have close to a 100 million subscribers each.<br>
And, just about every one of those subscribers uses RFC 1918 space.<br>
What about those 2 smaller players, Sprint and T-Mobile. Both of them<br>
use squat space. Despite spending time and money on outreach, this<br>
HUGE part of the internet is not part of the ARIN numbering system<br>
(unless you count the ARIN addresses on the CGN). At least, not part<br>
of ARIN's need-based policy. Mobile uses CGN because ARIN's policies<br>
have not and will not fit with the growth of these networks and their<br>
architectures. Not today, but also not in 2003. I would like that<br>
that to change [7]. Speaking for myself, what i saw was a network was<br>
designed to best fit the business needs. That network design did not<br>
fit ARIN policies for efficiency, and so ARIN would not provide<br>
addresses and CGNs were rolled in to close the gap between the best<br>
network design and the ARIN policies.<br>
<br>
Speaking more for myself, in 2000 i worked for an ISP, and one of my<br>
job roles was assigning addresses to T1 and T3 customers of the ISP.<br>
It was a painful process for me and my customers. We lived in world<br>
where people just wanted a /24 to turn up their LAN, but i could not<br>
just give it to them. It was a world of scarcity of addresses, emails<br>
full of made up justifications, and that persist today.<br>
<br>
In fact, last year i tried to get a /48 of address space for a lab<br>
network attached to a T3 from TWT. They would not give me more than a<br>
/56. I heard from another guy that Internap would only give him a<br>
/64. Need-based is a trickled down disease on network design.<br>
<br>
It is not just mobile doing CGN. AT&T has deployed CGN to landline<br>
DSL [8], and now Verizon DSL too [9]<br>
<br>
As previously noted, the ARIN free pool is a non-trivial sum of 24<br>
million IPv4 addresses. Yet, companies continue to buy addresses and<br>
/ or deploy CGN. And they do it at massive scale. We are talking<br>
about the biggest cloud and access network providers can't seem to get<br>
what they need from ARIN whether it be IPv4 addresses or effective<br>
IPv6 deployment advocacy.<br>
<br>
My conclusion from all this is that need-based policy did not help<br>
IPv4 and is actively hurting IPv6.<br>
<br>
NRPM and ARIN should get out of the business of telling people how to<br>
number their networks, it has not helped the businesses or the<br>
internet. I say this because "we" did not transition to IPv6 and the<br>
market for IPv4 and the technology known as CGN is seen as more<br>
effective solution than ARIN or IPv6<br>
<br>
That brings me to policy changes that i would like feedback on.<br>
<br>
1. Should ARIN continue to administer need-based policy now and after<br>
run-out? Please note the discussion of winners and loser with data<br>
points [3] and [5]. Who is ARIN serving with the need-based policy?<br>
<br>
2. I have made the claim that ARIN's need-based policy has negatively<br>
impacted system design, the specific system being the internet. The<br>
squat / CGN internet that is on your phone [7] and coming to your DSL<br>
[8],[9].<br>
<br>
3. By moving away from need based policy from ipv4, we accept reality<br>
that the market rules [6]. IPv4 addresses are part of the means of<br>
production in a capitalist society. IPv4 addresses should not be<br>
acquired by playing some logic game with people via ARIN tickets or<br>
intellectual thumb-wrestling and posturing on PPML.<br>
<br>
4. IPv6 is designed without need in mind, there is no reason for ARIN<br>
to import the notion that need is factor when each LAN is given 2^64<br>
addresses. Organizations that want PI should get an ASN (existing<br>
policy) and a minimum /32 and be done. End of story. There is no<br>
logic for conservation of a limitless resource (in this case, it is<br>
bounded by ASN). Growth beyond a /32 should just be a simple written<br>
justification, not gear and subscriber logs showing 80% use.<br>
<br>
5. These simplifications can be reflected in a rate structure that<br>
results from such simplification.<br>
<br>
<br>
[1] <a href="https://www.ripe.net/ripe/policies/proposals/2013-03/" target="_blank">https://www.ripe.net/ripe/policies/proposals/2013-03/</a><br>
[2] <a href="https://www.arin.net/resources/request/ipv4_countdown.html" target="_blank">https://www.arin.net/resources/request/ipv4_countdown.html</a><br>
[3] <a href="http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf" target="_blank">http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf</a><br>
[4] <a href="http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight=" target="_blank">http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight=</a><br>
[5] <a href="http://whois.arin.net/rest/net/NET-65-91-116-0-1.html" target="_blank">http://whois.arin.net/rest/net/NET-65-91-116-0-1.html</a><br>
[6] <a href="http://www.bbc.co.uk/news/technology-12859585" target="_blank">http://www.bbc.co.uk/news/technology-12859585</a><br>
[7] <a href="https://www.arin.net/policy/proposals/2013_2.html" target="_blank">https://www.arin.net/policy/proposals/2013_2.html</a><br>
[8] <a href="http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address-" target="_blank">http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address-</a><br>
[9] <a href="https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm" target="_blank">https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm</a><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></div>