Search RPD Archives
[rpd] SL-BIS arguments in RIPE-NCC proposal
Ornella GANKPA
honest1989 at gmail.com
Fri Sep 22 13:38:09 UTC 2017
Hi everyone,
I would like to bring this SL-bis like proposal that is being discussed
in RIPE-NCC :
https://www.ripe.net/participate/policies/proposals/2017-03
The discussion has just started but it is interesting to see the
principles and rationales of SL-bis shared in another region with more
IPv4, more IPv6 and fewer newcomers to worry about.
Best regards
Honest Ornella GANKPA
Le 29/08/2017 à 14:03, ALAIN AINA a écrit :
> Hi John,
>
>> On 19 Aug 2017, at 08:15, John Hay <jhay at meraka.csir.co.za
>> <mailto: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
>
> - 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
>>
>>
>>
>
>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170922/8169a9bb/attachment-0001.html>
More information about the RPD
mailing list