<div dir="ltr">Hi Alain,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 17 August 2017 at 18:35, ALAIN AINA <span dir="ltr"><<a href="mailto:aalain@trstech.net" target="_blank">aalain@trstech.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Hi John,</div><div> </div><div><div> 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><br></div><div>Maybe I should have climbed off my lurker chair earlier. :-/</div><div><br></div><div>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><br></div><div>Let me start and if someone wants to respond on this part, we can split it in a separate thread?</div><div><br></div><div>If one look at the Google IPv6 Statistics page: <a href="https://www.google.com/intl/en/ipv6/statistics.html" target="_blank">https://www.google.com/intl/<wbr>en/ipv6/statistics.html</a></div><div><br></div><div>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><br></div><div>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><br></div><div>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></div><div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>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></div><div><br></div><div>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> <br></div><div>So with that as background...<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><blockquote type="cite"><div>On 14 Aug 2017, at 19:48, John Hay <<a href="mailto:jhay@meraka.csir.co.za" target="_blank">jhay@meraka.csir.co.za</a>> wrote:</div><br class="gmail-m_1604065126668407761gmail-m_-7301121054839402356Apple-interchange-newline"><div><div dir="ltr"><br><div>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><br></div><div><div><br></div><div> SL-BIS with the max in phase 1 to /13 instead of /18 ?</div></div></div></div></blockquote><div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>Both have a point and I think we need to find a middle way that feels fairly fair to both sides. :-)</div><div><br></div></div><div>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></div><div><br></div><div><div>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></div><div><br></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><br></div><div>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></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><br></div></div><br><blockquote type="cite"><div><div dir="ltr"><div> 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></div><div><br></div><div>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><br></div><div>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><br></div><div>Thus, the no limit on numbers of request from members in Phase 1 and Phase 2.</div></div></div></blockquote><div><br></div><div>But 5.4.6.2 in -BIS does limit it?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><div>The same spirit prevails with the dedicated reserve for IPv6 deployment:</div><div><br></div><div>- Covers new comers as well as old players(LIRs and  End-users) if they meet 5.4.7.2.2. </div><div><br></div><div>=====</div><div>5.4.7.2.2 The applicant must demonstrate that no other allocations or assignments will meet this need.</div><div>=======</div><div><br></div><div>-  Make the reserve to last for some times with :</div><div><br></div><div>* Reserve size (/12)</div><div>* 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><div><div><br></div><div>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><br></div><div>Africa has the lowest Internet penetration and the biggest growth rate (2000-2017) <a href="http://www.internetworldstats.com/stats.htm" target="_blank">http://www.internetworldstats.<wbr>com/stats.htm</a></div></div></div></blockquote><div><br></div><div>True and there is no denying that. But it also does not say future growth has to be in IPv4 internet. 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></div><div><br></div><div>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><br></div><div>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> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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><br></div><div><br></div><div>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><br></div><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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><br></div><div><div><br></div><div>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">https://afrinic.net/fr/library<wbr>/policies/2089-soft-landing-sd</a></div></div></div></div></blockquote><div><br></div><div>I have read that, but miss the reasoning behind it. I just see:</div><div><br></div><div> <i>"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><br></div></div><div>Regards</div><div><br></div><div>John</div><div>--</div><div>John Hay</div><div><br></div><div><br></div><br></div></div></div></div>