----------------------------------------------------------------------------------------------- prop-164-v006: 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 an account holder 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 reduce their allocation size to a /36 or /40, by keeping the first /36 or /40 address block and returning the balance of their allocation." - 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. "Where a suitable /28 address block is not available at the time of request, APNIC will allocate the requested block size from the largest contiguous address space available. No space will be reserved for future expansion in this circumstance. The account holder may submit a subsequent request for additional space, which will be evaluated against the IPv6 address pool available at that time. If there is no available address block that can fulfil the request, APNIC will commence releasing address reserved under this policy back into the available pool for delegation." [Context (not part of the proposal): If an account holder 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 account holder 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. "Where the space reserved alongside an existing allocation is not fully available - for example, because part of it has already been delegated to another account holder - APNIC will expand the allocation to the nearest available /32 address block that contains the account holder's existing allocation, or, where no such block is available, to the nearest available /32 address block." - (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 an account holder 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