[arin-ppml] Set aside round deux

Owen DeLong owen at delong.com
Thu Jul 29 00:09:35 EDT 2010


On Jul 28, 2010, at 7:18 PM, Roger Marquis wrote:

>>> If you are worried about vast tracts of IPs ripe for the plucking,
>>> then let's write policy to find and recover those tracts - Or at least
>>> to stop Orgs with those unused/underused resources from getting more.
>>> Size, type, industry are not the issues here; efficient utilization
>>> is.
>> 
>> Find and recover is a non-starter because it costs too much money
>> for ARIN to do this kind of detailed audit.
> 
> One FTE is too much money for ARIN?  Considering the ROI I have to
> disagree.
> 
Likely return is very close to zero. Given that, the amount of investment
possible for a decent ROI is well below one FTE.

>> Efficient utilization is unknown without audits.
> 
> Agreed, however, this sort of audit is not only feasible it is actually
> pretty straightforward.  It would have to be done in two phases, the
> first automated ie., collecting statistics, the second manual and
> personal.  Phase two would be much like what we think of as "management
> by walking around" requiring face time, on-site visits, meetings, and a
> fair bit of travel by the auditor.  There's just too much detailed
> understanding and communication required to leave anything other than a
> small percent of this job to emails, phone calls, or anything other than
> face to face discussion.
> 
You assume that all valid uses of address space are publicly visible
for automated statistics to gather. That simply isn't true.

Additionally, much of the space to be audited is legacy space where
it is not entirely clear ARIN can do much about the situation after the
audit anyway.

> Tech audits are never easy, however, these would be different in some
> respects.  One difference would be with regards to stonewalling.  Every
> auditor and project manager has to deal with stonewalling, but in this
> scenario the case for treating such responses as strong indications of
> hoarding and waste would be compelling, and should result in raising the
> profile of that particular org's audit and also raising its requirements
> for keeping old and requesting new addresses.
> 
Auditing is already done to some extent for each new request. There is
a draft policy in place to expand this. However, there is a big leap of
faith in between beginning to audit and actually reclaiming significant
amounts of address space.

Do you have any evidence that there are significant quantities of
non-legacy address space available to be reclaimed at the end of
an audit process? Even a basis for credible suspicion?

> As with any audit this one should be based on pre-defined policies to the
> extent possible.  Those policies would have to insure confidentiality,
> indemnification (for auditors and whistle-blowers), and strong
> disincentives for failing to facilitate the auditor's task at a minimum.
> 
ARIN really doesn't have any ability to protect whistle-blowers or to
provide much in the way of disincentives for failure to cooperate.
That would require legislation, not just ARIN policy. Since ARIN
deals with resources in at least 24 national jurisdictions, legislation
would be complicated at best.
> 
> That's probably not a productive motivation for an IPv4 audit.  An
> auditor would have to be equally aware of both the need for an IPv6
> transition and the real-world barriers to that transition.  Agendas like
> some (including myself) have expressed with regards to IPv6, NAT, GUA,
> etc. would have to take a back seat to understanding and appreciation of
> day-to-day operational realities and, most importantly, organizational
> budgeting and politics.
> 
An auditor as you are describing shouldn't actually bring any opinions
on IPv6 transition or any of the other factors to the table at all. To the
extent possible, the auditor should be strictly looking at whether the
address utilization is sufficiently efficient according to ARIN policy to
justify the address space held and making a report of that fact or of
the extent to which the organization in question is out of compliance
with ARIN policy.

The next step would be for staff to institute voluntary or forced reclamation
procedures as required under section 12 after the audit, if the organization
is significantly out of compliance.

> If my experience working at orgs who have and continue to hoard /8s and
> /16s is representative, the amount of recoverable address space using
> this methodology would be upwards of 20% of all IPv4 addresses.
> 
Are those orgs hoarding ARIN-issued space or legacy space? If it's legacy
space, how, exactly do you expect ARIN with no contract and tenuous at
best RFC-based policy to actually reclaim such addresses?

Additionally, 20% is a pretty bold claim. That would require no less
than 51 /8s available to reclaim. Of the 221 available unicast /8s
issued by or available to be issued by IANA, ARIN has received 51.

Accordingly, for ARIN to achieve the return of 20% of all IPv4 addresses,
they would need to prove that 71% of all addresses under ARIN
stewardship, legacy and RSA-bound together, are un-utilized and
subject to reclamation. They would then need to successfully
reclaim them.

First, I think your premise is flawed and that it is very unlikely that
71% of IP addresses in the ARIN region are wasted. I don't think
the number even approaches 20%, but, 71% is an outrageous
claim.

Second, even if we assume that 50% of all legacy addresses are
un-utilized, reclaiming them may well be an impossible legal
battle.

On a theoretical level, if there is demand for address space, then
NRPM 8.3 should lead to the majority of the possible reclamations
without need for massive resources invested into auditing as there
will be available financial incentives to organizations to make
space they do not need available to organizations that need it.

I don't expect NRPM 8.3 to be particularly effective. I do expect it
to be much more effective than any such forced reclamation
effort could possibly be and on a much more timely basis.

Owen




More information about the ARIN-PPML mailing list