AFRINIC and the RIPE NCC are pleased to announce the installation of a RIPE Atlas anchor on AFRINIC's infrastructure in Mauritius. The installation is part of a Memorandum of Understanding (MoU) between the two RIRs to increase collaborative efforts in the promotion of Internet development throughout their respective regions. 

The RIPE Atlas project is a global network of probes that measure Internet connectivity and reachability, providing an unprecedented understanding of the state of the Internet in real time. The data collected by the AFRINIC-hosted anchor, mu-plu-as32768, together with the project's other anchors and probes, is made available to anyone and provides valuable information about the local and regional connectivity and reachability of the Internet. 

Find out more about the RIPE Atlas Project and the RIPE Atlas community, its contributions, and the hosts who stand out in the RIPE Atlas network.

Read the MoU here.

The Internet Assigned Numbers Authority (IANA) made an allocation of the equivalent of a /12 of IPv4 address space to AFRINIC and each of the other four RIRs in accordance with the "Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA". This policy states that the RIRs will each receive one-fifth of any recovered addresses in the IANA's recovered pool every six months, in March and September.

AFRINIC was allocated the IPv4 address range 45.96.0.0 - 45.111.255.255 from IANA's recovered pool.

For more information about getting Internet resources from AFRINIC, please see: http://www.afrinic.net/en/services/becoming-a-member/resource-member

For information about IPv4 exhaustion, please see:  http://www.afrinic.net/en/community/ipv4-exhaustion

 ICANN announced that it had begun the process of allocating the remaining blocks of IPv4 address space to the five Regional Internet Registries (RIR). The trigger for this was LACNIC's pool of IPv4 address space reaching a /9 ( 8,388,606 addresses). LACNIC has now moved into Phase 1 of its community-defined IPv4 Exhaustion Plan. APNIC exhausted its supply of IPv4 address space in 2011 and the RIPE NCC followed quickly in 2012. In April 2014, ARIN announced that it had reached phase 4 of its IPv4 Exhaustion Plan.  

"The Internet technical community has been preparing for this phase in global IPv4 exhaustion for the last few years and we expect the community-developed "Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA" to kick-in shortly," says Adiel A. Akplogan, CEO of AFRINIC. "As we move into this new phase of the Internet's evolution, we cannot ignore the fact that total exhaustion of the global IPv4 pool will occur in the very near future. Although AFRINIC's supply of IPv4 address space has not reached critically low levels yet, we cannot predict how long our supplies will last. Existing and emerging networks will face scalability issues unless they are made IPv6 ready to ensure long-term network growth and global connectivity. It is now imperative that all African stakeholders ensure that IPv6 is deployed on their networks, that devices are IPv6 enabled and our content is available over IPv6 immediately so that we remain connected to the global IPv6 Internet and so that our millions of future Internet users can get online."

The community is encouraged to contribute to discussions on the Policy Discussion Mailing list and during the upcoming AFRINIC Meeting to voice their opinion on all aspects of regional and global Internet number resource allocation policies.

AFRINIC has been leading the effort throughout Africa to promote and support IPv6 deployment since 2005 through outreach, education, free training courses and provision of an IPv6 test bed. Find out more about our IPv6 Programme. 

Read Adiel A. Akplogan's recent statement on the urgent need for all African stakeholders to deploy IPv6.

As part of our ongoing effort to improve our services, we invite you to participate in the 2018 AFRINIC Stakeholders survey, open from 16 October -31 December 2018.. The survey will seek to understand our membership and community perceptions and expectations on AFRINIC services and operations.

Please take the survey by clicking on the link here:https://surveys.dcdmresearch.com/index.php/686434?lang=en.

The survey contains 38 questions and should take 20-25 minutes to complete.

The survey will be conducted by an independent research organization, DCDM Research in line with the GDPR and 2017 Mauritius Data Protection Act guidelines.

Your feedback is extremely valuable and will help us to improve our ability to serve you.

We look forward to your participation.

Sincerely,

AFRINIC Team

AFRINIC has released a new version of its Routing Registry service <https://afrinic.net/en/services/afrinic-irr>.

This new version has removed the need for the ASN holder to authorise route or route6 objects.

Previously, route and route6 objects had to be authorised by both the holder of the IPv4 or IPv6 address space, and the holder of the ASN. In the case that the ASN and the address space were held by different organisations, then there was a process for semi-authorised objects to be held for seven days pending complete authorisation. In the case that the ASN was not issued by AFRINIC, then hostmaster staff had to authorise the route or route6 objects.

After discussion in AFRINIC's database working group <https://lists.afrinic.net/mailman/listinfo/dbwg>, and checking the practices of other Internet Routing Registry services, AFRINIC has decided to remove the need for the ASN holder to authorise any route or route6 objects in the AFRINIC IRR. The route or route6 objects still need to be authorised by the address space holder, using the password associated with the mnt-routes or mnt-lower fields in the associated inetnum or inet6num object. The address holder is responsible for maintaining the accuracy of the route(6) objects in the AFRINIC IRR.

These changes have been reflected in the updated version of the AFRINIC Internet Routing Registry Guide.

https://www.afrinic.net/images/AFRINIC_IRR_Public_Guide_09272018.pdf

The policy "Lame delegations in AFRINIC reverse DNS" has been ratified on 21 March 2018.

The policy ensures that lame delegations appearing in the reverse DNS are acted upon by equipping the WHOIS with automatic checks, notifications to admin-c, tech-c and zone-c contacts of domain objects and removal of lame delegations after 30 days.

On day 1 of every month, a fresh scan of WHOIS domain objects is performed and checks made for lame delegations. During the next 30 days, multiple lameness checks are performed. Up to 4 notifications are sent to admin-c, tech-c and zone-c contacts of domain objects with lame delegations as long as the lame delegations are detected, allowing them to act upon them.

AFRINIC has published a manual <https://www.afrinic.net/services/lame-delegation> for members to act on the lame delegations. At the end of the 30-day period, remaining lame delegations are automatically removed from the WHOIS.

These features have been deployed in the WHOIS.