[arin-ppml] The Library Book Approach to IPv4 Scarcity

[Chris Grundemann]

This is (yet another) a policy that may help us ease away from IPv4,
maintain contact between ARIN and it's members and maybe even avoid a
transfer market.  I have been kicking the general idea around for over six
months and it has recently matured with input from some very intelligent
folks.  I do not want to associate them with this particular idea
unwittingly so I won't name them here but I would like to thank them here
anonymously - thank you.  It is not an official proposal yet as I fear that
there won't be much support for it.  If you do think that this is a good
idea or at least on the right track, please let me know - on or off list.  I
don't want to bang my head against the wall too long if I am alone.  Also,
if you hate it, think I am crazy or just don't think it will work, I would
love to hear why.   Although many have influenced it, this is my work and my
opinion alone and does not represent the views of any organization or
individuals I may be affiliated with. ((IMHO))
Thank you,
~Chris


== Potential Proposal:

Once every 12months each holder of IPv4 addresses is required to fully
document their IP utilization and demonstrate that the current utilization
standard for IPv4 assignments and allocations is being met. This shall
include all currently held IPv4 space, regardless of origin or registration
status.

A fee shall be assessed for underutilization or insufficient documentation.

    * The fee for one 12m period shall be waived if the address holder
returns a contiguous block of IPv4 space equal to at least 1/256th of
currently held space and no less than one /24 (class C equivalent) to ARINs
free pool.
    * The fee for one 12m period shall be waived if the address holder signs
an ARIN RSA for any uncontested and unregistered IPv4 space, this waiver
shall be restricted to one use per member organization.


== Rationale:

IP space (v4, v6, vX) is a public resource and as such should be borrowed,
used and returned by those with a need for it. Think of IPv4 prefixes like
library books (another finite public resource): When you check out a book,
you are expected to return it on a certain date. If that date comes and you
are still actively using the book, you are allowed to state that and keep
the book. Since we are at a point now where IPv4 space is recognizably
finite, it makes sense to implement a similar policy at the RIR(s) - that is
a time frame. This policy would require that after X amount of time, the
LIR/EU would need to return to the RIR with justification if they wish to
keep the space. The burden should be on the LIR/EU to prove that they are
actively using the space.


== Some thoughts:

1) This policy should be part of a comprehensive plan including:
- A policy to identify abandoned space
- A policy to reclaim abandoned space
- A policy to restrict some (if not all) IPv4 space allocations/assignments
to new entrants deploying IPv6
- A continuing increase in utilization requirements

2) I do worry that some (perhaps many) will try to game the system by
exaggerating or falsifying 'proof' of efficient utilization. At the same
time I think that having that caveat will make this much easier for most to
swallow and hopefully accept than a similar proposal which assessed the fee
to all holders of IPv4 space regardless of utilization. The idea (hope) is
that as IPv4 becomes more and more scarce, the community will raise the
utilization requirements to include things like NAT and IPv6. This would
provide a constant pressure on all community members to become more
efficient in their IPv4 use which in turn should help keep some addresses
free for new entrants. This is the opposite effect of an unrestricted market
based approach which would encourage large holders of addresses to hold more
and more IPv4, to store value and bar new competition.

3) I am not sure what the fee should be or if it should be spelled out in
policy, this is probably something that ARIN staff should set and be able to
change when needed. Perhaps the policy should define simply how the fee is
assessed, ie: per IP or per % underutilized, etc. It may also be helpful or
necessary to add a statement in the policy requiring any proceeds from these
fees to be used for something in particular (legacy outreach, IPv6
promotion, payment/credit to orgs with utilization above the efficiency
requirement, etc).

4) I expect that some (possibly many) organizations will find it easier to
simply return some space than even trouble themselves with trying to justify
their current holdings. This will be especially true of organizations which
hold large amounts of space.

5) I am expecting that bringing resources under an ARIN RSA may be easier
and less painful for organizations which already hold other RSA covered
space than a full IP audit or returning space. Under this assumption the
final sentence has two goals:
A) To help incent organizations to secure legacy space in any existing or
inevitable grey/black market early on (and get it over with). If there are
no back-room deals for exchange of legacy space now or in the future, than
this is not an issue and can be ignored, this policy will have no affect in
this area.
B) To get any transfered legacy IPv4 space (see point A) under an RSA so
that we are all playing on the same field by the same rules. I think if
everyone had a more similar role in the game we might work together better.
I will note however that legacy holders with no RSA covered space have no
increased incentive to sign an RSA under this proposal then they do today
(and no increased risk in not signing one).

6) I originally considered a period of 24 months but shortened it to 12
months considering the rapid approach of IANA free pool exhaustion; 24
months will be far to long of an interval to have a significant impact on
IPv4 availability.


-- 
Chris Grundemann
www.chrisgrundemann.com
www.linkedin.com/in/cgrundemann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081027/ab2025bf/attachment.htm>