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

[rpd] LACNIC reaches final /10 of IPv4 space

Andrew Alston Andrew.Alston at
Wed Jun 11 06:47:50 UTC 2014

Hi All,

As far as I can see it the following should be considered.

Firstly, our continent is far to NAT dependent, and this is in everyone's disadvantage.  From a network provider perspective, clients who run NAT are more likely to churn due to ease of renumbering.  From a client perspective, the limitations on end to end communications can introduce problems.  From a security perspective, the ability of individuals with nefarious purpose to hide behind NAT creates problems. As such, I'd argue that using our remaining space to remove the heavy NAT we see on this continent would be advantageous.

Further to this, the removal of NAT actually encourages the adoption of IPv6, it is far easier to dual-stack a network with IPv6 if you can run a single topology without worrying about the IPv4 translations.  The question is, how do we encourage people to move away from a legacy behavior that is in their disadvantage but for so long as been painted as a security mechanism (which it most certainly is not, and there are multiple papers to back this perspective available).

Secondly, we need to consider if we wish to encourage end user adoption of IPv4 space, or encourage further takeup of space by LIR's.  There is a key differentiator here, and it actually creates an interesting conflict.  From a provider perspective, having clients numbered on their space again, reduces churn and is in the advantage of the provider (LIR), from a client perspective, having provider independent space makes them more portable, grants the easy ability to multi-home and in many instances it may be easier for them to obtain end user space than to get it out of a provider.  That however comes with the disadvantage that the end user who chooses this route will probably need to think about running BGP (particularly if they are multi-homing), or alternatively having their sole provider announce on their behalf, this creates complexity that can lead to a rise in OPEX.

Either way though, I believe we need to encourage the adoption of our space by whatever reasonable means are possible.  Sitting on a large pool of IPv4 space that is being unallocated disadvantages the continent in a multitude of ways, including, but not limited to:

a.)    The amount of V4 space sitting unused discourages the adoption of IPv6, which in the long term holistic sense is bad for the continent in general

b.)    The large pool encourages dodgy vendors to come with an argument that we don't need V6 any time soon so we can be a legacy hardware dumping ground

c.)     A greater adoption of V4 by the general community will lead to a greater economy of scale in terms of allocation and management of space within the RIR.

Hence, I'd welcome any ideas as to how to drastically encourage the uptake of the V4 that is sitting unused in our pool.

Note: This thoughts represent my personal views and are in no way stated as board perspective or the perspective of any other entity to which I may be associated.



From: rpd-bounces at [mailto:rpd-bounces at] On Behalf Of Kris Seeburn
Sent: Wednesday, June 11, 2014 8:43 AM
To: rpd
Subject: Re: [rpd] LACNIC reaches final /10 of IPv4 space

There are two ends to it.

 *   We either look at a policy to protect our ipv4 space which would actually defeat the full push of ipv6
 *   Or we find ways to deplete our ipv4 space faster that we can move to ipv6 faster

We all know that most hosting / ecom sites are still based on ipv4 infrastructure though. As much as we need to protect the ipv4 space we still need to push the ipv6 space. Afrinic nevertheless still has a good deal of ipv4 space. The question is how do we move both agenda forward?

I think obviously we need to look at our policy and what can make things work for us. A sharing or sales of ipv4 space with other RIRs as need may also look as a better way of still protecting the precious space whilst still making money out of it. I am not sure. I think this is still a dilemma we all need to figure out.

NB: This is not a board perspective but my personal take at it.


On Jun 11, 2014, at 9:17 AM, Bope Domilongo Christian <christianbope at<mailto:christianbope at>> wrote:

Thank you Alan and seun, this an important  milestone, having a policy to protect our critical resources will be great.
With best regards,
writing on my personal capacity.

On Wed, Jun 11, 2014 at 4:13 AM, Seun Ojedeji <seun.ojedeji at<mailto:seun.ojedeji at>> wrote:

Thanks for this update Alan, from all indication it will seem that v4 exhaustion time within AfriNIC region may be sooner than earlier predicted.

Should this region be worried?... maybe:
- More content in those region where v4 is getting exhausted will go v6 but then v6 deployment in our region is relatively low (someone says there is translation to the rescue)
- Our region will continue to experience an increase in v4 requests from organizations that are more domicile in regions with v4 exhaustion. Perhaps this could be an opportunity to "by policy" improve ISP establishment in our region? Maybe yes. Should we also "by policy" ensure addresses within this region are used more within the region.... how do we encourage this as the region seem to be comfortable with *translation*. Can policy make this happen?

PS: My views alone.
sent from Google nexus 4
kindly excuse brevity and typos.
On 10 Jun 2014 17:23, "Alan Barrett" <apb at<mailto:apb at>> wrote:
Three weeks ago, on 20 May 2014, LACNIC's available pool of IPv4 space became less then a /9 equivalent.  This triggered the activation of IANA's Recovered IPv4 Pool in terms of Global Policy GPP-IPv4-2011.

Today, 10 June 2014, LACNIC's available pool of IPv4 space became less than a /10 equivalent (4194302 IPv4 addresses).  This triggers LACNIC's IPv4 exhaustion policy.

Announcements from 20 May 2014:

Announcement from 10 Jun 2014:

--apb (Alan Barrett)
rpd mailing list
rpd at<mailto:rpd at>

rpd mailing list
rpd at<mailto:rpd at>

rpd mailing list
rpd at<mailto:rpd at>

Kris Seeburn
seeburn.k at<mailto:seeburn.k at>


DISCLAIMER: This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, copy, print, or rely on this email. We cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of this company or one of its agents.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list