<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi John,</div><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Aug 2017, at 08:15, John Hay <<a href="mailto:jhay@meraka.csir.co.za" class="">jhay@meraka.csir.co.za</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Alain,<br class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 17 August 2017 at 18:35, ALAIN AINA <span dir="ltr" class=""><<a href="mailto:aalain@trstech.net" target="_blank" class="">aalain@trstech.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="">Hi John,</div><div class=""> </div><div class=""><div class=""> 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...</div></div></div></blockquote><div class=""><br class=""></div><div class="">Maybe I should have climbed off my lurker chair earlier. :-/</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Let me start and if someone wants to respond on this part, we can split it in a separate thread?</div><div class=""><br class=""></div><div class="">If one look at the Google IPv6 Statistics page: <a href="https://www.google.com/intl/en/ipv6/statistics.html" target="_blank" class="">https://www.google.com/intl/<wbr class="">en/ipv6/statistics.html</a></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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?</div><div class=""> <br class=""></div><div class="">So with that as background…</div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Nice background. </div><div><br class=""></div><div>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.</div><div class=""><br class=""></div><div>I will not argue much, as you said, doing so, will just be adding to speculation.</div><div><br class=""></div><div>I share your optimistic views on things here and will just build on it.</div><div><br class=""></div><div>- 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.</div><div><br class=""></div><div><a href="https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption" class="">https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption</a></div><div><br class=""></div><div>- 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. </div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 14 Aug 2017, at 19:48, John Hay <<a href="mailto:jhay@meraka.csir.co.za" target="_blank" class="">jhay@meraka.csir.co.za</a>> wrote:</div><br class="gmail-m_1604065126668407761gmail-m_-7301121054839402356Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""> SL-BIS with the max in phase 1 to /13 instead of /18 ?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div><div class="">To some it is fair to deny someone that needs it now because he already got some, for in case someone else comes later.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Both have a point and I think we need to find a middle way that feels fairly fair to both sides. :-)</div></div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>The current SL adopted gradual exhaustion :</div><div>Phase 1, move from /10 to /13. no limit on number of requests.</div><div>Phase 2, set max to /22, no limit on number of requests</div><div>set a /12 for unforeseen future for board to decide on when pool is empty</div><div><br class=""></div><div><br class=""></div><div>current stats show:</div><div><br class=""></div><div>- 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</div><div><br class=""></div><div>- the minimum allocation size is /22 and the last 6 years stats show that /22 is the biggest allocation per prefix distribution. </div><div><br class=""></div><div>SL-bis 4.0 after long series of discussions proposes:</div><div><br class=""></div><div><div>Phase 1, move from /10 to /18. no limit on number of requests.</div><div>Phase 2, set max to /22, no limit on number of requests</div><div>Turn the unforeseen future reserve of /12 to IPv6 deployment dedicated reserve:</div><div><br class=""></div><div>* serve old and new members to allow access to legacy v4-only networks from v6-only networks</div><div>* with the special and restrictive allocation criteria set in 5.4.7</div></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class=""><br class=""></div></div><div class="">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. :-)<br class=""></div><div class=""><br class=""></div><div class=""><div class="">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.<br class=""></div><div class=""><br class=""></div>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.</div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>i see your points…. but</div><div> </div><div>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. </div><div><br class=""></div><div>Again not to deny legitimate needs and avoid pushing old members to become new member through artifices ? </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">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. <br class=""></div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>….and make sure we can review compliance… </div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div class=""><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> I would take it a step further to say that only new <span class="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-" id="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-:9sf.21">LIRs</span> and End Users can get assignments from it. Maybe even only new <span class="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-" id="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-:9sf.22">LIRs</span>?<br class=""></div><div class=""><br class=""></div><div class="">Keeping a /12 for that might be too big. Looking at <span class="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-" id="gmail-m_1604065126668407761gmail-m_-7301121054839402356gmail-:9sf.23">AFRINIC</span>
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.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thus, the no limit on numbers of request from members in Phase 1 and Phase 2.</div></div></div></blockquote><div class=""><br class=""></div><div class="">But 5.4.6.2 in -BIS does limit it?</div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div>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.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div class=""><br class=""></div><div class="">The same spirit prevails with the dedicated reserve for IPv6 deployment:</div><div class=""><br class=""></div><div class="">- Covers new comers as well as old players(LIRs and End-users) if they meet 5.4.7.2.2. </div><div class=""><br class=""></div><div class="">=====</div><div class="">5.4.7.2.2 The applicant must demonstrate that no other allocations or assignments will meet this need.</div><div class="">=======</div><div class=""><br class=""></div><div class="">- Make the reserve to last for some times with :</div><div class=""><br class=""></div><div class="">* Reserve size (/12)</div><div class="">* 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)</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Africa has the lowest Internet penetration and the biggest growth rate (2000-2017) <a href="http://www.internetworldstats.com/stats.htm" target="_blank" class="">http://www.internetworldstats.<wbr class="">com/stats.htm</a></div></div></div></blockquote><div class=""><br class=""></div><div class="">True and there is no denying that. But it also does not say future growth has to be in IPv4 internet. </div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div>:-)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">It feels like this part was done to achieve a hidden agenda. That might be better done by updating the eligibility criteria.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">The motivations for the 5.4.6.2 shall be read in the SL-SD proposal. <a href="https://afrinic.net/fr/library/policies/2089-soft-landing-sd" target="_blank" class="">https://afrinic.net/fr/library<wbr class="">/policies/2089-soft-landing-sd</a></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I have read that, but miss the reasoning behind it. I just see:</div><div class=""><br class=""></div><div class=""> <i class="">"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.”</i></div></div></div></div></div></div></blockquote><div><br class=""></div>There are more authoritative voices to elaborate on this.</div><div><br class=""></div><div><br class=""></div><div>In conclusion,</div><div><br class=""></div><div>As to decide today taking into account:</div><div>- all we discuss here</div><div>- the statistics for the region</div><div>- the upcoming implementation of Intra-region v4 transfer</div><div>- the specificities of this region,</div><div><br class=""></div><div> 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 ? </div><div><br class=""></div><div><br class=""></div><div>Merci</div><div><br class=""></div><div>—Alain</div><div>=======<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class=""><br class=""></div></div><div class="">Regards</div><div class=""><br class=""></div><div class="">John</div><div class="">--</div><div class="">John Hay</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></div></div></div></div></div></body></html>