I support the proposal. It's clear, and I don't think it needs to be changed. I think aligning with ARIN's practices is a good idea. I expect other RIRs will follow in the future.
-JB On Sat, 1 Aug 2026, at 04:30, Bikram Shrestha wrote: > Dear SIG members, > A new version of the proposal "prop-164: Allocations of IPv6 Resources longer > than a /32 with a nibble boundary alignment" has been sent to the Policy SIG > for review. > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-164/ > You are encouraged to express your views on the proposal: > • Do you support or oppose the proposal? > • Is there anything in the proposal that is not clear? > • What changes could be made to this proposal to make it more effective? > Please find the text of the proposal below. > Regards, > Bikram, Shaila, and Ching-Heng > APNIC Policy SIG Chairs > > --------------------------------------------------------------------------------- > > prop-164-v005: Allocations of IPv6 Resources longer than a /32 with a nibble > boundary alignment > > --------------------------------------------------------------------------------- > > Proposers: > Christopher Hawker ([email protected]) > Luke Thompson ([email protected]) > > 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 > _______________________________________________ > Go to the SIG-policy-chair mailing list on Orbit -- > https://orbit.apnic.net/mailing-list/[email protected] > Explore https://orbit.apnic.net, where the APNIC community connect, discuss > and share information related to Internet addressing and networking. > To unsubscribe send an email to [email protected] > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected] https://jon.brewer.nz/
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
