[arin-ppml] The case against need based justification

cb.list6 cb.list6 at gmail.com
Mon Apr 8 01:13:07 EDT 2013


Need-based justification is being reviewed in RIPE [1]

That spurred me to review need based justification in ARIN for both
IPv4 and IPv6.

I would like to present some facts for review so that the ARIN
community can judge the success of need-based justification and
consider the role it will have in future policy.

First, as of this writing, ARIN still has  2.47 /8s free [2].
Excluding the last /8 which is locked in a way by policy, that leaves
approximately 24 Million addresses in the free pool.  Assuming a free
market cost of $10 per IPv4 address, that is $240 million worth of
IPv4 cost off-set from which one would have to pay the free ipv4
market for those addresses.  This is a relevant sum on nearly any
balance sheet.  So, it is not acceptable to say folks are turning away
from it because ARIN is offering that space in a fair way.  The free
pool is relevant.

There is a case that the need-based policy has done well, and it has
done well for some.  Comcast, for example, has 18 million subscribers
and 70 Million IPv4 addresses [3].  For simple math, we can call that
3.8 addresses for every 1 customer.  Then, you have a network like
Metro PCS who has 9 million subscribers (2.2 million of which are LTE)
[4] on what i can tell is 1,024 IPv4 addresses.  Which is a
0.000113778 IPv4 addresses per subscriber from ARIN.  I do not speak
for Metro PCS, i just found their case interesting.

So, there are winners and losers in need-based.  Winners puts more
time and money into the process, losers are busy optimizing other
parts of their business instead of working the ARIN system.  Looking
back at [3],  winners are also big companies with a lot of resource
and ... they probably send people to ARIN meetings and ... maybe they
even send lawyers to ARIN meetings.  I don't know, i have never been
to an ARIN meeting myself.

So far, i hope we have seen that the free pool as of today is relevant
and that need-based is not strictly "fair" in how the distribution
happens, and that there are winners and losers.  Winners invest more
time and effort, and sometimes time and effort is from lawyers not
engineers.

Now, there is more.  Many organizations have found ARIN unsuitable for
their address needs.  We know that in 2011 when the free pool was much
larger than it is now (4+ /8s?), Microsoft bought IPv4 space from  a
bankruptcy court [6].  Amazon among others has also made substantial
market buys.  These companies are obviously not getting what they want
from a need-based policy, and i assume they made cogent business case
to close these deals.  The difference is they have the money to work
the policy like Comcast, but instead they worked a different angle
also applying money.  But, need-based is not a about money.  Is it?
It is about justified need, or the appearance of such.  It would
appear that Amazon and Microsoft could justify need, but the
need-based policy does not appear to work for them.  I am aware of the
transfer policy and how need is, for some reason, a different standard
there.

So, that is open market end of things, organizations pay millions of
dollars instead of thousands of dollars to not use a need-based policy
of the ARIN free pool.  Seems like the symptom of something broken.

Here is another symptom of something broken.  The largest internet
growth engine is mobile.  Mobile contributes a huge amount of traffic,
growth, and "stuff" on the Internet.  If Zuck does not mention mobile
20 times in an earnings call, FB stock dives.  AT&T wireless and
Verizon Wireless both have close to a 100 million subscribers each.
And, just about every one of those subscribers uses RFC 1918 space.
What about those 2 smaller players, Sprint and T-Mobile.  Both of them
use squat space.  Despite spending time and money on outreach, this
HUGE part of the internet is not part of the ARIN numbering system
(unless you count the ARIN addresses on the CGN).  At least, not part
of ARIN's need-based policy.   Mobile uses CGN because ARIN's policies
have not and will not fit with the growth of these networks and their
architectures.  Not today, but also not in 2003.  I would like that
that to change [7].  Speaking for myself, what i saw was a network was
designed to best fit the business needs.  That network design did not
fit ARIN policies for efficiency, and so ARIN would not provide
addresses and CGNs were rolled in to close the gap between the best
network design and the ARIN policies.

Speaking more for myself, in 2000 i worked for an ISP, and one of my
job roles was assigning addresses to T1 and T3 customers of the ISP.
It was a painful process for me and my customers.  We lived in world
where people just wanted a /24 to turn up their LAN, but i could not
just give it to them.  It was a world of scarcity of addresses, emails
full of made up justifications, and that persist today.

In fact, last year i tried to get a /48 of address space for a lab
network attached to a T3 from TWT.  They would not give me more than a
/56.  I heard from another guy that Internap would only give him a
/64.  Need-based is a trickled down disease on network design.

It is not just mobile doing CGN.  AT&T has deployed CGN to landline
DSL [8], and now Verizon DSL too [9]

As previously noted, the ARIN free pool is a non-trivial sum of 24
million IPv4 addresses.  Yet, companies continue to buy addresses and
/ or deploy CGN.  And they do it at massive scale.  We are talking
about the biggest cloud and access network providers can't seem to get
what they need from ARIN whether it be IPv4 addresses or effective
IPv6 deployment advocacy.

My conclusion from all this is that need-based policy did not help
IPv4 and is actively hurting IPv6.

NRPM and ARIN should get out of the business of telling people how to
number their networks, it has not helped the businesses or the
internet.  I say this because "we" did not transition to IPv6 and the
market for IPv4 and the technology known as CGN is seen as more
effective solution than ARIN or IPv6

That brings me to policy changes that i would like feedback on.

1. Should ARIN continue to administer need-based policy now and after
run-out?  Please note the discussion of winners and loser with data
points [3] and [5]. Who is ARIN serving with the need-based policy?

2.  I have made the claim that ARIN's need-based policy has negatively
impacted system design, the specific system being the internet.  The
squat / CGN internet that is on your phone [7] and coming to your DSL
[8],[9].

3.  By moving away from need based policy from ipv4, we accept reality
that the market rules [6].  IPv4 addresses are part of the means of
production in a capitalist society.  IPv4 addresses should not be
acquired by playing some logic game with people  via ARIN tickets or
intellectual thumb-wrestling and posturing on PPML.

4.  IPv6 is designed without need in mind, there is no reason for ARIN
to import the notion that need is factor when each LAN is given 2^64
addresses.  Organizations that want PI should get an ASN (existing
policy) and a minimum /32 and be done. End of story.  There is no
logic for conservation of a limitless resource (in this case, it is
bounded by ASN).  Growth beyond a /32 should just be a simple written
justification, not gear and subscriber logs showing 80% use.

5.  These simplifications can be reflected in a rate structure that
results from such simplification.


[1] https://www.ripe.net/ripe/policies/proposals/2013-03/
[2] https://www.arin.net/resources/request/ipv4_countdown.html
[3] http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf
[4] http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight=
[5] http://whois.arin.net/rest/net/NET-65-91-116-0-1.html
[6] http://www.bbc.co.uk/news/technology-12859585
[7] https://www.arin.net/policy/proposals/2013_2.html
[8] http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address-
[9] https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm



More information about the ARIN-PPML mailing list