Policy Archive

Last Modified on -
Details
  • Ref. Name:
    AFPUB-2016-V4-003-DRAFT03
  • Submitted:
    23 December 2016
  • Versions: 3
  • Status:
    Last Call
  • Author:
    - Ali HADJI, Comores Telecoms
    - Komi ELITCHA 
    - Damnam Kanlanfei BAGOLIBE
    - Serge Patrick GHANSAH-GNONKOTO, NIC CIS 
    - Nicholas Mbonimpa, RENU
    - Alain P. AINA, WACREN

1.0 Summary of the Problem Being Addressed by this Policy Proposal

Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within the region is needed. The goal of this policy is to define conditions under which transfers must occur.

 

2.0 Summary of How this Proposal Addresses the Problem

The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization.

 

3.0 Proposal

This proposal modifies the CPM by introducing an article 5.7 as follows:

 

5.7 IPv4 Resources transfer within the AFRINIC Region

Like the other Regional Internet Registries, AFRINIC will soon exhaust its IPv4 pool. In order to meet the needs of late resource requestors, a transfer policy for IPv4 resources within the region is needed. The goal of this policy is to define conditions under which transfers must occur.

The policy solves the issue of an African organization needing IPv4 number resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC can no longer satisfy the needs of such an organization.

 

5.7.1 Summary of the policy

This policy applies to an organization with justified need for IPv4 resources that cannot be satisfied by AFRINIC.

 

5.7.2 IPv4 resources to be transferred must be from an existing AFRINIC member’s account or from a Legacy Resource Holder in the AFRINIC service region.

 

5.7.3. Conditions on the source of the transfer

 

5.7.3.1 The source must be the current rightful holder of the IPv4 address resources recognized by AFRINIC, and not be involved in any dispute as to the status of those resources.

 

5.7.3.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC for a period of 12 months after a transfer approval.

 

5.7.3.3 Source entities must not have received a transfer, allocation, or assignment of IPv4 number resources from AFRINIC for the 12 months prior to the approval of transfer request. This restriction excludes mergers and acquisitions transfers.

 

5.7.4. Conditions on the recipient of the transfer

 

5.7.4.1 AFRINIC must approve the recipient's need for the IPv4 number resources. In order for an organization to qualify for receiving a transfer, it must first go through the process of justifying its IPv4 resource needs before AFRINIC. That is to say, the organization must justify before AFRINIC its initial/additional allocation/assignment usage, as applicable, according to the policies in force.

 

5.7.4.2 The recipient must be an AFRINIC member, subject to current AFRINIC policies and must sign the Registration Services Agreement for resources being received.

 

5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.

  

4.0 Revision History

 

24 May 2016 First Version 1.0 posted to list for discussion.
22 Jul 2016

Version 2.0

  • Addition of Acknowledgement section (5.0)
  • Amendment of the policy's numbering
  • Modification of section 3.2.2 which becomes 3.4.2 
23 Dec 2016

Version 3.0 

  • Rewording of 3.1 [currently 5.7.1]: The policy proposal is no more subject to phase 2 of the current IPv4 Soft Landing policy
  • Rewording of 3.2 [currently 5.7.2]: The policy proposal accommodates IPv4 Legacy resources
  • Removal of old 3.4.2: The statement is already covered by 3.4.1 [currently 5.7.4.1]
  • Rewording of old 3.4.3 that become 3.4.2 [currently 5.7.4.2]: Fix membership condition of recipient following rewording of 3.2 [currently 5.7.2] Addition of new 3.4.3 [currently 5.7.4.3]: About the change of the status of transferred IPv4 legacy space
  • Removal of old 3.4.4; No need for the requirement on recipients of the transfer to demonstrate a need up to 12-month supply of IPv4 address space. Justification based on policies in force.
  • Removal of 6.0 (References)

 

5.0 Acknowledgements

The authors would like to thank Owen Delong and Mark Elkins for their insights. They also thank all those who contributed actively in the discussions around this proposal.

 

 

Last Modified on -
Ref Name AFPUB-2006-v6-002 Old Ref. afpol-v6200607
Status Withdrawn
Date 04 July 2006
Author(s) Jordi Palet Martinez
Organisation Consulintel
 
TOC
  1. Acknowledgments:
  2. Summary of Proposal
  3. Draft Policy Text
  4. Proposed replacement text
  5. Rationale

Acknowledgments:

I would like to acknowledge all those who have contributed during many years, to the discussion of the modifications to the existing policy suggested by this proposal.

Summary of Proposal:

Policy Document to be Affected: afpol-v6200407-000

This policy modification is intended to provide a solution for the lengthy discussions that have taken place in the different regions regarding existing IPv6 Policies. It also takes account of the changes that have already taken place in other Regional Internet Registry (RIR) service regions.

It is an alternative solution to the existing proposals around IPv6 Provider Independent (PI) assignments.

Often, some organizations need to make internal assignments. Their networks may be made up of a number of sites that each has their own L2 infrastructure. In some cases, organisations may have a small number of sites, but still need their own block so that they can avoid future renumbering, if they change their upstream provider or identify a need to become Multihomed.

One example might be a large university that has several campuses and faculties, each requiring IPv6 addresses. It may have one or several upstream providers. The university will most likely need to be able to assign IPv6 addresses from the same block to its sites and, at the same time, be able to use one or several upstreams. The university network behaves like an internal university ISP to each of the End Sites.

Draft Policy Text:

Existing section 5.1.1. (afpol-v6200407-000)

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organisation must:

a) be an LIR;
b) not be an end site;
c) show a detailed plan to provide IPv6 connectivity to organizations in
the AfriNIC region.
d) show a reasonable plan for making /48 IPv6 assignments to end sites in
the AfriNIC region within twelve months. The LIR should also plan to
announce the allocation as a single aggregated block in the inter-domain
routing system within twelve months.

Proposed replacement text:

5.1.1. Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an organisation must:

a) be an LIR;
b) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region. The organizations may be other organizations, but also own/related departments/entities/sites;
c) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months.

Other text to be deleted from afpol-v6200407-000:

5.4.2. Assignment of multiple /48s to a single end site

When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level.

Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having AfriNIC review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.

Rationale:

a. Arguments Supporting the Proposal

There have been already clear examples and discussions in different regions about the need for this modification.

The difficulty encountered in receiving IPv6 address space by some big entities that have a need to use IPv6 is a clear barrier for its deployment.

b. Arguments Opposing the Proposal

One possible effect of this proposal would be a growth of global routing tables. This is only to be expected when new allocations are made possible under this proposal.

Page 31 of 55