Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Auwal Tata tatauwal at
Wed Jun 23 13:12:46 UTC 2010

Thanks MCTim, now somebody is actually thinking my direction. I raised
this issue during the Afrinic meetings in Kigali. I said limiting an
LIR to a /23 that will eventually subnetted and given out to endusers
will be grossly inadequate. /23 only contains 2 /24s with just 254
usable IPs how many end users can be accommodated with that. This will
only encourage NATting. I dont suppose that exactly conforms with our
I believe some of us have this sentimental attachment  to IPV4 will
not want to let go. I strongly think allocation of IPV4 should
continue as is so it gets exhausted, then people will realise how much
they need to move to IPV6.


On Wed, Jun 23, 2010 at 1:35 PM, McTim <dogwallah at> wrote:
> All,
> 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.
> 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.
> 2. The stated objectives of all RIRs are Conservation, Aggregation and
> Registration.
> See slide 33 of
> 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.
> 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."
> 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.
> While my crystal ball may be just as foggy as others, in the
> theoretical situation where each of the existing LIRs (~1000 now and
> approaching 1500 in 3 years time) has gotten all of their possible
> allocations AND demand by endusers for IPv4 is still high, then there
> is only one possible outcome (unless we change this policy at some
> point).  That outcome is a surge in demand for PI (EndUser) blocks.
> Both Aggregation and Conservation depend upon LIRs requesting
> resources they need.  This is our mantra (some of our critics call it
> our "religion" see Milton Muelller).  We are changing that due to the
> perception (not the reality) of a shortage of IPv4 blocks in this
> region.  While it still holds true for v6, we are shooting ourselves
> in the v4 foot.
> 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 ;-)
> --
> Cheers,
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> _______________________________________________
> rpd mailing list
> rpd at

More information about the RPD mailing list