[arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships

[Jack Bates]

On 2/11/2011 11:52 AM, John Curran wrote:
> 1) Will these suballocations be listed via SWIP/rWHOIS per the existing
>    policy for customer assignments?
>

"ARIN does not limit
  reassignment by ISPs to their customers based on any criteria except
  those that are explicitly described in the NRPM"

To my knowledge, ARIN does not do this now, and it seems as though the 
policy is a clarification to head off future restrictions such as "You 
must have a link of X size for a reassignment to be valid."

This would assum that SWIP/rWHOIS is still required by existing policy.

> 2) Are there any minimum prefix size restrictions (since there is no
>     routing relationship implied between the customer and the ISP which
>     provides aggregation)
>

There currently aren't, and even in cases of direct transit customers, 
there is no guarantee in the routing table that a prefix size will be 
maintained. This is seen in the current DFZ in large volumes of 
deaggregation.

> 3) Is there any prefix size maximum (e.g. could an organization holding
>     a /8 have one customer receive the entire /8 as their assignment?)
>

Given justified need, does it matter? I believe the NRPM already covers 
justified need, though it tends to be limited in scope primarily to 
requesting additional address space. As people will be requesting less 
address space, this limits the scope and power of ARIN.

An ISP hands out space to customers. Not all those customers are 
directly connected. Some ISPs function solely as an LIR. This 
traditionally has been accepted and allowed in justification for 
subsequent requests.

I don't see that this policy actually changes that fact, but attempt to 
clarify it given the current arguments over people selling address space 
to others who are not directly connected to their network.

The question for ARIN and the community becomes, what should be in the 
NRPM for ARIN to deal with recourse when justification has not been met 
on reallocations or assignments? This applies both to IPv4 and IPv6, as 
the recourse of denying subsequent allocations is extremely limited for 
both (IPv4 will be exhausted, and IPv6 requires much less interaction 
with ARIN).

I believe this last question is the most important, and I think it 
should fall in lines with the clarification of this proposal (ie, we 
should not forbid LIRs and ISPs from doing allocations which are needs 
based regardless of the customer relationship).


Jack