Two-factor authentication (2FA), sometimes referred to as two-step verification or dual-factor authentication, is a security process in which users provide two different authentication factors to verify themselves. This process helps to protect better both the user's credentials and the user’s resources.

For MyAFRINIC portal users, the two authentication factors are:

1. The account password
2. A one-time six-digit security code.

The code is generated by a third-party Time-based One-Time Password (TOTP) authenticator, defined as an open standard in RFC6238. Any application that supports TOTP can be used for two-factor authentication.

2FA implementation for the MyAFRINIC portal is an optional but highly recommended security feature, as it adds a layer of security to the authentication process. If enabled, you will be required to enter your password and the six-digit security code; generated by a TOTP authenticator on a device you control, typically a smartphone; whenever you sign in.

Prerequisite for two-factor authentication.

You must first install a TOTP application on your smartphone or tablet before enabling two-factor authentication in MyAFRINIC. Some examples are:

• Google Authenticator (Android, iOS, BlackBerry)
• Microsoft Authenticator (Android, iOS)
• Authy (iOS, Android, BlackBerry)
• FreeOTP (Android)
• HDE OTP Generator (iOS)

You may choose your own authenticator of choice other than the ones listed above.

How do I enable Two-Factor Authentication?

Enabling 2FA is a straightforward procedure; the following steps should get it enabled:

1. Log into Myafrinic Account
2. Click on “My Account”, then select Security
3. Select the "2-Factor Authentication" button.
4. Select setup. When setting up the authenticator app, you can either:
   • Scan the QR-code displayed, or
   • Enter the “Secret Key” manually.
5. Use the six-digit from the app to conclude the setup.
   • If your six-digit security code does not match, please check that your phone has an automatic time zone setting selected.
6. A demo guide can be found here.

What’s Next after Enabling 2FA

Once 2FA is enabled, you will be required to supply both authentication factors every time you log in and access information from Myafrinic. You will be required to enter your NIC-HDL and password first, and then you will be asked to "enter the security code generated by your authenticator app".

In most cases, just launching the authenticator app will generate a new code. You should enter this code to gain access to your account. In most authenticator apps, the auto-generated code is valid for 30 seconds only. You should use the code within that time; otherwise, it will expire, and a new code will be generated. You may refer to your authenticator app's documentation for specific instructions.

What if I can't generate the six-digit code?

If you find yourself in a situation where you cannot access the authenticator app, you will need to use a backup security code to sign in to the Myafrinic portal. The backup code is a 10-character one-time code you can use in place of the OTP code to access your account.

When you have enabled the 2FA authentication, you will find the “Generate Backup Codes” button under the 2-Factor Authentication section. The backup codes will be generated when the button is clicked, and the system will give you 5 one-time use backup codes. Write these down or print out, and store them in a safe place. Each Backup Code can only be used once; however, you can generate a new set of codes at any time.

If you are locked out of your account and do not have the backup security code, please contact us.

What if I don't have or want to use a smartphone?

A smartphone with an authenticator app makes it very easy to use 2FA, but in principle, you can use any application capable of generating Time-based One-Time Passwords. For example, the OATH Toolkit allows you to generate security codes from the command line. The man page will give you details on how to use the application. The other option could be the OTP Manager, another simple application for managing One Time Password (OTP) tokens.

Can I disable 2-factor authentication after enabling it?

Yes. 2FA is optional but a highly recommended security feature. You can disable the functionality by navigating to the Security page of your “My Account” section, clicking the button "Disable” button".

 Important Note:

On 24 June 2021 during the scheduled maintenance to add the 2FA feature on MyAFRINIC, the change was rolled back as we encountered some issues. We provided the report on our status page at https://status.afrinic.net/#notice-121229

We are now expecting the deployment in the second week of July.

The African Network Information Centre (AFRINIC) in collaboration with the Africa Network Operators Group (AfNOG) have proudly concluded the second AIS’21 virtual conference.

The event took place from 31 May to 4 June 2021 and was attended by 378 delegates from 55 countries.

The conference was enriched by technical sessions from renowned experts who delivered insightful presentations on topics such as IPv6, Blockchain Governance, Internet Routing security, Digital Inclusion among others.

The conference saw over seventy presentations that spun over 5 days. The Last day of the conference was dedicated to the AFRINIC Annual General Members Meeting.

The agenda also consisted of other notable pre-event sessions that took place from 24 - 28 May and included several AfNOG tutorials, the AFRINIC Government Working Group Meeting, the newcomers’ session and a session dedicated to Inclusivity and Diversity in the AFRINIC ecosystem.

Presentations and Daily Recaps

1. We invite you to read all the session recaps: 31 May | 1 June | 2 June | 3 June | 4 June
2. The Meeting agenda and slides are available here.
3. Watch the videos for all the sessions here.
4. Meeting statistics are available here.

The Platform

We learnt a lot from our past experience as this was our second time using the Meetecho platform. The overall experience was better than last year. The Organising Team was prepared and took several actions that led to the smooth running of the programme such as organising daily tests with speakers, moderators and MCs who could get acquainted with the platform. The coordination among staff, speakers, moderators and MCs also was well orchestrated.

The Meetecho platform provided a feature for speakers to upload their slides which was an additional option to sharing their screen, and this proved useful.

This time, we introduced several innovations such as a quiz competition during the breaks and for the first time we held an online cocktail online on a dedicated platform ‘’Spatial Chat’’. Those events were well received by our delegates and have set the benchmark for our upcoming AFRINIC and AIS events.

Another novelty, the AIS '21 Online Opening Ceremony was set on a hybrid format with our Chief Guest, HE Mr Augustin Kibassa the Minister of Posts, Telecommunications & ICT giving the Opening Speech live from Kinshasa in DRC.

However, we faced some technical challenges with the hybrid format as well as a bug was reported on the slide share functionality on 28 May during the newcomer’s session. There were some concerns also raised with regards to privacy issues on filling our online survey form and with meeting tokens during the AGMM.

We take with us the lessons learned as we shall strive to get better at these aspects for our future events.

Technical Performance

The following graphs highlight how our infrastructure performed during our virtual meeting. As more people joined the meeting, the network usage started to peak on each day. On the first day, we got the highest network traffic.

Streaming also requires CPU power to process the video and audio, the highest CPU usage matches the first day where we saw the highest number of concurrent participants joining.

Meeting Partners and Sponsorship

It is important we acknowledge our AIS'21 Online Sponsors. This meeting was sponsored by ICANN, ISOC, dotAfrica, Flexoptix, Liquid Intelligent Technologies, Topdog and Emtel. We appreciate your continuous support.

What’s Next

AIS’21 Online was a rich learning experience for the whole AIS team who displayed a great team spirit. We are thankful to everyone who made this event a success as we look ahead to our next AIS/AFRINIC Meeting.

We shall also be happy to share our experience gained over the two online AIS meetings held with anyone who is interested in organising similar online events. The AIS organising team may be contacted at meeting [at] afrinic.net or comms [at] afrinic.net

Internet resilience is the ability of a network to maintain an acceptable level of service at all times. The Internet plays a critical role in society and the COVID-19 pandemic has reinforced the importance of reliable and stable Internet connectivity. However, not all countries have Internet infrastructure that is robust enough to provide an acceptable level of service to users.

In Africa, Internet resilience has not been sufficiently measured to date. So, as part of the Internet Society’s Measuring the Internet project, we want to find out how well African countries cope with Internet outages or disruptions and how resilient networks in Africa really are.

We’re going to seek these answers through the Measuring Internet Resilience in Africa (MIRA) project, by evaluating the capability of a country to provide continuous, stable, and reliable Internet connectivity.

How the MIRA Project Measures Internet Resilience in Africa

The MIRA project is a joint initiative between African Network Information Centre (AFRINIC) and the Internet Society. The project uses Internet measurements gathered by measurement devices, called MIRA pods, located within African countries in order to:

• Determine levels of Internet resilience in African countries over time by recording specific metrics, including throughput and latency (the time it takes to reach various Internet destinations).
• Increase the number of Internet measurement vantage points in Africa, i.e., the places from which measurements are taken.
• Make the data available to everyone, everywhere on the Internet Society Pulse platform.

Who Can Use the Data from the MIRA Project?

The data presented will be freely available to all and can be used by anyone to gain insight into the availability and resilience of the African Internet, including:

• Network operators and Internet Service Providers (ISPs) seeking to improve their services.
• National Regulatory Authorities (NRAs) define the legal and operational environments for the Internet.
• Researchers and engineers aiming to quantify and improve Internet resilience and performance in Africa.
• Internet users, researchers, and engineers seeking to learn more about the Internet landscape in Africa.

What Will Be Measured?

Internet resilience encompasses many underlying components, ranging from the resilience of physical Internet infrastructure (such as undersea or terrestrial cables) to market resilience and quality of service (QoS), which includes performance, uptime, and available bandwidth.

As part of the MIRA project, we will measure:

• The availability and diversity of the physical Internet infrastructure.
• The quality of service of the network from the user’s perspective.
• The availability and efficiency of the peering infrastructure, including the number of IXPs and ISPs.
• The availability and performance of the DNS ecosystem (a key component of Internet performance and resilience).

What We’ve Done So Far

MIRA is already collecting – or preparing to collect – throughput and latency measurements in Benin, Burkina Faso, Congo DRC, Kenya, Madagascar, Nigeria, Rwanda, Tunisia, and South Africa using measurement data from a third party, M-Lab. We’ll soon be adding data from the RIPE NCC’s RIPE Atlas. These measurements are being carried out in these countries by dedicated Raspberry Pi devices that we call MIRA Pods. The initial data will be available shortly. 

Where Can I Find MIRA Data?

The data is available on the Internet Society’s Pulse platform so that everyone can easily find the data they need about the state of Internet resilience in the first set of countries in which we’re carrying out measurements.

How Can I Participate?

To get a robust overview of the Internet’s resiliency in Africa, it’s important to increase the number of vantage points, i.e., the networks from where measurements can be carried out. We are slowly rolling out the measurement infrastructure and will need help from volunteers who can host lightweight probes – the MIRA Pods mentioned above – on their home networks. The probes need to be in-home networks in order to capture the real-world experiences of Internet users.

How Can I Find out More about MIRA?

If you would like to learn more about the technology and methodology behind the project, please read the detailed project overview:

• MIRA Project Overview – English
• MIRA Project Overview – French 
• MIRA Project Overview – Spanish

For technical details about the MIRA project and the measurement infrastructure, visit our page on GitHub.

If you would like to host a MIRA Pod on your network, please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. for more details.

You can find out more about the project in the Internet Resiliencesection on the Internet Society Pulse platform.

By Kevin Chege

Director, Internet Development

Internet Society

IPv6 Extension Headers

IPv6 Extension Headers have been a part of the core IPv6 specification as detailed in RFC8200. They offer supplementary information about IPv6 packets on how they are processed or routed, such as Hop-by-Hop Options. The Hop-by-Hop Options header is not inserted or deleted.

Still, it may be examined or processed by any node along a packet's delivery path until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field the IPv6 header.

The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header (taken from RFC 8200).

Their implementations within several IPv6 deployments have led to many security issues such as the 'Cisco IOS Software IPv6 Virtual Fragmentation Reassembly Denial of Service Vulnerability' or IPv6 Hop-by-Hop options use-after-free.

IETF works on IPv6 Extension Headers

Several IPv6 engineers came together to write the 'Operational Implications of IPv6 Packets with Extension Headers' 

The document highlights the issues regarding IPv6 Extension Headers and why they are dropped intentionally on the public Internet.

Packet forwarding constraints

Many consumer-grade routers have limitations regarding the length of IP header they can process. With IPv6 Extension Headers, this can lead to throughput reduction or simply dropping packets.

ECMP and Hash-based Load-Sharing

Many routers need to infer more information regarding how to do load sharing. The IPv6 flow label header would be helpful for this purpose as it would avoid having to process several IPv6 Extension Headers before making a decision.

Unfortunately, many routers (approximately 20-30%) deployed fail to use the IPv6 flow label header properly, and therefore, IPv6 Extension Headers are often dropped in those cases.

Security issues with IPv6 Extension Headers

Many routers have a default deny policy in security operations. This means that IPv6 Extension Headers are often dropped by default. Additionally, when Access Control Lists are set, they are often done in a manner where IPv6 Extension Headers can cause a security bypass. Therefore, for security reasons, they are usually dropped. Additionally, due to the processing requirements of those additional headers, many firewalls prefer to drop them as they can be used as a Denial of service vector.

Conclusion

The IETF draft on 'Operational Implications of IPv6 Packets with Extension Headers' offers an excellent in-depth discussion to Network Engineers on the implications of IPv6 extensions on the operation side.

In this blog, we gave an overview to Network and Systems Engineers. We encourage readers to go through the Internet-Draft and, if possible, offer suggestions to the IETF v6ops Working Group. 

About Author

Logan Velvindron Infrastructure Security Engineer  He experiments with new security technologies that have business value. In addition to this, he is a contributor to the Internet Engineering Task Force both as a specification developer, Security Area/Internet of Things Directorate member and a Working Group chair. He has managed and led several IETF hackathons during both African Internet Summit and IETF meetings.

AFRINIC has implemented the Lame Delegation policy proposal in its entirety; specifically fulfilling the requirements of Section 10.7 of the CPM

The planned go-live date is 29th April 2021.

Definition of 'LAME'

An authoritative DNS name server is considered lame when it does not adequately respond to queries for a domain, for which it is the designated Start of Authority (SOA).

For the purpose of this policy implementation, a DNS nameserver that, if queried using a standard DNS client or library, the server does not respond with an authoritative answer for the specific domain is considered lame.

No differentiation is made here between the following behaviours of a DNS server:

• Not responding at all.
• Responding in some way, but not for the specific domain queried.
• Responding for the correct domain, but without the authority bit set.

All the above variations result in a 'lame' delegation.

What does this implementation entail?

DNS lameness tests will be run on a monthly basis on all nameservers registered as "nserver" records within "domain" objects in the AFRINIC WHOIS database.

These checks will be running from at least three different geographical locations and a single successful recorded authoritative answer from a single test location is sufficient to NOT consider a nameserver as “lame”.

Once a given ‘nserver’ record has been determined to be lame for a given domain, and reasonable attempts have been made to contact the responsible person(s), the nserver attribute must then be removed from the given domain object. A ‘remarks’ line will be added to the domain object in the database recording this.

In the event that all nameserver records are lame for a given domain, the domain object will be removed in its entirety.

The complete "lameness" checking approach is as follows:

The lameness checks will continue to run on a daily basis and where a nameserver is no longer detected as lame, the corresponding remark will be removed.

What is the impact on members whose domains have lame delegations?

The negative impact of reverse DNS Lame delegations will affect the users of the network in question as well as any third parties relying on DNS records from the affected domain.

DNS lookup for deleted domains will be answered by an NXDOMAIN response, meaning this domain is not listed in any AFRINIC DNS zone.

What can a member do to resolve Lame Delegation?

AFRINIC highly recommends that the necessary steps must be taken to correct the DNS lameness issue before deletion takes place; this could either be, by making the nameservers authoritative for the relevant zones, or by editing the list of nameservers in the "nserver" attributes of the relevant "domain" objects.

Objects with lame delegations can be updated by logging in to https://my.afrinic.net

• Go to the "Resources" tab
• Select "Reverse Delegation" in the drop-down list
• Click the expand icon adjacent to the IP prefix
• Select the edit icon

You may also do it through the WHOIS web interface on the AFRINIC website https://www.afrinic.net/whois or through e-mail, where the domain objects can be submitted to This email address is being protected from spambots. You need JavaScript enabled to view it..

The implementation is designed to minimize the possibility of false positives and we recommend to members to make use of the lameness checker https://afrinic.net/whois/lame to verify against false positives as well validating any updates made or any new reverse domain delegation registered.

Statistics regarding Lame DNS delegation statistics are available here: https://stats.afrinic.net/lamerdns/

For any inquiries, you can contact This email address is being protected from spambots. You need JavaScript enabled to view it..

Further reference:

Consolidated Policy Manual section 10.7 at https://afrinic.net/policy/manual#lame

How to resolve Lame Delegation? https://afrinic.net/support/whois/resolve-lame-delegation

DNS troubleshooting best practices are recommended in RFC 1912 at https://www.ietf.org/rfc/rfc1912.txt

AFRINIC will be participating in the virtual event OSIANE 2021 organised by the nongovernmental organisation PRATIC (Promotion, Reflection and Analysis on Information and Communication Technologies).

AFRINIC CEO Eddy Kayihura will be part of a panel in the session entitled "Towards a High-Quality Internet in Central Africa"

• More information about this event is available at https://www.internetsociety.org/events/central-africa-peering-forum/capf-2021/
• Registration for this event is open at https://isoc.zoom.us/webinar/register/WN_fVU-aGAaRx-mAfjvRMgE8g (Apr 29, 2021, 01:00 PM UTC)

AFRINIC is a proud sponsor of OSIANE 2021 which is being held alongside the Central Africa Peering Forum (CAPF).