IPv6 PI Clarification

Policy Development Process (PDP)

← Back to PPM Minutes

Details

ID: AFPUB-2019-v6-001-DRAFT02

Version: 2.0

Status: Implemented

Authors: Jordi Palet Martinez -

jordi.palet at theipv6company.com

The IPv6 Company

Owen DeLong -

owen at delong.com

Great Home Tek, Inc

Amends: CPM art 6.8

Submitted: 14th May 2019

Proposal

1.0 Summary of the problem being addressed by this proposal

By means of policy proposal “IPv6 PI Update” (AFPUB-2018-V6-004), the IPv6 Provider Independent (PI) space policy that provides IPv6 space for end-sites was revised/updated.

This revision however overlooked a sentence in the previous section 6.8.2.v, which read:

“The 'end-site' must show a plan to use and announce the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AFRINIC”.

This text was retained under 6.8.2.iv.

Of course, this doesn’t make sense because there are several possible cases, which are in the scope of this policy, that will not announce their IPv6 PI address space, such as:

IXP’s LAN peering space.
Numbering of private networks not connected to the Internet is a perfectly valid use case for IPv6 PI space and should be supported by RIR policy

In addition, the existing text is referring to end-sites, when actually should consider end-user organizations. An end-site, considered as a single “location”, will not address cases such as organizations having multiple end-sites and will force multiple AFRINIC end-user memberships.

An organization with multiple end-sites, will probably fall in one of the following cases:

Multiple end-sites connected with Layer 2 and BGP to their upstreams (a bank, a multi-campus university, etc.), will be able to obtain a prefix length sufficient to accommodate the entire number of sites, hopefully in the nibble boundary and announce a single aggregated prefix.
Multiple end-sites not connected among them and being announced as "different" networks, for example, even with different ISPs. Typically, will use and announce a single /48 for each end-site.
A possible mix case among 1 and 2 above.

2.0 Summary of how this proposal addresses the problem

Simple rewording of the text to allow those cases that don’t need to announce their IPv6 PI space.

3.0 Proposal

Current

Proposed

6.8 PI Assignments

This policy is aimed at providing IPv6 address space to end-sites.

6.8 PI Assignments

This policy is aimed at providing IPv6 address space to end-user organizations.

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.1 Introduction

This policy allows 'end-sites' of end-user organizations to be assigned IPv6 provider independent (PI) addresses. These include critical Infrastructure providers such as TLD root server operators and public Internet exchange Points (IXP's).

6.8.2 Assignment Criteria

Assignment target - End-sites which provide Public Internet services for a single administrative organisations' network, regardless of their size.
Assignment criteria:
1. The end-site must not be an LIR
2. The end-site must become an AFRINIC End User Member and pay the normal AFRINIC fee for its membership category
3. The end-site must justify the need for the IPv6 PI address space.
4. The end-site must show a plan to use the IPv6 provider independent address space within twelve (12) months. After that period, if not announced, the assigned IPv6 PI address space should be reclaimed and returned to the free pool by AFRINIC.
5. The IPv6 provider independent address space to be announced by the end-site should not be disaggregated.

6.8.2 Assignment Criteria

Assignment target - End-user organizations which provide services for their administrative organizations’ network, regardless of their size.
Assignment criteria:
1. The organization must not be an LIR.
2. The organization must be or become an AFRINIC End User Member.
3. The organization must justify the number of end-sites and the need for the IPv6 PI address space.
4. The organization must deploy the IPv6 provider independent address space at each of the end-sites, for which addresses are obtained, within twelve (12) months.
5. If the addressing space issued under this policy is to be announced, to the extent practicable, the organization should aggregate any announcements of prefixes so as to minimize global routing table growth.

6.8.3 Provider Independent (PI) address space:

The provider independent (PI) assignment should be made from a specific block.
The initial provider independent assignment size to an end-site should be a /48, or a shorter prefix if the end-site can justify it.
Subsequent assignments must be documented and justified. Where possible, such assignments will be made from a contiguous address block (i.e., extending the existing assignment "n" bits to the left).

6.8.3 Provider Independent (PI) address space:

The provider independent (PI) assignment should be made from a specific block.
The initial provider independent assignment size for each organization shall be at least a /48 per end site. If multiple end sites are requested and will be connected to each other, a nibble-aligned prefix shall be issued sufficient to allow at least one /48 per end-site. Valid justification for a shorter prefix for any end sites shall be accommodated.
The organization assignment will be calculated on the basis of the number of end-sites and adjusted to the nearest nibble-boundary.
Subsequent assignments must be documented and justified. Where possible, such assignments will be made from a contiguous address block (i.e., extending the existing assignment "n" bits to the left).
AFRINIC shall use a sparse allocation algorithm when issuing space to maximize the likelihood of success for the mechanism defined in the preceding paragraph.

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:
i. Receive a new block with the new requested prefix size, with the commitment to renumber its network and return the original block within a period of 6 months;
ii. Receive a new block which, together with the block that has already been assigned, covers the new justified need, and keep both blocks.
This procedure can only be used once by each end-site.

6.8.4 Rectifying the size of an initial assignment

An organization 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:
i. Receive a new block with the new requested prefix size, with the agreement to utilize the new block for all future deployment and deprecate the old block through attrition, returning when empty. There is no deadline for return at this time;
ii. Receive a new block which, together with the block that has already been assigned, covers the new justified need, and keep both blocks.
This procedure can only be used once by each organization.