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
|
6.8.2 Assignment Criteria
|
6.8.3 Provider Independent (PI) address space:
|
6.8.3 Provider Independent (PI) address space:
|
6.8.4 Rectifying the size of an initial assignment
|
6.8.4 Rectifying the size of an initial assignment
|
4. References
Other RIRs have already accommodated this requirement in their policies:
- APNIC: 10.1.4. Provider Independent IPv6 assignment
https://www.apnic.net/community/policy/resources#Part%203:%20IPv6%20Policy
- ARIN: 6.5.8.1. Initial Assignment Criteria
- LACNIC: 4.5.4.2 Direct assignment of portable IPv6 addresses to End sites not having portable IPv4 addresses previously assigned by LACNIC
https://www.lacnic.net/684/2/lacnic/4-ipv6-address-allocation-and-assignment-policies
- RIPE: 7. IPv6 Provider Independent (PI) Assignments
https://www.ripe.net/publications/docs/ripe-707#IPv6_PI_Assignments
Revision History
Revision History
Date |
Details |
09 April 2019 |
Version 1: AFPUB-2019-v6-DRAFT01 Initial Draft Posted to rpd |
14 May 2019 |
Version 2: AFPUB-2019-v6-DRAFT02 Comprehensive revisions to 6.8.2, 6.8.3 and 6.8.4
|