[rpd] AFRINIC Number Resources Transfer Policy Version 1.0

[Noah]

Attention PDWG Co-chairs,

Any reason this proposal has not been posted online on the AFRINIC website?

*./noah*
neo - network engineering and operations


On Sat, Oct 17, 2020 at 4:03 PM Noah <noah at neo.co.tz> wrote:


> Dear Working Group/Co-Chairs,

>

> A new policy proposal  named "AFRINIC resources transfer policy" is

> submitted for discussions. This proposal obsoletes the current  IPv4

> transfer within AFRINIC  service region policy, defines rules for transfers

> of IPv4 and ASNs within the region and between the AFRINIC service region

> and other regions.

>

> The policy allows a category of resources to be transferred out of the

> region, another category of resources to be transferred inside and denies

> the transfer of certain resources.

>

> We expect this to be a response to a harmonised policy which addresses

> some of the limitations of the intra-rir policy and proposes a solution for

> an inter-rir transfer  which minimizes the foreseen risks of uncontrolled

> outflow of resources.

>

> Please find the proposals text below and also attached pdf format.

>

> Happiest Weekend,

> Noah on behalf of

> The Co-authors

>

>

> ================================================================

>

> Policy Name: *AFRINIC Number Resources Transfer Policy*

> ID: (Assigned by AFRINIC)

> Submission *Date: 17 Oct 2020*

> Version: 1.0

> Author(s): (a) Name, (b) Email address, (c) Affiliation, if applicable

>       Gregoire Olaotan Ehoumi, gregoire at ehoumi.net, independent

>       Noah  Maina, noah.maina at seacom.com, SEACOM

>       Adeola A. P. Aina, alain.aina at wacren.net, WACREN

>

>

> *Sections of Policy Manual affected*

> *Obsoletes*: IPv4 Resources transfer within the AFRINIC Region (Section

> 5.7 of the CPM)

>

> *1.0 Summary of the problem being addressed by this proposal*

>

> The AFRINIC IPv4 pool is expected to run out soon. Some entities may need

> IPv4 space to support their IPv6 deployments, especially to support

> transition mechanisms, which AFRINIC may not meet. The current Intra-RIR

> policy in force at AFRINIC allows entities to receive unused IPv4 addresses

> from other members solely within the AFRINIC region, based on justified

> needs. Considering the limited IPv4 space initially made available to

> AFRINIC (AFRINIC manages only 7.23 /8s with a very low ratio of IPv4

> addresses per Internet user), there will therefore be a need to allow for

> unused IPv4 from other regions to move into the AFRINIC service region °V

> this without necessarily depleting AFRINIC's slim amount of IPv4 addresses

> by transferring space out of the region. The current Intra-RIR transfer

> policy allows all types of IPv4 allocations/assignments to be transferred,

> including IPv4 from special purpose blocks (reserved blocks for IXPs and

> DNS root ops, Last /8, etc.) The current intra-RIR transfer policy does not

> cover ASNs while there are cases where transfers of ASNs among AFRINIC

> members is desirable.

>

>

> *2.0 Summary of how this proposal addresses the problem*

>

> This new policy defines a set of rules to allow transfer of IPv4 addresses

> and ASNs within the AFRINIC service region; and between the AFRINIC service

> region and other regions by specifying what categories of resources are

> eligible for transfer, the location of parties (sources and recipients) and

> the conditions to be met.

> The policy segregates resources in different categories and defines which

> transfer rules apply to each category.

> Only Legacy resources and resources transferred in from other regions will

> be transferable out of the AFRINIC service region.

> The policy also makes the following provisions:

> - Number resources are non-transferable unless AFRINIC has expressly and

> in writing approved a request for transfer. AFRINIC is tasked with making

> prudent decisions on whether to approve the transfer of number resources.

> - IPv4 addresses and ASNs can be transferred only in accordance with this

> policy.

> - AFRINIC does not recognize transfers outside of approved transfer

> policies and requires organizations holding such resources to return them

> to the appropriate registries.

> The goal of this transfer policy is to help distribute resources from

> those who no longer need them to organizations that need the resources, but

> cannot obtain them from the AFRINIC free pools.

> AFRINIC recognizes the following types of transfers:

> - merger, acquisition, takeover or consolidation,

> - between AFRINIC members,

> - between an AFRINIC member and an organization in another region,

> - between a Legacy resource holder and an AFRINIC member,

> - between a Legacy resource holder and an organization in another region.

> AFRINIC will process and record Inter-RIR resource transfers only when the

> counterpart RIR has an Inter-RIR transfer policy that permits the transfer

> of IPv4 address space and ASNs between its own region and AFRINIC.

> Currently, the other regions are APNIC, ARIN, LACNIC, RIPE NCC.

>

> *3.0 Proposal*

>

> Insert the following text into the CPM (numbering to be changed by staff

> as appropriate):

> 3.1 Definitions

> 3.1.1 "Resource" refers to IPv4 Address space or Autonomous System Numbers.

> "AFRINIC pool" means the AFRINIC managed pool of IPv4 and ASNs, obtained

> from IANA (allocated and recovered) or through the ERX (Early registration

> transfers).

> 3.1.2 "Special-Purpose pool" means the pool of resources currently

> reserved for Critical Internet Infrastructures (section 5.6.4 of CPM) and

> resources distributed during the Exhaustion phases of the soft landing

> policy (section 5.4 of CPM).

> 3.1.3 "Legacy resources" refer to resources allocated prior to the RIR

> system and tagged as Legacy by AFRINIC.

> 3.1.4 "Others" means resources transferred from other regions through

> Inter-RIR transfers.

> 3.1.5 "Inter-RIR transfer" means the transfer of resources from a resource

> holder in the AFRINIC service region to an organization in another region

> or vice-versa.

>

> *3.2 Marking of the resources*

> AFRINIC pool == Regional

> Special-Purpose pool == Reserved

> Legacy == Legacy

> Others == Global

>

> *3.3 Rules and procedures for selecting resources eligible for transfers*

> 3.3.1 If source and recipient are AFRINIC members, then allow "Regional",

> "Global" or "Legacy" for transfer and mark transferred "Legacy" as "Global".

> 3.3.2 If source is Legacy holder and recipient is AFRINIC member, then

> allow "Legacy" for transfer and mark transferred resources as "Global".

> 3.3.3 If source is Legacy holder and recipient is in another region, then

> allow "Legacy" for transfer.

> 3.3.4 If source is AFRINIC member and recipient is in another region, then

> allow "Global" for transfer.

> 3.3.5 If source is from another region and recipient is AFRINIC member,

> then allow "Any", and then mark the transferred resources as "Global".

> 3.3.6 Irrespective of the source and recipient, if the resource to be

> transferred is "Reserved" then deny transfer. This restriction excludes

> mergers, acquisitions and takeover transfers.

>

> *3.4 Conditions on resources to be transferred*

> - The size of the IPv4 address prefix should be a minimum of /24.

> - The resource must qualify for the type of transfer requested.

> - The resource will be covered by AFRINIC policies after transfer into the

> region.

>

>

> *3.5 Conditions on the source*- Must be the right holder of the resources

> to be transferred with no disputes.

> - If the source is from other regions, conditions on the source are

> defined in the counterpart RIRs transfer policy.

>

> *3.6 Conditions on the recipient*

> - Will be subject to current AFRINIC policies.

> -  Must sign RSA.

> - Recipient that does not have prior resources must:

> ++ demonstrate a detailed plan for the use of the transferred resources

> (in the case of ASN, the recipient must meet the criteria for assignment

> of ASN).

> - Recipient with prior resources must:

> ++ demonstrate a detailed plan for the use of the transferred resources

> (in the case of ASN, the recipient must meet the criteria for assignment

> of ASN).

> ++ Show past usage rate.

> ++ Provide evidence of compliance with AFRINIC policies with respect to

> past allocations/assignments.

> - If the recipient is in another region, the conditions on the recipient

> are defined in the counterparts RIR transfer policy.

>

> * 4. References*

>

> https://www.nro.net/wp-content/uploads/NRO-Statistics-2019Q2.pdf

> https://www.potaroo.net/tools/ipv4/

> https://bgp.potaroo.net/iso3166/v4cc.html

> https://resources.potaroo.net/iso3166/ascc.html

> ftp://ftp.afrinic.net/stats/afrinic/transfers/

>

> ================================================================

>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20201025/454fb50e/attachment.html>