Policy Pre-CPM

Last Modified on -
Details
  • Ref. Name:
    AFPUB-2009-v4-002
  • Old Ref:
    Afpol-v4gb200903
  • Status:
    Implemented
  • Date:
    11 Nov 2010
  • Author:
    • Adiel A. Akplogan,
      AfriNIC
    • Maemura Akinori,
      APNIC
    • Geoff Huston,
      APNIC
    • Paul Wilson,
      APNIC
    • Ray Plzak,
      ARIN
    • Oscar A. Robles-Garay,
      LACNIC
    • Raul Echeberria,
      LACNIC
    • Axel Pawlik,
      RIPE NCC
    • Nigel Titley,
      RIPE NCC

1) Incentive

With the depletion of the IANA free pool of IPv4 address space, the current policy regarding the allocation of IPv4 address space to the RIRs will become irrelevant. The RIRs may, according to their individual policies and procedures, recover IPv4 address space. This policy provides a mechanism for the RIRs to put the recovered IPv4 address space back to the the IANA central pool and provides the IANA the policy by which it can allocate them back to the RIRs on a needs basis. This policy creates a new global pool of IPv4 address space that can be allocated where it is needed on a global basis without a transfer of address space between the RIRs.

AFRINICwill therefore assign numbering resources to entities requiring temporary IP numbers for a fixed period of time. In this document, "IP resources" refers to unicast IPv4/v6 addresses and AS numbers.

 

2) Proposal

This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases.

  1. Phase I: Recovery of IPv4 Address Space - Upon ratification of this policy by the ICANN Board of Directors, the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool.
  2. Phase II: Allocation of Recovered IPv4 address space by the IANA- Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005 [1]) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. The following definitions apply to this policy
    • Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report.
    • IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices.
    • Aggregated address blocks. Aggregated address blocks are contiguous prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two contiguous prefixes that can be combined to form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes that cannot be combined on a natural bit boundary to form an aggregated block.

 

3) Allocation of IPv4 Address Space

(A) For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year.

(B) At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. The minimum 'IPv4 allocation unit' size will be a /24.

(C) In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph 2.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. An example of how allocations would be made in practice is included as Appendix A.

 

4) IPv4 Address Space Allocation Criteria

A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period.

 

5) Initial Allocation of IPv4 Address Space

Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process.

 

6) Reporting

(A) All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR.

(B) All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR.

(C) The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated.

(D) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" [2] page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated.

 

7) Situation in other RIRs

This proposal has been adopted in APNIC region and is being submitted in all other RIR regions, with a view to becoming a global policy [3].

 

8) References

[1] Global Addressing Policy ASO-001-2 http://aso.icann.org/docs/aso-001-2.pdf

[2] Internet Protocol v4 Address Space http://www.iana.org/assignments/ipv4-address-space

[3] ICANN Address Supporting Organization (ASO) MoU http://aso.icann.org/docs/aso-mou2004.html

 

Appendix A

Example 1:

On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses) worth of IPv4 addresses.

a. IANA calculates that 1/10 of this space is 3,276 addresses.
b. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /21 (2,048 addresses).
c. Each RIR can request and receive a single allocation unit equivalent to a /21 worth of addresses.
d. IANA may not be able to allocate a contiguous /21 and may allocate discontinuous smaller blocks equivalent to a /21 worth of addresses.

Example 2:

On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses) worth of IPv4 addresses.

a. IANA calculates that 1/10 of this space is 409 addresses.
b. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /24 (256 addresses).
c. Each RIR can request and receive a single allocation unit equivalent to a /24 worth of addresses.
d. As the minimum size of address space returned to IANA is /24, IANA can allocate a contiguous range of addresses that amount to a /24.

Example 3:

On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses) worth of IPv4 addresses.
a. IANA calculates that 1/10 of this space is 204 addresses.
b. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /25 (128 addresses).
c. A /25 is smaller than the minimum permissible allocation size under this policy. Therefore, IANA is unable to make an allocation until more address space is received.

 

History
05.03.2009 Accepted by the ASO AC as a global policy proposal and thus open for discussion on rpd.
21.05.2009 Consensus reached at AfriNIC 10.
23.05.2009 15 Days Last Call for Comments starts.
06.06.2009 15 Days Last Call for Comments ends.
09.11.2010 Notification of board approval sent to rpd mailing list.

Last Modified on -
Details
  • Ref. Name:
    AFPUB-2010-GEN-005
  • Policy Affected:
    AFPUB-2004-GEN-001
  • Status:
    Implemented
  • Date:
    11 Nov 2010
  • Author:
    S. Moonesamy

1) Incentive

The initial policy development process (AFPUB-2004-GEN-001) used by AfriNIC was meant to be a transitional process. A revised policy was specified once AfriNIC was well established. The existing policy (AFPUB-2008-GEN-001) does not specify what should be done in the event that the PDP-MG cannot attend an public policy meeting or if a person disagrees with an action taken by the PDP-MG.

 

The lack of information affects the transparency of the policy development process. It has a negative impact on the decision-making process as issues that have been discussed and resolved on the mailing list are reopened during the public policy meeting because the community is not aware of the mailing list discussions. There is also a lack of documentation about the procedures used, and the approval and implementation of a policy.

 

The steps used to determine consensus leads to a situation where comments provided during online discussions do not bear the same weight as those made during the public policy meeting.

 

There is also a lack of awareness and a lack of understanding of the principles upon which the policy development process are based. Although the existing policy does not explicitly mention the principles, it follows the same principles mentioned in this document.

 

It is proposed to revise the existing policy so that the principles and procedures are documented. This document adds procedures to the policy development process to deal with disputes and the recall of the Chair. It also adds some flexibility to vary the process in the case of an emergency.

 

2) Introduction

This document describes the AfriNIC Policy Development Process (PDP). The policies are documented AfriNIC community decisions that directly determine the rules by which AfriNIC manages and administers Internet number resources.

 

The procedures described in this document are designed to be fair, open and objective and are intended to:

  • provide ample opportunity for participation and comment by all interested parties;
  • establish widespread Internet community consensus.

These procedures adopt generally accepted practices and provide the flexibility to adapt to a variety of circumstances that can occur in a process. This document obsoletes AFPUB-2008-GEN-001.

 

3) Scope

The Policy Development Process covers the development and modification of policies for handling Internet Number Resources within the AfriNIC service region. Changes to the Policy Development Process itself will also follow the process.

 

Internet number resource policies are distinctly separate from AfriNIC general business practices and procedures. General business practices and procedures are not within the purview of the Policy Development Process.

 

This policy will take effect at the first AfriNIC Public Policy Meeting following the ratification by the AfriNIC Board of Directors.

 

4) Policy Development Principles

All policies are developed by the Internet community following three principles: openness, transparency and fairness. The Internet community initiates and discusses the proposals. If consensus is reached on the draft policy, it is recommended to the AfriNIC Board of Directors for adoption as a policy.

3.1 Openness

All policies are developed in an open forum in which anyone may participate. There are no qualifications for participation.

 

3.2 Transparency

All aspects of the Policy Development Process are documented and publicly available via the AfriNIC website. The discussions are publicly archived. All procedures that are developed to implement the policy are documented by AfriNIC and are publicly available.

 

3.3 Fairness

The policies are to ensure fair distribution of resources and facilitating the operation of the Internet.

Actions are taken within a reasonable period of time.

 

5) Policy Development Working Group

The Policy Development Working Group (PDWG) discusses about the proposals. Anyone may participate via the Internet or in person. The work is carried out through the Resource Policy Discussion mailing list (RPD) and the Public Policy Meeting (PPM). Any person, participating either in person or remotely, is considered to be part of the Policy Development Working Group.

 

The Policy Development Working Group has two Chairs to perform the administrative functions of the group. The Working Group Chairs will be chosen by the AfriNIC community during the Public Policy Meeting and they will serve staggered two-year terms. The term ends during the first Public Policy Meeting meeting corresponding to the end of the term for which they were appointed. A term may begin or end no sooner than the first day of the Public Policy Meeting and no later than the last day of the Public Policy Meeting as determined by the mutual agreement of the current Chair and the new Chair.

 

As a special case for the two Working Group Chairs appointed when this policy first takes effect, one of the Chairs will be appointed for a two-year term, and the other Chair will be appointed for a one-year term.

 

If the Working Group Chair is unable to serve his or her full term, the Working Group may select a replacement to serve the remainder of the term. If the Working Group Chairs are unable to attend the Public Policy Meeting, the Working Group shall nominate a Chair for the session. Anyone present at the meeting, whether in person or by remote participation, may participate in the selection process for a temporary Chair.

 

6) Policy Development Process

Anyone can submit a proposal. Policy proposals are submitted to the Resource Policy Discussion mailing list by the author. AfriNIC will provide administrative support and assist the author(s) in drafting the proposal, if requested. AfriNIC shall also provide relevant facts and statistics if requested during the discussion.

 

6.1 Draft Policy

During the development of a policy, draft versions of the document are made available for review and comment by publishing them on the AfriNIC website and posting them to the Resource Policy Discussion mailing list. The document shall include the information mentioned in Appendix A. Each draft policy is assigned a unique identifier by AfriNIC. The website shall also contain the version history and the status of all proposals.

 

The draft policy shall be available for review for at least four weeks before the next Public Policy Meeting. The author(s) shall make the necessary changes to the draft policy according to the feedback received. The Working Group Chair(s) may request AfriNIC to provide an analysis, technical, financial, legal or other, of the impact of the draft policy.

 

A draft policy expires after one calendar year unless it is approved by the AfriNIC Board of Directors as a policy. The timeout period is restarted when the draft policy is replaced by a more recent version of the proposal. A draft policy can be withdrawn by the author(s) by sending a notification to the Resource Policy Discussion mailing list.

 

6.2 Public Policy Meeting

The draft policy is placed on the agenda of the an open public policy meeting. The agenda of the meeting shall be announced on the Resource Policy Discussion mailing list at least two weeks prior to the meeting. No change can be made to a draft policy within one week of the meeting. This is so that a stable version of the draft policy can be considered at the meeting. The Chair(s) determines whether rough consensus has been achieved during the Public Policy Meeting.

 

The Chair(s) shall publish the minutes of proceedings of the Public Policy Meeting not later than three weeks after the meeting.

 

6.3 Last Call

A final review of the draft policy is initiated by the Working Group Chair(s) by sending an announcement to the Resource Policy Discussion mailing list. The Last Call period shall be at least two weeks. The Working Group Chair(s) shall evaluate the feedback received during the Public Policy Meeting and during this period and decide whether consensus has been achieved.

 

6.4 Approval

The Working Group Chair(s) shall recommend the draft policy to the AfriNIC Board of Directors for approval if it has the consensus of the Policy Development Working Group. The recommendation shall include a report of the discussions of the draft policy and feedback from the Last Call. The draft policy shall be ratified by the AfriNIC Board of Directors.

 

6.5 Implementation

The adoption and implementation date of the policy is announced on the Resource Policy Discussion mailing list. The implementation date should be less than six months after the end of the Last Call unless a waiver is requested.

 

7) Conflict Resolution

A person who disagrees with the actions taken by the Chair(s) shall discuss the matter with the Working Group Chair(s) or with the Working Group. If the disagreement cannot be resolved in this way, the person may file an appeal with an Appeal Committee appointed by the AfriNIC Board of Directors. An appeal can only be filed if it is supported by three (3) persons from the Working Group who have participated in the discussions.

 

The appeal must be submitted within two weeks of the public knowledge of the decision. The Appeal Committee shall issue a report on its review of the complaint to the Working Group. The Appeal Committee may direct that the Chair(s) decision be annulled if the Policy Development Process has not been followed.

 

Anyone may request the recall of a Working Group Chair at any time, upon written request with justification to the AfriNIC Board of Directors. The request must supported by at least five (5) other persons from the Working Group. The AfriNIC Board of Directors shall appoint a recall committee, excluding the persons requesting the recall and the Working Group Chairs. The recall committee shall investigate the circumstances of the justification for the recall and determine the outcome.

 

8) Varying the Process

The process outlined in this document may vary in the case of an emergency. Variance is for use when a one-time waiving of some provision of this document is required. The decision to vary the process is taken by the Working Group Chair. There must be an explanation about why the variance is needed. The review period, including the Last Call, shall not be less than four weeks. If there is consensus, the policy is approved as described in Section 5.4 and it must be presented at the next Public Policy Meeting.

 

9) Acknowledgements

The author would like to acknowledge that some text and procedures in this document have been adapted from RFC 2026. Thanks to Adiel Apklogan and Alain Aina for their insight, and Alan P. Barrett. The author only documented the process; full credit belongs to the AfriNIC community.

 

Appendix A

Draft Policy Template

The Draft Policy shall include:

1. Unique identifier (assigned by AfriNIC)

2. Draft Policy Name

3. Author(s)
(a) Name
(b) Email address
(c) Affiliation, if applicable

4. Draft Policy Version
5. Submission Date
6. Changes to existing policies (updates, obsoletes), if applicable
7. Summary of proposal
8. Proposal
9. List of changes between previous versions of the draft, if applicable

 

 

History
25.06.2010 15 Days Last Call period starts
03.06.2010 Proposal reaches consensus during AfriNIC-12 in Kigali
11.03.2010 Author posts version 4. New reference now AFPUB-2010-GEN-004
11.03.2010 Author posts version 3 to mailing list. New reference now AFPUB-2010-GEN-003.
23.03.2010 Author posts updated version to mailing list. New reference now AFPUB-2010-GEN-001
19.01.2010 Author posts a change to incentive section
10.12.2009 Policy first proposed by direct submission to rpd mailing list and discussions commence
11.11.2010 Notification of board approval sent to rpd mailing list.
24.11.2010 Board sends communique to clarify some implementation details. Due to there not being enough time for proper elections, board proposed that S. Moonesamy and Paulos Nyirenda be interim chairs. Paulos declined on the 25th and Alan Barret volunteered.
 
Previous Versions
  1. AFPUB-2009-GEN-001
  2. AFPUB-2010-GEN-001
  3. AFPUB-2010-GEN-003
  4. AFPUB-2010-GEN-004

 

Page 5 of 12