Search RPD Archives
[rpd] Statistics on IPV4 allocation in Africa as of 2016
Danny
afahounko at gmail.com
Sat Jun 18 11:26:54 UTC 2016
Hello Nishal,
I don't support either your comment/suggestions.
One question: How are we going to increase use of IPv6 in our region if we
do not strengthen our policies about ipv6 adoption?
"Don't tell me how to run my network " routhly said. I personally don't
support and don't like this answer.
AFRINIC vision is "Be the leading force in growing the internet for
Africa's sustainable development" and it is Afrinic duty to put all the
necessary guidelines for the development of Internet in our region.
Please we should not forget Afrinic mission in our region.
And Afrinic has already started by trainings and capacity building.
We need just to strengthen it and make the IPv6 a reality in our region.
Regards.
On Jun 18, 2016 2:24 AM, "Nishal Goburdhan" <nishal at controlfreak.co.za>
wrote:
On 17 Jun 2016, at 15:30, ALAIN AINA wrote:
1- Lets adopt the Soft landing proposal which imposes IPv6 ressources(PA or
> PI) before IPv4 allocation.
>
> It will stop people for getting IPv4 without requesting IPV6. It also make
> members/users work on IPv6 plans to convince their parent LIRs or to meet
> the assignment and allocation criteria specified in the policies*
>
i can’t support this part.
it is not afrinic’s responsibility to tell networks how they should be
running. while we all, unequivocally, support networks adopting IPv6, it’s
not afrinic (nor our) business to *force* someone to request resources,
simply because we think it’s a good idea. especially if there is no
guarantee, nor indication, that this will actually be used.
we *already* have good evidence - from afrinic - to show, that simply
allocating/assigning IPv6 resources, is not the same, as networks actually
using it. at which point the allocation is largely worthless, and the
resource (and effort spent in allocation) is effectively wasted. the
afrinic AIRRS report, which i’m sure you’re familiar with :-) shows
clearly that whilst the hostmasters are indeed allocating v6, not much of
that is actually being routed (forget being actually used!). it’s no
stretch to infer, that enforcing IPv6 allocations, is not really going to
do anything to improve IPv6 adoption, but simply add to some politically
correct statistics about allocations..
it could be argued that this would make future allocations/assignments
easier; i think that the afrinic hostmasters would answer “not really”
since their criteria for IPv6 allocations are, well .. considerably easier
to meet, than for ipv4.
additionally, at some point, afrinic *will* start charging for ipv6. (or,
the services related to that - read it however you will). at that point,
afrinic is going to be potentially charging real money to some
organisation, for something that the organisation had not wanted, but that
they had been *forced* to request. IANAL, but that’s a potential liability
issue that afrinic would do well to steer away from.
natural selection will see to those networks that won’t adopt v6..
2- Lets adopt the Audit/review policy to describe how AFRINIC shall
> proceed with auditing members ressources utilisation(IPv6 in this case) and
> tell compliance level and issues/reasons of non-deployment of IPv6.
>
to the best of my knowledge, afrinic hasn’t rescinded any ipv6
allocations/assignments to members in good standing. this, even though,
the policy criteria for allocation/assignment says that the allocation
should be routed within a year. while those members are in good standing,
i don’t support afrinic reclaiming those v6 resources (and neither do i
feel i have the energy to submit a policy change for this ;-)) because i
can’t see that reclamation process, improving v6 adoption.
we should be doing all that’s possible to make it *easier* to use IPv6 (we
all agree on this i am sure!)
so, if i was going to suggest burning afrinic’s time, i would say, do
things like:
* make the initial (default) allocation to eligible members, an
“auto-allocate” process inside my.afrinic.net (akin to what apnic does)
* improve the integration in getting ipv6 routed; a simpler, easier to use
irrd front-end ;-)
[..and a few others suggestions that aren’t really RPD related, so probably
better not discussed here..]
so, if you’re suggesting a policy, to have afrinic go back and audit and
reclaim those allocated, but not yet routed v6 resources, i can’t really
support that either. i think, yes, we’re going to get to a point where we
*will* want afrinic to do these sorts of audits; but now, while there’s
*some* interest to request these resources, we shouldn’t be overly harsh
with requestors.
there’s a subtle difference in these two sections; i’m all for giving
requestors the v6 resources that they are *ASKING* for, and, being lenient
in these still early (to some) days of ipv6 adoption.
i’m very opposed to *FORCING* requestors, into something that they do not
want (even if it might be for their benefit).
3- Lets request AFRINIC R&D team to do an IPV6 readiness analysis per
> member:
> - IPv6 allocation/assignments in Whois
> - Route6 objects in the IRR
> - Routing policy in the IRR
> - IPv6 prefixes in the routing table
> - IP6.arpa sub-domains delegation
> - DNS over IPv6
> - Org web site over IPv6
> - Etc…
>
> And rank members based on their IPv6 readiness. It will tell where we are
> and may help folks making decisions.
> Does it sound like a good plan ?
>
i’m unclear about what you mean here? are you suggesting a policy proposal
to do this (since this is RPD)? or some other initiative (in which case,
let’s continue this on comm*-discuss?). fwiw, i would support some
initiative to do this (a la NCC’s RIPE-NESS from a while back), and
possibly even volunteer some time. i don’t think that should be a *policy*
though.
—n.
_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160618/362b971b/attachment-0001.html>
More information about the RPD
mailing list