Your IP address is 54.82.27.141

Resource Policy Manual - DRAFT

5. IPv4

This section describes the guidelines for the responsible management IPv4 address space in the AFRINIC service region. The guidelines are developed through an open, bottom up policy development process of the Policy Development Working Group.


5.1 IPv4 Address Space


For the purpose of this document, IPv4 addresses are 32-bit binary numbers (used as identifiers in the IPv4 protocol) and are usually in three types:

5.1.1 Public/global IP addresses that are assigned to be globally unique according to the goals described in section 6 of this document.

5.1.2 Private IPv4 address space is set aside for use in private IPv4 networks. Anyone may use these addresses in their private networks without registration. Hosts with private IPv4 addresses cannot be reached from the internet unless enabled through NAT (Network Address Translation). Note that some Internet services may not work properly under NAT. See RFC 2993 for engineering / technical implications of using NAT. RFC1918 also describes the blocks set aside for private use.

5.1.3 IP address ranges reserved for experiments: These are described in RFC3330. Some ranges are also reserved for multicast.

 

5.2 Goals of the Internet Registry System


5.2.1 Goals


It is AFRINIC's primary duty, as a custodian of a public resource, to ensure that for all IPv4 allocations and assignments, the following goals are met:

5.2.1.1 Uniqueness - In order that each host on the public internet can be uniquely identified, each public unicast IPv4 address must be globally unique.

5.2.1.2 Registration - Every assignment and allocation of public Internet address space must be registered in the AFRINIC whois database. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels.

5.2.1.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 (RFC2519).

5.2.1.4 Conservation - To maximize the lifetime of the public Internet address space resource, addresses must be distributed according to actual need and on the basis of immediate use. Therefore, stockpiling of address space and maintaining reservations must, in general, be avoided.

 

5.2.2 Conflict of goals

The goals of conservation and aggregation often conflict with each other. Some or all of the goals may occasionally be in conflict with the interests of individual IRs or end-users. Therefore, IRs evaluating requests for allocations and assignments must carefully analyze all relevant considerations and must seek to balance the needs of the applicant with the needs of the Internet community as a whole. These policies are intended to help IRs balance these needs fairly. Documenting the decision making process for each allocation or assignment helps ensure the process remains transparent and honest.

 

5.2.3 Documentation

In order to properly evaluate requests, an RIR must carefully examine all relevant documentation relating to the networks in question. Such documentation may include network engineering plans, sub-netting plans, descriptions of network topology, and descriptions of network routing plans. All documentation should conform to a consistent standard and any estimates and predictions that are documented must be realistic and justifiable.

 

5.2.4 Fairness

All policies and practices relating to the use of public address space will apply fairly and equitably to all existing and potential members of AFRINIC regardless of their location, nationality, size, or any other factor.

 

5.3 Registration Requirements

5.3.1 All communication with AFRINIC will be in English.

5.3.2 All allocations, PI assignments, PA assignments, sub-allocations and other types of resource assignments will be registered in the AFRINIC database. Any unregistered resources will be considered invalid. The registration data (name, IP block/range, contacts, status, etc..) must be correct at all times. This is necessary to support network operations.

 

5.4 Soft Landing

This section describes how AFRINIC shall assign, allocate, and manage IPv4 resources during the "Exhaustion Phase" which begins when AFRINIC first needs to assign or allocate IP addresses from the final /8 block of IPv4 address space.

In order to ensure a smooth transition to IPv6, AFRINIC's pool should be managed to provide members with address space after the IPv4 pool is depleted. This will help in maintaining IPv4 networks while deploying IPv6 networks - a practice that characterizes the transition period. This section proposes a strategy for allocation and Assignment and maintenance of AFRINIC's IPv4 pool post exhaustion. Enforcement of the “soft landing” policy begins when AFRINIC starts to allocation space from the final IANA allocated/8.

This IPv4 Soft Landing policy applies to the management of address space that will be available to AFRINIC after the current IPv4 pool is depleted. The purpose of this document is to ensure that address space is assigned and/or allocated in a manner that is acceptable to the AFRINIC community especially during this time of IPv4 exhaustion.


5.4.1 Definitions Specific to the Soft Landing Section:

  • Existing LIR's- An Existing LIR is a LIR that assigns address space to 'end-users' and has already been assigned or allocated IPv4 address space by AFRINIC.
  • New LIR- A New LIR, is a LIR that assigns address space to 'end-users' and is a member of AFRINIC but has not been assigned or allocated any IPv4 address space prior to the Exhaustion phase.
  • End User- An End User is an organization that receives assignments of IP addresses exclusively for use in its operational networks
  • Final /8 block of IPv4 address space, or "Final /8"- The Final /8 block of IPv4 address space, or "Final /8", is the /8 block of IPv4 address space that has been allocated by the IANA to AFRINIC in terms of section 2.2 C of the Global Policy for the Allocation of the Remaining IPv4 Address Space <http://www.icann.org/en/general/allocation-remaining-ipv4-space.html> at the time of exhaustion of the IANA pool of IPv4 address space. AFRINIC's version of the Global Policy for the Allocation of the Remaining IPv4 Address Space is also known as AFPUB-2009-v4-001.

5.4.2 Current Phase

The "Current Phase" is the status quo at the time of adoption of this policy. During this phase, AFRINIC will continue allocating or assigning IPv4 addresses to LIRs and End Users using the current policies.

The current phase will continue until an otherwise-valid request for IPv4 address space from any LIR or end user to AFRINIC either:

(a) Cannot be fulfilled with the IPv4 address space available in the AFRINIC pool (with the exception of the Final /8), or:

(b) Can be fulfilled, but would leave the AFRINIC IPv4 address pool empty (with the exception of the Final /8).

The request that results in either of the above conditions being fulfilled will be the last IPv4 address space request that AFRINIC will accept from any LIR or End User in the Current Phase. If the request can be processed in terms of the Current Phase policies, then it will be so processed; otherwise, it will be processed in terms of Exhaustion Phase policies.

AFRINIC will publically announce that the Exhaustion Phase has begun at this point. For the avoidance of doubt all applications that are currently in the process at this point will be evaluated as per the new policy.


5.4.3 Exhaustion Phase

During the Exhaustion Phase, the following allocation and assignment guidelines will be used. They apply to both LIRs and End Users, and to all IPv4 address space allocated, assigned, or otherwise managed by AFRINIC during the transition to and after the beginning of the Exhaustion Phase, regardless of whether or not such IPv4 address space is a part of the Final /8. The exhaustion phase will be divided into two parts:


5.4.3.1 Exhaustion Phase 1

During this phase, allocation/assignment of address space will continue as in the Current phase (/24 for a EU and /22 for a LIR) but the maximum will change from /10 to /13.

Allocations and assignments will be made from the Final /8 or from any other IPv4 address space available to AFRINIC, until no more than a /11 of non-reserved space is available in the Final /8. At this point the Exhaustion Phase 2 will begin. For the avoidance of doubt all applications will be in the process at this point will be evaluated as per the new policy.


5.4.3.2 Exhaustion Phase 2

During this phase a minimum allocation/assignment size will be /24, and the maximum will be /22 per allocation/assignment.


5.4.4  For any LIR or End User requesting IPv4 address space during the Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period.


5.4.5 The current allocation and assignment period of 12 months shall be changed to 8 months. The current allocation and assignment period of 12 months shall be changed to 8 months. This will help to ensure that LIRs request only for resources they need in the short to medium term, and promote fairness in the equitable distribution of the last IPv4 address pool. This assignment period will remain the same throughout the life span of this Policy.


5.4.6 Allocation Criteria

5.4.6.1 In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). In the case of new LIRs or End Users with no previous allocations or assignments, this requirement does not apply to their first allocation or assignment request.

5.4.6.2 AFRINIC resources are for AFRINIC service region and any use outside the region should be solely in support of connectivity back to the AFRINIC region.


5.4.7 IPv4 Address Space Reserve

5.4.7.1 A /12 IPv4 address block will be in reserved out of the fFinal /8. This /12 IPv4 address block shall be preserved by AFRINIC for some future uses, as yet unforeseen. The Internet is innovative and we cannot predict with certainty what might happen. Therefore, it is prudent to keep this block in reserve, just in case some future requirement creates a demand for IPv4 addresses.

5.4.7.2 When AFRINIC, can no longer meet any more requests for address space (from the Final /8 or from any other available address space), the Board may at its discretion and considering the demand and other factors at the time replenish the exhaustion pool with whatever address space (or part thereof) that may be available to AFRINIC at the time, in a manner that is in the best interest of the community.

 

5.5 IPv4 LIR/ISP Allocations


5.5.1 Allocation policies and guidelines


5.5.1.1 Introduction


5.5.1.1.1 AFRINIC allocates ranges of IPv4 addresses to Local Internet Registries (LIRs). LIRs reassign or sub-allocate that space to their customers. All LIR's assigning address space allocated from AFRINIC are also advised to adopt a set of policies that are consistent with the policies described in this document.

5.5.1.1.2 Determination of IP address space allocation size is the responsibility of AFRINIC staff. In an effort to ensure that Classless Inter-Domain Routing (CIDR) is implemented and utilized as efficiently as possible, AFRINIC will issue blocks of IPv4 addresses on appropriate "CIDR-supported" bit boundaries. (CIDR - "Classless Inter-Domain Routing", is explained in RFC1517-1959).

5.5.1.1.3 If an LIR plans to exchange or transfer address space, it needs to contact AFRINIC so that the changes are properly registered. The LIR remains responsible for all the allocations registered in the AFRINIC database until they have been transferred to another LIR or returned to AFRINIC. LIR's must ensure that all policies are applied.

 

5.5.1.2 First IPv4 Allocation

5.5.1.2.1 AFRINIC's minimum allocation is /22 or 1024 IPv4 addresses.

5.5.1.2.2 The organisation must be an AFRINIC member in good standing, and;

5.5.1.2.3 Must show an existing efficient utilization of IP addresses from their upstream provider. Justification may be based on a combination of immediate need and existing usage, in which case, the existing assignments must be renumbered into the LIR's new allocation.

The verification of previous efficient utilisation is based on assignments (and sub-allocations) registered in the RIPE, ARIN, LACNIC and APNIC databases and only these registered assignments will be considered valid.


5.5.1.3 Slow start mechanism for first allocations:

AFRINIC shall apply a slow start mechanism to all new LIRs. With respect to allocations made by AFRINIC, the first allocation an LIR receives will be the size of the minimum practical allocation described in 5.4.1.2.1 unless otherwise justified.

The slow start policy is used by all RIR's to prevent allocations of large blocks of address space that may then remain substantially unassigned. AFRINIC will implement the slow start mechanism in a consistent and fair manner for every LIR, and will apply the same principles and standards to every applicant for address space.


5.5.1.4 Additional Allocation

5.5.1.4.1 An LIR may receive an additional allocation when about 80% of all the address space currently allocated to it has been used in valid assignments and/or sub-allocations. A new allocation can also be made if single assignment or sub-allocation requires more addresses than those currently held by the LIR.

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

5.5.1.4.3 AFRINIC will always try to allocate contiguous address ranges, allowing the LIR to minimise the number of route announcements it makes. However, it will not always be possible to allocate a range contiguous with the LIR's previous allocation.

 

5.5.1.5 Sub-Allocations

The minimum size of a sub-allocation is /24. It allows a reasonable number of small assignments to be made by a downstream ISP. An LIR may not sub-allocate IPv4 space above its sub-allocation window (see section 10.0 for sub-allocation windows).

LIR's may make sub-allocations to multiple downstream ISP's. (Downstream ISP's efficiently using a sub-allocation qualify to receive a /22 allocation should they want to become an LIR).

The LIR is responsible for ensuring that address space allocated to it, and subsequently, the address space that it sub-allocates, is used in accordance with the community's policies and guidelines.

LIRs are advised to make use of the slow-start mechanism when making sub-allocations to downstream ISPs. Here, the LIR ensures that the space sub-allocated is efficiently used and the LIR can also monitor and determine the ability of the downstream ISP to operate within the policies set by the community.

Sub-allocations form part of an LIR's aggregatable space. Therefore, an LIR should ensure that IP space is not retained by the downstream ISP if the reseller ceases to obtain connectivity from the LIR's network (sub-allocations are non-portable).


5.5.1.6 PA Assignment policies and guidelines

LIR's must request approval from AFRINIC approval for all sub-allocations above their Sub-Allocation Window (see section 10.0 for SAW policy).

The following guidelines are intended to help LIRs and end-users in their search for equitable compromises:


5.5.1.7 Documentation

The information required by AFRINIC to justify an end-user's IP address requirements include addressing needs, network infrastructure and future plans. Such information is required when an LIR is requesting IP space for their end-users at the time of sending in the request. In order to ensure that previous sub-allocation are not duplicated, the current address space usage is also required. This information is essential in making the appropriate sub-allocation approvals, and the level of detail will depend on the size of the request and complexity of the network.

The LIR should ensure that the necessary information is completed before making a sub-allocation request to AFRINIC. Sub-allocation request forms are available to the LIR through their account in MyAFRINIC.

When making sub-allocation from their SAW, LIR's should also ensure that such information is given by the end-user.


5.5.1.8 Network infrastructure (of LIR) vs End-User networks

IP addresses used solely for connecting an end-user to a service provider (e.g., point-to-point links) are considered as part of the service provider's infrastructure. Such addresses should only be registered as part of the service provider's infrastructure. When an end user has a network using public address space, this space must be registered with the contacts of the end-user. If the end-user is an individual rather than an organisation, the space may be registered with the contact information of the service provider but with the end-user referenced in the AFRINIC whois database object.


5.5.1.9 Utilisation

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


5.5.1.10 Reservations not supported

End-users are not permitted to reserve address space based on long term plans. This violates the goal of conservation and fragments the address space when initial forecasts are not met. If an LIR wants to assign address space for customers, it must make the assignments from any unallocated or unassigned address space it currently holds. For the purposes evaluating allocation requests, space reserved by an LIR for other customers is considered unused.


5.5.1.11 Validity of an assignment

Assignments remain valid as long as the original criteria on which the assignment was based are still in place and the assignment is registered in the AFRINIC database. An assignment is therefore invalid if it is not registered in the database and if the purpose for which it was registered has changed or no longer holds.


5.5.1.12 Re-numbering

This is replacing IP addresses on a one-to-one basis. Valid assignments can be replaced with the same number of addresses if the original assignment criteria are still met. The 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 period of three months is normally considered sufficient to migrate a network to the new IP space. Once a network has been renumbered, AFRINIC staff will remove the old assignment from the AFRINIC database. In case the three months period is not sufficient, the LIR should inform AFRINIC about the additional time they might take to completely renumber.

 

5.5.1.13 Sub-Allocation Window (SAW)

5.5.1.13.1 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 notation.

5.5.1.13.2 AFRINIC will review sub-allocation made by the LIR's using their SAW in to ensure that policies are followed correctly. LIR's should also ensure that documentation for sub-allocation made using the SAW be similar to that requested for larger requests.


5.5.1.13.3 Below are a few guidelines for the SAW:

a) All new LIRs have a SAW of zero where all sub-allocations will need prior approval by AFRINIC.

b) The LIR cannot make any sub-allocation to the end-user above their SAW in a 12 months period (1 year). At the end of a calendar year from the approval of a SAW, the SAW is refreshed for one more 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) LIR's are welcome to approach AFRINIC for a review of 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 will be considered:

  • All required documentation is normally presented.
  • Previous sub-allocation assignments from this sub-allocation are all registered in the database correctly.
  • Current SAW has not been misused/abused.

d) New LIR's are advised to train their contacts to handle address space assignments according to the policies and procedures in this document. If, due to inexperienced contacts at the LIR, errors due to poor judgement consistently happen, the SAW may be lowered or removed to allow AFRINIC staff to assist in training the LIR's staff in the AFRINIC community's policies.

 

5.5.1.14 Record keeping by LIRs

LIRs must keep and maintain records of any documentation regarding assignments and sub-allocations to end-users. It is needed for future reference when evaluating requests from the same organisation and for any audits by AFRINIC. These documents should be kept electronically for easier access. It's advisable that these records should include but not be limited to:

  • The original request.
  • Supporting documentation.
  • Related correspondence between LIR and end-user.
  • Decision of the assignment, and reasons behind any unusual decision.
  • Role of person that made the decision.

 

5.6 IPv4 End-User (PI) Assignments

AFRINIC assigns blocks of IPv4 addresses to end-users who request address space for their internal use in running their own networks, but not for sub-delegation or reassignment of those addresses outside their organization. End-users must meet some requirements for justifying the assignment of an address block.


5.6.1 Minimum assignment

In general, the minimum block of IP address space assigned by AFRINIC to end- users is a /24. If assignments smaller than /24 are needed, end-users should contact their upstream provider. Prefixes assigned to End-User will be from a block reserved for that purpose.


5.6.2 First End-user assignment criteria


The requesting end user must:

  • Be an AFRINIC member in good standing;
  • Show either an existing efficient utilization of at least a /25 equivalent from their upstream provider, or:
  • Justify an immediate need of at least 50% of the total requested size based on their Network Infrastructure. For example, a new company.

5.6.3 Additional PI Assignment

Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requestors must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criteria that must be met are:

  • A 25% immediate utilization rate, and
  • A 50% utilization rate within one year.

A greater utilization rate may be required based on individual network requirements.

Concerning Private IP addresses, end-users not currently connected to an ISP and/or plan not to be connected to the Internet are encouraged to use private IP numbers reserved for non-connected networks (see RFC 1918).

 

5.6.4 PI Assignments to critical Infrastructure

5.6.4.1 AFRINIC will make End-User assignment to critical infrastructure providers of the Internet such as public internet exchange points and core DNS service providers. These allocations will be no longer than a /24 using IPv4. Multiple allocations may be granted in certain situations. - Exchange point assignment MUST be assigned from specific blocks reserved only for this purpose.

5.6.4.2 AFRINIC will make a list of these blocks publicly available.

5.6.4.3 Exchange point operators must provide justification for the allocation, including: connectionpolicy, location, other participants (minimum of three total), ASN, and contact information. This policy does not preclude exchange point operators from requesting address space under other policies such as becoming LIR.


5.6.4.4 Definitions


5.6.4.4.1 Exchange Point: An Internet Exchange Point is defined as a physical network infrastructure (layer 2) operated by a single entity whose purpose is to facilitate the exchange of Internet traffic between ISPs. There must be a minimum of three ISPs connected and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be acquired through the appropriate means (e.g. an upstream ISP).


5.6.4.4.2 Core DNS service provider: A core DNS service provider is a company who provides DNS service for the root level of the DNS tree (ICANN-sanctioned root operators).

 

 

5.7 Anycast Assignments in the AFRINIC service region


This provision allows the use of one (1) /24 of IPv4 for anycast services from a PA allocation or end user assignment. These /24s will be assumed to be "fully utilised" by AFRINIC staff when considering utilisation for first allocation or for an additional allocation or assignment.DNS service provider is a company who provides DNS service for the root level of the DNS tree (ICANN-sanctioned root operators).


5.7.1 An organization may obtain one (1) /24 IPv4 prefix for anycast or GRX purposes from an allocation or end-user assignment. These prefixes must be used for the sole purpose of anycasting web or authoritative DNS servers as described in BCP126/RFC 4786 or for GPRS Roaming Exchange.


5.7.2 These prefixes will count as being fully utilised when an organization applies for additional resources. The utilization criteria that apply to all IPv4 initial allocation or assignment requests shall be waived for anycast allocation or assignment requests.


5.7.3 Blocks used for anycast services cannot be further assigned or sub-allocated. They shall be tagged with the status attribute in the AfriNIC DB as "ASSIGNED ANYCAST".


(Page 5 of 11)

Comments   

 
# Mark Elkins 2013-11-29 17:27
The Soft Landing section is missing the 10%rule (what percentage can be used outside of the area). As this was the first thing I looked for - I have no idea what else might be missing.
Reply
 
 
# EB 2014-01-10 14:06
Mark,

The "10%" requirement appears to have been removed at one point during the revisions and discussions. The final content restricting out-of-region usage reads: "AfriNIC resources are for AfriNIC service region and any use outside the region should be solely in support of connectivity back to the AfriNIC region"

See 3.8 of http://www.afrinic.net/en/library/policies/697-ipv4-soft-landing-policy
Reply
 

Add comment


Security code
Refresh