[rpd] SL-BIS (Was Re: Appeal Committee Terms of Reference (Version 1))

Tue Aug 29 13:03:27 UTC 2017

Hi John,

> On 19 Aug 2017, at 08:15, John Hay <jhay at meraka.csir.co.za> wrote:
> 
> Hi Alain,
> 
> On 17 August 2017 at 18:35, ALAIN AINA <aalain at trstech.net <mailto:aalain at trstech.net>> wrote:
> Hi John,
>  
>  Thanks for these comments and questions.  It is the sort of discussions, i am trying  to attract with my  recent mail on the proposal(*) See inline...
> 
> Maybe I should have climbed off my lurker chair earlier. :-/
> 
> Before I answer some of the questions, I think the group should discuss how they think the IPv4 to IPv6 transition is going to happen. While we might not totally agree because it will be speculation, I think it can help to better shape policies like the soft landing one.
> 
> Let me start and if someone wants to respond on this part, we can split it in a separate thread?
> 
> If one look at the Google IPv6 Statistics page: https://www.google.com/intl/en/ipv6/statistics.html <https://www.google.com/intl/en/ipv6/statistics.html>
> 
> If one extrapolate the graph, 50% of Google users will be using IPv6 to reach them in around 3 years. So after that IPv4 is the minority protocol.
> 
> At some stage we are going to see sites or users with only IPv6 addresses. That might put pressure on current IPv4 only sites to add IPv6, especially if it is a CEO that cannot communicate with someone and he finds out that it is because his IT guys never implemented IPv6.
> 
> So at some stage even those that think they have lots of IPv4 space, will implement IPv6 because they need to communicate with IPv6 only sites or people. This will cause the use of IPv4 to dwindle because most Operating Systems prefer IPv6 for connections if the destination has both.
> 
> ISPs will see traffic through their v6tov4 translation boxes dwindle and if v6tov4 cloud services appear, might prefer out sourcing that rather than doing it themselves to keep those last sites accessible to their IPv6 only clients.
> 
> At some stage sites will start to switch IPv4 off on dual stack machines and if IPv4 traffic still warrants it, maybe just a small translation box will be in the kept in the corner.
> 
> Already a lot of the big sites people access are available on IPv6, Google, Akamai (also everyone that use them to host their data), Facebook, CNN... Those that do not have it yet, are busy implementing it.
> 
> So all this leads me to think that in 3-4 years and probably earlier, it will be natural for anybody building a new network will do it IPv6 only and have a few IPv4 addresses with a v6tov4 translation service of some kind to handle those few sites his users still need to access over IPv4. Not like now where most people first think of IPv4 addresses and then almost as an afterthought add IPv6.
> 
> So that leads to the question, how long do we have to make IPv4 addresses last because ending up with a big block that was never allocated is unfair to those that could have used it now. Burning everything today is unfair to the new guys requesting tomorrow. Will it be unfair to a new guy in 5 years though?
> 
> So with that as background…

Nice  background. 

I also like your extrapolation toward 50%  of  the google users using IPv6 in around 3 years and  IPv4 minority status thereafter. The main goal has always been to move from the  predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model.

I will not argue much, as you said, doing so, will  just be adding to speculation.

I share your optimistic views on things here and will just build on it.

-  While the google global stats sound encouraging, the growth is not uniform across regions and countries. The per  region and country distribution is more revealing.

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption <https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption>

- Even if IPv4 becomes minority in 3 years, it will still  be in the game and may still be  majority in some regions  including ours. 

> 
> 
>> On 14 Aug 2017, at 19:48, John Hay <jhay at meraka.csir.co.za <mailto:jhay at meraka.csir.co.za>> wrote:
>> 
>> 
>> I prefer the current soft landing policy, except that I do like the direction of section 5.4.7 (IPv6 deployment reserve) of the -BIS proposal.
> 
> 
>  SL-BIS with the max in phase 1 to /13 instead of /18 ?
> 
> It depends on what we want to achieve. So it has to compliment the rest of the policy. If the policy make it possible for a company to get the same size via multiple small requests, we just cause AFRINIC staff more work and we fragment the routing tables more, if we force the block too small.
> 
> Fair is a word that has been used in the soft landing threads and it is one of those words that sounds so simple, but it is not and I think that is in part what caused all the "unhappiness" in the Soft Landing related threads.
> 
> To some it is fair to deny someone that needs it now because he already got some, for in case someone else comes later.
> 
> To others it is fair to give to ones that ask now because they need it now and we do not know how many will really come in future and they might not even need their own IPv4 addresses anymore.
> 
> Both have a point and I think we need to find a middle way that feels fairly fair to both sides. :-)

That  is the whole exercise we have been trying to build consensus around for the past 18 months. keep serving existing members and made provision for new comers without creating an unused space for a long period.

The current SL adopted gradual exhaustion :
Phase 1, move from /10 to /13.  no limit on number of requests.
Phase 2,  set max to /22,  no limit on number of requests
set a /12 for unforeseen future for board to decide on when pool is empty

current stats show:

-  87% of the afrinic membership are <= small ( >=/18 - < /16). which led to all the proposals to fix phase 1:  max to /18 or /17 or /16 instead of /13

- the minimum allocation size is /22 and the last 6 years stats show that  /22 is the biggest allocation per prefix  distribution. 

SL-bis 4.0 after long series of discussions proposes:

Phase 1, move from /10 to /18.  no limit on number of requests.
Phase 2,  set max to /22,  no limit on number of requests
Turn the unforeseen future  reserve of /12 to  IPv6 deployment  dedicated reserve:

* serve old and new members to allow access to legacy v4-only networks from v6-only networks
* with the special and restrictive  allocation criteria set in  5.4.7

> 
> Maybe the fairness should be that for the duration of phase 1, anybody that requests, and meet the criteria can get IPv4 space. If we really want to, we can use -BIS 5.4.4, where you show your planning for the next 8 months and you get what you will need for those 8 months. But then you must be able to come back and request again at the end of that period. This is fair because someone cannot just hog all space in the beginning, so right up to the end newcomers also have a chance to get space. Remember big guys connecting many people to the internet, are not our enemy. They do what we all think should happen in Africa, they connect people to the internet. Content providers should also be able to get IPv4 addresses because the only reason they need IPv4 addresses is because you have not implemented IPv6 for your users yet. :-) And they need to put their servers close because that makes your users happy with you. :-)
> 
> I think the phase 2 and "IPv6 deployment reserve" blocks should be folded in a single smallish block, that is kept for only new requests and for some really critical invention. I don't think even DNS should be classified as critical. New requests get a single /24. AFRINIC gets about 150 new members a year, so calculations should be based around that.
> 
> It is also fair to newcomers because even if they come after we have run out of the big (phase 1) block, they will get a /24. If they arrive before we run out, they can get a bigger block, like the rest.

i see your points…. but

The reserve is  for people running v6-only and need some v4 for v4overv6 using v4 sharing. New comers will meet the criteria at 1st request which is the main goal.  At the same time, not to deny old members who can justify that any other allocation can meet the need. 

Again not to deny legitimate  needs  and avoid  pushing old members to become new member through artifices  ? 

> 
> If we think people found ways to receive IPv4 address space and use it for uses that are detrimental to the growth of internet in Africa, we should fix the eligibility criteria or maybe if it is possible, add a clause to say for which kinds of use the address space may be allocated. 

….and make sure we can review compliance… 

> 
> 
> 
>> I would take it a step further to say that only new LIRs and End Users can get assignments from it. Maybe even only new LIRs?
>> 
>> Keeping a /12 for that might be too big. Looking at AFRINIC statistics, there are about 150 new members a year, so for 10 years (which I think is too long, but a nice round number), 1500, rounded up to 2048 at a /24 each is a /13 that needs to be kept out.
> 
> The spirit of the current SL which SL-bis followed is to make fair distribution, give chance to many, at all stages, but avoid stocking unused space.
> 
> Thus, the no limit on numbers of request from members in Phase 1 and Phase 2.
> 
> But 5.4.6.2 in -BIS does limit it?

As i said 5.4.6.2 was introduced in SL-bis 5.0 as a compromise  to a community “approved” version which was supposed to reach consensus and be fast tracked.

> 
> 
> The same spirit prevails with the dedicated reserve for IPv6 deployment:
> 
> - Covers new comers as well as old players(LIRs and  End-users) if they meet 5.4.7.2.2. 
> 
> =====
> 5.4.7.2.2 The applicant must demonstrate that no other allocations or assignments will meet this need.
> =======
> 
> -  Make the reserve to last for some times with :
> 
> * Reserve size (/12)
> * Limit the max allocation to /24 with an allocations/assignment  window of 6 months(so a member can only get a max of /23 in 12 months)
> 
> a /12 represents a total of 1,048,576 IPs. At  a rate of 100 nodes sharing one public IPv4, this IPv6 dedicated reserve allows about 104,857,600 nodes access to legacy v4-only networks through IPv6-only networks, when  no more v4 space is left in AFRINIC normal  pool.
> 
> Africa has the lowest Internet penetration and the biggest growth rate (2000-2017) http://www.internetworldstats.com/stats.htm <http://www.internetworldstats.com/stats.htm>
> 
> True and there is no denying that. But it also does not say future growth has to be in IPv4 internet.

Definitely not. I read this as : We have a huge users to be connected in this region, which must be around v6, but we have to guarantee access to legacy v4-only for a long period  as  probability is high for persistent v4-only  for extended period in this region.

> I think anybody building a new network now and not building it with IPv6 from the ground up and just adding IPv4 where needed, is wasting time and money. The point of internet is to communicate and get data/information from the rest of the world, so you have to do what the rest of the world is doing, not what they did 5 years ago.
> 
> While a 100 nodes sharing an IPv4 address might be needed now, if you have rolled out IPv6 and get decent IPv6 connectivity, you might soon find out that you can make the ratio higher. (For our group of about 300 people with dual-stacked machines, only half of our internet traffic is IPv4 these days.)
> 
> PS. I would put a question mark around their statistics because they are clearly behind the times with their web site not reachable via IPv6.

:-)

> 
> 
>> 
>> I do not like 5.4.6.2 in the -BIS proposal, because it penalise legitimate big members, just because they are big. (And big members are not less efficient with addresses.) Telling a member you can get 8 months worth of addresses every 24 months is not going to fit in their business plan. It will be almost the same as telling them come once only.
> 
> 
> 5.4.6 was introduced in SL-BIS 5.0 based on a community request to fill a gap conditions in SL-bis 4.0
> 
>> 
>> It feels like this part was done to achieve a hidden agenda. That might be better done by updating the eligibility criteria.
> 
> 
> The motivations for the 5.4.6.2 shall be read in the SL-SD proposal.   https://afrinic.net/fr/library/policies/2089-soft-landing-sd <https://afrinic.net/fr/library/policies/2089-soft-landing-sd>
> 
> I have read that, but miss the reasoning behind it. I just see:
> 
> "b. Allows organizations to request allocations/assignments without limiting the number of times or maximum size that can be requested. The authors of this policy feel this is not prudent management of the last /8 block.”

There are more authoritative voices to elaborate  on  this.

In conclusion,

As to decide today taking into account:
- all we discuss here
- the statistics for the region
- the upcoming implementation of Intra-region v4 transfer
-  the specificities of this region,

 wise risks management strategy would recommend  the “conservative” approach which counts v4 in our v6 future for the coming years. Better be proven wrong  in this mode than in the others ? 

Merci

—Alain
=======
> 
> Regards
> 
> John
> --
> John Hay
> 
> 
> 

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