Policy Pre-CPM

Ref. Name AFPUB-2010-v4-003-draft-02
Status

Proposal EXpired

Date 24 Nov 2011
Author(s) Steve Bertrand
Chris Grundemann
Martin Hannigan
Aaron Hughes
Louie Lee
Matt Pounsett
Jason Schiller
Policy Affected  
 
TOC

 

Incentive:

Allow all IPv4 inventory regardless of prefix size to be returned to, and subsequently reallocated fairly and equitably by the IANA post-runout.

 

1.) Rationale

This policy defines the process for the allocation of IPv4 addresses post "Exhaustion Phase"[1]. A global policy is required in order for the IANA to be able to transparently continue to be able to allocate IPv4 addresses beyond exhaustion. In order to fulfill the requirements of this policy, the IANA must set up a reclamation pool to hold addresses in and distribute from in compliance with this policy. This policy establishes the process by which IPv4 addresses can be returned to and re-issued from the IANA post Exhaustion Phase.

This document does not stipulate performance requirements in the provision of services by the IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN.

 

The intent of this policy is as follows:

    • To include all post Exhaustion Phase IPv4 address space returned to the IANA.
    • Allows allocations by the IANA from the Reclamation Pool once the Exhaustion Phase has been completed.
    • Defines "need" as the basis for further IPv4 allocations by the IANA.
    • Does not differentiate any class of IPv4 address space unless otherwise defined by an RFC.
    • Encourage the return of IPv4 address space by making this allocation process available.
    • Disallow transfers of addresses sourced from the Reclamation Pool in the absence of an IPv4 Global Transfer Policy to neutralize transfer process inequities across RIR regions.
    • Applies to legacy IPv4 Address Space initially allocated by the IANA to users including the allocations to RIRs.
    • Includes any length of fragments currently held by the IANA now or in the future.



2.) Reclamation Pool

Upon adoption of this IPv4 address policy by the ICANN Board of Directors, the IANA shall establish a Reclamation Pool to be utilized post RIR IPv4 exhaustion as defined in Section 4. The reclamation pool will initially contain any fragments that may be left over in IANA inventory. As soon as the first RIR exhausts its inventory of IP address space, this Reclamation Pool will be declared active. When the Reclamation Pool is declared active, the Global Policy for the Allocation of the Remaining IPv4 Address Space[3] and Policy for Allocation of IPv4 Blocks to Regional Internet Registries[4] will be formally deprecated.

 

3.) Returning Address Space to the IANA

The IANA will accept into the Reclamation Pool all eligible IPv4 address space that are offered for return. Eligible address space includes addresses that are not designated as "special use" by an IETF RFC or addresses allocated to RIR's unless they are being returned by the RIR that they were originally allocated to. Legacy address holders may return address space directly to the IANA if they so choose.

 

4.) Address Allocations from the Reclamation Pool by the IANA

Allocations from the Reclamation Pool may begin once the pool is declared active. Addresses in the Reclamation Pool must be allocated on a CIDR boundary. Allocations from the Reclamation Pool are subject to a minimum allocation unit equal to the minimum allocation unit of all RIRs and a maximum allocation unit of one /8. The Reclamation Pool will be divided on CIDR boundaries and distributed evenly to all eligible RIRs once each quarter. Any remainder not evenly divisible by the number of eligible RIRs will remain in the Reclamation Pool until such time sufficient address returns allow another round of allocations.

 

5.) RIR Eligibility for Receiving Allocations from the Reclamation Pool

Upon the exhaustion of an RIR's free space pool and after receiving their final /8 from the IANA[3], an RIR will become eligible to request address space from the IANA Reclamation Pool when it publicly announces via its respective global announcements email list and by posting a notice on its website that it has exhausted its supply of IPv4 address space. Exhaustion is defined as an inventory of less than the equivalent of a single /8 and the inability to further assign address space to its customers in units equal to or shorter than the longest of any RIR's policy defined minimum allocation unit. Up to one /10 or equivalent of IPv4 address space specifically reserved for any special purpose by an RIR will not be counted against that RIR when determining eligibility unless that space was received from the IANA reclamation pool. Any RIR that is formed after the ICANN Board of Directors has ratified this policy is not eligible to utilize this policy to obtain IPv4 address space from the IANA.

 

6.) Reporting Requirements

The IANA shall publish on at least a weekly basis a report that is publicly available which at a minimum details all address space that has been received and that has been allocated. The IANA shall publish a Returned Address Space Report which indicates what resources were returned, by whom and when. The IANA shall publish an Allocations Report on at least a weekly basis which at a minimum indicates what IPv4 address space has been allocated, which RIR received the allocation and when. The IANA shall publish a public notice confirming RIR eligibility subsequent to Section 4.

 

7.) No Transfer Rights

Address space assigned from the Reclamation Pool may be transferred if there is either an ICANN Board ratified global policy or globally coordinated RIR policy specifically written to deal with transfers whether inter-RIR or from one entity to another. Transfers must meet the requirements of such a policy. In the absence of such a policy, no transfers of any kind related to address space allocated or assigned from the reclamation pool is allowed.

 

8.) Definitions

IANA - Internet Assigned Numbers Authority, or its successor

ICANN - Internet Corporation for Assigned Names and Numbers, or its successor

RIR - Regional Internet Registry as recognized by ICANN

MoU - Memorandum of Understanding between ICANN and the RIRs

IPv4 - Internet Protocol Version Four(4), the target protocol of this Global Policy

Free Space Pool - IPv4 Addresses that are in inventory at any RIR, and/or the IANA

 

9) Contributors

The following individuals donated their time, resources and effort to develop this proposal on behalf of the Internet Community:

Steve Bertrand
Chris Grundemann
Martin Hannigan
Aaron Hughes
Louie Lee
Matt Pounsett
Jason Schiller

 


10) References

1. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm
Global Policy for the Allocation of the Remaining IPv4 Address Space, IANA, Retrieved 27 April 2010

2. http://aso.icann.org/documents/memorandum-of-understanding/index.html ICANN Address Supporting Organization (ASO) MoU , Retrieved 27 May 2010.

3. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm Global Policy for the Allocation of the Remaining IPv4 Address Space

4. http://aso.icann.org/wp-content/uploads/2009/09/aso-001-2.pdf Policy for Allocation of IPv4 Blocks to Regional Internet Registries

History
25.08.2010 Proposal first posted to rpd mailing list by Steve Bertrand.
27.08.2010 Posted to website and assigned reference AFPUB-2010-v4-003
25.11.2010 New update discussed during AfriNIC-13 Public Policy Meeting and renamed to AFPUB-2010-GEN-006
24.11.2011

 2011-11-24 - Proposal expires after one year of inactivity.

Previous Version
  AFPUB-2010-v4-003-draft-01

 

Details

  • Ref. Name: AFPUB-2014-GEN-004-DRAFT-03

  • Status: Last Call

  • Date: 03 Jun 2015

  • Status:
    Implemented
  • Author(s):
    Frank Habicht, Tanzania Internet Exchange,
    Michuki Mwangi, Internet Society/KIXP,
    Nishal Goburdhan, Packet Clearing House/JINX

 

1. Summary of the problem being addressed by this proposal

AFRINIC has an existing policy to make IPv4 assignments to Critical Infrastructure, but not one to specifically reserve Internet Number Resources space for IXPs. As a result, it is anticipated that the exhaustion of these resources could make it difficult, if not impossible for IXPs to get sufficient resources to grow.

 

2. Summary of how this proposal addresses the problem 

This policy requests AFRINIC to reserve, and publish IPv4 resources, and ASNs for use by IXPs only. 

 

3. Proposal

3.1 Introduction

 

It is widely considered that Internet Exchange Points (IXPs) are one of the critical elements needed for Internet economies to develop. Africa is still in the process of developing these, and is, at the same time, faced with the imminent exhaustion of its IPv4 resources. 

 

Not having IPv4 addresses to grow, or start, new IXPs would create unnecessary and unneeded routing complexity for Internet connected networks, looking to peer at IXPs to further their network scope.

 

AFRINIC already has an existing policy to make allocations to IXPs [1], but that policy does not specifically reserve IPV4 space to ensure that there will be such, for future IXPs to grow and develop.  Additionally, this policy reserves a set of ASNs between 0 - 65535 for use by IXPs, for IXP BGP Route Servers. 

 

3.2 Distinction between IXP peering and management networks

 

We distinguish between two kinds of IP number resources needed and used at IXPs. 

 

An IXP peering LAN is the contiguous network address block that the IXP would use to assign unique IP addresses to each peering member, for each peering participant to exchange network traffic across the shared peering infrastructure. Best practice has the IXP peering LAN not being visible in a view of the global routing table, among other things to reduce the attack vectors for ISP border routers via the IXP. 

 

From a network identification, monitoring and analysis perspective, it is thus desirable, that the "peering LAN" space be provided from a contiguous block. The IXP management LAN is the management network that the IXP uses to provision services at the IXP, like monitoring, statistics, mail, ticket systems, provisioning of transit to DNS Roots, etc. Management networks, are meant to be reachable globally, for instance to publish data and allow remote access for common good network infrastructure (such as root and TLD DNS servers) and research projects. 

 

3.3 BGP Route Servers use 

 

Typically IXPs use BGP route servers to help manage peering sessions between different participants.  The route servers implement IXP routing policy in the form of BGP communities, typically in the form of A:B, where A,B represent A=IXP BGP route server and B=participant ASN. 

 

Current BGP implementations utilise 6 bytes for the extended community attribute. Therefore, an IXP with a 4-byte ASN in use at its route server would not be able to successfully implement the A:B BGP community mapping, if an IXP participant has a 4-byte ASN. This situation is likely to be experienced by more IXPs, as additional 4-byte ASNs are allocated through the current AFRINIC process. 

 

If IXP route server communities include the IXP ASN and the peer's ASN (expected to be 4-byte), and a total of only 6 bytes are available, it follows that IXP route servers ASN could not be longer than occupying more than 2 bytes. 

 

3.4 Proposal 

 

To ensure that there are sufficient resources for IXPs to develop, this policy proposes that AFRINIC reserve IPv4 addresses for IXP peering LANs out of an address block marked particularly, and exclusively, for IXP peering LAN use. 

 

Assignments for IXP peering LANs must be from one dedicated block, published as such by AFRINIC. The Peering LAN assignments for each IXP should ensure that the adjacent /24 IP block is reserved (based on the minimum end-user assignment policy size of /24) to support future growth of the IXP. This will enable an IXP to increase its peering LAN resources to /23 without having to renumber to a new contiguous IP block allocation. 

 

Assignments for IXP management addresses should NOT be provided from the same block as the IXP peering LANs. 

 

It is proposed that a /16 block be reserved for future requirements for IXP peering LANs in the AFRINIC service region, and that AFRINIC publish this block as such. In addition, the assignments for the IXP peering LAN should reserve the adjacent contiguous /24 IP block to the requesting IXP for future growth.

 

These reservations shall be upheld until such a time that the available pool of the /16 can no longer allocate /23 assignments. Thereafter, new requests may be assigned from the reserved space held for future IXP growth.  It is further proposed to reserve the equivalent of an additional /16 block for IXP management prefixes, separate from the peering LANs. 

 

It is proposed that AFRINIC reserves a block of ASNs between 0 - 65535 for use in BGP route servers at IXPs in the AFRINIC service region. The number of ASNs to be reserved should be the larger of 114, or half of the remaining ASNs between 0 - 65535 within AFRINIC's block at the date of ratification of this policy.  AFRINIC will allocate these resources on a first come first served basis. 

 

3.5 Evaluation criteria 

 

This policy does not suggest new evaluation criteria for what determines a valid IXP. 

 

4. Revision History

  1. 23 Oct 2014 - AFPUB-2014-GEN-004-DRAFT-01 posted on rpd list.
  2. 05 Nov 2014 - AFPUB-2014-GEN-004-DRAFT-02 posted on rpd list.
  3. 11 Jun 2015 - AFPUB-2014-GEN-004-DRAFT-03 posted on rpd list.

 


References

 

[1] AFRINIC Policy for End User Assignments - AFPUB-2006-GEN-001, http://afrinic.net/en/library/policies/127-afpub-2006-gen-001 Sections (5) and (6)

 

 

Page 1 of 12