[AfriNIC-rpd] Last Call: IPv4 Soft Landing Proposal

[Alan Barrett]

On Wed, 23 Jun 2010, McTim wrote:
> I'm going on safari to USA soon, and will be unable to participate in
> policy discussions until August, so here is my preemptive reaction to
> the upcoming last call:
> 
> I must object quite strenuously to this policy and to it's being put
> to Last Call on both policy and process grounds.

OK.

> Policy objections:
> 
> 1. It aims to promote adoption of v6 by trying to lengthen the
> lifetime of IPv4.  This seems contradictory to me.  By making v4 last
> longer, we are only retarding the growth of IPv6
> usage.

I think that proposed rewording of the "Incentive" fixes that contradiction.

> 2. The stated objectives of all RIRs are Conservation, Aggregation and
> Registration.
> 
> See slide 33 of http://www.afrinic.net/training/materials/Member-Training-v2.pdf
> 
> This policy negates 2 of those objectives.   It actively promotes
> deaggregation by setting an artificially low maximum allocation size.
> Currently our maximum allocation size is a /10.  This policy limits
> LIRs to a /23 in the exhaustion phase, thus mandating the announcement
> of multiple /23's.  This does not limit routing table growth, instead
> it encourages it.

Sure.  Note that this will happen only during the Exhaustion Phase,
at which time there will be very few IPv4 addresses available; the
alternative to setting a low maximum size would be setting a higher
maximum size.  I saw consensus in the public policy meeting for setting
the maximum at /23.

> In terms of conservation, the intended consequence of this policy is
> to reserve a /12 for future use, which is an idea I support.  However,
> the UNINTENDED consequence of this policy is to reserve the majority
> of the last /8, by "locking up" most of the 16 million IPs of the last
> /8.
> 
> quoting GB:
> 
> "You limit each LIR to a /21 of addressing resources. That provides
> for 7680 (excluding the reserved /12) LIRs to obtain maximum
> allocations. AfriNIC currently has 1009 members and a growth rate of
> less than 100 members per year[1]. This means that at the end of 5
> years 80% of our final /8 will be locked up and un-allocatable under
> this policy."

This would be true if the policy applied only to LIRs, but I saw
consensus at the public policy meeting for making the policy apply
to both LIRs and End Users.  There could be vary many End Users, and
of course there's scope for changes to the policy based on future
experience.

> Conservation is one thing, however making a large portion of the /8
> "un-allocatable" as an unintended consequence is not only overly
> conservative, it is absurd and bad policy making IMHO.  In other
> words, while trying to extend the lifetime of v4 in this region, we
> are making it much shorter artificially!!
> 
> The response I got to this objection at he meeting is that "none of us
> know what the environment will be in the future".  While this is
> correct, it does not seem unreasonable to conclude that the current
> growth rate of LIRs will not change substantially due to consolidation
> in the ISP market.  Even if we quadrupled the number of LIRs in 2
> years, we would still be "locking" a substantial portion of the last
> /8.

I think that the response you got in the meeting was that there could be
many more end users than LIRs.

> On process, I just didn't see the consensus that the PDP-MG did in the
> room or on the list on this one.  Points out that we do indeed need a
> new PDP.  But that one is for another day ;-)

I was unhappy with the way the PDP-MG declared consensus, but despite
that, I believe that there was consensus on the proposal as a whole,
subject to several changes that were discussed.  The changes that I
remember included:

  * After the transition to the Exhaustion Phase, all allocations or
    assignments follow the new rules, regardless of whether or not they
    are filled from the Last /8.

  * Both LIRs and End Users can get address space during the Exhaustion
    Phase.

  * The rule about no more than 10% being used outside the AfriNIC
    region applies separately to each allocation or assignment.

--apb (Alan Barrett)