[arin-ppml] Policy Proposal: Protective UsageTransferPolicyforIPv4 Address

[Leo Bicknell]

In a message written on Wed, Feb 11, 2009 at 02:38:18PM -0500, Chris Malayter wrote:
>    I think what the author was trying to do was to bring light to the
>    situation without turning this into a discussion about a particular
>    corporation, and in fact was trying to bring light to, this COULD
>    happen.  If the community does not want to have a policy in place to
>    protect people from this happening, that's one choice, I think he was
>    hoping for the alternative.

This case is very interesting because it involves many critical
infrastructure providers in a single upstream block.  Let's go ahead and
forget the current situation though, and look at it through a more
objective lens.

From the PPML (https://www.arin.net/policy/nrpm.html#four4):

] ARIN will make micro-allocations to critical infrastructure providers of
] the Internet, including public exchange points, core DNS service
] providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as
] well as the RIRs and IANA.

If we were to use the same definition of critical infrastructure, what
is the impact?

In the root zone there are 1045 name servers listed for TLD servers:

% dig axfr . @f.root-servers.net | grep "IN[^A-Z]*NS" | awk ' {print $5}' | sort -u | wc -l
    1045

Plus of course the 13 root servers themselves.  I'd like to point out
though this number is wobbly:

  - This number may be too high, as some number of these nameservers 
    are already in ARIN provided micro-allocations.

  - There is no easy way to break out which of these are in the ARIN
    region.

  - This number may be too low, as many of these nameservers are
    anycasted and the policy would allow them to get space for multiple
    sites.

There is another significant difference from the case we've been
discussing.  Where these hosts are in PA space they are unlikely
to be in a single upstream block of PA space.   Even if you assume
a reasonable number like three or four hundred TLD operators who
could complain, they are likely to be in three or four hundred
different blocks.

As such the vast majority of the cases will be a provider with a
large (/14-/18) PA block having perhaps one critical infrastructure
(/24?) allocation in it.  This policy would allow that one allocation
to hold up the transfer of an entire larger block, which may in
fact be otherwise empty.

Indeed, if the average PA block was a /16, and only 256 critical
infrastructure users used the process detailed in this policy that
would place an entire /8 in limbo.

There is also a billing issue.  If a PA provider attempts to "kick
out" a critical infrastructure holder and they appeal, winning even
just a six month hold that may well result in the upstream having
to pay another year of ARIN fees.  I think this would be the first
time ARIN policy forced a provider into a situation where they had
to pay fees, as today they can always just return the block prior
to the next renewal.

Lastly, it sets bad precedent.  The community has provided a mechanism
for critical infrastructure to avoid this problem, and to provide more
special treatment now is hard to defend.  Indeed, if the folks who have
a mechanism out of this issue need help, that would only strengthen the
argument in my mind that the average user would need help which is an
entirely different, and several orders of magnitude larger can of worms.

So to summarize the problems with such a proposal on the merits:

  - There are multiple ways out that have not yet been exhausted.
  - It affects too many people, this could result in hundreds of appeals
    for ARIN.
  - It creates billing, and by extension liability issues.
  - It sets bad precedent.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090212/ad0be1b3/attachment.sig>