[arin-ppml] Inital ISP IPv6 Allocation Policy Question

[Owen DeLong]

On Mar 21, 2012, at 9:41 PM, David Farmer wrote:

> 
> 
> On 3/21/12 20:50 CDT, Owen DeLong wrote:
>> On Mar 21, 2012, at 5:11 PM, Kevin Blumberg wrote:
>> 
>>> I wanted to get some feedback from the community on the following section of the NRPM.
>>> 
>>> 6.5.2.2. Qualifications
>>> 
>>> An organization qualifies for an allocation under this policy if they meet any of the following criteria:
>>> 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
>>> 
>>> In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any
>>> further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement?
>>> 
>> 
>> Sort of yes and sort of no. They would still need to evaluate their IPv6 need in terms of determining a prefix size if the provider wanted something other than a /32. Since most providers will likely need something larger than a  /32, I'm not a big fan of the idea of setting up an APNIC-Like Easy IPv6 "Push here for a /32" button.
> 
> Heather beat me to the punch, but I fleshed it out a bit more.  And, I agree with the warning button.
> 
> I tend to agree with the objection to just proving a one click for a /32, as it will not serve many providers very well.  However, what if we created a policy allowing for an even more simplified justification for larger IPv6 allocations based on a providers total IPv4 allocations.
> 
> Something like; if a ISP has an equilivant of a total /15 or more of IPv4, they need no additional justification to receive /28, and if they have a /9 or more they need on additional justification to receive /24, more than a /24 requires a complete justification.
> 
> Similarly, we could provider end-users a simplified justification for IPv6 assignments as well.  End-users with than a /18 or more of IPv4 automatically qualify for a /44 of IPv6, or more than a /15 they automatically qualify for a /44, more than a /44 requires a complete justification.
> 
> Because there will probably be a financial impact, it should be implemented with maybe two clicks, for a provider select from /36, /32, /28, and /24, allowing the appropriate options base on a providers total IPv4 allocation.  This would probably allow an 80/20 rule to come in to play and provide for web page for IPv6 allocations appropriate for more than 80% of ARIN members.
> 
> The /18, /15, and /9 are just examples, you would want to look at a histogram of total IPv4 allocations by organization, before actually picking the cut-offs, but I think those may be at least in the ballpark.
> 

It just doesn't map that well. I've been through just about every exercise possible in terms of how much IPv6 space should equal how much IPv4 space and the answer always works out to "it depends".

Sure, you can come up with rules of thumb that fit a limited constrained set of possible environments, but, that's not what ARIN deals with. When you look for something that has to fit residential, business, backbone, colo, etc. providers and then multiply it by the number of variations in each space, there's really no formulaic mapping function that actually works. At least none that I've been able to find.

The current IPv6 justification process really is pretty simple. It took me less than 30 minutes to put all the data together and submit the form through ARIN online (25 of the 30 minutes... Gawd I miss simple easy to use templates). It took ARIN less than 24 hours to approve the request. There was a brief delay for the officer attestation and I wouldn't mind providing an attestation waiver for IPv4 subscribers getting their first IPv6 allocation. This was fora  subsequent IPv6 allocation for a /24 based on our actual need and utilization of our existing /32 rather than an initial allocation, but, frankly, an initial allocation would have been even easier as it would not have required existing IPv6 utilization data.

Here's a simple flow for preparing a request under the current rules:

1.	How many end sites are served by  your largest aggregation point?
		(Let this answer be A)
2.	How many aggregation points do you expect to have in the next 5 years?
		(Let this answer be P)

Find a number n such that (n%4==0) && (2^n > 4P/3).
Find a number o such that (o%4==0) && (2^n > 4A/3).

X = 48 - (n+o) [see note 1]

3.	Request a /X

Someone even posted a .XLS template for doing this to PPML as part of the discussion of the current policy.

Owen

[note 1] 48 applies only if your PAU is /48 or shorter. If you assign something longer than a /48 (e.g. /56, /60, /64) to any of your customers, then your PAU is the smallest block you assign to a customer end site. Use that number in place of /48. For example, if you are a residential provider and provide /64s to your residential customers, then your PAU is /64 and you should use 64 in place of 48 in the above formula.