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

[rpd] inputs on IPv4 Inter-RIR policy proposals - AFRINIC needs this policy now!

Lee Howard lee.howard at
Fri Jun 28 15:59:55 UTC 2019

Years ago I looked at the economics of IPv4 address supply.

I was wrong in my predictions about timing: I concluded that the market 
would be exhausted of addresses much sooner because I didn't account for 
people hoarding before run out. I knew it, but I couldn't figure out how 
to analyze it.

I said that there might be about 520 million IPv4 addresses that were 
under utilized (read the paper for my reasoning). About 150 million 
addresses have been traded.[1]

There are 1.2 billion people in Africa[2]. Out of four /8s [3], roughly 
65 million addresses, Afrinic has .3 /8 remaining,[4] less than 5 
million addresses. Only 36% of Africans have Internet[5], making 768 
million Africans still to be connected.

Africa, as a region, has both the lowest deployment of IPv6 and the most 
people left to connect. Even at a NAT ratio of 10 users to 1 IPv4 
address, Africa is still short by 100 million users, or if people have 
more than one device, several times that number.

By comparison, 4.4 billion users globally have Internet[6], out of 7.7 
billion. I make that as 2.5 billion non-Africans needing Internet addresses.

So 768 million Africans to be connected have less than 5 million 
addresses, plus some fraction of 64 million underutilized addresses that 
can be traded within the region. 0.006 addresses per person.

2.5 billion non-Africans to be connected have 370 million underutilized 
addresses to trade. 0.148 addresses per person.

Based on scarcity, Africa has the greater need for addresses. Economists 
describe markets as a way to distribute resources according to their 
best and highest use. Since that's hard to quantify, they use money as a 
metric for best and highest use. Africa has the greatest need, and 
addresses there would serve better (potentially more people) than 

If the only supply is within the region, the prices will be much higher 
than outside the region. If in a year IPv4 addresses are US$30 each, 
they could be US$50 each in Africa, which makes them unaffordable for 
many companies. Prices would be the same everywhere if all regions 
allowed inter-RIR transfers. But there still isn't enough supply.

A company can save money on IPv4 addresses and CGN by deploying IPv6. 
But it's too late to deploy IPv6 before Afrinic runs out of addresses. 
Addresses will run out, and the market will not be able to satisfy the 
need for addresses. ISPs and mobile carriers everywhere in Africa will 
have to deploy CGN, and at higher density than elsewhere in the world. 
The cost for businesses to connect will be much higher, since they need 
inbound access and therefore unique IPv4 addresses. African Internet 
deployment will stall, all because IPv6 has not been deployed and there 
is no way to get more IPv4 addresses.

Are those the kind of numbers you were looking for?








On 6/28/19 9:30 AM, Noah wrote:
> On Fri, Jun 28, 2019 at 4:17 PM Andrew Alston 
> <Andrew.Alston at 
> <mailto:Andrew.Alston at>> wrote:
>     Are you not asking for the identical thing?
>     You have absolutely zero empirical data about how much space will
>     supposedly flow off the continent – and I strongly dispute that it
>     will – because I don’t believe there is enough of it on the
>     continent as it is to even serve current needs.
>     We’re being asked to refuse support for as policy based on fear
>     mongering that has no evidence to support said fears
> There is historical evidence to show that other resources (non-INR) 
> have left the continent to the benefit of other regions but Africa. 
> Show them the $$$ and they will dance.
> I had a very interesting discussion with one of the IPv$ brokers and 
> and he surely cant wait to trade some of the space in our region. I 
> will not go into the details of that discussion but it was enough for 
> me to personally stay firm to my opposition of any policy that would 
> open room for resources meant to be used in our region being traded 
> fast due to economic reasons beyond the real purpose they were meant 
> for which is to help build the African Internet Infrastructure.
> You think its fear mongering, but I can assure you that money is money 
> and people dont play around when it comes to money.
> Noah
>     Andrew
>     *From:*Boubakar Barry <boubakarbarry at
>     <mailto:boubakarbarry at>>
>     *Sent:* Friday, 28 June 2019 16:01
>     *To:* Andrew Alston <Andrew.Alston at
>     <mailto:Andrew.Alston at>>
>     *Cc:* Noah <noah at <mailto:noah at>>; JORDI PALET
>     MARTINEZ <jordi.palet at
>     <mailto:jordi.palet at>>; RPD <rpd at
>     <mailto:rpd at>>
>     *Subject:* Re: [rpd] inputs on IPv4 Inter-RIR policy proposals -
>     AFRINIC needs this policy now!
>     On Fri, Jun 28, 2019 at 11:29 AM Andrew Alston
>     <Andrew.Alston at
>     <mailto:Andrew.Alston at>> wrote:
>         You’re asking for the impossible – because to get that you’d
>         need to go to all the brokers (I assume)
>     So, we jump into the dark, with no parachute (data would have
>     helped somehow), all eyes closed? Keeping them open in these
>     circumstances won't help anyway.
>     Boubakar
>         *From:*Noah <noah at <mailto:noah at>>
>         *Sent:* Friday, 28 June 2019 14:17
>         *To:* JORDI PALET MARTINEZ <jordi.palet at
>         <mailto:jordi.palet at>>
>         *Cc:* RPD <rpd at <mailto:rpd at>>
>         *Subject:* Re: [rpd] inputs on IPv4 Inter-RIR policy proposals
>         - AFRINIC needs this policy now!
>         So Jordi,
>         I still oppose this policy with strongest terms possible. I
>         still believe IPv4 space will leave our region so fast when
>         holders of Idle space who are yet to put them to good use as
>         was allocated/assigned will trade them for some dollars rather
>         than return them to AfriNIC. What we need is a policy that
>         would discourage IPv4 from being transferred out of the region
>         because of attractive prices of IPv$ but rather encourage more
>         space coming into the region.
>         We already have a transfer policy that can facilitate internal
>         transfers withing our region and I am keen of getting a report
>         from AfriNIC on how this is going.
>         @Jordi, please also share some statistical numbers of
>         available IPv4 space that would actually come into our region
>         so that we can work with figures rather than assumptions.
>         Noah
>         On Sun, Jun 23, 2019 at 7:01 PM JORDI PALET MARTINEZ via RPD
>         <rpd at <mailto:rpd at>> wrote:
>             Hi again Sylvain,
>             I’m very thankful for your inputs!
>             We need to make sure that others also participate!
>             See below in-line.
>             Regards,
>             Jordi
>             @jordipalet
>             El 21/6/19 23:15, "Sylvain BAYA" <abscoco at
>             <mailto:abscoco at>> escribió:
>             Hi all,
>             Le vendredi 21 juin 2019, JORDI PALET MARTINEZ via RPD
>             <rpd at <mailto:rpd at>> a écrit :
>                 Hi Sylvain,
>                 I want to thank you, I guess we won a “strong”
>                 contributor to policy discussions! (I recall your name
>                 from previous discussions, but you’re now more active,
>                 which is what I wish from every one).
>             :-D ...please don't expose me too much Jordi ;-)
>             I'm just trying to do my best...i'm not any kind of expert
>             :'-(
>             Now I realized that you were not on-site, pity!
>                  See below, in-line.
>                 Saludos,
>                 Jordi
>                 @jordipalet
>                 El 20/6/19 22:37, "Sylvain BAYA" <abscoco at
>                 <mailto:abscoco at>> escribió:
>                 Hi all,
>                 Please see, inline, below...
>                 Le jeudi 20 juin 2019, JORDI PALET MARTINEZ via RPD
>                 <rpd at <mailto:rpd at>> a écrit :
>                     Hi Sylvain,
>                     Sorry the email was sent before I finished it …
>                     Responding below, in-line.
>                     Regards,
>                     Jordi
>                     @jordipalet
>                     El 20/6/19 15:05, "Sylvain BAYA"
>                     <abscoco at <mailto:abscoco at>>
>                     escribió:
>                     Hi all,
>                     Le jeudi 20 juin 2019, JORDI PALET MARTINEZ via
>                     RPD <rpd at <mailto:rpd at>> a
>                     écrit :
>                         As said, this text is redundant (see specific
>                         text below my signature), but I don't mind to
>                         have explicit text if this facilitate the
>                         community to reach consensus.
>                         Here is my proposal, again, please comment
>                         about this ASAP, so we can submit a new
>                         version already, instead of waiting to be
>                         closer to the next meeting. This way we can
>                         ensure that we get on time the staff impact
>                         analysis, in case something else need to be
>                         amended.
>                         "The Inter-RIR transfers will be automatically
>                         suspended in case the balance between IPv4
>                         out-going and in-coming addresses becomes cero."
>                     Jordi,
>                     ...typos on “zero” ?
>                     Yeah … my spelling checker often confuses English
>                     and Spanish!
>                     Anyway, here is a better version, because this
>                     balance is actually “cero” at the start of the
>                     implementation, so the text may be misleading, we
>                     need to define .
>                 Alright !
>                 I like the new visage of this policy proposal because
>                 i really appreciate the way you are leading the
>                 discussions around it.
>                 Believe me, that I always try to heard everybody
>                 position and accommodate as much as possible, my own
>                 thinking/knowledge and the text to that (or convincing
>                 other if I believe they have a wrong vision). This is
>                 the way to reach consensus.
>             Go ahead on this way ! i declare my support for such an
>             approach, because i'm personaly sharing a similar approach.
>             Hopefully other participants will also share it.
>                 While contributing to this thread, what i want is to
>                 be sure that this policy proposal could be really
>                 beneficial to AFRINIC region|community.
>                 Same as me, again, the right thing to do.
>                     “The Inter-RIR transfers will only be enabled once
>                     AFRINIC enter into Exhaustion Phase 2 (
>                     <>). The Inter-RIR transfers will be
>                     automatically suspended in case the number of
>                     out-going IPv4 addresses exceeds the in-coming
>                     ones by six consecutive months.”
>                 This version is a good starting point. Thanks.
>                 I understand it like this :
>                 * This Policy Validity Starting Point : Exhaustion Phase 2
>                 * Initial point : balance of zero (nothing in|out)
>                 * First auto-stop point : when the in/out balance
>                 becomes down
>                 ..* After 06 consecutive months {seems to be not
>                 interesting for me}
>                 ..* Even 02 consecutive months is not really
>                 interesting, because we miss an #x amount (or %) of
>                 resource (IPv4) limit to not reach at any time
>                 (without any mention of #y consecutive months) to
>                 reduce an unwilling risk.
>                 This policy shall be able, maybe, to stop a
>                 transaction (in course) which could conduct us out of
>                 a specific low acceptable in/out balance. So think
>                 about it again please.
>                 This is not possible, I believe, unless someone
>                 discovers a “magic way to write it down” (which I
>                 can’t see now). Anyway, I’m still trying to think
>                 something before ending this email …
>             ...quite difficult for sure :-)
>             It's simply confirming us that to reach the *goal* of this
>             (and other) policy proposal, we need to think deeply on
>             details. Other meaning : we need more active
>             volunteers|participants engaged with sincere contributions.
>             **EXACTLY!** Meetings time is precious and we aren’t
>             allowed to modify the text of the proposals on-site, we
>             need inputs way ahead!
>                 I’ve not personally been involved in transfers, but I
>                 understand the process and transfers don’t happen “in
>                 the second”. There are documents to review,
>                 justification to be reviewed by the two RIRs,
>                 contracts to be signed, payments to be done (via an
>                 escrow), etc. It is a matter of several days or weeks.
>             Thanks for these clarifications.
>                 It may happen that in the middle of a month, several
>                 “negotiations” for transfers are running, and some of
>                 them in one or the other direction may reach or not in
>                 time for the end of that month. That’s why I’m
>                 suggesting a number of months.
>    my knowledge, to better text this situation (and
>             reach the *goal*) we must considere that the transfer is
>             started when the parties have sent a request to the staff.
>             What we can also do is to add a new section with advices
>             for those who will need to start a inter RIR transfer
>             procedure. On that section, we shall explain why they must
>             not take more than one (?), two or three months to
>             complete the pre-process (b2b negociations). They shall
>             know and understand the risk to come too late to the staff
>             to request a transfer ; because the negociation phase took
>             too much time... :-/
>             I don’t think this is possible. Transfers have a lot of
>             “business talks” among the parties. Only once the parties
>             have reached an agreement, they need to go into the
>             process. You could do on the other way around, it can be a
>             mix of both. I don’t think the community must provide a
>             rule on that, because this has not been done in other
>             RIRs. If we try to setup our own rule, then our policy
>             will have mismatches with the other policies and then we
>             may be in the situation that they are not reciprocal, or
>             the existing procedures in the other regions need to be
>             re-worked, why they are going to do it, now that we are
>             the last one?.
>                 If the staff tries to evaluate the transfers at a
>                 single point in time, it may be misleading as some
>                 operations in the opposite direction may be being
>                 processed. The RIRs may have an “alert” of a possible
>                 transfer, depending on the direction, I don’t know if
>                 the exiting coordination systems allow them to check
>                 those (this will sort out the problem), but still will
>                 not be precise, as some other folks may be
>                 “negotiating” a transfer and have not yet informed the
>                 relevant RIRs until the parties agree.
>             Ok, we need a clarification from the staff. But before
>             that, i propose something below to address the problem...
>                 If we stop the policy immediately the balance becomes
>                 “bad” for AFRINIC, then a transfer in the other
>                 direction will not be able to happen. You see the point.
>             Ok you are right ! But let me try other
>             possibility|solution i see : are we still prioritising
>             incoming transfers ? :-)
>             To be sure, i think we can include a similar (to the
>             following) text (about transfer procedure) :
>             “Initiators of a transfer must start the procedure earlier
>             by submitting their request. The transfer procedure is
>             concluded after a cycle of $four months, devided in two
>             periods of $two months for each. Initiators submit their
>             case to the staff and wait for the staff to give their
>             conclusion at least $two months after the "submissions
>             period" and not more than $four months (including the
>             "verification period"). The staff will collect the cases
>             (submissions|requests) during the "submissions period".
>             The staff can start to study the cases immediately, after
>             receiving them, until the end of the "verification period"
>             which is coinciding with the next "submission period";
>             while collecting other cases. Those in line with the CPM
>             (policy compliant) at the end of the correspondent
>             "verification period". The staff should focus to the goal
>             : keep the in/out balance exceding. Incoming transfer
>             submissions shall be prioritised and treated separately.”
>             I don’t think this will work, as I just explained a few
>             reasons above. In principle I will not support this.
>             With this bit of text, i'm trying to solve a problem you
>             raised above.
>             It does, at least, the following :
>             * To change the approach in considering that
>             * We can considerably diminish the risk by allowing the
>             staff to study the transfer submissions (cases) during the
>             same dedicated "verifications period" (even just during
>             $one month if possible) and
>             * Inform all the requestors only after the "verifications
>             period"
>             * With the *goal* balance in mind :-)
>             * Special treathment for incoming transfers ;-)
>             * A cycle of four months within two equal periods for
>             submissions and verifications
>             * More control of the balance
>             * Focus : *goal* balance
>             * ...
>             See below … it is not needed. I think, just you
>             misunderstood my point 4.
>                 We need to “take a bit of risk”, considering that the
>                 real risk, looking at the numbers I’ve presented is
>                 really low.
>             I agree, but just a *bit of risk* :-)
>             I wasn't able to follow your first presentation during the
>             PPM (Public Policy Meeting), just the Hijacking one.
>             Please share the slides of all your policy proposal
>             presentations.
>             And now I realize this is part of the problem for your
>             questions. Please, pause this discussion until you’re able
>             to see the video of my presentation and the slides! I
>             guess then you may change a bit your view about the risk, etc.
>             I already asked the staff (previous email) to make sure
>             they are published tomorrow. I think they deserve the
>             break today :-)
>                 Remember that “nobody” from AFRINIC is forced to sell.
>                 Who will sell? Those that for example, reduce or close
>                 the business, or those that deploy IPv6, etc.
>              Ok it walk samely for incoming and outgoing transfers.
>             Considering that we have a seller and a buyer on both side
>             transfers.
>                 Who will buy? Those that go to AFRINIC, ask for more,
>                 can’t get all what they need, and try to get the rest
>                 of their needs via transfers.
>                 What is the logic here? Why ARIN is the major donator
>                 to all the other RIRs?
>    what i recall [1] they still have too much unused
>             IPv4 addresses.
>                 If we don’t take a risk, we lose.
>             ...i'm ok with that, but let's try to find the lowest risk :-)
>                     This means that if one month there are “more
>                     addresses going out”, it happens again the next
>                     month, and it happens again by a third month and
>                     so on, then is suspended.
>        monthly public reports should be needed (for the
>                 community to follow-up and for more transparency) ?
>                 If yes, let's clearly state|text it also.
>                 I believe there is already a public AFRINIC reporting
>                 of the Inter-RIR transfers, so we will see this
>                 reported ASAP any transfer is completed I think.
>             Can someone share an uri ?
>             I think we must insert this requirement to the relevant
>             section of the CPM, if not existent.
>                 If this is not the case (can please the staff
>                 confirm?), I fully agree (for both Inter and
>                 Intra-RIR) and will add a specific text so they are
>                 reported, not just monthly, but with each completed
>                 transfer.
>             You are welcome ! Thanks :-)
>                 Which this web page, any member, the board, etc., can
>                 tell the staff at any point, if they don’t realize by
>                 themselves, “hey what is going on here? Are we good
>                 with the transfers?”.
>             Yes, transparency and more power to the community ;-)
>                     I’ve also added a condition to make sure that this
>                     policy only starts once we are in the next
>                     exhaustion phase.
>                     So, you shall consider that, if AFRINIC
>                     service|community doesn't gain anything in the
>                     balance this policy should not be needed...
>                     And that should be clearly stated.
>                     I agree with that, but I don’t think we need to
>                     put that in the policy text, this should be in the
>                     text of the policy justification.
>                 ...wasn't the point here. Apologize but English is not
>                 my first tongue.
>                 What i was (trying) advising|suggesting is to ensure
>                 to text it the clearest possible ; in order to remove
>                 any ambiguity.
>                 I'm glad that you have seen, by yourself, that there
>                 was a problem with the first zero state.
>                 Got it, thanks! And nothing to excuse!
>                         Note that in order to make it simpler, I've
>                         used a text that instead of talking about %,
>                         is stating that the balance of in/out is
>                         reached. This way we ensure that the total
>                         number of the "region IPv4 addresses" never
>                         can go down regarding the actual figures, so
>                         Africa never will lose addresses. Do you think
>                         this is good enough?
>                     Ok after policing this, it seems to be necessary
>                     to clearly state, *“policily”*, that the staff
>                     must follow-up (automatically) the in/out balance,
>                     with regular (automated) public reports and a
>                     special (auto) stop report (for the zero state).
>                     I'm not sure how to "policy-ze" this idea. Perhaps
>                     with a separate policy ?
>                     I’m not completely sure to understand 100% what
>                     you mean, but let me try anyway: Staff is mandated
>                     to follow the policies. So, during the
>                     implementation the staff will make the necessary
>                     provisions so they get an alarm when the balance
>                     of in-coming vs out-going addresses becomes cero.
>                     It may be done automatically anyway, but at least
>                     they should get an “alarm”. The operational
>                     details about “how” to implement this are outside
>                     of the policy scope.
>                 Ok i am in accord with the logic of separation between
>                 policy rules and their operational implementations. I
>                 don't want us to “policy-ze” the implementation phase
>                 of any policy :-)
>                 But you probably miss something in my above suggestion.
>                 The point is that, if you don't clearly ask, via a
>                 policy, for a regular (public) report (for example)
>                 from the staff, you could not be sure to get it when
>                 it shall be needed. Because, without a specific policy
>                 provision, it will be just out of their duties...
>                 Let’s try it again, based on all the discussion (the
>                 numbers are just to split the text now, they will be
>                 correctly placed in the relevant part of the policy
>                 proposal when we “reach consensus” about this text:
>                 1.Each time a transfer is completed, the relevant,
>                 non-confidential information will be automatically
>                 published in a specific web page, including at least:
>                 Date of the transfer, transferred addresses, source
>                 organization and RIR, destination organization and RIR.
>                 2.The Inter-RIR transfers will only be enabled once
>                 AFRINIC enter into Exhaustion Phase 2 (
>                 <>).
>                 3.The Inter-RIR transfers will be automatically
>                 suspended in case the number of outgoing IPv4
>                 addresses exceeds the incoming ones by six consecutive
>                 months.
>                 4.The staff can provisionally suspend any suspicious
>                 operation that creates a big unbalance against
>                 AFRINIC, until the board takes a decision.
>                 See point 4. If there is any suspicious unbalance, the
>                 suspension temporary suspension of **that** operation
>                 protects our pool of addresses, for a few days (I
>                 guess the board in that case should call for a
>                 decision by email or by conference call), and
>                 meanwhile, it can be observed if other “incoming”
>                 operations will restore the balance.
>             Possible solution, thanks for the effort you produced
>             above. But there is still more than acceptable risk on it
>             (including point 4) ; because the next new transfer
>             request can come after the *few* days of suspension.
>             The point here is that the staff is still able to suspend
>             any suspicious operation. Not just one. Is not that clear
>             my text? (any)
>             Please look how to also consider the alternative solution
>             i have proposed above. I don't need you to keep that text
>             as it is, but to use it to figure how it could be merged
>             with yours and reduce the risk (no suspension with it).
>             __
>             [1]: MIT and their 8 million IPv4 addresses –
>             Friendly,
>             --sb.
>                 I really believe this is not needed, it can be done
>                 applying the bylaws (very recently ARIN board
>                 suspended in emergency a policy, so it is a good
>                 demonstration that this works even if is not in the
>                 policy) but I’m happy to keep this text if this means
>                 that we are more unconcerned this way.
>                 What do you think?
>                 Thanks!
>                 [...]
>             _______________________________________________ RPD
>             mailing list RPD at <mailto:RPD at>
>             **********************************************
>             IPv4 is over
>             Are you ready for the new Internet ?
>             The IPv6 Company
>             This electronic message contains information which may be
>             privileged or confidential. The information is intended to
>             be for the exclusive use of the individual(s) named above
>             and further non-explicilty authorized disclosure, copying,
>             distribution or use of the contents of this information,
>             even if partially, including attached files, is strictly
>             prohibited and will be considered a criminal offense. If
>             you are not the intended recipient be aware that any
>             disclosure, copying, distribution or use of the contents
>             of this information, even if partially, including attached
>             files, is strictly prohibited, will be considered a
>             criminal offense, so you must reply to the original sender
>             to inform about this communication and delete it.
>             _______________________________________________
>             RPD mailing list
>             RPD at <mailto:RPD at>
>         _______________________________________________
>         RPD mailing list
>         RPD at <mailto:RPD at>
> _______________________________________________
> RPD mailing list
> RPD at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list