[arin-ppml] Policy Proposal: Last Minute Assistance for Small ISPs

[Member Services]

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

1. Policy Proposal Name: Last Minute Assistance for Small ISPs

2. Proposal Originator: Ted Mittelstaedt

3. Proposal Version: 1

4. Date: 7/24/2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

Under section 4.2.2. Initial allocation to ISPs

Section 4.2.2.1.1 (Use of /20) will be modified to be the following:

Sentence:

"Until ARIN has assigned 90% of it's remaining IP addressing,"

will be inserted at the beginning of the paragraph.

The following four paragraphs will be added:

When ARIN has reached 90% allocation of it's remaining IP free pool,
the minimum allocation of /20 requirement will be changed to a minimum
allocation of /21 in this section and all other sections that reference
the /20 minimum EXCEPT for transfers under section 8.3.

When ARIN has reached 95% allocation of it's remaining IP free pool,
the minimum allocation of /21 requirement will be changed to a minimum
allocation of /22 in this section and all other sections that reference
the /21 minimum EXCEPT for transfers under section 8.3.

When ARIN has reached 97% allocation of it's remaining IP free pool,
the minimum allocation of /22 requirement will be changed to a minimum
allocation of /23 in this section and all other sections that reference
the /22 minimum EXCEPT for transfers under section 8.3.

When ARIN has exhausted all of it's remaining IP free pool, for any
transfers under section 8.3, the minimum allocation size will remain at
  /20, in this section and all other sections that reference a minimum
allocation size.  It will remain at /23 for IPv4 that is voluntarily
returned to ARIN.

8. Rationale:

Once ARIN is no longer able to assign IPv4, there will be many smaller
ISP's who never qualified for an initial allocation under section
4.2.2.1.1. of the NRPM, who are using multiple /24 assignments from an
upstream provider, and who will see their costs for continuing to use
IPv4 numbering from their upstreams increasing as the "market price" set
by section 8.3 of the NRPM applies a price on IPv4 numbers.  For
example, it would be perfectly logical for a large network that observes
the price of a /20 transfer under section 8.3 at $10,000 to decide to
apply a yearly usage price of $600 to any /24's they have assigned to
their customers.

As the "transfer market" setup under section 8.3 continues to operate
post IPv4 runout, and costs of yearly IPv4 assignment fees from
LIR's diverge further and further from the yearly fees for allocations
from the RIR's, LIR's will have small ISP's using multiple /24
assignments at an extreme disadvantage.

Those small ISP's will be unable to get IPv4 from ARIN even if they
qualify at some time post-runout, they will be unable to afford to pay
large sums of money for transfers under section 8.3 (and likely wouldn't
meet minimum utilization requirements for the blocks that would be
transferred under section 8.3 even if they could), and if they go to
a competitive upstream, they will be essentially "going from the frying
pan to the fire".  It is likely that this could force many of them out
of business.

What this proposal attempts to do is give those small ISP's a chance
to obtain some small amount of portable numbering BEFORE IPv4 runout,
so that they can use this in conjunction with NAT or other technologies
post-IPv4 runout to manage until the userbase on the Internet switches
to IPv6.

ARIN's original rationale for setting the minimum allocation at /20 was
to prevent extreme fragmentation of the dfz and prevent it from growing
to impossibly large levels.  This goal has been pretty much met.  And
when 95% of the assignable IPv4 has been handed out by ARIN under the
"/20 minimum" rule, even if the rest of the IP was handed out as /24's,
it won't appreciably affect fragmentation in the dfz.  In addition, as
the years pass post-IPv4 runout, and organizations search around for
available IPv4 it's logical to assume that many more small allocations
that were assigned as "legacy" assignments, and are currently idle, will
be found and put into use - policy should discourage this and encourage
them to be returned to ARIN to be aggregated with other small
allocations.  Post IPv4 runout, the Internet should be transitioning to
IPv6, this policy should therefore be regarded primarily as a stopgap to
help small ISP's over the hump.

The small ISPs will still be required to show that they can make
efficient utilization of their requested block, still be required
to pay fees and meet all the other obligations any org must meet.
The only thing that changes is lowering the minimum limit.

9. Timetable for implementation; immediate