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

[David Farmer]

On 27 Jul 2009 Member Services wrote:

> 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,"


This probably needs an additional clause, something like, "Until ARIN has 
been allocated its last /8 per section 10.4.2.2, and ARIN has assigned 90% 
of it's remaining IP addressing."

I'm not sure the percentages are actually meaningful without setting the 
starting point.  I haven't run the numbers, but it is possible that ARIN has 
already allocated 90% of the IPv4 address space that it will allocate.  If this 
isn't the intent, then maybe you need to be much more specific where the 
measurement starts.  

Maybe a better way is to provide specific CIDR-based threshold triggers 
rather than percentages anyway.  Maybe say the last /11 instead of 90% 
(87.5% of a /8), /12 instead of 95% (93.75% of a /8), and /13 instead of 97% 
(96.875% of a /8). This way you probablly don't need to explicitly say start 
with the last /8.

> 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

How would you envision this working with other policy proposals?  Such as 
93. Predicable IPv4 Run Out by Prefix Size and 94. Predictable IPv4 Run 
Out by Allocation Window.  Would you do this instead of one or both of those 
or would you do this and one or both of those too?



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================