[arin-ppml] Bootstrapping new entrants after IPv4 exhaustion

[David Farmer]

On 11/22/13, 14:06 , Owen DeLong wrote:
>
> On Nov 22, 2013, at 11:25 AM, David Farmer <farmer at umn.edu> wrote:
>
>> On 11/22/13, 08:50 , Brandon Ross wrote:
>>> On Thu, 21 Nov 2013, Jo Rhett wrote:
>>>
>>>> I'd like to see some actual documented issues with this. Almost
>>>> everyone I know is sitting on large amounts of smaller blocks they can
>>>> easily allocate to people. It's the larger (/21 or greater) blocks
>>>> which are becoming scarce.
>>>
>>> What kind of documentation are you looking for?
>>
>> I would think an a copy of an email or a letter from the upstream which confirms the upstream can't/won’t provide them address space, for some reason other than they don't think the customer justifies additional address space.
>>
>
> David, I think that would be fine documentation to submit to ARIN under my proposal, but I don’t think it addresses what Jo was asking for.
>
> I believe Jo is asking to see documentation that this is an actual problem that needs solving.

Ok, rereading that a couple more times, I see what you are saying.

So, this isn't a problem, just yet, therefore there really aren't any 
documented cases.  However, it will be a problem when the free pool runs 
out, and telling people to wait a full policy cycle after the free pool 
is gone, will be unacceptable.  Looking at Geoff Huston's cumulative 
probability graph I'd say we have at most two policy cycles to deal with 
this before the issue is on top of us, and two isn't a very safe bet.

http://www.potaroo.net/tools/ipv4/plotvarcum.png

>> It is unfair for ARIN to withhold address space because the upstream has address space but won't provide it to the requester for what ever reason.  I think it is reasonable to require some confirming documentation that the upstream is not providing address space.  You can't just "say" your ISP is not providing it.
>>
>> However, if an ISP is saying you don’t justify additional address space, then you shouldn’t qualify for address space from ARIN under an exception like this.
>>
>
> Agreed…
>
>> Also, ARIN should be able to refuse if they feel there is collusion between an ISP and a requester.
>
> This is trickier. incorporating how ARIN feels into policy is an interesting concept. Not one I am particularly comfortable with, and, in my experience, neither is ARIN staff.
>
> I will, however, say that the collusion I think you are talking about would basically qualify as fraud and that I believe there is already sufficient policy to deal with situations where ARIN staff suspects that a request is fraudulent.

I wasn't suggesting that as policy language.  But, I think you are 
probably right it is fraud, and ARIN has tools for that.  I think we 
just need to make sure ARIN has the right tools for that kind of fraud.

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