Route Aggregation Policy (Draft 1)
- Last Modified on -
| Ref. Name: AFPUB-2017-V4-002-DRAFT-01 |
Versions:1.0 Status: Under Discussion Amends: CPM 5.4.4 |
Author:
|
| Submitted: 21 April 2017 |
|
Date |
Revision |
|
21 April 2017 |
Version 1 : AFPUB-2017-V4-002-DRAFT-01 |
Under the current policy text, it is explicitly stated that an LIR has no limits on the amount of additional allocations they can take, if issued individually, it will result in a significant increase of entries in the routing table.
Allow AFRINIC to issue IPv4 prefixes as contiguous bit boundary ranges, limiting the number of broken prefixes being announced.
Replace Clause 5.4.4 of the Consolidated Policy Manual (CPM) as follows:
Current text:
5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period.
New text:
5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period. For the sake of routing table conservation, prefixes will be issued as aggregates when an LIR requests multiple additional allocations.
The proposal requires that for LIRs requesting multiple IPv4 allocations, AFRINIC will issue those blocks as aggregates (on contiguous bit boundary ranges). This provision is in CPM 5.4.4 which is being rephrased.
CPM 5.4.4 is being rephrased as follows:
Current: 5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period.
New: 5.4.4 For any LIR or End User requesting IPv4 address space during the Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period. For the sake of routing table conservation, prefixes will be issued as aggregates when an LIR requests multiple additional allocations.
Observations:
None Observed
| Details | Date | Revision History |
|
28 March 2018 |
Version 1: AFPUB-2018-V6-004-DRAFT01 Initial Draft Posted to rpd. |
Since this policy was developed, the IPv4 addressing space has been exhausted, and the IPv6 deployment has evolved, so it doesn’t make sense to tie an IPv6 policy to the existence or IPv4 (same way as it is not tied the initial allocation policy).
In addition to that, because AFRINIC provided IPv6 PI at no cost to existing IPv4 PI holders, it may happen that the “default” assignment was requested without a proper addressing plan and this may not be the correct one at the implementation time.
This proposal updates the relevant text to accommodate the possibility to obtain IPv6 PI even if there is not IPv4 PI.
This proposal also adds a new section in order to allow a rectification of the initial assignment.
Article 6.8 of the CPM will be modified as follows:
Current |
Proposed |
|
6.8 PI Assignments The current policy does not allow IPv6 provider independent (PI) address assignment to any 'end-sites'. In addition, lack of IPv6 transport will compel many 'end-sites' to tunnel. Thus, to avoid renumbering when IPv6 transport will be available, a provider independent assignment seems reasonable. More so, not all LIR's have IPv6 address space allocations. This makes it impossible for end-users to get PA IPv6 address space from such upstream (LIR's). This policy is also aimed at providing IPv6 address space to such end-users as long as they already have or qualify to get PI IPv4 addresses. |
6.8 PI Assignments This policy is aimed at providing IPv6 address space to end-user. |
|
6.8.1 Introduction This policy allows 'end-sites' to be assigned IPv6 provider independent (PI) addresses. 'End-sites' include End-Users who already have or qualify to get IPv4 PI addresses and critical Infrastructure providers such as TLD root server operators and public Internet exchange Points (IXP's). |
6.8.1 Introduction This policy allows 'end-sites' to be assigned IPv6 provider independent (PI) addresses. 'End-sites' include End-Users and critical Infrastructure providers such as TLD root server operators and public Internet exchange Points (IXP's). |
|
6.8.2 Assignment Criteria
|
6.8.2 Assignment Criteria
|
|
6.8.3 Provider Independent (PI) address space:
|
6.8.3 Provider Independent (PI) address space:
|
|
[Introduce new clause 6.8.4] |
6.8.4. Rectifying the size of an initial assignment An ‘End-site’ may submit a new addressing plan to AFRINIC if the plan initially submitted to justify the initial assignment no longer satisfies their current needs. The new assignment will be consistent with the new plan and comply with 6.8.2 and 6.8.3. If possible, the same address block will be “upgraded” to the new required prefix size. However, if the adjacent prefixes are already being used by other organizations or if such assignment would not leave sufficient space for subsequent assignments, AFRINIC will inform to the requesting organization, which will have the following options:
This procedure can only be used once by each end-site. |
Similar text exists and/or has been proposed in related policy documents at other RIR communities.