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

[rpd] Re: [members-discuss] Virtual Africa is the logical target for IP address colonists

Seun Ojedeji seun.ojedeji at
Wed Jun 18 20:18:45 UTC 2014

sent from Google nexus 4
kindly excuse brevity and typos.
On 18 Jun 2014 20:43, "Stephen Wilcox" <steve.wilcox at> wrote:
> So..
> This reminds me of one of the many stories, metaphors, proverbs where
people try frantically yet in vain to stop something from happening which
is already an inevitability... choose the one that you prefer to relate to
the story of AfriNIC's remaining IPv4 address space.
> First, just a reminder, but AfriNIC has 3x /8s remaining, this compared
to other RIRs which each burned 3x /8s in just over a year... so its very
much the case of trying to stop a flood which is already underway.
I don't think the community is stopping the flood, just that the community
wants the flood to flow within it's region as much. Just like it happened
in other region.

> Second, remember the general rule of thumb that the more complicated the
policy the more holes and exceptions and easier it will be to circumvent.
> So, if you want the goal to be to preserving space for use in the African
region then follow the logical rules to make policy:
> 1) Address space only be made available to African *owned* companies
> 2) Address space only justifiable for allocation for African *based*
> 3) A cap on the maximum amount of space an LIR can obtain *regardless of
justification* - perhaps one level for now, and a lower level when the
final /8 is reached (RIPE implemented a /22 per LIR for example when the
final /8 was reached)
There is a similar final /8 policy for this region.

> 4) Consider imposing a requirement on LIRs/end users to demonstrate they
are running IPv6 to the extent of their ability (limit of
upstream/downstream technology without significant investment) after the
initial IPv4 allocation before granting larger IPv4 blocks.
Would you be kind to turn this into policy?

> As a curiosity, its interesting that whilst innovation comes
traditionally from research and education, it seems to be the special case
of RENs that they want more than anyone to have access to more IPv4
And you don't think those RENs could burn v4 faster by applying them on
their networks. Why do you think RENs should not get v4?

In fact, they are the ones who can lead IPv6, CGNAT and produce trained
engineers who later move from education to industry taking their modern
technology with them.
CGNAT? Maybe not. I guess they already have enough experience in that and
may not be a desired transfer skill. Nevertheless I think every
institution that apply for v4 also get a v6 so I guess there is/will be
room for research on both v4 and v6 as we both know that those two protocol
will stay side by side for a while.

Personal view.

> - my 2 cents :)
> Steve
> On 18 June 2014 19:58, Adiel Akplogan <adiel at> wrote:
>> [I think that the discussion has taken a path which now need it to be
moved to the rpd list]
>> On Jun 18, 2014, at 17:13 PM, Douglas Onyango <ondouglas at>
>> > On 18 June 2014 12:02, Adiel Akplogan <adiel at> wrote:
>> >> In this discussion I don't think the real challenge is about
organisations that already have a well established footprint in the region
trying to expend their network out of Africa, but rather about how far an
IP Analyst can go using his/her own judgment in cases where a company (new
or not) recently decide to enter the IP service business/market and is
requesting resources that will obviously be used in majority (up to 5%-90%
as we already seen) outside of the region.
>> >
>> > I agree with the problem description. I have said the same thing in a
>> > previous email and also mentioned that the policy I am drafting will
>> > strike a balance between the two interests.
>> Good to hear this.
>> - a.
>> _______________________________________________
>> rpd mailing list
>> rpd at
> _______________________________________________
> rpd mailing list
> rpd at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list