Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share key feedback from our community regarding prop-164, based on a meeting we organized on 24th Aug to discuss these proposals. Please note that this is a summary of the discussions among the 17 Japanese community members who attended the meeting. Overall, participants expressed mostly negative opinions toward this proposal. (Comment details) - Many participants felt that the proposal still does not clearly explain why the current minimum allocation size of /32 is no longer appropriate. - Several participants questioned whether WHOIS/RDAP registration accuracy is sufficient justification for changing the IPv6 allocation policy. - Some felt that the proposal focuses only on address conservation, while overlooking other long-standing policy objectives such as aggregation and minimizing routing overhead. - The rationale for introducing nibble-boundary allocations was considered unclear. Participants requested concrete operational benefits and use cases. - Some participants noted that changing a long-established allocation size requires stronger justification than currently provided. Regards, Satoru Tsurumaki Japan Open Policy Forum Steering Team 2026年8月1日(土) 2:43 Bikram Shrestha <[email protected]>: > 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] -- -- Satoru Tsurumaki BBIX, Inc
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
