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

[Ted Mittelstaedt]

David Farmer wrote:
> 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."
> 

Your right, bad, bad, bad mistake on my part!

> 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.  
> 

I was intending the last /8 of IANA-assigned.

> 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.
> 

Yes, this probably is a much better way to do it.  Question for you, 
what do you think of the curve?  Do you think the percentages, or
CIDR-equivalents of the last /8 are good?

>> 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. 

I think both of those proposals will suffer the same fate as
2007-05-02, "IPv4 Soft Landing"

Unless my read of the ARIN participatory membership is incorrect,
people are generally opposed to trying to keep chewing the
gum once all the flavor is gone.

There's not a lot of point to making the IPv4 requesting
criteria so stringent that practically nobody can get an
allocation.  It reminds me of North Korea's 4 authorized "Christian"
churches that are attended by nobody, and do nothing, but allow
the regime to claim they are tolerant.

Sure, if you make criteria for IPv4 so tough that nobody can
meet it, you can claim that ARIN hasn't run out of IPv4 yet
for the next 3-4 decades.

 > Would you do this instead of one or both of those
> or would you do this and one or both of those too?
> 

I'm generally opposed to both of those proposals but my gut
feel is they will be shot down anyway so I don't really feel
"threatened" by them, nor do I really even bother to think
about them.  When I came up with
this proposal I wasn't viewing it as an "opposition" proposal
to those proposals.

I can see, though, how someone might consider this to be diametrically
opposed to those proposals.  I'm suggesting we make it easier to get 
IPv4 at the last minute - those proposals are making it harder.

But this depends on how you view IPv4 runout.  I view IPv4 runout
as a fundamental fact, no amount of wriggling on the hook is
going to get the worm off, it's gonna happen no matter how much
IPv4 we dig out of the archives.

Others who may view IPv4 runout as something that we actually have
control over, and can manipulate, would probably feel that a
proposal like mine undercuts the entire IPv4 addressing scheme.

If people who are actively opposing those proposals want to use
this proposal as a hill to rally behind, I don't care one way or
the other.  It wasn't intended as such, however.

Where I'm coming from is simple - we all know that there's small
fry out there, we all know that some of those small fry are gonna
get stomped hard by IPv4 runout, and since the small fry definitely
didn't cause IPv4 runout, I just felt it was kind of unfair to allow
that to happen without throwing them a lifeline.  After all it's
not like it would really be a lot of skin off our collective nose
to do this for them for a few years, and it would mean a great
deal of difference to many of them.

Ted