AFRINIC Number Resources Transfer Policy (Draft-2)

Proposal

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 address 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 – 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 and are not assignable to any other organization 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 or takeover,
• 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.

 

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 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 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 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 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, 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, 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 counterpart’s RIR transfer policy.

 

 4. References

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

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

http://bgp.potaroo.net/iso3166/v4cc.html

http://resources.potaroo.net/iso3166/ascc.html

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

 

Revision History

Revision History 

Date	Details
29 Aug 2019	Version 1: AFPUB-2019-GEN-002-DRAFT01 Submitted for discussion
22 Sep 2019	Version 2: AFPUB-2019-GEN-002-DRAFT01 Submitted for discussion
	Rephrase the following clauses for clarity: Type of resources transferable out of the region in section 2.0 Type of transfers recognized by AFRINIC in section 2.0 3.1.2 to include all allocations/assignments during the exhaustion phases to the "reserved" pool 3.1.5 to enlarge the  definition of Inter-RIR transfer to explicitly cover Legacy resource holders 3.3.6 to exclude merger, acquisition and takeover from the restriction on transfer of "reserved" pool

  

AFRINIC Policy Impact Assessment

 

AFRINIC Staff Assessment

Date of Assessment	Relevant to Proposal
Sept 2020	AFPUB-2019-GEN-002-DRAFT02

 

1.0 Staff Understanding of the Proposal

• ASN's shall be transferrable both inter and intra-region
• Legacy IPv4 space in the AFRINIC region can be transferred out. Transferred IPv4 space from other regions into AFRINIC can also be transferred out.
• Number resources are non-transferable and are not assignable to any other organisation unless AFRINIC has expressly and in writing approved a request for transfer. AFRINIC's approval is usually documented electronically in tickets.
• IPv4 addresses and ASNs can be transferred only if the transfer requests are evaluated against and in accordance with this policy.
• AFRINIC does not recognise transfers outside of approved transfer policies and requires organisations holding such resources to return them to the appropriate registries. Meaning that any transfers that happened outside any approved AFRINIC policies are not valid and the recipient organisations will be required to return the space to AFRINIC or the RIRs
• AFRINIC recognizes the following types of transfers - bother inter and intra-RIR:
  • merger, acquisition or takeover,
  • 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.
• The policy requires some categorisation"marking" that will, in turn, require AFRINIC to tag currently delegated resources and available resources.
• The resource will be covered by AFRINIC policies after transfer into the region. Legacy resources will no longer be legacy

 

The transfer conditions have been summarised in the table below:- 

 

Policy Condition	Source	Recipient	Resource Type		Final Tag	Transfer Type	Conditions
			Allowed	Denied			Source	Recipient
3.3.1	AFRINIC Member	AFRINIC Member	Regional, Global or Legacy	Reserved	Legacy ->  Global Regional -> no change Global -> no change	Intra-RIR	Must be the right holder of the resources to be transferred with no disputes.	Sign RSA. New members - Comply with policies, demonstrate a plan to use transferred IPv4 resources /ASN policy compliance Existing Members - demonstrate a plan to use transferred IPv4 resources /ASN policy compliance, past usage rate, compliance AFRINIC policies with respect to past allocations/assignments.
3.3.2	Legacy	AFRINIC Member	Legacy	Reserved, Regional and Global	Legacy ->  Global	Inter-RIR & Intra-RIR	Must be the right holder of the resources to be transferred with no disputes.
3.3.3	Legacy	RIR	Legacy	Reserved, Regional and Global	N/A	Inter-RIR	Must be the right holder of the resources to be transferred with no disputes.
3.3.4	AFRINIC Member	RIR	Global	Reserved, Regional	N/A	Inter-RIR	Must be the right holder of the resources to be transferred with no disputes.
3.3.5	RIR	AFRINIC Member	Any IPv4/ASN	N/A	Global	Inter-RIR	- defined in the counterpart RIRs - transfer policy.

 

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.

 

1.2 Staff Need more clarification from Authors

None

 

2.0 Staff Comments On Areas of Impact

If the proposal reaches consensus:

 

2.1 Impact on Systems

1. The Transfer tool on MyAFRINIC will require further adjustments to accommodate inter-RIR transfers
2. Reverse DNS impacts to be considered (for majority /8s)
3. RPKI ROAs
4. Transfer logs
5. RT (AFRINIC Ticketing System)
6. Resource tagging to be implemented on MyAFRINIC

 

2.2 Impact on Processes and procedure

1. Processes and procedures will require a review.
2. Coordination with the RIRs who have compatible inter-RIR transfer policies will also be required

 

2.3 Impact on Operations

1. Resource Transfer evaluation are resource-intensive and MS department would require additional staffing needs to facilitate officiate and timely evaluations
2. Resources will also be required in the software engineering team to implement the transfer on the AFRINIC systems.