[arin-ppml] Initial ISP Allocation Policy

[Owen DeLong]

Sent from my iPad

On Jul 18, 2013, at 4:36 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> Hello everyone,
> 
> I would like to thank everyone for a very good discussion in this thread. First I'll give a very brief summary of the discussion so far, and then I have a solution to float to the list for feedback.
> 
> Myself, Dan, Bill, and Steven have posted in favor of the high level concept that the differentiation in ARIN policy between enterprise networks and provider networks is no longer productive or relevant.  Owen may agree in principle, but cautions us to be very careful with how we proceed.  He is concerned that an effective "one size fits all" solution may be very difficult to design. George offers us an alternative nomenclature to consider (NSP v. ISP).
> 
> I would like to now shift the discussion to how we approach potentially collapsing the two categories into one so that future interactions with ARIN are conducted under policy language which is relevant in 2014 and beyond.
> 
> I agree with Dan that a wholesale paradigm shift in ARIN policy can only be accomplished with multiple proposals. There would be quite a few sections to change (with each change requiring careful consideration by the community).  Moreover, I think we must be sensitive to ARIN's need to react to the possible impacts to both the financial and workflow modeling that would result from any changes we propose.  
> 
> At the same time, incremental change in NRPM is actually really hard. If this were 5 years ago, I would probably work very hard to help effect incremental change.  But I think ARIN and the community have together failed to react to changes in the market over the last 15 years, and it is time to consider very big change. Let's get NRPM into a sane state for 2014 and beyond.
> 
> In an effort to roll up sleeves and be productive, please indulge me while I lay out one potential vision for what a sane NRPM might look like.  I warn you, good reader, that some of what I propose is very radical.
> 
> - A section on obtaining initial IPv4 addresses from ARIN.  No distinction between end-users and ISPs.  No distinction between single-homed and multi-homed deployments (*if you don't understand why the difference has no virtue, ping me on or off list and I will show you the math as I see it).  Text might look something like:
> 
>    "In order to receive an initial allocation from ARIN, an organization must:
>    
>        - demonstrate they operate an IP network that requires 
>        IPv4 addresses to deploy and/or grow; and
> 
>        - provide a numbering plan detailing how IPv4 addresses 
>        will be used in the first 180 days upon receiving an allocation.
> 
>    ARIN will review and verify the data provided, and provide for the organization's 6 month need."
> 

6 months is far too short a planning horizon for any organization, IMHO. The intent of the (now ridiculous) 3 month window in the ISP policy was to make sure that the 1 year request at the head of the line could not drain the pool granting $ISP-A a 1-year advantage over everyone else in line ($ISP-B through $ISP-Z, for example).

I think that the 1 year time horizon for IPv4 is still perfectly reasonable so long as there is an IPv4 free pool. I think that having a dichotomy between the transfer planning horizon and the free-pool planning horizon is utterly and completely harmful and I will continue to argue against that.

> - A section on obtaining additional blocks, which still outlines the 80% rule. ("If you've efficiently used what you have, you can have more" is a technically sound concept that does not need much fixing.)  Platform differences which are already fleshed out in NRPM (e.g., residential market area provider networks with their different metrics than more common buildouts) can and should remain.  

Admittedly, this may be within your IPv4 policy in which case it makes sense, but since you said additional blocks and not additional IPv4 blocks, I have to point say I think this is a very silly way to approach IPv6, especially for service providers. First, I think that the current iPv6 policy is much more liberal and does a much better job of allowing for organic asymmetric growth as is more likely to occur than symmetric growth required by a straight 80% rule which has always been problematic. It was a reasonable compromise to deal with scarcity, but it would be very harmful IMHO for IPv6.

> - We would have to figure out what to do with the requirement to SWIP, as the requirement is predicated on the classification of "ISP" actually existing (which it would not).  That might need a working group to reconcile.

You've just punted on one of the central reasons for the distinction. This is a classic example of where the devil is in the details and you've chosen a hand-wave over the details. I don't mean to be flip or glib, but if you don't have a solution here, then you have a building with no foundation, IMHO.

> - A section on obtaining initial IPv6 addresses from ARIN. Given that IPv6 is still very much in its infancy, I really would like to see very simple NRPM text which allows requestors to self-select what size block they need. The only barrier to abuse or silliness would be the fee schedule.   It is arrogant and technically indefensible that ARIN policy today tries to dictate what a network does, and does not, justify as far as block size.  IPv6 is much too immature for ARIN policy to presume such wisdom.

I very much disagree with you here. The present IPv6 policy comes up very close to what you propose and does virtually allow an organization to self-select any remotely-conceivable block size that they need. The formula in current ISP policy allows so much round-up of ones most optimistic projections of ones largest pieces of their network that it is very easy to get a quite large block of IPv6 addresses. I have worked on two applications for /24s under the current policy that were successful. The first one (a subsequent allocation for an ISP that already had a /32) was very easy. The second one took a little more effort to convince ARIN that the organization in question truly operated as an ISP, but once ARIN was convinced that they were an ISP and not an end-user (the confusion was actually quite understandable in this particular case), it also sailed through. In neither case were there any significant hurdles in terms of the size of request.

As to the end user policy, it's pretty easy now. Admittedly, you either have to be sizeable or multi-homed, but I don't think that's related to the ISP/End-User distinction nearly so much as it is an artifact of the portion of the community that is hyper-concerned with routing-table growth. While I agree with you that it would be desirable to remove the multihome constraint from policy, such a move has not yet achieved community consensus. That would be an improvement to existing policy, IMHO.

Beyond that, the end-user policy boils down to: Count the number of end sites you have. Round up to a nibble boundary and move left from /48. So you get at least one /48 per end-site. Since an end-site is defined as a single building or structure or a single tenant in a multi-tenant building or structure, I think that's a pretty reasonable starting point. However, the policy also includes a relief valve just in case that allows you to request multiple /48s for any end-site that needs more than 40,000 (IIRC) unique networks.

I think that having a different formula for those allocating addresses to others and those directly managing end sites makes  a lot of sense as the required management regimes are quite different in my experience. 

I admit that if you just let everyone choose their block size based on how much they want to pay, this distinction loses a lot of relevance, but I don't think that such a policy is in any way a positive change at this time.

I think it would amount to turning ARIN into an IPv6 auction house offering address space to the highest bidders, thus allowing wealthy corporations to get whatever they needed while likely increasing the pricing for many end-users for even just a /48 to the point that they could no longer retain their blocks.

> - A section on obtaining additional IPv6 addresses from ARIN.  Existing text in 6.5.3 is probably good enough for today, as there are only a handful of networks in the world with any experience needing additional IPv6 addresses due to efficient use of an initial block.  Obtaining additional IPv6 addresses is a topic for many years from now, not today.

Not necessarily so many years as you may think given the number of thoroughly undersized allocations that are still out there.

> Do you think any of this has value?  Would it accomplish the overarching goal of improving ARIN policy to make it relevant to network operators in 2014 and beyond?  What would your sane NRPM look like?

I'm very skeptical for the reasons outlined above.

I applaud your effort, but I could not support such a policy.

Owen