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

[rpd] Some thoughts, and some actions required

Andrew Alston Andrew.Alston at liquidtelecom.com
Fri Jan 29 02:44:14 UTC 2016


Hi Scott,

I believe there are two options here.


a.)    We leave the soft landing policy as it is and we get a transfer policy that kicks in the day AfriNIC enters Exhaustion Phase 2 (This still leaves the availability of /13 blocks until there is a /11 worth of non-reserved space left)

b.)    We scrap Exhaustion phase 1, so that the moment we hit the last /8 we move straight into Exhaustion phase 2, and we get a transfer policy that kicks in at the same time as the soft landing policy.

What I have said repeatedly is my fear that we hit depletion (or exhaustion phase 2 as per the current policy), and we are without a transfer policy that allows for users to get the space they need on the open market.

I also believe that in the current soft landing policy, irrespective of option (a) or (b) above, we need to clarify section 3.9 and what that /12 reserve is for.  I think we’re close enough to slightly better clarify this section.

Andrew

From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: 28 January 2016 23:26
To: Andrew Alston <Andrew.Alston at liquidtelecom.com>
Cc: rpd at afrinic.net
Subject: Re: [rpd] Some thoughts, and some actions required

I agree that a transfer policy (that activates as soon as the first valid request cannot be satisfied by AfriNIC due to insufficient IPv4 space, if not before) is necessary to minimize disruption to African networks that need to continue using some amount of IPv4 (hopefully alongside IPv6) after run-out.  The recent discussions toward that end in the LACNIC region may be instructive there.

I would also suggest that at the very least the AfriNIC community consider an addition to the soft-landing policy that sets aside an IPv4 block dedicated to facilitating IPv6 deployment, by making IPv4 addresses available for IPv6 translation technologies, dual stack DNS servers, etc.  Something like https://www.arin.net/policy/nrpm.html#four10 could be implemented either by carving out a pool out of AfriNIC's existing inventory, or by dedicating space newly redistributed from IANA for the purpose.  Alternately, a RIPE/APNIC style "one block per network" soft landing policy would accomplish a similar objective: making sure that future new entrants can continue to receive enough IPv4 addresses to talk to the legacy IPv4 Internet while using IPv6 for most of their internal addressing needs.  Such an approach may be simpler to model and implement, but will likely require a larger block to be set aside to make sure it doesn't run out over a reasonable timeframe, which means it would have to be implemented sooner (before the free pool is completely used up).

If anyone has any questions about what has worked well in other regions, please speak up: there are a number of us from outside the region who would be happy to answer questions, but it will be up to the AfriNIC community to draft and adopt policy for Africa.

-Scott (speaking solely for myself, without hats, based on my own personal observations)

On Thu, Jan 28, 2016 at 12:28 PM, Andrew Alston <Andrew.Alston at liquidtelecom.com<mailto:Andrew.Alston at liquidtelecom.com>> wrote:
Hi Owen,

I simply proposed two options for what is coming.  Please be assured it is not the run out of IPv4 that I fear, it is the run out in the absence of a transfer policy that allows those that still need some (however limited) v4 access to some.

How that is achieved is not really a concern to me, but achieved it must be because the reality is, even in a nat64-pt world, for some time at least some degree of v4 will be necessary.

I think that the depletion has very positive aspects because it will spur the development of v6, but we also cannot be unrealistic, and hence I am pleading with this community to work together to look for a way that does not prolong v4, but at least preserves the African internet ecosystem which sadly is very far from ready for the inevitable thud.

Let's get together, get a transfer policy in place that makes sense and go forward into whatever the night shall bring, but in this case, believe me, I am not raging at the dying of the light, because the bulb is already terminal


Andrew
Sent from Outlook Mobile<https://aka.ms/sdimjr>

_____________________________
From: Owen DeLong <owen at delong.com<mailto:owen at delong.com>>
Sent: Thursday, January 28, 2016 21:28
Subject: Re: [rpd] Some thoughts, and some actions required
To: Andrew Alston <andrew.alston at liquidtelecom.com<mailto:andrew.alston at liquidtelecom.com>>
Cc: <rpd at afrinic.net<mailto:rpd at afrinic.net>>



On Jan 28, 2016, at 07:25 , Andrew Alston < Andrew.Alston at liquidtelecom.com<mailto:Andrew.Alston at liquidtelecom.com>> wrote:

Hi All,

So, I was analysing some of the latest publicly available numbers on AfriNIC space and allocations.  What follows is a summary of that analysis, and then some points that need to be discussed.

AFRINIC as of the last report I have seen had 30.6 million addresses still available (This may have dropped since that figure came out).
AFRINIC allocated 16.9 million addresses last year.
The allocation rates for 2015 are up 35% from 2014, and in 2015 and 2014 combined we allocated a total of 29.4 million addresses.  This is approximately double what was allocated in 2012 and 2013 combined.

Based on a 35% increase in the rate of allocation from 2015, and there is little reason to doubt this will happen, we will be in soft landing in July of this year approximately.

Due to the fact that the current soft landing policy still allows extremely large allocations, this will not significantly slow down the allocation rates, and if anything, moving into soft landing may well spur more people into action and applications, which could actually INCREASE the rate of allocation.  Should the allocation rate remain unchanged, Africa is out of space by late March/Beginning April 2017.

Now, things to consider.

A.) The soft landing policy ideally needs to be changed to drastically tighten the allocations in the soft landing phases, and if we plan to do this, we have ONE chance to get it right, and that’s in Gaborone.  If we fail to pass a modification to that policy at the Gaborone meeting later this year, there will be no more time left to do anything to prevent total depletion.
B.) Total depletion is coming, and nothing can stop it, and we no longer have years of IP space left in the AfriNIC pool.  This means that without a transfer policy of some form of another, be it intra-RIR or inter-RIR, anyone who does not get space within this period, will not be able to get space within the AfriNIC region, at all.  (Unless they go and join out of region RIR’s and transfer to the entities they register in those out of region RIRs, but it will be an entirely off continent process).

I’m not convinced that any change to the soft landing proposal is necessary. Frankly, AfriNIC’s anomalously long runout period is, IMHO, doing more harm than good at this point.

Anyone still building out network infrastructure with the assumption of continuing IPv4 address availability is delusional and severely misguided.

AfriNIC’s free pool has already lasted well beyond every other RIR.


So, we can continue to sit and argue with our heads in the sand, or we can realise, we have one more policy meeting left before soft landing, and possibly one more meeting after that before total depletion with the current policies.  We either leave all politics that normally is so pervasive in the discussions behind and make some meaningful strides towards serious policy change, or we fully accept that the end of IPv4 is here and we are going over the cliff, like it or not.  There are no other options.

No matter how much you change policy, the end of IPv4 is here and we are going over the cliff. The policy choice remaining is the choice of where in the spectrum of tumbling slowly to the bottom of the ravine while maximizing injury and pain along the way vs. a long rapid drop followed by a very loud thud.

The current policy seems to favor the loud thud. What you seem to be advocating is the longer, slower, more painful tumble.

They both end up hurting, but with the thud, the pain does not last as long. The cliff is not so tall that anyone will die, but the sooner we get to the bottom, the sooner we can patch things up and move on with IPv6.

So, lets discuss, how do we deal with what is coming.  Let me also state, the argument that was made in Pointe Noir that some how AfriNIC will save us from depletion is completely inaccurate.  AfriNIC as an organisation cannot act outside of the auspicious of policy, and that means the community as a whole, has to work together if they want change, or accept that together we run of out space and do whatever needs to be done after that day.

The idea that AfriNIC as an organization can somehow save us from depletion (regardless of what changes are made to policy) is ludicrous. There are only 3.2 billion unicast IPv4 addresses in the entire system. There are more roughly 7 billion people on the planet. We are moving towards a world where each person will need at least 5 IP addresses (laptop, desktop at home, desktop at work, tablet, smart phone) and you still need to account for servers, datacenter infrastructure, network infrastructure, etc. No matter how you slice it, we probably need about 60 billion IP addresses, so trying to squeeze all of that into 3.2 billion just isn’t going to work no matter how hard you try.

Lossy compression may be OK for video and audio files, but it’s really not good for most things in the real world (automobiles, aircraft, and network addresses, for example).

Runout is coming. Any effort to avoid it only serves to extend the pain of the process and inflict more damage along the way.

Owen




_______________________________________________
RPD mailing list
RPD at afrinic.net<mailto:RPD at afrinic.net>
https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160129/bd7957fd/attachment-0001.html>


More information about the RPD mailing list