[arin-ppml] [arin-discuss] IPv6 as justification for IPv4?

[Rob Seastrom]

"Tim St. Pierre" <tim at communicatefreely.net> writes:

> I applied for a /22 under the immediate need category, but I don't
> qualify, since I can really only use about 2/3 of it within 30 days.

Something seems wrong here.  I've filled out an immediate need request
or two in my time and had the luxury of being constrained by devices
that want address pools (LNSes, CMTSes) so I can round up to the next
power of 2.  I will note for Mr. St. Pierre's benefit that it is
possible that he misread the reason for his denial - the bar for
supporting documentation is extraordinarily high in an immediate need
application, since one is substituting a big pile of paperwork for
one's slow start utilization record that is normally used to justify
space.

Assuming that Mr. St. Pierre didn't misread his reason for denial, I'm
a bit confused.

Once upon a time, Immediate Need was a one-size-fits-all /20.  That
got fixed to be an appropriate sized block some years ago (see
https://www.arin.net/policy/proposals/2007_9.html for details).

Is ARIN staff currently interpreting NRPM 4.2.1.6 to mean that
immediate need can only be demonstrated for exact powers of two, with
100% utilization immediately?  Has the 80% rule somehow gotten
applied here?

This would seem to me to be the wrong test to apply.  When I authored
2007-9 I assumed that Staff would evaluate immediate need and issue
the smallest aggregate that would cover the number of addresses
justified for immediate use.

Without commenting on Mr. St. Pierre's particular case, could ARIN
staff comment on whether current policy is creating a problem at the
low size end of the justification window (i.e., is the fully filled
/23 a problem when an ISP can not get a /23 under current policy?) or
is being interpreted to mean only exact precise powers of two, no more
and no less, and any other perceived inadequacies in the current
immediate need policy?

I am not in favor of using IPv6 utilization as a justification for
IPv4 addresses at this time.  I am however in favor of smoking out
whether 4.2.1.6 needs to be revisited.

-r