Search RPD Archives
[rpd] SL-BIS (Was Re: Appeal Committee Terms of Reference (Version 1))
jhay at meraka.csir.co.za
Sat Aug 19 08:15:39 UTC 2017
On 17 August 2017 at 18:35, ALAIN AINA <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
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/
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
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
So with that as background...
> On 14 Aug 2017, at 19:48, John Hay <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. :-)
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.
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.
> 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
> Thus, the no limit on numbers of request from members in Phase 1 and Phase
But 22.214.171.124 in -BIS does limit it?
> 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 126.96.36.199.2.
> 188.8.131.52.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
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.
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
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 184.108.40.206 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 220.127.116.11 shall be read in the SL-SD proposal.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPD