----------------------------------------------------------------------------------------------- prop-164-v005: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment ----------------------------------------------------------------------------------------------- Proposers: Christopher Hawker (chris@thesysadmin.au) Luke Thompson (luke.t@tnc.works) 1. Problem statement -------------------- Currently, if an account holder receives an assignment longer than a /32 (e.g. a /40), they cannot make sub-assignments to their customers or internal areas within their organisation and maintain accurate records of longer prefixes regarding these sub-assignments within Whois/RDAP. If they want to properly document sub-assignments and update Whois, they are required to request a /32. Maintaining accurate records is critical to ensure the stable and secure management of Internet Number Resources. 2. Objective of policy change ----------------------------- This policy change will reduce the minimum allocation size from a /32 prefix to a /40 prefix. This is to reduce the minimum amount of resources which a member has to apply for, which in turn allows them to maintain more accurate Whois/RDAP records. 3. Situation in other regions ----------------------------- - ARIN already allows for /36 and /40 prefix delegations under section 6.5.2.1 of their Number Resource Policy Manual. - LACNIC, RIPE NCC and AFRINIC policies all still list /32 as the minimum allocation size. 4. Proposed policy solution --------------------------- Update "APNIC-127 APNIC Internet Number Resource Policies" per the below: - 5.2.3.1 LIR-to-ISP allocation Add a new line that reads: "When an LIR makes a delegation to an ISP with whom they are directly connected, they must update the Whois database with the relevant delegation details." - 8.1 Minimum IPv6 allocation Replace the first paragraph with: "The minimum allocation size for IPv6 address space is /40." - 8.1.1 Returning excess IPv6 allocation/s Add new section 8.1.1 with: "If an account holder has been allocated a /32 or shorter, they will be eligible to return the balance of their allocation, reducing their allocation size to a /40. If a member has a /32 or shorter IPv6 allocation, they may reduce it to a /40 by keeping the first /40 and returning all other space." - 8.2.1 Account holders with existing IPv4 space Replace "An account holder that has an IPv4 allocation is eligible for a /32 IPv6 address block" with "An account holder that has an IPv4 allocation is eligible for a /40 IPv6 address block". - (NEW) 8.2.3 Reservation of IPv6 space for future expansion Add a new section with the above title and the following text: "When an account holder requests an allocation longer than a /28, APNIC will make a sparse allocation from a /28 address block. The difference in block size will be reserved for future allocations to the account holder. If in the event that APNIC exhausts its available IPv6 pool and is unable to secure further delegations, reserved space will be released into the free pool for further delegation to other account holders." [Context (not part of the proposal): If a member requests a /32, the Secretariat will select an available /28 block and allocate the first /32 to the account holder, reserving all other space from that /28 for the account holder's future requests. If the member in 2 year's time comes back to the Secretariat requesting another /32, the Secretariat will be able to allocate the second /32 from that reserved /28 and update delegation records to reflect that a /31 has been delegated as opposed to 2 x /32 blocks.] - 8.3.1 Existing IPv6 address resource holders Replace paragraph 1 with the following: "Resource holders that have received between a /40 and /33 IPv6 allocation are immediately entitled to have their allocation expanded to a /32 address block, without providing justification, so long as they satisfy the criteria in Section 8.2.2. "The /32 address block will contain the already allocated smaller address block (one or multiple /40 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the account holder. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in this document." - (NEW) 8.4 Size of IPv6 Allocation(s) Add a new section with the above title and the following text: "For all allocations (initial or subsequent) made under this policy, the allocation size must align with the next shortest 4-bit (nibble) boundary. For example, if an account holder submits a request for a /42 IPv6 allocation, they shall be allocated a /40 IPv6 address block without requiring additional justification." 5. Advantages / Disadvantages ----------------------------- Advantages: - This would allow members to maintain more accurate records for longer prefixes from a delegation within the Whois database. Disadvantages: - None known. 6. Impact on resource holders ----------------------------- No known impacts to resource holders. 7. References ------------- https://www.apnic.net/community/policy/resources#a_h_2_2_3 https://www.apnic.net/community/policy/resources#a_h_5_2_3_1 https://www.apnic.net/community/policy/resources#a_h_8_1 https://www.apnic.net/community/policy/resources#a_h_8_2_1 https://www.arin.net/participate/policy/nrpm/#6-5-2-1-size