Hi Chris, This is Koki, one of the attendees at the JPOPF's meeting.
Per the proposal text, network operators with longer than a /32 cannot redelegate address space from this space to their customers. They also cannot create sub-records within Whois for assigned space apart from the parent record. This may not accurately reflect how the space is used.
I still don't fully understand why this requires changing the minimum allocation size, or how the allocation size relates to WHOIS accuracy. Under the current APNIC policy, an LIR can receive a /32 if it already holds an IPv4 allocation or can demonstrate a plan to provide IPv6 connectivity and make assignments within two years. Even if an LIR actually needs less address space than a /32, it can still receive a /32 and register re-allocations and assignments within that allocation. I think the current /32 allocation already provides a way to address the WHOIS registration issue.
Some felt that the proposal focuses only on address conservation, while overlooking other long-standing policy objectives such as aggregation and minimizing routing overhead.
It is true that the proposal does not mention conservation. However, since the issue described above can already be addressed by allocating a /32, It seems to me that the main impact of this proposal would be on address conservation.
This proposal is not a global first. ARIN's policy manual permit allocations of a /40 on request, see https://www.arin.net/participate/policy/nrpm/#6-5-2-1-size.
I don't think APNIC needs to follow ARIN's policy simply because ARIN already permits /40 allocations. What I would like to understand is why ARIN introduced this policy. Was it for the same reason as this proposal? What problem was it intended to solve, and why is the same change necessary in the APNIC region? Regards, Koki Nakagawa On 2026/08/27 9:58, Christopher Hawker wrote:
Satoru-san, Many participants felt that the proposal still does not clearly explain why the current minimum allocation size of /32 is no longer appropriate. Per the proposal text, network operators with longer than a /32 cannot redelegate address space from this space to their customers. They also cannot create sub-records within Whois for assigned space apart from the parent record. This may not accurately reflect how the space is used. Several participants questioned whether WHOIS/RDAP registration accuracy is sufficient justification for changing the IPv6 allocation policy. It is not the only reason, see above. Some felt that the proposal focuses only on address conservation, while overlooking other long-standing policy objectives such as aggregation and minimizing routing overhead. This proposal does not discuss or even mention "conservation", so it is unclear how this view/opinion is formed. The rationale for introducing nibble-boundary allocations was considered unclear. Participants requested concrete operational benefits and use cases. If a network operator requests a /45 but policy says they are to receive a /44, and they receive said /44, it makes no difference operationally to their network. This is to maintain clear and easy calculation and delegation of address space. Some participants noted that changing a long-established allocation size requires stronger justification than currently provided. This proposal is not a global first. ARIN's policy manual permit allocations of a /40 on request, see https://www.arin.net/participate/policy/nrpm/#6-5-2-1-size. As a proposal author, I would also encourage members from the JPOPF to directly share their concerns with the Policy SIG. I note that it was stated that 17 members from the Japanese community were in attendance, however, references such as "several participants questioned" and "some participants noted" are used, which makes it difficult to gauge how many members expressed these concerns and whether it is significant enough to justify making changes. Regards,Christopher Hawker _______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
