[arin-ppml] Clarify /29 assignment identification requirement

Jimmy Hess mysidia at gmail.com
Sat Apr 28 16:13:30 EDT 2012

On 4/28/12, William Herrin <bill at herrin.us> wrote:

Well,  I will say,  that  /32  dedicated user address assignments
merit more scrutiny.
Dynamic address pools are different,  because no IP address is
permanently assigned.
The question then is not "is this customer actually using the
resource";  but, are there enough (also identifiable) customers
served by the pool, with a growth rate to justify a pool of that size.

With single /32 dedicated assignments, there is a great danger that
the ISP allocated the address to a customer, and out of laziness --
after that customer terminates service,  the ISP neglects  to take the
manual actions required release the IP resource -- causing that to be

Perhaps because it is more convenient to just allocate a new IP,  and
only cleanup when forced to do so,  because the ARIN free pool has

> about ARIN asking for customer identities for /32 users, none have
> expressed that ARIN inquired into customer identities for their
> dynamic pools and one expressly stated that ARIN didn't ask about the
> much larger dynamic pools at all. Four does not make a statistical
> sample but it does suggest a pattern.

The pattern it suggests is only that 4 or so organizations receiving
information requests for ARIN regarding  /32 assignments have raised
issue with it.

We have no way of knowing what caused their applications to raise
suspicions of ARIN.
We have no way of knowing if they are dismayed by the information
request,  because they want to attempt to squeeze more IPs out of ARIN
than  policy says they should be allocated.

Or possibly they want more IPs out of ARIN, and see the requirement to
properly document usage of /32s  (still part of the public IP  address
resources)  as a hinderance.

I would expect ARIN to perform the necessary spot checking, if  the
rate of increase in usage/requirement of dynamically assigned pools is


More information about the ARIN-PPML mailing list