Summary

This document describes the policy for IPv4 Address allocations and assignments in the AFRINIC service region.

1) Introduction

AFRINIC (African Network Information Center) is the Regional Internet Registry (RIR) for the AFRINIC service region. It is responsible for the allocation of IPv4 address space within the African service region.

The Internet Assigned Numbers Authority (IANA) allocates parts of the IPv4 address space to AFRINIC for distribution within the AFRINIC service region. This document describes the policy for IPv4 Address allocation and assignments in the AFRINIC service region.

The first policy for IPv4 address allocation (AFPUB-2005-v4-001) was adopted in May 2006. This document incorporates the experience gained in allocating IPv4 addresses since 2006. It obsoletes AFPUB-2005-v4-001.

2) Definitions

2.1) IPv4 Addresses

IPv4 addresses are fixed length of four octets (32 bits). This document refers to IPv4 addresses administered by AFRINIC as documented in the IANA IPv4 Address Space Registry [REG].

2.2) Internet Registry

An Internet Registry is an organization that is responsible for distributing IP address space to its customers and for registering those addresses. Internet Registries are classified according to their primary function.

2.3) Regional Internet Registry

A Regional Internet Registry (RIR) operates within a large geopolitical region such as a continent. The purpose of a Regional Internet Registry is to manage and distribute Internet number resources within its service region.

2.4) Local Internet Registry

A Local Internet Registry (LIR) is an Internet Registry that receives allocations from an RIR and primarily assigns address space to the users of the network services it provides. The users are end users and possibly other Internet Service Providers.

2.5) Internet Service Provider

An Internet Service Provider (ISP) assigns IP address space to the end users of a network service it provides. Its customers can be other ISPs.

2.6) End User

An end user or end site has a legal or commercial relationship (the same or associated entities) with an Internet Service Provider.

2.7) Allocate

Allocate refers to the distribution of IP address space to Local Internet Registries for the purpose of subsequent distribution.

2.8) Sub-Allocate

To "sub-allocate" means to IP address space distribute by Local Internet Registries to ISPs for the purpose of subsequent distribution.

2.9) Assign

Assign means to delegate IP address space to an Internet Service Provider or End User for their operations. Assignments must only be made for specific purposes documented by the organisations and are not to be sub-assigned to other parties.

2.10) Provider Aggregatable IP Address Space

Provider Aggregatable IP address space is IP address space which has been allocated to LIRs from which they can assign or sub-allocate to end users, downstream networks as a non-portable block. If the end user or downstream network changes provider (LIR), the IP address space assigned or sub-allocated by the previous provider (LIR) should be returned and the network renumbered.

2.11) Provider Independent IP Address Space

Provider Independent (or portable) IP address space cannot be aggregated and can only be assigned by a RIR through an LIR. Provider Independent (PI) IP address space is expensive to route and might not be globally routable. Sub-allocations cannot be made from this type of IP address space by the end user or LIR.

3) Internet Registry System

The Internet Registry system consists of the following levels of hierarchy as seen from the top down: IANA, Regional Internet Registries, Local Internet Registries. The Internet Registry system ensures the uniqueness of Internet number resources and provides information for Internet troubleshooting at all levels.

4) Goals

AFRINIC has the duty to act as a custodian of a public resource in its administration of IPv4 address space. It shall ensure that IPv4 address space is distributed according to the following goals:

• Uniqueness
• Fair distribution
• Aggregation
• Registration

4.1 Uniqueness

In order for each host on the public Internet to be addressable each public unicast IPv4 address must be globally unique.

4.2 Fair distribution

IPv4 addresses shall be distributed fairly according to operational needs while taking into account that IPv4 addresses is a finite resource.

4.3 Aggregation

Distributing IPv4 addresses in a hierachical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing, and to limit the expansion of Internet routing tables.

4.4 Registration

Every assignment and allocation of IPv4 address space shall be registered in the AFRINIC Whois. This is necessary to ensure uniqueness, transparency and to provide information for Internet troubleshooting at all levels.

4.5 Conflicting Goals

It is in the interest of the Internet community as a whole that the above goals be pursued. However, fair distribution and aggregation are conflicting goals. All the above goals may occasionally be in conflict with the interests of individual Internet Registries or end users. Internet Registries evaluating requests for allocations and assignments must carefully analyze all relevant considerations to seek an appropriate compromise.

5) Documentation

The decision-making process for each allocation or assignment shall be documented to ensure that the process is fair. Documentation should conform to well-known practices. Estimates and predictions must be realistic and justifiable.

5.1 Language

AFRINIC uses English as its working language.

6) Registration Requirements

An allocation or assignment is valid as long as the criteria on which the original allocation or assignment was based are still in place, the purpose for which the request was made has not changed, and it is registered in the AFRINIC Whois. The registration data (name, range, contact information, status, etc.) must be kept up-to-date.

An unregistered assignment, allocation, or sub-allocation is considered as invalid.

6.1 Cancelling a Registration

Any of the following may be considered as grounds for cancelling a registration:

(a) Failure to use the IPv4 address space within a period of one month following its registration.

(b) Failure to comply with AFRINIC contractual obligations.

(c) Failure to adhere to documented AFRINIC community decisions.

AFRINIC shall inform the community that the IPv4 address block is once again available.

7) IPv4 Address Allocation Guidelines

An IPv4 allocation is a range of IPv4 addresses from which assignments or sub-allocations are made. In an effort to ensure that Classless Inter-Domain Routing (CIDR), as described in BCP 122 [BCP122], is implemented and utilized as efficiently as possible, AFRINIC will issue blocks of IPv4 addresses on appropriate "CIDR-supported" bit boundaries. A LIR assigning IPv4 address space allocated by AFRINIC must adopt policies that are consistent with this document.

7.1 Initial Allocation

The minimum initial allocation is a /22 IPv4 address prefix length.

Justification is based on a combination of immediate need and existing usage of IPv4 addresses. Existing assignments of IPv4 addresses should be renumbered into the LIR's new allocation.

Verification of existing usage of IPv4 addresses is based on assignments and sub-allocations registered in the AFRINIC, APNIC, ARIN, LACNIC and RIPE Whois and only these registered assignments will be considered as valid.

A minimum initial allocation may also be considered if an Internet Service Provider interconnects with other networks at an Internet Exchange Point in the AFRINIC service region which has an open policy. Additional information may be requested to justify the allocation.

7.2 Slow Start Mechanism For Initial Allocations

The slow start mechanism is to prevent allocations of large blocks of IPv4 address space that may then remain substantially unassigned.

A slow start mechanism shall be applied for to a new LIR. The initial allocation made by AFRINIC to an LIR will be the size of the IPv4 address prefix described in Section 7.1 unless otherwise justified.

7.3 Additional Allocation

Requests for an additional allocation will be considered if about 80% of all the IPv4 address space currently allocated to the LIR has been used for valid assignments and/or sub-allocations. A new allocation request can also be considered if an assignment or sub-allocation requires more addresses than the amount of IPv4 addresses currently held by the LIR.

Reservations are not considered as valid assignments or sub-allocations. It may be useful for internal aggregation to keep some IPv4 address blocks free for future growth. These internal reservations are however not considered as valid usage and must be assigned or sub-allocated before requesting an additional allocation.

Contiguous IPv4 address ranges should be allocated to allow the LIR to minimise the number of route announcements it makes. However, it may not always be possible to allocate an IPv4 address range contiguous with the LIR's previous allocation.

7.4 Sub-Allocations

The minimum IPv4 address prefix length of a sub-allocation is a /24. It allows a reasonable number of small assignments to be made by a downstream ISP. A LIR may not sub-allocate IPv4 address space above its suballocation window (see Section 9 for sub-allocation window).

LIRs may make sub-allocations to multiple downstream ISPs. (Downstream ISPs efficiently using a sub-allocation qualify to receive a /22 IPv4 address prefix length should they want to become an LIR).

The LIR is responsible for ensuring that IPv4 address space allocated to it, and subsequently, the IPv4 address space that it sub-allocates, is used in accordance with documented AFRINIC community decisions [PDP].

It is recommended that LIRs make use of the slow-start mechanism for sub-allocations to downstream ISPs. It is to ensure that the IPv4 address space sub-allocated is used efficiently. It can help the LIR determine whether the downstream ISPs are operating according to documented AFRINIC community decisions.

Sub-allocations are part of a LIR's aggregatable IPv4 address space. A LIR shall ensure that IPv4 address space is not sub-allocated to a downstream ISP if the downstream ISP is not longer connected to the LIR's network (sub-allocations are non-portable).

7.5 Maximum Allocation

The recommended maximum allocation is a /10 IPv4 address prefix length.

8) IPv4 Assignment Guidelines

A LIR must obtain approval from AFRINIC approval for all sub-allocations above its Sub-Allocation Window (see Section 9 for Sub-Allocation Window).

When a LIR makes a sub-allocation from its Sub-Allocation Window, it must provide the information to the end user.

AFRINIC may request information about IPv4 addressing needs, network infrastructure and future plans to verify an end user's IPv4 address requirements. In order to ensure that previous sub-allocations are not duplicated, information about existing IPv4 address space usage is required.

The amount of information required depends on the size of the request and complexity of the network. Guidance to facilitate requests should be publicly available.

8.1 Utilisation

Immediate utilisation of assignments should be at least 25% of the assigned IPv4 address space. After one calendar year, unless there are special circumstances, it should be at least 50%.

8.2 Reservations not supported

End users cannot reserve IPv4 address space based on long term plans as this affects fair distribution and fragments the IPv4 address space when initial forecasts are not met. A LIR assigning IPv4 address space to end users must make the assignments from any unallocated or unassigned address space it currently holds. All IPv4 address space reserved by an LIR for its end users is considered as unused.

8.3 Re-numbering

Valid assignments can be replaced with the same number of IPv4 addresses if the original assignment criteria are are still met. The IPv4 addresses to be replaced must still be in use. When a renumbering request exceeds the LIR's sub-allocation window, the request should be sent to AFRINIC for approval.

A LIR will be given a period of up to three months to migrate to the new IPv4 address space. The LIR may request additional time if there is appropriate justification. Once a network has been renumbered, AFRINIC will remove the old assignment from the AFRINIC Whois.

8.4 Network Infrastructure of LIR vs End User Networks

IPv4 addresses used solely for connecting an end user to an LIR (e.g., point-to-point links) are considered as part of the LIR's infrastructure. These addresses should be registered as part of the LIR's infrastructure.

Sub-allocations made by a LIR to an end user must be registered in AFRINIC Whois. This IPv4 address space must be registered with the contacts of the end user. If the end user is an individual rather than an organisation the IPv4 address space may be registered with the contact information of the LIR but with the end user referenced in the AFRINIC Whois database object.

9) Sub-Allocation Window

A sub-allocation window (SAW) refers to the maximum number of IPv4 addresses that the LIR may sub-allocate to the end users without seeking approval from AFRINIC. The SAW size is expressed in CIDR notatation. AFRINIC shall review the sub-allocation made by the LIR using its SAW for compliance. A LIR should ensure that documentation for sub-allocation made using the SAW be similar to that requested for larger requests.

9.1 Sub-Allocation Window Guidelines

The guidelines for the sub-allocation window (SAW) are as follows:

(a) A new LIR has a SAW of zero. The LIR shall request approval from AFRINIC for sub-allocations.

(b) A LIR cannot make any sub-allocation to the end user above their SAW in a 12 months period (one calendar year). At the end of a calendar year from the approval of a SAW, the SAW is refreshed for one more calendar year. In case the LIR's SAW is exhausted for a particular end-user, approval must be sought from AFRINIC for any other sub-allocation to the same end-user.

(c) A LIR can ask AFRINIC to review their SAW. They may also seek a second opinion from AFRINIC even for a sub-allocation that could be made with their SAW if they chose. Before a SAW is raised the following shall be considered:

1. All required documentation is normally presented.
2. Previous sub-allocation assignments from this sub-allocation are all registered in the database correctly.
3. The current SAW has not been misused or abused.

A LIR should ensure that its end users handle IPv4 address space assignments according to this document. If errors occur repeatedly the SAW may be lowered or removed. The SAW may also be lowered or removed during or after an audit if invalid assignments are noted.

10) Record keeping

A LIR shall keep and maintain records regarding assignments and sub-allocations to its end users. These records may be used to evaluate requests made by the LIR or for any audits performed by AFRINIC. For convenience, the records should be accessible in an electronic format. It is recommended that the records include but are not be limited to:

(a) The original request.

(b) Supporting documentation.

(c) Related correspondence between LIR and end user.

(d) The assignment decision, including the reasons for any unusual decision.

(e) Role of the person who made the decision.

The history of events and the persons responsible should be clear.

11) Acknowledgements

The author would like to thank Adiel A. Akplogan and Ernest Byaruhanga for most of the text which were copied from AFPUB-2005-v4-001

.

12) References

• [REG] IANA IPv4 Address Space Registry <http://www.iana.org/assignments/ipv4-address-space/>
• [BCP122] Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, <http://www.rfc-editor.org/bcp/bcp122.txt>
• [PDP] Policy Development Process in the AFRINIC service region <http://afrinic.net/en/community/policy-development>