IPv6 Policy and references Update (Draft 1)

1.0 Summary of the Problem Being Addressed by this Policy Proposal

Since this policy was developed, IPv6 deployment has evolved and also some parts of the policy have been changed, which led to several inconsistencies in the actual text, even wrong references to other text sections.

In addition to ironing out such inconsistencies, this proposal updates an important reference to a very recent document to make it easier to understand how LIRs can assign IPv6 addresses to their users.

This proposal does not imply any changes in how the actual policy is applied. Instead, the proposed changes are simply clarifications or involve correcting errors and updating references to avoid potential misinterpretations.

IPv4 exhaustion in other regions combined with other factors has imposed huge pressure on the AFRINIC IPv4 pool with requests for large IPv4 blocks, with very little IPv6 deployment. The pressure on the AFRINIC IPv4 pool has led to some policy proposals to reserve some blocks for certain sub-communities.

2.0 Summary of How this Proposal Addresses the Problem

This proposal reviews the text in those sections that need to be updated, correcting references to wrong sections, avoids misunderstandings and can be particularly helpful in solving one of overall issues with IPv6 deployment: the fact that a single /64 is assigned to end users, which is not correct in the case of IPv6.

The concept of “utilization” is clarified so it will have a neutral reading, regardless of the size of the prefix each LIR decides to assign.

3. Proposal

Articles 6.0, 6.1, 6.5.4.1, 6.5.4.2 and 6.8 of the CPM will be modified as follows:

Current	Proposed
6.0 IPv6 This section defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations in the AFRINIC region. It provides recommendations to the addressing registries (AFRINIC, APNIC, ARIN, LACNIC and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting. For more details about this document please read the RFC-3177.	6.0 IPv6 This section defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (LIRs) and other organisations in the AFRINIC region. In particular, it recommends the assignment of /48 in the general case and /64 when it is known that one and only one subnet is needed (i.e., point-to-point links or a cellular PDP-context). For more details, please read RFC6177.
6.1 Utilisation Unlike IPv4, IPv6 is generally assigned to End Sites in fixed amounts (e.g. /48). The actual usage of addresses within each assignment will be low when compared to IPv4 assignments. In IPv6,"utilisation" is only measured in terms of the bits to the left of the /48 boundary. In other words, "utilisation" refers to the assignment of /48s to End Sites and not the number of addresses assigned within individual /48s at those End Sites. Throughout this document, the term "utilisation" refers to the allocation of /48s to End Sites and not the number of addresses assigned within individual /48s within those End Sites.	6.1 Utilisation Unlike IPv4, IPv6 is generally assigned to End Sites in fixed amounts. The actual usage of addresses within each assignment will be low when compared to IPv4 assignments. In IPv6,"utilisation" is only measured in terms of the number of prefixes assigned to End Sites, not their size or the number of addresses actually used in those prefixes. This is how it should be understood throughout this document.
6.5.4.1 Assignment address space size Assignments are to be made using the following guidelines: 1. /48 in the general case, except for very large subscribers. 1. /64 when it is known that one and only one subnet is needed by design 1. /128 when it is absolutely known that one and only one device is connecting. AFRINIC is not concerned about which address size an LIR actually assigns. Accordingly, AFRINIC will not request the detailed information on IPv6 user networks (as in IPv4), except for the cases described in section 6.3.3 and for the purpose of measuring utilization as defined in this document.	6.5.4.1 Assignment address space Assignments are to be made in accordance with the need specified by the LIRs’ users as well as with other existing recommendations such as [RIPE-690, https://www.ripe.net/publications/docs/ripe-690], highlights of which are summarized below: 1. End sites or users must be assigned a prefix that is a multiple of "n" /64’s which must be enough to meet their current and planned needs, considering existing protocols and future possibilities and thus avoiding possible renumbering scenarios. 1. The size of the prefix to be assigned is an operational decision of the LIR, although the selection of /48s is recommended for simpler and more functional infrastructure for all the endpoints of the network. 1. Persistent prefix assignments are recommended to avoid undesired failures. 1. Using a /64 prefix for point-to-point with GUAs (Global Unicast Addresses) is recommended. AFRINIC is not concerned about which prefix size an LIR actually assigns. Accordingly, AFRINIC will not request detailed information on IPv6 user networks (as in IPv4), except for the cases described in section 6.5.2 and for the purpose of measuring utilization.
6.5.4.2 Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having AFRINIC review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future.	6.5.4.2 [TO BE DELETED FROM CPM]
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-users as long as they already have or qualify to get PI IPv4 addresses.

4. Revision History

Date	Details
14 March 2018	Version 1: AFPUB-2018-V6-001-DRAFT01 Initial Draft Posted to rpd

5. References

Similar text exists and/or has been proposed in related policy documents at other RIR communities.