[arin-ppml] ARIN-prop-162 Redefining request window in 4.2.4.4

[Jimmy Hess]

On Sun, Jan 29, 2012 at 11:21 AM, Owen DeLong <owen at delong.com> wrote:

> On Jan 29, 2012, at 7:45 AM, Joe Maimon wrote:
> >> On Jan 28, 2012, at 7:53 PM, Joe Maimon wrote:
>
> Denying addressees to customers that want to use them today through
> existing providers in order to keep them available for possible customers
> later who might use them through providers who don't exist yet is not,
> IMHO, responsible.
>

I oppose the policy proposal,  both the specific text, and the idea of
increasing the supply allowed to be applied for to 12-months or longer
without additional constraint.

The RIR should deny addresses to customers that want to use them from 4 to
12 months from now every time, if they are wanting more than a /16 right
now, they can and should have to wait to apply for that until the need is
closer;  so that they can be given in preference to those that need the
addresses within 3 months,  while addresses are scarce.    By definition,
if the addresses aren't needed within 3 months,  then they don't need those
addresses yet.    It would just be convenient, beneficial, and more
profitable for the provider to have them up front.


Rapid RIR free pool exhaustion is not in the best interests of the
community served by ARIN.

With a 12-month supply allowed, it is possible that provider A today
receives a 12-month supply,  and  5 months from now,  this results in
provider B being denied an allocation it has immediate need for,  long
before  provider A  runs out of supply.


We are talking about essentially changing the rule from a 3-month supply to
a 12-month supply for new allocations again.   ARIN already tried that, we
started with that,  it brought ARIN to its current state of near exhaustion
of its IPv4 free pool.

The free pool exhaustion rate was greatly reduced with the move to a
3-month supply.

There are good reasons to inconvenience the provider that would like to
have more than a 3 month supply of addresses from the ARIN free pool, by
maintaining the 3-month supply rule as is:

(1) It makes providers do extra work to make sure they really do need these
extra addresses before sending in an application - the provider gets
reduced returns from each application for addresses, making the costs and
efforts to apply stand out,  and encouraging investigation into  IPv6 and
other less inconvenient sources for IPv4 addresses, which reduces
exhaustion rate.

(2) The cost increases for providers obtaining extra large allocations --
they can no longer just "forecast an entire year" and get a hefty
allocation that is probably a large overestimate in the first place;  they
now get 4 times a year, perhaps, to review their consumption.

(3) It encourages the providers to restructure their networks to free
addresses or reduce their requirements for addresses, for example utilizing
technologies such as NAT  /31 P-t-P links, and increase utilization
efficiency. Increased efficiency means that fewer addresses are wasted.

(4) With the transfer market  allowing a 12-month supply and free pool
allowing a 6-month supply, this encourages providers to seek addresses on
the transfer market.

#4  attaches an economic value to IP addresses,  which encourages _many_
networks and especially legacy networks to optimize address usage,
possibly with a mind for generating revenue through paid transfers to ISPs
having a desire for a 12-month supply of addresses.


Large providers who desire massive 12-month supply allocations have more
resources/are more equipped to negotiate and find sources of IP addresses
that can be made through specified transfer,  than small organizations.


The large providers  consume so much IPv4,  that if they become much more
efficient with their IPv4 utilization, clean house,   it is quite possible
the IPv4 exhaustion problem could cease to be a problem.

Taking that into account... IPv4 address exhaustion any time soon is not
necessarily inevitable.

It was a trend under the prior conditions of allocation.

 --
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120130/59392415/attachment.htm>