[arin-ppml] A Redefinition of IPv4 Need post ARINrun-out(was:Re:Against2013-4)

Thu Jun 13 11:50:52 EDT 2013

I would be opposed to a flat out cap that allows requests under a
certain size to not require need and requests over that size to require
need.

This is an unfair burden to organizations who require lots of address
space for growth.

Consider a small rural residential ISP, with a /22.
- This ISP is using a single /24 for loopback, point-to-point,
management network, and corporate network.

- This IPS has 615 customers each with a single IPv4 address.

- This ISP has seen fairly linear growth of 600 customers every two years.

In 6 months they will exhaust their currently held space.
They already qualify for another /22.
Once they get this additional /22 that gives them addresses to cover 4
years.
(/22 is about 3.4 years of customer + 6 months current available)

A /12 represents 6,990 years worth of address space
A /16 represents 218 years of address space
A /20 represents 13.5 years of address space

Should small organizations be able to by a virtually unlimited amount of
address if they can afford it?

Should a large organization (who can demonstrate need) only be permitted
to buy two years worth of address space?

In this example a /22 provides a 4 year window, I would argue that needs
based transfers for larger than a /22 would need to support a 4 year window
for fairness.

Remember the community discussed how much (in units of time) an organization
should be able to purchase.  The though was two years should be reasonably
long for an organization who did not plan for IPv6 deployment to get one
more
allocation, and still deploy IPv6 before running out.

If all organizations deployed IPv6 in a serious way in the next two years,
the IPv4
depletion problem would essentially be solved.

The problem is the community as a whole has failed to deploy IPv6 in a
timely
fashion.  This is because it has real costs, and generates no new products,
services,
or revenue.  Corporations have been short sighted in their investments, and
have
concluded that then only need to deploy IPv6 just before their organization
runs out
of IPv4 (that is the orgs that are paying attention and planning for IPv6).
 Since
everyone runs out at different times, you can't move to IPv6-only until a
critical mass
of organizations has already run out and embraced IPv6 in a real way.

Organizations have also realized they only have to do native IPv4 for
shortly longer
than their competitors then they can force all new customers into some sort
of
provider based large scale NAT (CGN 444 + IPv6 / GCN 644).

So now people are bracing for a slow and painful transition to IPv6.

Never mind anti-competitive behavior of cornoring the market on IPv4
addresses,
think about reasonable players the feel the need to stockpile enough
addresses
to continue doing native IPv4 longer than their competition in order to not
loose
their customer base to competitors who can offer a better native IPv4
product when
you can't.

Which means getting years worth of IPv4 space...
Which means we are not going to run out...
Which means we can continue to save by deferring the cost
of deploying IPv6...
Which menas buying more space...
(if we are not ready to deploy IPv6  buy two more years worth)
(or if the industry hasn't embraced IPv6 in a real way buy enough to last
until it has)

If you are looking to make needs justification easier then maybe something
like:
- any org can transfer a single /22 no need required
- any org can transfer up to four times the amount of address rounded to
nearest CIDR utilized in the last year
   * (jan 1, had 14 M addresses in use, dec 31 had  17M) 3M = /20 qualify
for /18
- any org who transfered a /22 can get an additional /22 when the current
one is 80%
utilized even if they have utilized less than a 513 addresses in the last
year
   *( jan 1 had 711 addresses, dec 31 had 820) 109 = /25

But agin the community will have to accept a four year window, which will
likely do
bad things to IPv6 deployment.  If you made the threshold a /23, then you
could keep
the two year window... but they why not just go to RIPE or APNIC and get a
/22 from
the soft landing policy?

___Jason

On Thu, Jun 13, 2013 at 10:17 AM, Mike Burns <mike at nationwideinc.com> wrote:

>   Hi Brian,
>
> Thanks for your thoughts.
> No doubt a more vigorous transfer market will lead to more router
> misconfigurations.
> 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.
>
> 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.
>
> Your point about moving to IPv6 is important, because that move is the
> 800lb gorilla in the room.
> 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.
> Who would speculate under these conditions?
> What if we limited his total purchases to a /12, or his aggregate holdings
> to a /12, otherwise he would be needs-tested?
>
> Regards,
> Mike
>
>
>
>
>  *From:* Brian Jones <bjones at vt.edu>
> *Sent:* Thursday, June 13, 2013 9:30 AM
> *To:* Mike Burns <mike at nationwideinc.com>
> *Cc:* Mike Burns <mike at iptrading.com> ; arin-ppml at arin.net
>  *Subject:* Re: [arin-ppml] A Redefinition of IPv4 Need post
> ARINrun-out(was:Re:Against2013-4)
>
> Mike,
> See inline comments.
>
> On Wed, Jun 12, 2013 at 10:05 PM, Mike Burns <mike at nationwideinc.com>wrote:
>
>> **
>> Hi Brian,
>>
>> I understand that there is a danger of overpurchasing (by whomever's
>> definition) that comes from the removal of a needs test for transfers.
>> 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. 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.
>>
>> A vibrant market is one of the best mechanisms to prevent what you
>> mention-the problem of addresses sitting idle while real need exists.
>>
>
>
> At the risk of contradicting myself, I'm not sure a vibrant market is the
> *best *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.
>
>
>
>>  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.
>>
>
> 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.
>
>
>>
>> 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.
>>
>> How likely is this transaction to occur for small allocations like the
>> /24 needed by Mr. Ryerse of this thread?
>>
>> 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.
>>
>>
>
> 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.
>
> --
> Brian
>
>
>
>>  Regards,
>> Mike
>>
>>
>>
>>
>>  ----- Original Message -----
>> *From:* Brian Jones <bjones at vt.edu>
>> *To:* Mike Burns <mike at iptrading.com>
>>  *Cc:* arin-ppml at arin.net ; Mike Burns <mike at nationwideinc.com>
>> *Sent:* Wednesday, June 12, 2013 9:28 PM
>> *Subject:* Re: [arin-ppml] A Redefinition of IPv4 Need post
>> ARINrun-out(was:Re:Against 2013-4)
>>
>>
>> Hi Mike,
>>
>> 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.
>>
>> 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... :)
>>
>> Brian
>>
>> On Jun 12, 2013 3:15 PM, "Mike Burns" <mike at iptrading.com> wrote:
>> >
>> > Hi Brian,
>> >
>> > Thanks for your input.
>> >
>> > 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?
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > Regards,
>> > Mike
>> >
>> >
>> > From: Brian Jones
>> > Sent: Wednesday, June 12, 2013 2:54 PM
>> > To: Mike Burns
>> > Cc: arin-ppml at arin.net
>> > Subject: Re: [arin-ppml] A Redefinition of IPv4 Need post ARIN
>> run-out(was:Re:Against 2013-4)
>> >
>> >
>> > 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...
>> >
>> > Intelligent allocation of the remaining IPv4 space is important in my
>> opinion.
>> >
>> > From Dave Farmer's email earlier:
>> > "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. "
>> >
>> > 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."
>> >
>> > (Of course I support the idea that we all move to IPv6!) :)
>> >
>> > --
>> > Brian
>> >
>> >
>> > On Wed, Jun 12, 2013 at 11:20 AM, Mike Burns <mike at nationwideinc.com>
>> wrote:
>> >>
>> >> Hi Brian, Matthew, and Martin,
>> >>
>> >> Can I take your plus ones to indicate support of the cap even in the
>> face of the shell company issue?
>> >> (As well as support of the idea that we should all move to IPv6.)
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >>
>> >> From: Brian Jones
>> >> Sent: Wednesday, June 12, 2013 11:03 AM
>> >> To: arin-ppml at arin.net
>> >> Subject: Re: [arin-ppml] A Redefinition of IPv4 Need post ARIN run-out
>> (was:Re:Against 2013-4)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Jun 11, 2013 at 10:42 PM, Martin Hannigan <hannigan at gmail.com>
>> wrote:
>> >>>
>> >>> On Tue, Jun 11, 2013 at 10:24 PM, cb.list6 <cb.list6 at gmail.com>
>> wrote:
>> >>>>
>> >>>>
>> >>>> On Jun 11, 2013 7:15 PM, "Matthew Kaufman" <matthew at matthew.at>
>> wrote:
>> >>>> >
>> >>>> > 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.
>> >>>> >
>> >>>>
>> >>>> +1
>> >>>>
>> >>>> CB
>> >>>
>> >>>
>> >>> +1
>> >>>
>> >>> Best,
>> >>>
>> >>> -M
>> >>>
>> >>>
>> >>
>> >>
>> >> +1
>> >>
>> >> --
>> >> Brian
>> >>
>> >>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> PPML
>> >>> You are receiving this message because you are subscribed to
>> >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> >>> Unsubscribe or manage your mailing list subscription at:
>> >>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> >>> Please contact info at arin.net if you experience any issues.
>> >>
>> >>
>> >> ________________________________
>> >> _______________________________________________
>> >> PPML
>> >> You are receiving this message because you are subscribed to
>> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> >> Unsubscribe or manage your mailing list subscription at:
>> >> http://lists.arin.net/mailman/listinfo/arin-ppml
>> >> Please contact info at arin.net if you experience any issues.
>> >
>> >
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130613/f85dd505/attachment.htm>