Dear SIG members,

A new version of the proposal "prop-164-v005: Allocations of IPv6 Resources
longer than a /32

with a nibble boundary alignment" has been sent to the Policy SIG for
review.


It will be presented at the Open Policy Meeting (OPM) at APNIC 62 on
Thursday, 10 September 2026.


Information about earlier versions is available from:

https://www.apnic.net/community/policy/proposals/prop-164/


We invite you to review and comment on the proposal on the mailing list
before the OPM.



The comment on the mailing list before the OPM is an important part of the
Policy Development Process (PDP).

We encourage you 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?
   - Does this proposal solve a problem you are experiencing? If so, tell
   the community about your situation.



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
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]

Reply via email to